<ac:macro ac:name="toc" />
<li>Date: 21 March 2012, 18:00-19:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2012-03-21 Meeting Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Matthew Weier O'Phinney (nickname weierophinney)</li>
<li>Next meeting: 28 March 2012</li>
<p>(Search for 18:03 in the log.)</p>
<p>Matthew (weierophinney) indicated he'd finished incorporating feedback from the mailing list and comments to the <ac:link><ri:page ri:content-title="RFC - Forms" /><ac:link-body>Forms RFC</ac:link-body></ac:link>, and wanted to determine if it was ready for development at this stage.</p>
<p>Mike Willbanks (mwillbanks) raised an objection to using the term "Model" in the form component. Matthew and Guilherme Blanco (guilhermeblanco) indicated that the usage gives symmetry with the View layer, and that forms are largely considered part of a Data Transfer Object anyways, which is one form of "model". Mike and others indicated that they feel "model" is a loaded term and could raise unintended connotations for new users. Matthew asked Mike to create a poll; the functionality remains the same, but we should ask a larger population what their preference is for naming. (Mike suggested "Object".)</p>
<p>Artur Bodera (Thinkscape) does not like that decorators are gone from the new RFC, and also lamented the lack of an easy pattern such as "$this->renderForm($form)". Matthew and Kyle Spraggs (SpiffyJr) indicated that the proposed usage of view helpers largely mimics the decorators from ZF1 without calling them such, and that it's entirely possible to create a helper that would render an entire form at once. A point was also made that we could build something mimicing the decorator system in ZF1 via view helpers (i.e., pass a list of helpers to use, and the helper would call each in turn). Artur thinks these are must-haves for a stable release. Matthew indicated he's fine with including something these items in the spec, but that he will not prioritize it for beta4.</p>
<p>Matthew raised a question about subforms (now called Fieldsets): should they be able to validate themselves? His original intent was that validation happens at the form-level only; however a number of people have indicated they'd like to build a form out of several smaller forms. After discussion, we decided that Fieldsets and Forms will be equivalent in functionality.</p>
<p>In the end, when Matthew asked if he had a green light, votes were in favor.</p>
<p><strong>tl;dr</strong>: Forms RFC is ready for development!</p>
<h3>Removing automatic translations</h3>
<p>(Search for 18:30 in the log.)</p>
<p>Ben Scholzen (DASPRiD) raised an item on the agenda regarding translations. In ZF1, and much of the current ZF2 code base, components which might benefit from i18n/l10n concerns allow injecting a Translator; in fact, if not injected, most of these will pull it from the registry, if available. This has led to hard to debug issues running the full test suite, as well as hard to debug issues when on a site with multiple locales possible. </p>
<p>However, the biggest problem is that it makes it almost impossible to use scanners such as xgettext to build up lists of strings that need translations, because there's no single pattern to look for in the code, and because many of the strings are found embedded in class properties.</p>
<p>Ben suggests we remove automatic translation from ZF2. He suggests two possiblities, neither of which is exclusive:</p>
<li>Explicit translations: <code>$label = $translator->translate('some string');</code> This has the benefit of being easily scanned for, and is completely opt-in; developers would pass in already translated strings where needed.</li>
<li>"Lazy" translation: have the translator return a functor that also implements <code>__toString()</code>: <code>$label = $translator->lazyTranslate('some string');</code> The benefit to this is that for objects that are loaded dynamically, we could still inject a translator instance; however, the strings would be still easily scanned for.</li>
<p>Some questions were raised about how this might impact error messages from form validation, particularly when using the Builder with annotations. Matthew brainstormed a little, and noted that since the Builder is consumed by a Factory, and the factory would contain things such as plugin brokers, developers could inject configured validators which would then be cloned by the broker (using the prototype pattern), thus effecting "automated" translation. This would obviously need some clear documentation samples. (Search for 18:45 in the log for the examples.)</p>
<p>In the end, we gave Ben a green light for this. The result will mean stripping translation from most ZF components.</p>
<p><strong>tl;dr</strong>: Explicit translations should make for better tooling, looser coupling, and likely more performant code.</p>
<ac:macro ac:name="html"><ac:parameter ac:name="output">html</ac:parameter><ac:plain-text-body><![CDATA[
white-space: -moz-pre-wrap; /* Mozilla, supported since 1999 */
white-space: -pre-wrap; /* Opera 4 - 6 */
white-space: -o-pre-wrap; /* Opera 7 */
white-space: pre-wrap; /* CSS3 - Text module (Candidate Recommendation) http://www.w3.org/TR/css3-text/#white-space */
word-wrap: break-word; /* IE 5.5+ */
border: 1px solid darkgray;
18:02 <weierophinney> let's get started!
18:02 <weierophinney> Reminder, agenda is here: http://bit.ly/GEd68x
18:03 <weierophinney> First topic: Forms
18:03 <weierophinney> RFC for forms is here: http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms
18:03 <weierophinney> If you haven't read through it yet... start.
18:04 <Thinkscape> weierophinney: what changed since 4 weeks ago ?
18:04 <weierophinney> I've incorporated a bunch of changes from the ML and comments, and I think it's up-to-date at this point... unless anybody in here has additions.
18:04 <mwillbanks> weierophinney: I'm not a fan of the "bindModel" method; i would really like to see it more of a "bindObject" because that is more or less what it is
18:04 <weierophinney> Thinkscape: I've clarified the section on the Builder, based on discussions with SpiffyJr and guilhermeblanco, and added some interfaces.
18:05 <DASPRiD> Thinkscape, http://framework.zend.com/wiki/pages/viewpreviousversions.action?pageId=46793010
18:05 <mwillbanks> i guess the thing about it, is that it started to state that ZF should care about what a "model is" and what a "model is not"
18:05 <weierophinney> mwillbanks: I had that argument with guilhermeblanco yesterday
18:05 <SpiffyJr> It's a model because it helps define the form, so in this context, I think model is accurate.
18:05 <SpiffyJr> Object is equally accurate - I have no preference.
18:05 <weierophinney> mwillbanks: I'm leaning towards using the term "Model" simply because it (a) implies an object, and (b) has a nice symmetry with Zend\View at this point.
18:06 <DASPRiD> SpiffyJr, stdclass ;P
18:06 <Freeaqingme> but some people consider their mappers to be a model, others consider entities their 'model'. Doesnt make it easier to explain..
18:06 <Freeaqingme> weierophinney, true
18:06 <weierophinney> mwillbanks: als, guilherme talked about forms being essentially data transfer objects, and thus "model" specific anyways.
18:06 <Thinkscape> weierophinney: does " @Assert\EmailAddress" really mean "@Filter" ?
18:06 <DASPRiD> Freeaqingme, they have to learn that they are wrong
18:06 <mwillbanks> weierophinney: but only in some cases
18:06 <SpiffyJr> assert = validate
18:06 <Thinkscape> I don't use mappers.
18:06 <weierophinney> Thinkscape: yes – that's from guilherme, and is a Doctrine annotation. We'd use different annotations.
18:06 <SpiffyJr> Thinkscape, you're asserting that the field is an email address
18:06 <Thinkscape> SpiffyJr: but then you have @filter
18:06 <SpiffyJr> assert = validate, filter = filter
18:07 <Thinkscape> why not @validate ?
18:07 <Thinkscape> because = Zend\Validate
18:07 <SpiffyJr> I just like the word more
18:07 <SpiffyJr> Validate makes more sense for zf2
18:07 <DASPRiD> Thinkscape, Zend\Validator
18:07 <weierophinney> Thinkscape: we'd use the annotations work in Zend\Code, which, IIRC, uses class names.
18:07 <SpiffyJr> But, the glory of annotations, is that they're namespace based
18:07 <SpiffyJr> So you can use whatever you want
18:07 <SpiffyJr> I'll probably use assert but validate by default is probably best
18:07 <weierophinney> SpiffyJr: +1 there
18:07 <EvanDotPro> +1
18:08 <weierophinney> mwillbanks: when is a form not a DTO?
18:08 <Freeaqingme> If we'd be going for annotations, I think there should be an option to still set validators etc programmatically. allows for easier extension
18:08 <weierophinney> mwillbanks: I was trying to come up with examples yesterday, but couldn't think of any.
18:08 <SpiffyJr> Freeaqingme, +1 - a must have, imo
18:08 <weierophinney> Freeaqingme: there will be
18:09 <weierophinney> Freeaqingme: the annotations would build on top of programmatic usage, and simply provide a convenience factor.
18:09 <Freeaqingme> that'd be great
18:09 <SpiffyJr> (a damn sexy convenience feature)
18:09 <EvanDotPro> Freeaqingme: absolutely.. i would imagine that's how the annotations would work anyway
18:09 <guilhermeblan> \o/
18:09 <Thinkscape> the rendering part still sucks to me. My argument being: decorators were pain, but once set up (and then elements/forms subclassed) i just worried about data/modelling/fields and not rendering. $form->render() was a bliss. In all other cases I used plain vanila HTML.
18:09 <weierophinney> Freeaqingme: also, note that there's an item to take forms built via the builder and cache them as full objects, which would, of course, utilize the programmatic support.
18:10 <SpiffyJr> Thinkscape, there's nothing wrong with creating your own view helper which, is essentially, a decorator.
18:10 <Thinkscape> Now, there's "something" – there's a lot work to create i.e. a wrapper... I won't use it - just write HTML
18:10 <Thinkscape> but I don't get the option to have full-form-rendering.
18:10 <SpiffyJr> Yes you do, write a view helper for it.
18:10 <SpiffyJr> Or, we should include one by default
18:10 <weierophinney> Thinkscape: you can basically do decorators via view helpers.
18:10 <SpiffyJr> View helpers === decorators
18:10 <Thinkscape> I know I can
18:10 <weierophinney> SpiffyJr: exactly
18:10 <Thinkscape> I can also write my own Form component. not an argument
18:10 <DASPRiD> Thinkscape, i already brought up that point me thinks
18:10 <Thinkscape> I'm talking about what I get out of the box from zf2
18:10 <DASPRiD> so you can do echo $this->renderForm($form);
18:10 <SpiffyJr> weierophinney, Thinkscape +1 for including a default view helper to render an entire form?
18:11 <jurians> DASPRiD: +1
18:11 <weierophinney> Thinkscape: I think we can manage to do similar support via the view helpers.
18:11 <weierophinney> I don't want to prioritize it for beta4, though. There's a lot of work without going into a separate decorator system right now.
18:11 * Freeaqingme writes down to have those reviewed by a senior frontender (am getting comments regularly on zend_form 1 default decorators..)
18:11 <DASPRiD> weierophinney, oh, by the way, html5doctor and other sources say that dl/dt/dd is semantically not suited for forms
18:11 <Thinkscape> ok, but now we do still have a miriad of those "partial" view helpers... they are useless in my opinion. Too little flexible to use.
18:11 <weierophinney> Once we get the basics in place, if somebody wants to write that part, I'm for it.
18:12 <Thinkscape> The only thing I get is ..... i can shuffle them :\
18:12 <weierophinney> Thinkscape: they're no different than the decorator system is now, really
18:12 <weierophinney> Thinkscape: all the decorators do in most cases is delegate to view helpers anyways.
18:12 <mwillbanks> weierophinney: i guess in the foundations of forms it is a DTO; however, there may be instances where you only want it on the front-end and not on the back-end... meaning the DTO on the PHP side may not make sense; but binding them specifically to models IMO is not good or even the suggestion of which, since not all of the data from forms is to be utilized and in that case I believe it makes sense to state bindDto instead of bindModel
18:12 <Thinkscape> weierophinney: agreed.
18:12 <Thinkscape> weierophinney: we might come up with something better though.
18:12 <mwillbanks> uggg frontend/backend part sounded dirty
18:13 <guilhermeblan> mwillbanks: the DTO is still a model for a form
18:13 <weierophinney> mwillbanks: let's do a poll, then – tbh, I know what it will do; the naming is simply for end users as far as I'm concerned.
18:13 <guilhermeblan> which can be a VO, an Entity, or a Zend_Db entity
18:13 <weierophinney> guilhermeblanco: or maybe none of those.
18:14 <Freeaqingme> VO?
18:14 <guilhermeblan> ValueObject
18:14 <wilmoore> But isn't Model binding optional anyhow?
18:14 <guilhermeblan> weierophinney: for rendering one... ya... you can be not using the DTP
18:14 <matuszemi> what happens in case I want to bind a form values into "multi-object"?
18:14 <Freeaqingme> I would go for entity since VO/entity/dto means all the same more or less, but I'm thinking entity is most commonly known/used
18:14 <weierophinney> wilmoore: yes – but mwillbanks is suggesting we don't use the verbiage "Model" and instead "Object"
18:14 <Thinkscape> weierophinney: so basically the builder works by scanning annotations - regardles of what the class really is ? (mapper, vo, stdclass or whatever) ?
18:14 <DASPRiD> if i understand it correctly, model is juwst for validation
18:15 <DASPRiD> if you dont need the form on the backend, you dont need a model
18:15 <guilhermeblan> matuszemi: you map a master DTO and then you transfer the validate fields from the master form into the desired object
18:15 <DASPRiD> right?
18:15 <Freeaqingme> matuszemi, define 'multi-object'?
18:15 <guilhermeblan> if it's an hierarchy, you can add subforms
18:15 <weierophinney> Thinkscape: it can use annotations. Your definition will determine if it does, and can even override annotations if present.
18:15 <wilmoore> mwillbanks: Model seems fine IMHO
18:15 <Freeaqingme> weierophinney, just checking, would there be any differences with subforms?
18:15 <Freeaqingme> as to now?
18:16 <Evil_Otto> wait, are we talking about creating forms via annotations in the models? (excuse my ignorance)
18:16 <DASPRiD> Evil_Otto, hah
18:16 <weierophinney> Freeaqingme: for the RFC right now, the main differences are: s/SubForm/Fieldset/, and not sure yet if they'd include validation, or if validation is at the form level only.
18:16 <mwillbanks> guilhermeblanco: wilmoore: the big thing that bugs me about the naming is what it suggests in what people "view" models as... it really is a value object and sure you might pass it directly to entities but note that i am saying "entities" not "entity", so in that case it is a ValueObject aka DataTransferObject much like anything else
18:16 <weierophinney> Evil_Otto: as an option yes – but you could also do everything programmatically or via a vanilla factory.
18:17 <SpiffyJr> weierophinney, ping me if you need input I'm in crunch time at work
18:17 <SpiffyJr> weierophinney, if not I'll read the log later
18:17 <guilhermeblan> mwillbanks: you always pass a DTO... I just added compatibility with the current ZF2 ViewModel
18:17 <weierophinney> SpiffyJr: cool, thx!
18:17 <Evil_Otto> so in theory i could make a change to my model and it would add the element to the form automagically when i go to grab the form next time?
18:17 <weierophinney> Evil_Otto: yes.
18:17 <Thinkscape> weierophinney: ok, just wanted to make sure it does not bind to specific "data management pattern". i.e. I usually don't use mappers and don't use vo too often. I want it to be able to digest any object and work with "definition" to build the form.
18:17 <Evil_Otto> Oh I'm going to use the hell out of that.
18:17 <weierophinney> Thinkscape: it doesn't.
18:17 <DASPRiD> Evil_Otto, hehe
18:17 <wilmoore> mwillbanks: I see your point, though I still think Model works fine and forces people to really think about how they are naming things. That said, the path of least resistance seems like going with Object would be fine.
18:18 <wilmoore> mwillbanks: kind of a win-win situation
18:18 <weierophinney> wilmoore: I'm fine with a poll, too.
18:18 <Thinkscape> weierophinney: I'd avoid using "model" though, as it's also a pattern. Builder working with "objects" might be a better wording (while giving a few examples of objects people normally will use)
18:18 <guilhermeblan> mwillbanks: also... Object or DTO is a non-specialized terminology... Model is a specialization of a DTO
18:18 <wilmoore> weierophinney: a good poll never hurt anybody
18:18 <guilhermeblan> weierophinney: poll +0
18:19 <DASPRiD> ValueObject still sounds good to me as well
18:19 <mwillbanks> guilhermeblanco: depending on the pattern :|
18:19 <weierophinney> guilhermeblanco: I think that's understood – I think what mwillbanks is getting at is he feels the terminology is too specialized.
18:19 <DASPRiD> or TheThingWillValidatorsAndFiltersAttachedToIt
18:19 <weierophinney> DASPRiD: too verbose
18:19 <DASPRiD> weierophinney,
18:19 <weierophinney> both of them.
18:19 <Thinkscape> weierophinney: ^^
18:19 <mwillbanks> DASPRiD: i liked that one
18:19 <SpiffyJr> subforms = fieldsets now?
18:19 <SpiffyJr> iirc
18:19 <weierophinney> SpiffyJr: yes
18:19 <DASPRiD> weierophinney, i thought we like it verbose
18:20 <wilmoore> DASPRiD: your naming just grew on me
18:20 <mwillbanks> DASPRiD: twss
18:20 <weierophinney> SpiffyJr: do you think subforms/fieldsets should be able to validate by themselves? or leave that to the form composing them?
18:20 <DASPRiD> wilmoore, hehe
18:20 <weierophinney> keep it clean, folks
18:20 <weierophinney> Any other questions/concerns/feedback for the forms RFC?
18:21 <Thinkscape> subforms: If we used builder with nested/recursive structures (like object having object) then subforms should also be forms - be build with a (separate) definition.
18:21 <DASPRiD> on a sidenote: can we divide the RFC group into open/done or something? it gets really confusing to see what's still active there
18:21 <weierophinney> My big question is: do I have a green light to proceed at this point?
18:21 <DASPRiD> +1
18:21 <weierophinney> DASPRiD: yes, we need to do so. Since you asked the question, I volunteer you for that task.
18:21 <weierophinney> Thinkscape: good point.
18:21 <DASPRiD> as if i knew what's still open there
18:22 <weierophinney> Thinkscape: the way I've conceived it currently is that a form is a fieldset with validation – we could simply merge the concepts.
18:22 <guilhermeblan> weierophinney: sorry... I gtg
18:22 <weierophinney> laters, guilhermeblanco – thanks for the help with the RFC!
18:22 <Thinkscape> also: we have FooDefinition and BarDefinition .... if foo object contains bar, bar form is built with BarDefinition.
18:22 <Thinkscape> fieldset vs form ---it's just rendering
18:22 <Thinkscape> structurally, it could be form in a form.
18:22 <Freeaqingme> +1 Thinkscape
18:22 <Thinkscape> Also - and the validateRecursively()
18:23 <Thinkscape> filterRecursively() etc.
18:23 <weierophinney> Thinkscape: well, it's also a matter of validation. Right now, it's simpler if there's only one input filter, but we could compose multiple ones as well.
18:23 <weierophinney> using recursion, yes.
18:23 * weierophinn is getting a headache... he's gone down that road before...
18:23 <Thinkscape> weierophinney: wait ... BarDefinition with object bar has different validators than foo
18:23 <Thinkscape> can't mix those... or you'll be in trouble.
18:23 <Thinkscape> foo contains bar ... $foo->bar instanceof bar
18:23 <mwillbanks> weierophinney: that part scares me
18:24 <weierophinney> Thinkscape: STOP! YOU'RE MAKING IT TOO COMPLEX!
18:24 <mwillbanks> weierophinney: seem to remember a translate bug deep in the process in zf1
18:24 <Thinkscape> I won't comment on my headache when going through Zend\View last weekend
18:24 <weierophinney> mwillbanks: that's the next topic
18:24 <mwillbanks> weierophinney: strategery
18:24 <weierophinney> Any other questions/concerns/feedback for the forms RFC? Ready/not-ready?
18:24 <matuszemi> tbh.. if we keep current subform functionality and getValues() returns array of arrays of arrays of... (super useful when developing module extensions) I'm up for anything
18:25 <weierophinney> Thinkscape: yep, need to get back to you on that.
18:25 <weierophinney> matuszemi: fieldsets are meant to have nested structures, so should be no problem.
18:25 <SpiffyJr> did my internet die?
18:25 <SpiffyJr> no comments for 4 minutes...
18:25 <mwillbanks> Thinkscape: i think my team has a good solid solution for DM and entities for that type of stuff; let me check into it
18:25 <Freeaqingme> weierophinney, ready here. With the one note that we shouldnt hack on subforms to it later
18:25 <weierophinney> Freeaqingme: it's part of the design.
18:25 <DASPRiD> mwillbanks, DM? DarkMatter?
18:26 <mwillbanks> DASPRiD: muhahaha
18:26 <Freeaqingme> weierophinney, ready
18:26 <mwillbanks> mwillbanks: data mapper
18:26 <weierophinney> SpiffyJr: yes. Been busy in here.
18:26 <DASPRiD> mwillbanks, ah… why are you talking to yourself?
18:27 <weierophinney> Green light/red light, folks? It sounds like "yes", but I want to be sure.
18:27 <matuszemi> weierophinney: so we do not nest forms? but form can have elements and element sets?
18:27 <Spabby> green
18:27 <mwillbanks> weierophinney: go
18:27 * DASPRiD looks for the green lightbulb
18:27 <DASPRiD> /set background-color #00ff00
18:27 <DASPRiD> kay, you got green light
18:27 <mwillbanks> DASPRiD: http://www.earthlyenergy.eu/sandfire-documents/green-lightbulb.jpg
18:27 <DASPRiD> mwillbanks,
18:28 <SpiffyJr> holy scroll
18:28 <DASPRiD> mwillbanks, very nice graphic actually
18:28 <DASPRiD> mwillbanks, except for the bottom…
18:28 <DASPRiD> mwillbanks, badly colored there, should have been excluded
18:28 <weierophinney> matuszemi: fieldsets can be nested; also, sounds like I'll treate fieldsets and forms as equals.
18:28 <SpiffyJr> weierophinney, validate themselves
18:28 <mwillbanks> DASPRiD: well; compliments of google image search
18:28 <SpiffyJr> weierophinney, it's possible you could have a "subform" that's only a subform part of the time
18:28 <SpiffyJr> but also a fully functioning form on its own
18:29 * DASPRiD just noticed that he wrote a micro-RFC in the agenda
18:29 <weierophinney> SpiffyJr: yep, that's the request/discussion in here.
18:29 <SpiffyJr> weierophinney, i had about 100 lines of scroll
18:29 <Thinkscape> SpiffyJr: it will be, actually.
18:29 <mwillbanks> DASPRiD: you're just realizing that?
18:29 <weierophinney> So... I'll take this as a provisional "yes" vote at this time, and get started.
18:29 <SpiffyJr> weierophinney, borrowing internet from the neighbor until my new router arrives?
18:29 <DASPRiD> mwillbanks, heh yeah
18:29 <DASPRiD> mwillbanks, i wrote it at work while doing other stuff
18:29 <matuszemi> weierophinney: cool.. again.. if I can do $mainform->addSubfom($subform) I'm cool..
18:29 <weierophinney> Next topic: DASPRiD wants to talk about translations.
18:29 <DASPRiD> \o/
18:30 <weierophinney> matuszemi: $mainform->add($fieldset) – even easier.
18:30 <weierophinney> DASPRiD: you have the floor.
18:30 <mwillbanks> DASPRiD: +1
18:30 <DASPRiD> okay so i hope most people here have read the micro RFC in the agenda
18:30 <mickaelCOLLET> +1
18:30 <DASPRiD> the problem many people had with zf1 is the automagical translation feature
18:30 <DASPRiD> because scanners like xgettext simply cannot extract message ids from configs
18:30 <DASPRiD> except if you write some dirty hacks (i did that a lot)
18:31 <DASPRiD> the idea is to make translations in forms, navigation and so on explicit
18:31 <matuszemi> weierophinney: what happens if you want to reuse subform separatelly? anyway.. let's discuss this later on zftalk.2
18:31 <DASPRiD> just like the path we followed with zf2 the entire time so far
18:31 <DASPRiD> performance wise it shouldn't matter a lot, especially thanks to the new lazy loading of text domains
18:31 <DASPRiD> that plus Bittarman's suggestion of lazy translations
18:32 <DASPRiD> plus the new caching strategy
18:32 <matuszemi> +1 for explicit translations.. I've had same problem.
18:32 <DASPRiD> so, there are two examples in the agenda demonstrating what i suggest
18:32 <DASPRiD> are there any thoughts about/against that?
18:33 <mwillbanks> DASPRiD: green light
18:33 <wilmoore> DASPRiD: +1
18:33 <DASPRiD> weierophinney, since you are doing forms, any concerns there?
18:33 <Gabriel403> I'm pro it
18:33 <weierophinney> DASPRiD: the only thing I see there I'm not sure of is that if you're extending Form to create a custom one, you'd need to inject a translator, so that as you build elements, you have it available.
18:33 <weierophinney> DASPRiD: correct?
18:34 <weierophinney> but that also means we don't have to have direct integration with Translator by default
18:34 <weierophinney> which I like – makes my job easier.
18:34 <DASPRiD> weierophinney, heh
18:34 <DASPRiD> weierophinney, that's the idea behind it
18:34 <DASPRiD> it also removes coupling of i18n from forms, navigation and so on
18:35 <DASPRiD> and well, how the user gets the translator into it when extending is up to him, tho we could supply examples/best practices
18:35 <SpiffyJr> +1 for explicit translations (back to work)
18:35 <matuszemi> ^^ yep..
18:35 <Freeaqingme> +1
18:35 <DASPRiD> who was working on zend\navigation again?
18:35 <SpiffyJr> <--
18:35 <DASPRiD> SpiffyJr, ah great, then you can refactor translator out of it
18:35 <SpiffyJr> ah hell
18:36 <SpiffyJr> did i say me?
18:36 <SpiffyJr> i meant, uh, yah.
18:36 <matuszemi> SpiffyJr: when is it gonna be finished?
18:36 <Gabriel403> wouldn't you translate before you get to the form? so the form only has the text it needs?
18:36 <weierophinney> DASPRiD: I'm +1, then. auto-translation and deep integration of translation in the various components has been a testing nightmare.
18:36 <DASPRiD> weierophinney, question is, what about validators?
18:36 <DASPRiD> weierophinney, i know…
18:36 <DASPRiD> Gabriel403, see ->lazyTranslate() in the agenda example
18:36 <SpiffyJr> matuszemi, uh, soon'ish?
18:36 <SpiffyJr> matuszemi, work just got busy
18:36 <weierophinney> DASPRiD: you can already inject the message strings to use.
18:36 <matuszemi> hours/days?
18:37 <SpiffyJr> i'm not doing much with navigation, or wasn't...
18:37 <DASPRiD> weierophinney, ah, so you could just insert lazy translation callbacks there as well
18:37 <weierophinney> DASPRiD: I'd argue we leverage that, and have good examples of how to do it.
18:37 <SpiffyJr> matuszemi, all I had left was tests and community input
18:37 <weierophinney> DASPRiD: yes
18:37 <DASPRiD> weierophinney, sounds good!
18:37 <SpiffyJr> matuszemi, but if i'm moving translation out maybe a bit more?
18:37 <Gabriel403> DASPRiD: weierophinney that's was what i was meaning
18:37 <matuszemi> cool.. nice. so it's available from zf2/master?
18:37 <SpiffyJr> no
18:37 <SpiffyJr> itll be on my branch
18:37 <DASPRiD> Thinkscape, as the usual no-sayer: got any concerns?
18:37 <weierophinney> Gabriel403: it looks like we could accommodate it by either the lazyTranslation or by injecting message strings.
18:38 <DASPRiD> weierophinney, injecting message strings?
18:38 <weierophinney> DASPRiD: each validator allows you to specify the various error message strings already
18:38 <DASPRiD> yup
18:38 <weierophinney> they just provide defaults.
18:38 <DASPRiD> indeed
18:38 <DASPRiD> (very user-unfriendly ones)
18:38 <weierophinney> so, we either document how to inject them, or we use lazyTranslation.
18:39 <weierophinney> either way, should simplify things.
18:39 <DASPRiD> weierophinney, well, the user uses lazy translations by injecting those
18:39 <weierophinney> ah, well then.
18:39 <DASPRiD> we juwst have to document it well
18:39 <weierophinney> yep
18:39 <Thinkscape> DASPRiD: i'm flattered. Just do it the best way I stopped caring.
18:39 <Gabriel403> weierophinney: if you use notations for adding validation would that mean you'd use di for injecting the messages?
18:40 <DASPRiD> Thinkscape, heh okay
18:40 <weierophinney> Gabriel403: good question.
18:40 <DASPRiD> good point indeed
18:40 <weierophinney> DASPRiD: thoughts on Gabriel403's concerns?
18:40 <weierophinney> actually...
18:40 <DASPRiD> actually?
18:40 <wilmoore> Thinkscape: burn out?
18:40 <weierophinney> Gabriel403: the builder is consumed by the factory
18:41 <Thinkscape> wilmoore: having such label stuck on forehead... no thank you
18:41 <weierophinney> Gabriel403: I'd expect we could provide either default configuration or default objects (prototype pattern) to make that happen.
18:41 <wilmoore> Thinkscape:
18:41 <wilmoore> Thinkscape: It's done all in love.
18:41 <DASPRiD> weierophinney, but yeah, annotations and explicit translations don't go well together
18:42 <DASPRiD> Thinkscape, yeah, we all like you
18:42 <weierophinney> DASPRiD: you have to configure the builder anyways, so I'd expect you'd know the various validators you might use in your application
18:42 <DASPRiD> weierophinney, mhhh, i'm not too much into that builder yet
18:42 <mwillbanks> wait.... are we talking about translate or are we talking about forms again?
18:42 <DASPRiD> mwillbanks, both right now
18:43 <DASPRiD> mwillbanks, translator + annotations with labels and validation messages
18:43 <mwillbanks> alright; i gotta sit that one out... too much magic for me
18:43 <DASPRiD> mwillbanks, yeah, annotations are also not my area
18:44 <weierophinney> mwillbanks: I actually think we can make it explicit and automatic at the same time here.
18:44 <Gabriel403> I would have thought anotations use default message, adding validation programmatically would expose functionality to check them?
18:44 <Gabriel403> to alter them*
18:44 <weierophinney> Gabriel403: see above – annotations will match to a validator, which means if we have a prototype or configuration for it already, we can provide the translations.
18:45 <DASPRiD> weierophinney, could you come up with an example?
18:45 <Gabriel403> What DASPRiD said
18:45 <weierophinney> DASPRiD: Factory will likely use the PluginSpecBroker. That allows us to pass in things like "string_length" => array('messages' => array(...))
18:46 <mwillbanks> weierophinney: yes; i will use the explicit; just that annotations don't make me too happy... i understand people like them but it just seems like another one of those lets allow people to do the same thing 3 different ways
18:46 <weierophinney> so, when we have an annotation that maches that validator, it loads from the plugin broker, which gives us a configured object.
18:46 <Evil_Otto> mwillbanks: you must be new here.
18:46 <mwillbanks> weierophinney: not saying its a bad thing; i just enforce non-usage in code reviews for my team
18:46 <DASPRiD> weierophinney, interesting
18:46 <weierophinney> mwillbanks: they're opt-in only anyways.
18:46 <DASPRiD> weierophinney, what if you have the validator with the same name applied to two different fields, and want two different error messageS?
18:47 <mwillbanks> Evil_Otto: haha; you're always waiting for that punch line
18:47 <DASPRiD> (just had that in a current projecT)
18:47 <weierophinney> DASPRiD: you map different names for the validators, but have them resolve to the same class.
18:47 <Gabriel403> dinner time, will read back in a bit
18:47 <DASPRiD> weierophinney, ah!
18:47 <DASPRiD> weierophinney, however that works with your annotations then
18:47 <weierophinney> since we use a class-map by default with the plugin loaders, this is trivial now.
18:47 <weierophinney> DASPRiD: yep.
18:47 <DASPRiD> okay, this sounds all good to me
18:48 <weierophinney> DASPRiD: annotation can map to a short name – which the broker can then map to a class
18:48 <weierophinney> any other questions/concerns/feedback for DASPRiD and his translation ideas?
18:48 <weierophinney> green light/red light?
18:49 <matuszemi> green
18:49 <Thinkscape> pink
18:49 <wilmoore> green
18:49 * DASPRiD stabs Thinkscape
18:49 <DASPRiD> Thinkscape, your nickname is actually pruple here
18:50 <weierophinney> Thinkscape: reservations? I'd like to hear them, if you have them.
18:51 <Thinkscape> nah. Anything left on agenda ?
18:51 <mwillbanks> GREEN!
18:51 <gammamatrix> i have a question about a pull request i did:
18:51 <gammamatrix> http://framework.zend.com/issues/browse/ZF2-226
18:51 <DASPRiD> gammamatrix, wrong channel for that (me thinks)
18:51 <gammamatrix> i brought this up last week
18:51 <gammamatrix> in this meeting
18:52 <DASPRiD> oh, nevermind then
18:52 <DASPRiD> i wasn't there
18:52 <gammamatrix> but you are probably right
18:52 <DASPRiD> weierophinney, so, i guess that's a 100% green then
18:52 <DASPRiD> i'd say we are done
18:52 * DASPRiD cleans the floor
18:53 <SocalNick> general request about irc meetings: could whoever is in charge of scheduling meetings send a iCal message to the mailing list so we can add to Google Calendar, or other calendar software?
18:53 <weierophinney> gammamatrix: what's the question?
18:53 <weierophinney> SocalNick: noted.
18:53 <DASPRiD> SocalNick, every week, same time
18:53 <gammamatrix> what is the next step with the pull request?
18:53 <weierophinney> gammamatrix: myself, my team, or CR team needs to review and merge.
18:53 <SocalNick> thx
18:53 <weierophinney> We're a little behind right now.
18:53 <gammamatrix> ok, do i need to mark it as anything?
18:53 <gammamatrix> i am not in a hurry
18:53 <weierophinney> (Akrabat, myself, and a few others are finishing up 1.12.0 related code)
18:54 <weierophinney> gammamatrix: nope, you're all set.
18:54 <gammamatrix> thanks!
18:54 <DASPRiD> gammamatrix, when you open a pull request, it is ready to merge
18:54 <DASPRiD> (if it is not, then close it again )
18:54 <weierophinney> okay, I'm calling the meeting over at this point!
18:54 <DASPRiD> kay
18:54 <weierophinney> thanks everyone for the feedback!