<ac:macro ac:name="toc" />
<li>Date: 22 February 2012, 18:00-19:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2012-02-22 Meeting Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Matthew Weier O'Phinney (nickname weierophinney)</li>
<li>Next meeting: 29 February 2012</li>
<p>(Search for "18:02:08" in the log.)</p>
<p>Discussion centered around completeness of the <ac:link><ri:page ri:content-title="RFC - i18n layer" /><ac:link-body>i18n/l10n RFC</ac:link-body></ac:link>.</p>
<p>The primary issues raised:</p>
<li>The RFC should clearly note how currency and measurement localisation will be handled.</li>
<li>The RFC should note how classes/components dependent on i18n/l10n will be updated; in particular, routing, filters, and view helpers were raised as examples. Several noted that for items like routing, the base routes available should not require i18n/l10n, but that these capabilities should be done either via decoration or extension.</li>
<li>A debate arose regarding whether or not i18n/l10n-specific filters, view helpers, and routes should be kept inside the i18n/l10n namespace in order to reduce dependencies in those components (i.e., Zend\Filter would not have a dependency on i18n/l10n). There are good arguments on either side, and we decided to push this to the mailing list.</li>
<li>We need a namespace for the i18n/l10n components.</li>
<p><strong>tl;dr</strong>: The RFC is an excellent start, but a few details need to be addressed still.</p>
<p>(Search for "18:28:41" in the log.)</p>
<p>Matthew posted the <ac:link><ri:page ri:content-title="RFC - Forms" /><ac:link-body>Forms RFC</ac:link-body></ac:link>, and we had initial discussion<br />
and feedback during the meeting.</p>
<li>Additional use case illustrations were requested:
<li>Use case around forms in MVC</li>
<li>Use case about partial validation</li>
<li>Use case of PRG</li>
<li>Artur Bodera (Thinkscape) suggested a more "template"-driven way of rendering, a hybrid of sprintf with named segments, which could reduce number of view helpers required, and make rendering fairly flexible.</li>
<li>isValid() should not alter form/element state (value should be bound). This was intended in the RFC, but needs to be made explicit.</li>
<li>A number of people either like the ZF1-style decorators or the simplicity of "echo $form". The question is whether we may be able to build a solution that makes that possible on top of the proposed architecture. Matthew will take this under consideration.</li>
<li>Rob Allen (Akrabat) asked if the intention is for the validation/normalization chain to replace Zend\Filter\Input; Matthew answered in the affirmative, and will update the RFC accordingly.</li>
<p><strong>tl;dr</strong>: A lot of enthusiasm and ideas flying; the RFC has a little ways to go before it captures the various requirements.</p>
<h3>Beta 3 Readiness</h3>
<p>(Search for "18:48:25" in the log.)</p>
<p>Matthew reported that progress is good for shipping beta3 next week. The open<br />
<li>View layer (merged by Rob Allen just prior to the meeting)</li>
<li>DB abstraction layer (Ralph Schindler is almost ready to issue a PR for this)</li>
<li>Configuration refactoring (Ben Scholzen (DASPRiD) is reviewing the last set of changes submitted by Enrico Zimuel (ezimuel); Evan Coury (EvanDotPro) will prepare the Reader factory once merged)</li>
<li>A modest pull request queue</li>
<li>Documentation for new/refactored components.</li>
<p>During the meeting, we agreed:</p>
<li>Code Freeze for beta3 will happen Monday morning, CST.</li>
<li>Rob Allen will attempt to use the new DB layer with his tutorial application, and Evan Coury will attempt to integrate it in the ZfcUser module, as "real world" tests and review of the DB layer.</li>
<li>Everyone will attempt to get documentation in no later than end-of-day on Monday.</li>
<p><strong>tl;dr</strong>: It's a bit tight, but the new features look fairly solid for purposes of the beta, and just need a bit of user testing and polish.</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;
Feb 22 18:00:28 <weierophinney> Let's begin!
Feb 22 18:00:36 <weierophinney> Once again, I forgot to solicit a moderator.
Feb 22 18:00:46 <weierophinney> Which means I'm it.
Feb 22 18:00:58 <DASPRiD> heh
Feb 22 18:01:03 <weierophinney> Reminder: agenda is here: http://bit.ly/x6rG6w
Feb 22 18:01:32 <weierophinney> First topic: i18n RFC
Feb 22 18:01:39 <weierophinney> DASPRiD, want to begin?
Feb 22 18:01:55 <DASPRiD> weierophinney, actually i'm half-away right now
Feb 22 18:02:03 <DASPRiD> maybe swap order
Feb 22 18:02:08 <weierophinney> RFC is here: http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+i18n+layer
Feb 22 18:02:35 <weierophinney> DASPRiD, main point is to discuss the RFC – do people feel it's complete? if not, what isn't addressed? etc.
Feb 22 18:02:45 <weierophinney> bueller
Feb 22 18:02:47 <weierophinney> bueller
Feb 22 18:02:54 <weierophinney> (quiet bunch here)
Feb 22 18:03:07 <DASPRiD> question is, is anyone actually "here"
Feb 22 18:03:10 <DASPRiD> feels kinda silent
Feb 22 18:03:10 »» ocramius taking a look again
Feb 22 18:03:14 <kobsu> o/
Feb 22 18:03:17 »» ralphschindler is here
Feb 22 18:03:20 <MikeA_>
Feb 22 18:03:22 <DASPRiD> ah yeah, there we go
Feb 22 18:03:34 »» EvanDotPro is lurking
Feb 22 18:03:38 <DASPRiD> so, to give a quick brief about the RFC again:
Feb 22 18:03:47 <ocramius> are there any other locale-aware components not includedin the RFC?
Feb 22 18:04:01 <DASPRiD> ocramius, well, the router
Feb 22 18:04:09 <weierophinney> ocramius, only ones I'm aware of are Router, Currency, and Measure.
Feb 22 18:04:11 <tom_anderson> Validator\Float
Feb 22 18:04:24 <DASPRiD> it's mainly about getting rid of the current i18n core in ZF and using the Intl extension shipped with PHP
Feb 22 18:04:44 <DASPRiD> weierophinney, yeah, measure only very briefly for formatting the numbers
Feb 22 18:04:55 <ralphschindler> Zend\Form by extension of validator/filter is locale aware
Feb 22 18:04:55 <weierophinney> tom_anderson, I think that's covered with the NumberFormatter, as it can parse numbers
Feb 22 18:05:03 <DASPRiD> weierophinney, indeed
Feb 22 18:05:17 <weierophinney> DASPRiD, that may also cover currency, iirc
Feb 22 18:05:21 <ocramius> DASPRiD: so should the router implement that idea of "LocaleAware" DASPRiD?
Feb 22 18:05:46 <DASPRiD> ocramius, translatable segments will be integrated into the segment route
Feb 22 18:05:50 <ocramius> (I'm repeating myself)
Feb 22 18:05:51 <DASPRiD> (this is partly already done)
Feb 22 18:05:55 <DASPRiD> weierophinney, it does
Feb 22 18:06:04 <weierophinney> ralphschindler, actually, form also has traditionally allowed "translation" of labels. But if that's done in the view layer, it may be a moot point.
Feb 22 18:06:04 <DASPRiD> both parsing and formatting
Feb 22 18:06:27 <ocramius> okay
Feb 22 18:06:34 <ocramius> well, then it's fine for me...
Feb 22 18:06:57 <DASPRiD> about the availability of the PHP Intl extension:
Feb 22 18:07:10 <DASPRiD> It is actually in the core, but depending on the distribution, it has to be enabled
Feb 22 18:07:19 <DASPRiD> Also, for compiling from source, it requries the ICU headers
Feb 22 18:07:28 <DASPRiD> else it is silently disabled
Feb 22 18:07:51 <weierophinney> I can verify that it's not enabled by default when compiling from source, actually, which is a bit of a PITA.
Feb 22 18:08:15 <DASPRiD> weierophinney, so you have to pass --enable-intl ?
Feb 22 18:08:18 <ralphschindler> so, is it safe to say that if you want i18n features, you'll have a php distribution with i18n on?
Feb 22 18:08:19 <ocramius> weierophinney: should components check if extension_loaded ?
Feb 22 18:08:22 <weierophinney> DASPRiD, yes.
Feb 22 18:08:38 <weierophinney> ralphschindler, I would think so, if you're using 5.3+
Feb 22 18:09:01 <EvanDotPro> i'm +1 and saying it's up to the user to enable intl if they want i18n.
Feb 22 18:09:06 <EvanDotPro> s/and/for
Feb 22 18:09:14 <weierophinney> I do know that Zend Server enables it by default, and most distributions do as well.
Feb 22 18:09:29 <weierophinney> so to me, it's kind of a moot point whether or not a vanilla install has it enabled.
Feb 22 18:09:31 <DASPRiD> weierophinney, yeah, or at least (edbian/ubuntu) ship a php5-intl package
Feb 22 18:09:42 <ocramius> repeating question: should components check if extension_loaded ?
Feb 22 18:09:48 <weierophinney> ocramius, yes, I think so.
Feb 22 18:09:52 <ocramius> okay
Feb 22 18:09:54 <weierophinney> DASPRiD, can you note that in the RFC?
Feb 22 18:10:05 <DASPRiD> weierophinney, at which points would components check for that?
Feb 22 18:10:07 <DASPRiD> on __construct ?
Feb 22 18:10:16 <DASPRiD> or above class declaration?
Feb 22 18:10:32 <weierophinney> DASPRiD, the only other concern from the comments I've not seen addressed so far is the matter of DateTime allowing reset based on formats.
Feb 22 18:10:44 <weierophinney> DASPRiD, we usually do it in __construct.
Feb 22 18:10:47 <DASPRiD> weierophinney, ah, i talked with kobsu about that
Feb 22 18:10:48 <ralphschindler> DASPRiD: in __construct
Feb 22 18:10:53 <weierophinney> DASPRiD, yeah?
Feb 22 18:10:56 <kobsu> yes we talked about it
Feb 22 18:10:58 <weierophinney> what did kobsu indicate?
Feb 22 18:11:02 <ralphschindler> you don't want class_exists($class, true) to throw an error or exception
Feb 22 18:11:05 <DASPRiD> kobsu, your turn
Feb 22 18:11:15 <kobsu> weierophinney: that maybe i was using it wrongly
Feb 22 18:11:21 <weierophinney> kobsu, LOL
Feb 22 18:11:30 <weierophinney> okay, can one of you update that comment thread, then?
Feb 22 18:11:39 <weierophinney> just so folks know what the resolution to that discussion was.
Feb 22 18:11:42 <kobsu> DASPRiD had some better practices in mind
Feb 22 18:12:08 <weierophinney> Anybody else have any initial feedback for DASPRiD on the i18n/l10n rfc?
Feb 22 18:12:20 <DASPRiD> i'll update the rfc @ module checking
Feb 22 18:12:30 <weierophinney> DASPRiD, thx
Feb 22 18:12:33 <ralphschindler> i'd prefer composition of i18n features instead of it baked in
Feb 22 18:12:46 <weierophinney> ralphschindler, can you clarify?
Feb 22 18:12:52 <ralphschindler> so $route = new LocaleRoute(new Route(….))
Feb 22 18:12:58 <weierophinney> ah.
Feb 22 18:12:59 <ralphschindler> intend of Route having locale features in its codebase
Feb 22 18:13:04 »» weierophinney agrees in that regard.
Feb 22 18:13:20 <DASPRiD> ralphschindler, actually i had that idea already
Feb 22 18:13:23 <DASPRiD> forgot to not it
Feb 22 18:13:29 <ralphschindler> i dislike how our current route has so much code in it for something as simple as parsing out parts (b/c of i18n stuffs)
Feb 22 18:13:40 <DASPRiD> ralphschindler, although wrapping around any kind of route doesnt really work
Feb 22 18:13:54 <DASPRiD> ralphschindler, i was more thinking about extending the segment route
Feb 22 18:13:55 <weierophinney> well, then have separate, locale-aware routes.
Feb 22 18:13:59 <DASPRiD> to have a TranslateSegmentRoute
Feb 22 18:14:05 <weierophinney> but keep the base ones sane.
Feb 22 18:14:16 <DASPRiD> weierophinney, yeah, so extending may be fine?
Feb 22 18:14:19 <ralphschindler> I'm just saying to examine that architecture
Feb 22 18:14:27 <ocramius> nice catch ralphschindler +1 for this separation
Feb 22 18:14:29 <weierophinney> DASPRiD, can you note about router, currency, and measure in the rfc as well?
Feb 22 18:14:35 <DASPRiD> sure
Feb 22 18:14:36 »» Thinkscape reporting in
Feb 22 18:14:38 <weierophinney> greets, Thinkscape and mabe_
Feb 22 18:14:46 <DASPRiD> i'd just have to add a little logic to the base segment rotue to allow such extension
Feb 22 18:14:50 <ocramius> Thinkscape: discussing http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+i18n+layer
Feb 22 18:14:50 <DASPRiD> without too much copy/paste code
Feb 22 18:15:01 <weierophinney> DASPRiD, re: currency/measure, simply indicate that these are addressed with \NumberFormatter.
Feb 22 18:15:09 <DASPRiD> weierophinney, sure
Feb 22 18:15:19 <weierophinney> DASPRiD, extension would be okay, but composition would be better, if possible.
Feb 22 18:15:25 <DASPRiD> weierophinney, oh, it is already noted
Feb 22 18:15:29 <weierophinney> DASPRiD, thx
Feb 22 18:15:30 <DASPRiD> see last point in the 5.3 list
Feb 22 18:15:39 <DASPRiD> "Locale-aware formatting of numbers and currencies"…
Feb 22 18:15:50 <Xerkus> i don't understand why routes should be localized at all
Feb 22 18:16:04 <weierophinney> DASPRiD, kk – there was a comment about it, and you kind of brushed it off as "maybe" – but it looks like you're planning to address it.
Feb 22 18:16:05 <ocramius> Xerkus: I actually got that requirement many times...
Feb 22 18:16:09 <Thinkscape> Xerkus: it's useful to me
Feb 22 18:16:14 <weierophinney> Xerkus, I don't either, but a lot of folks use them.
Feb 22 18:16:22 <weierophinney> which means it's a feature we should target.
Feb 22 18:16:29 <DASPRiD> weierophinney, well, the comment was about the old rfc
Feb 22 18:16:38 <DASPRiD> i should probably have createad a new page
Feb 22 18:16:45 <weierophinney> DASPRiD, so post another comment indicating it's addressed, so folks like me don't get confused.
Feb 22 18:17:04 <DASPRiD> yeah will all be updated
Feb 22 18:17:16 <weierophinney> kk, coming up on time for this topic shortly... any other feedback for DASPRiD on the i18n/l10n rfc?
Feb 22 18:17:22 <Thinkscape_> DASPRiD: all in fafor of auto-detect component in zf2 ?
Feb 22 18:17:35 <DASPRiD> Thinkscape_, uh?
Feb 22 18:17:44 <ocramius> Thinkscape: that's in PHP 5.3
Feb 22 18:17:44 <Thinkscape_> $locale->setSupported(array('en_GB', 'nl_NL')); $locale->setDefault('en_GB'); $locale->autodetect($request);
Feb 22 18:17:50 <ocramius> oh, that one
Feb 22 18:17:53 <DASPRiD> Thinkscape_, ah that one
Feb 22 18:17:56 <Thinkscape_> it's not integrated into zf2 guts
Feb 22 18:18:13 <DASPRiD> Thinkscape_, yeah \Locale has auto detection, but not based on supported locales
Feb 22 18:18:22 <Akrabat> back
Feb 22 18:18:23 <DASPRiD> so we probably have to a helper for that
Feb 22 18:18:30 <EvanDotPro> DASPRiD: you mentioned module checking? what do you mean by that?
Feb 22 18:18:32 <DASPRiD> *to add
Feb 22 18:18:41 <DASPRiD> EvanDotPro, module_exists() calls in __construct
Feb 22 18:18:42 <Thinkscape_> also - have you been discussing integration with other zf2 components.... or rather - usage of locale stuff througout zf2 ?
Feb 22 18:18:43 <Akrabat> my only comment on i18n is that if I use \Router I don't want to have to have all of the ii8n stuff
Feb 22 18:18:44 <weierophinney> DASPRiD, that was in a comment as well. I think it's important to note in the RFC that there's a plan for it.
Feb 22 18:18:51 <weierophinney> Akrabat, yep, we covered that.
Feb 22 18:18:54 <ocramius> Akrabat: will be stripped
Feb 22 18:18:59 <ocramius> Akrabat: and separated
Feb 22 18:19:02 <Akrabat> ok good - so will live in another namespace?
Feb 22 18:19:06 <ocramius> (As of current discussion)
Feb 22 18:19:15 <DASPRiD> Akrabat, well, will be separate kind of routes
Feb 22 18:19:19 <weierophinney> Akrabat, more like there will be separate locale-aware routes.
Feb 22 18:19:23 <Akrabat> cos otherwise pear install router will pull in locale
Feb 22 18:19:24 <EvanDotPro> DASPRiD: you mean checking for the php extension? not zf2 modules.
Feb 22 18:19:32 <DASPRiD> Akrabat, mhhh
Feb 22 18:19:36 <DASPRiD> EvanDotPro, right
Feb 22 18:19:36 <Thinkscape_> routes is one thing that comes to my mind... but view rendering also requires a good integration.
Feb 22 18:19:41 <Akrabat> and that's one of my current pet peeves in zf11
Feb 22 18:19:42 <Akrabat> and that's one of my current pet peeves in zf1
Feb 22 18:19:46 <weierophinney> DASPRiD, Akrabat has a good point – maybe put the locale-aware routes under a l10n namespace?
Feb 22 18:20:02 <DASPRiD> weierophinney, mh yeah could make sense
Feb 22 18:20:05 <EvanDotPro> DASPRiD: extension_loaded()
Feb 22 18:20:10 <DASPRiD> EvanDotPro, whatever
Feb 22 18:20:29 <Akrabat> other than that, I'm +1 for using php5.3 extension
Feb 22 18:20:42 <weierophinney> Thinkscape, if there are helpers for translation and various localization tasks that are injected with the appropriate objects, does that address things for you?
Feb 22 18:20:45 »» Thinkscape_ is now known as Thinkscape
Feb 22 18:20:52 <DASPRiD> okay so routes get into the i18n namespace
Feb 22 18:21:06 <Thinkscape> "injected with the appropriate object" - intl or zf2-wrapped ?
Feb 22 18:21:08 <weierophinney> should i18n/l10n view helpers also be in that namespace?
Feb 22 18:21:15 <weierophinney> Thinkscape, the ZF2 bits
Feb 22 18:21:21 <DASPRiD> weierophinney, could make sense
Feb 22 18:21:24 <EvanDotPro> weierophinney: i'd say yes.
Feb 22 18:21:29 <DASPRiD> so yes why not
Feb 22 18:21:43 <Akrabat> yes
Feb 22 18:21:46 <DASPRiD> same for filters and validators
Feb 22 18:21:49 <Thinkscape> weierophinney: well, to follow up: what are other zf2\whateverlocale responsibilities, other that wrapping intl ?
Feb 22 18:21:58 <weierophinney> DASPRiD, can you note that bit in the RFC as well, please?
Feb 22 18:22:00 <Akrabat> same reasoning from a dependent packaging point of view
Feb 22 18:22:08 <DASPRiD> weierophinney, sure, writing it down soon
Feb 22 18:22:17 <mabe_> will all i18n/l10n components going into the same namespace ?
Feb 22 18:22:29 <DASPRiD> okay, so all components which have hard-dependencies on i18n go into the i18n namespace
Feb 22 18:22:32 <weierophinney> mabe_, I think that's the general consensus.
Feb 22 18:22:56 <DASPRiD> what are we going to use for i18n namespace?
Feb 22 18:22:57 <weierophinney> DASPRiD, i18n/l10n – or g11n (globalisation? is that right?)
Feb 22 18:23:06 <Thinkscape> that sounds odd
Feb 22 18:23:11 <Thinkscape> i.e. Zend\Filter\Translate
Feb 22 18:23:13 <DASPRiD> (l10n is actually the part of translating texts…)
Feb 22 18:23:16 <Thinkscape> it's in Filter, because it's a filter
Feb 22 18:23:21 <DASPRiD> Thinkscape, uh?
Feb 22 18:23:24 <weierophinney> (it's what li3 used)
Feb 22 18:23:39 <DASPRiD> (brb, getting pizza out of oven)
Feb 22 18:23:47 <weierophinney> Thinkscape, by that logic, all dojo or jquery stuff would be scattered between form, view, and whatnot.
Feb 22 18:23:56 <Thinkscape> Why would we move Zend\Filter\Translate into Zend\i18n\Filter ??
Feb 22 18:24:07 <weierophinney> making those packages then have dependencies on multiple other packages.
Feb 22 18:24:23 <Thinkscape> By that logic, why is Encrypt, Compress, File in filters ?
Feb 22 18:24:42 <weierophinney> Thinkscape, instead of the i18n stuff having dependencies on the components on which interfaces it depends.
Feb 22 18:24:49 <weierophinney> Thinkscape, they probably should not be.
Feb 22 18:24:58 <DASPRiD> re
Feb 22 18:25:00 <Thinkscape> so loosely-coupling as a primary goal?
Feb 22 18:25:35 <Thinkscape> because it does not help that 90% other filters are in Zend\Filter, while translate is in Zend\i18n\Filter (or wherever)
Feb 22 18:26:06 <Xerkus> filter Translate should be in \Filter\ and do nothing if translator object is not specified IMHO
Feb 22 18:26:31 <weierophinney> Thinkscape, can you raise this one on the ML? I think it needs further discussion.
Feb 22 18:26:36 <Thinkscape> weierophinney:
Feb 22 18:26:38 <Akrabat> Thinkscape its a very important one, yes.
Feb 22 18:26:45 <DASPRiD> tbh, is Zend\Translator really a filter?
Feb 22 18:26:57 <Thinkscape> it's a translator
Feb 22 18:27:04 <DASPRiD> yes
Feb 22 18:27:13 <Thinkscape> but yeah, a filter of sorts...
Feb 22 18:27:14 <mabe_> but there is a filter for that trnaslator
Feb 22 18:27:16 <weierophinney> Thinkscape, but it takes text and transforms it/filters it to an alternate representation.
Feb 22 18:27:23 <Thinkscape> true
Feb 22 18:27:34 <ocramius> hmm, never thought of it. Making it a filter makes it more flexible
Feb 22 18:27:34 <Thinkscape> so Translator goes into a bag of Zend\i18n
Feb 22 18:27:37 <DASPRiD> Zend\Transformer then
Feb 22 18:27:38 <DASPRiD>
Feb 22 18:27:42 <weierophinney> kk, let's move the discussion of where the various i18n/l10n stuff will live to the ML.
Feb 22 18:27:44 <Thinkscape> and we still have Filter\Translate to make things easy to find ...
Feb 22 18:27:51 <Thinkscape> (my little proposal)
Feb 22 18:27:52 <SpiffyJr> Forms!
Feb 22 18:27:54 »» SpiffyJr coughs
Feb 22 18:27:58 <Thinkscape> well, pyrus will have to manage
Feb 22 18:28:07 »» EvanDotPro hands SpiffyJr a bottle of water
Feb 22 18:28:18 <Thinkscape> rum
Feb 22 18:28:26 <weierophinney> Thinkscape, it's not just pyrus. It's how we set up packages. If we have to separate out individual classes from components, it becomes quite difficult.
Feb 22 18:28:34 <Thinkscape> weierophinney: I know
Feb 22 18:28:35 <Thinkscape> Next item on the agenda ?
Feb 22 18:28:41 <weierophinney> So, next item: forms rfc
Feb 22 18:28:44 <weierophinney> RFC is here: http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms
Feb 22 18:28:45 »» SpiffyJr cheers
Feb 22 18:28:49 <weierophinney> it's a FIRST DRAFT
Feb 22 18:29:00 <Thinkscape> Please no dummy </form> at the end... sounds like a bad design.
Feb 22 18:29:06 <Akrabat> so now come the disclaimers...
Feb 22 18:29:11 <DASPRiD> Thinkscape, i already had that
Feb 22 18:29:15 <DASPRiD> <?php echo $this->formRenderer()-->render($form); ?>
Feb 22 18:29:16 <weierophinney> Thinkscape, I hadn't thought of that. I totally get it's a bad idea.
Feb 22 18:29:24 <weierophinney> can we move on to OTHER bits to discuss, then?
Feb 22 18:29:33 <DASPRiD> heh
Feb 22 18:29:50 <ralphschindler> weierophinney: LOVE the sprintf model
Feb 22 18:29:57 <weierophinney> damn.. just seeing the comments....
Feb 22 18:30:00 »» weierophinney speed reads...
Feb 22 18:30:31 <Thinkscape> I'd like to point out little thing: it's nice that we now can output chunks of the form with $this->someChunk() — weierophinney: you explain that it's better, because a designer gets more control. But it is only a small improvement, because $this->label() STILL has some implicit way of rendering that <label>. What if I want labels to be <ul><li> or <span> ? – still need to subclass or whatever. So it does not resolve zf1 f
Feb 22 18:30:32 <EvanDotPro> i agree with jurians that we need something for PRG – that's a huge pain in zf1.
Feb 22 18:30:39 <DASPRiD> curl -o - http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms > /dev/mwop
Feb 22 18:30:51 <DASPRiD> EvanDotPro, what exactly?
Feb 22 18:31:07 <SpiffyJr> Thinkscape, <ul><?php echo $this->label();?></ul> ??
Feb 22 18:31:09 <ocramius> Thinkscape: what if we add arguments to the helpers?
Feb 22 18:31:24 <Thinkscape> SpiffyJr: no! I don't want <label> but <li> instead.
Feb 22 18:31:34 <Thinkscape> SpiffyJr: take a look at the example in RFC
Feb 22 18:31:41 <SpiffyJr> Comments or?
Feb 22 18:31:43 <EvanDotPro> DASPRiD: http://en.wikipedia.org/wiki/Post/Redirect/Get
Feb 22 18:31:54 <dmitrybelyakov> sometimes you might need your lable to wrap input
Feb 22 18:31:56 <DASPRiD> EvanDotPro, thx captn obvious
Feb 22 18:31:59 <mabe_> PRG shouldn't part of form - it's part of mvc
Feb 22 18:31:59 <DASPRiD> EvanDotPro, i know that pattern
Feb 22 18:32:03 <SpiffyJr> Thinkscape, I see.
Feb 22 18:32:08 <DASPRiD> mabe_, +1
Feb 22 18:32:15 <weierophinney> Thinkscape, so, the basic form view helpers would spit out a single markup tag. If you wanted the label to be done differently, you either use a different helper, or pull the metadata manually from the object to build your markup.
Feb 22 18:32:32 <Thinkscape> weierophinney: back to square one in my opinion.
Feb 22 18:32:37 <EvanDotPro> DASPRiD: well i don't have a specific suggestion (maybe integration with a single-hop session container?) .. but we need something
Feb 22 18:32:46 <ralphschindler> i think a published/documented sprintf variable list should be the base implementation for output in forms/elements
Feb 22 18:32:54 <weierophinney> Thinkscape, what do you mean by "square 1" here?
Feb 22 18:33:00 <ralphschindler> that way, you only need to understand PHP in order to customize
Feb 22 18:33:08 <DASPRiD> EvanDotPro, flash messenger!
Feb 22 18:33:25 <mabe_> lol
Feb 22 18:33:38 <Thinkscape> I didn't put much thought about it but I believe a template fragments strategy might be a good compromise ---- each form widget/elements is a hunk of parsable template. Changing it is a simple as replacing one string with another. Something along the lines of sprintf() but much more powerful.
Feb 22 18:33:41 <weierophinney> dmitrybelyakov, that's an implementation detail, and something a specialized helper could accomplish.
Feb 22 18:33:44 <EvanDotPro> DASPRiD: i use that currently, but i'm not sure that's the intended use case for something like this lol.
Feb 22 18:34:11 <jurians> weierophinney: for the RFC, I'd love to see some use cases: #1 forms in MVC setting, #2 forms with partial validation (ie from onBlur AJAX call) and #3 form with PRG pattern. Is that possible?
Feb 22 18:34:18 <weierophinney> Thinkscape, the problem with that approach is it requires us to ship templates with the framework. Which then means we need to create a way to make those discoverable.
Feb 22 18:34:34 <weierophinney> jurians, noting that now, and will add to the RFC.
Feb 22 18:34:39 <jurians> thanks
Feb 22 18:34:48 <Thinkscape> i.e. $form->fragments = array( "label" => "<label>:itemName</label>", "errorItem" => "<span class="error">:errorMessage</span>" ........ )
Feb 22 18:34:53 <ralphschindler> Thinkscape: the sprintf example weierophinney has in there is a template fragment
Feb 22 18:34:54 <Thinkscape> weierophinney: not really templates
Feb 22 18:34:58 <Thinkscape> chunks of code
Feb 22 18:35:10 <DASPRiD> jurians, plz no xml
Feb 22 18:35:21 <Thinkscape> think - zf1 view helper for "dom element" ...it made a concat of "<" + elName + something + something + ">" ...
Feb 22 18:35:29 <Thinkscape> ralphschindler: exactly ...
Feb 22 18:35:32 <ralphschindler> return sprintf("<div class=\"%s\">\n%s\n%s\n%s\n</div>", …) could easily be sprintf($this->fragment, … )
Feb 22 18:35:36 <weierophinney> Thinkscape, what about sprintf usage, then?
Feb 22 18:35:38 <Thinkscape> ralphschindler: but I mean something more powerful, but simple nevertheless...
Feb 22 18:35:40 <ralphschindler> with positional replacements
Feb 22 18:35:43 <ocramius> Thinkscape: this probably comes from the depths of my ignorance, but do ZF1 forms support partials?
Feb 22 18:35:45 <EvanDotPro> jurians: good call on partial validation – didn't think of that!
Feb 22 18:35:48 <weierophinney> Thinkscape, what's not powerful about sprintf?
Feb 22 18:35:50 <Thinkscape> ralphschindler: sprintf sucks because it requires knowledge of parameter order..
Feb 22 18:35:58 <ralphschindler> i have an idea on the more powerful part that fits in with sprintf
Feb 22 18:36:01 <weierophinney> ocramius, there's a ViewPartial decorator.
Feb 22 18:36:12 <weierophinney> Thinkscape, point taken
Feb 22 18:36:19 <ocramius> weierophinney: cool, now I need 5 mins of facedesk
Feb 22 18:36:28 <Thinkscape> you cannot do this in sprintf: '<label id=":elementId" class="error">:errorMessage</label>'
Feb 22 18:36:37 <Akrabat> annotations would be optional?
Feb 22 18:36:40 <ralphschindler> a ZenCoding expander could easily solve this as well for more complex fragments
Feb 22 18:36:42 <Akrabat> we could still do it via code/
Feb 22 18:36:49 <Akrabat> we could still do it via code? even
Feb 22 18:36:57 <EvanDotPro> ralphschindler: ooh that could be pretty cool
Feb 22 18:36:57 <weierophinney> Akrabat, yes
Feb 22 18:36:57 <DASPRiD> (EvanDotPro: 2 hours until last cigarette, that app worx!)
Feb 22 18:37:01 <Akrabat> k
Feb 22 18:37:04 <DASPRiD> s/until7since/
Feb 22 18:37:09 <ralphschindler> yes EvanDotPro - i've been sitting on that idea for a while now
Feb 22 18:37:23 <ocramius> oh nice =)
Feb 22 18:37:25 <Thinkscape> ralphschindler: new syntax though
Feb 22 18:37:29 <Thinkscape> (quirky one)
Feb 22 18:37:34 <ralphschindler> $element->setFragment('div>#somename%1s') … etc
Feb 22 18:37:38 <weierophinney> Thinkscape, I've noted about doing a hybrid of sprintf + named replacements
Feb 22 18:37:41 <ralphschindler> Thinkscape: we're not inventing the syntax
Feb 22 18:37:47 <ocramius> ralphschindler: sounds like a new component to me
Feb 22 18:38:01 <EvanDotPro> a filter?
Feb 22 18:38:07 <ralphschindler> yep, a filter
Feb 22 18:38:17 <Thinkscape> weierophinney: yes, but please keep in mind that it should be collection of fragments, NOT collection of classes each with a fragment, because this OO will bloat the thing out of proportions.
Feb 22 18:38:18 <SpiffyJr> ZenCode sure is handy... I could live with that.
Feb 22 18:38:28 <Akrabat> one minor point about zf1: isValid() calls setValues() internally. Can we ensure we don't change state in an isXxx() or hasXx() call please?
Feb 22 18:38:45 <EvanDotPro> Akrabat: +50
Feb 22 18:38:47 <weierophinney> Thinkscape, perhaps you can write up a ML post detailing how you envision that, then?
Feb 22 18:38:47 <rizza> Akrabat: +1
Feb 22 18:38:54 <SpiffyJr> Akrabat, good point - I'd rather call it something like bind();
Feb 22 18:38:54 <weierophinney> I don't want to interpret incorrectly.
Feb 22 18:39:03 <Thinkscape> weierophinney: you intepret correctly
Feb 22 18:39:16 <SpiffyJr> Akrabat, some naming that clearly expresses the form state is being modified.
Feb 22 18:39:18 <ocramius> SpiffyJr: where did I see that?
Feb 22 18:39:22 »» DASPRiD has to note that we should at one point think about Filter policy again, eventually most view helpers and validators can be considered filters)
Feb 22 18:39:23 <Thinkscape> weierophinney: think instead of 20 classes, 2-3 form-related classes.... and that's it.
Feb 22 18:39:32 <weierophinney> Akrabat, not sure I follow...
Feb 22 18:39:45 <ralphschindler> I know he is not here to talk about it but elazar, with large forms, ran into significant performance issues with regards to forms in ZF1, if we lighten the architectural load, performance should increase (things like sprintf over decorators for one)
Feb 22 18:39:50 <weierophinney> Thinkscape, right, but are you talking view helpers? or elsewhere?
Feb 22 18:39:53 <Thinkscape> DASPRiD: filter filters and returns. View helper spews out the result.
Feb 22 18:40:03 <EvanDotPro> weierophinney: when you call isValid($postData) it populates the form object
Feb 22 18:40:06 <DASPRiD> Thinkscape, well, same thing kinda
Feb 22 18:40:06 <EvanDotPro> with the values
Feb 22 18:40:07 <Thinkscape> weierophinney: both view helpers and form-building classes.
Feb 22 18:40:15 <Thinkscape> weierophinney: to make it simpler...
Feb 22 18:40:27 <SpiffyJr> weierophinney, isValid() changes form state which isn't very intuitive and something that an "isser" doesn't normally do.
Feb 22 18:40:30 <weierophinney> EvanDotPro, and Akrabat is suggesting not to do that?
Feb 22 18:40:32 <Thinkscape> weierophinney: I remember the stack when debugging zf1 form elements – it was horrendous!
Feb 22 18:40:41 <Akrabat> weierophinney: currently callling $form->isValid() causes a state change on the form object. This is "unexpected" for a method name that looks like a test. I want to ensure that we name our methods around validation in zf2 do not do that
Feb 22 18:40:54 <weierophinney> Thinkscape, already the plan – the only place I differed was the view helpers. But that may be easy to address.
Feb 22 18:40:57 <Thinkscape> weierophinney: (stack when rendering zf1 form elements)
Feb 22 18:40:58 <ralphschindler> +1 on Akrabat
Feb 22 18:41:03 <EvanDotPro> weierophinney: i'm suggesting not to do that as well.. it's an isXxx() method.. should not be acting like a setter
Feb 22 18:41:08 <mabe_> weierophinney: You RFC has a $form->setInputFilter - will there also a output filter ?
Feb 22 18:41:11 <Thinkscape> weierophinney: yes, but if we do these fragments, we don't need 10 view helpers
Feb 22 18:41:13 <Thinkscape> only one
Feb 22 18:41:17 <Thinkscape> or a handful
Feb 22 18:41:27 <ocramius> agreed with Akrabat: that one is chaos
Feb 22 18:41:29 <weierophinney> Akrabat, makes sense – I'd expect you'd need to bind values from the input filter manually
Feb 22 18:41:33 <weierophinney> Akrabat, I'll note that in the rfc
Feb 22 18:41:38 <Akrabat> cool
Feb 22 18:41:38 <weierophinney> mabe_, no
Feb 22 18:41:47 <weierophinney> mabe_, output filter is... the view layer.
Feb 22 18:41:53 <Akrabat> also, are we going to lose current zend\filter\input (i.e does this replace it?)
Feb 22 18:42:28 <Akrabat> cos two different things that we colloquially call "input filter" could be confusing
Feb 22 18:42:28 <weierophinney> Akrabat, I'd imagine this would replace it.
Feb 22 18:43:11 <Akrabat> great
Feb 22 18:43:15 <weierophinney> Akrabat, btw, I'd expect the isValid() call to either be direclty on the input filter, or, if on the form, proxy to it.
Feb 22 18:43:18 <Thinkscape> filter chain
Feb 22 18:43:27 <weierophinney> The values would be inside the input filter
Feb 22 18:43:30 <SpiffyJr> weierophinney, good
Feb 22 18:43:46 <weierophinney> so you'd need to bind them, or the form/elements would proxy to the filter to get their respective value.
Feb 22 18:44:19 <Akrabat> As others have mentioned, it would be helpful to add some code sample ideas on the entire process I think
Feb 22 18:44:35 <weierophinney> I've noted a number of things for the RFC, including additional usage samples. I'll update in the next day or two.
Feb 22 18:44:38 <Akrabat> makes sense
Feb 22 18:44:51 <weierophinney> We can discuss more on the lsit – this is simply the first foray, as far as I'm concerned.
Feb 22 18:44:58 <weierophinney> Shall we move on to the last topic?
Feb 22 18:44:59 <SpiffyJr> weierophinney, action and method are the only things managed in the opening <form> tag, correct?
Feb 22 18:45:22 <Thinkscape> SpiffyJr: don't forget enctype
Feb 22 18:45:25 <SpiffyJr> Breaking IDE's HTML parser with that opening form helper makes me sad face.
Feb 22 18:45:31 <Thinkscape> SpiffyJr: and target..
Feb 22 18:45:38 <rizza> And class, name, id...
Feb 22 18:45:42 <SpiffyJr> We didn't touch on annotations! Or a potential form builder!
Feb 22 18:45:48 <SpiffyJr> Or all that cool stuff...
Feb 22 18:45:58 <Akrabat> form() view helper shoud be formOpener() or something too but in general I'm liking where this is going, but we'll need more ML time
Feb 22 18:46:25 <ocramius> SpiffyJr: you mean entity- stuff?
Feb 22 18:46:27 <weierophinney> SpiffyJr, and any other attributes you might want. HTML5 now has data-*.
Feb 22 18:46:36 <ezimuel> I think we should split the logic of form (like validation) from the form UI (rendering)
Feb 22 18:46:38 <ocramius> we can't surely ignore that... that stuff is going to get used more and more...
Feb 22 18:46:46 <weierophinney> SpiffyJr, I'll be changing the open/close tag bit. Noted that at the start.
Feb 22 18:46:47 <rizza> ezimuel: I believe that's the idea.
Feb 22 18:46:51 <SpiffyJr> Okay.
Feb 22 18:47:06 <Akrabat> I would love to solve Tomáš' issue too if we can and have a way to render a form without having to write a view script for it
Feb 22 18:47:16 <DASPRiD> weierophinney, don't forget "placeholder" is there as well
Feb 22 18:47:16 <weierophinney> ezimuel, that's the goal of the RFC.
Feb 22 18:47:23 <weierophinney> DASPRiD, ?
Feb 22 18:47:28 <DASPRiD> on input elements
Feb 22 18:47:30 <SpiffyJr> Akrabat, Should be easy to write a generic view helper...
Feb 22 18:47:35 <rizza> Akrabat: I'd like that, too.
Feb 22 18:47:41 <DASPRiD> <input type="text" placeholder="Username" />
Feb 22 18:47:48 <SpiffyJr> Akrabat, $this->renderFormWithPTags($form); ... or whatever.
Feb 22 18:47:49 <weierophinney> DASPRiD, ah, right.
Feb 22 18:47:56 <weierophinney> I was thinking the view helper.
Feb 22 18:48:01 <DASPRiD> oh, heh
Feb 22 18:48:05 <Thinkscape> and input type="datetime"...
Feb 22 18:48:06 <Akrabat> SpiffyJr: yes, something like that
Feb 22 18:48:09 <Thinkscape> among others
Feb 22 18:48:10 <weierophinney> Akrabat, we may be able to do that. I'll think on it.
Feb 22 18:48:16 <weierophinney> kk, let's move on to the last topic.
Feb 22 18:48:17 <DASPRiD> Thinkscape, yeah, but thats sadly not widely supported yet
Feb 22 18:48:23 <DASPRiD> there's another topic?
Feb 22 18:48:25 <weierophinney> BETA 3 READINESS
Feb 22 18:48:26 <rizza> beta3
Feb 22 18:48:29 <DASPRiD> ah!
Feb 22 18:48:30 <Thinkscape> DASPRiD: but it's there, and easy to add-on to old browsers
Feb 22 18:48:35 <SpiffyJr> SHIP IT! Ship it all!
Feb 22 18:48:35 <DASPRiD> Thinkscape, true
Feb 22 18:48:40 <DASPRiD> modernizr to the rescue
Feb 22 18:48:44 <SpiffyJr> Oh wait, I'm not at work right now...
Feb 22 18:48:46 <ocramius> SpiffyJr: I think the entity- related stuff fits a module then
Feb 22 18:48:53 <weierophinney> MOVING ON
Feb 22 18:49:07 <weierophinney> I want to do code freeze (note, NOT docs freeze) by Friday.
Feb 22 18:49:08 <SpiffyJr> ocramius, fair enough, then. I'll keep working on SpiffyForm.
Feb 22 18:49:12 <DASPRiD> cat Form-Topic > /dev/null
Feb 22 18:49:14 <DASPRiD> next one
Feb 22 18:49:14 »» Thinkscape hears ringing in his ears..
Feb 22 18:49:16 <weierophinney> Akrabat has merged the view layer today.
Feb 22 18:49:16 <Akrabat> Friday?!?!?
Feb 22 18:49:26 <Thinkscape> already?
Feb 22 18:49:28 <SpiffyJr> It's merged and ready?
Feb 22 18:49:34 <weierophinney> and we have DB about to be queued up for a PR
Feb 22 18:49:37 <Akrabat> has someone else other than ralphschindler used db yet?
Feb 22 18:49:39 <weierophinney> (right, ralphschindler?!?!?!)
Feb 22 18:49:50 <ralphschindler> yep, I'm getting close on the pull request
Feb 22 18:49:51 <weierophinney> Config is ready to merge (if not done already)
Feb 22 18:49:59 <DASPRiD> weierophinney, uhm
Feb 22 18:50:06 <weierophinney> And I have a massive PR queue to go through.
Feb 22 18:50:13 <DASPRiD> weierophinney, i only briefly looked over it
Feb 22 18:50:14 <Akrabat> Thinkscape, SpiffyJr: view-layer is definitely rounded off enough to go to beta
Feb 22 18:50:23 <weierophinney> DASPRiD, kk, GET CRAKING.
Feb 22 18:50:23 <DASPRiD> weierophinney, there are a few things left which have to be changed
Feb 22 18:50:28 <SpiffyJr> Akrabat, is it already merged?
Feb 22 18:50:31 <weierophinney> SpiffyJr, YES
Feb 22 18:50:35 <SpiffyJr> Beautiful!
Feb 22 18:50:39 <DASPRiD> weierophinney, will try to review it this evening
Feb 22 18:50:39 <Akrabat> SpiffyJr: yes - I closed the PR 1 hour ago roughly
Feb 22 18:50:40 <SpiffyJr> I'll put up another PR for you then.
Feb 22 18:50:47 <weierophinney> DASPRiD, thanks!
Feb 22 18:50:53 <Thinkscape> DASPRiD: next evening
Feb 22 18:50:57 <DASPRiD> Thinkscape, uh?
Feb 22 18:51:03 <SpiffyJr> weierophinney, I have some Zend\Navigation PR's that I will try to get in by Friday.
Feb 22 18:51:03 <Akrabat> I'm concerned about Friday code freeze
Feb 22 18:51:12 <weierophinney> Akrabat has a good point: ralphschindler will post when he has the PR ready, and point folks to the various samples. PLEASE REVIEW AND TEST
Feb 22 18:51:21 <weierophinney> Akrabat, is it due to the DB stuff?
Feb 22 18:51:23 <Thinkscape> Akrabat: what code freeze?
Feb 22 18:51:25 <rizza> Seems like a lot of things that need to be done by Friday...
Feb 22 18:51:30 <SpiffyJr> Thinkscape, the beta3 code freeze for Friday
Feb 22 18:51:35 <weierophinney> I can maybe extend to Monday
Feb 22 18:51:41 <DASPRiD> monday is probably more sane
Feb 22 18:51:44 <Akrabat> weierophinney: yes = db
Feb 22 18:51:45 <DASPRiD> gives us the weekend just in case
Feb 22 18:51:46 <weierophinney> Does having the weekend seem reasonable?
Feb 22 18:51:59 <Thinkscape> db is for beta4. right ?
Feb 22 18:52:15 <weierophinney> Thinkscape, no, beta3. There will be additional adapters for beta4, though.
Feb 22 18:52:46 <weierophinney> Thinkscape, ralphschindler has been testing on sqlite, mysqli/pdo_mysql, and sqlsrv/pdo_sqlsrv
Feb 22 18:52:54 <weierophinney> (and pdo_sqlite, obviously)
Feb 22 18:53:17 <weierophinney> There's enough differences between them that he's been able to ensure the architecture accommodates variances.
Feb 22 18:53:57 <Akrabat> something without auto-increment would be useful to test too really
Feb 22 18:54:11 <Akrabat> e.g. oracle
Feb 22 18:54:12 <weierophinney> ralphschindler, have you tested that scenario?
Feb 22 18:54:18 <SpiffyJr> New to B3: View, Log, Config, and DB?
Feb 22 18:54:20 <Akrabat> but I wouldn't wish that on anyone
Feb 22 18:54:30 <ralphschindler> Akrabat: sql server has IDENTITY
Feb 22 18:54:32 <weierophinney> SpiffyJr, yes.
Feb 22 18:55:00 <Thinkscape> Akrabat: ralphschindler: postgresql
Feb 22 18:55:01 <weierophinney> SpiffyJr, plus a host of PRs. I think this beta will have something like 200 PRs merged.
Feb 22 18:55:03 <Akrabat> ralphschindler: true
Feb 22 18:55:12 <weierophinney> Thinkscape, that's planned for beta4.
Feb 22 18:55:16 <SpiffyJr> weierophinney, very nice - removing the CLA was a very very good step.
Feb 22 18:55:24 <Thinkscape> weierophinney: you sure you can handle that before mon?
Feb 22 18:55:24 »» weierophinney agrees.
Feb 22 18:55:26 <ralphschindler> postgres is closer to my heart so, i plan on hitting it pretty soon
Feb 22 18:55:34 <Thinkscape> weierophinney: I believe in you nevertheless
Feb 22 18:55:34 <DASPRiD> indeed @ cla
Feb 22 18:55:44 <ralphschindler> i've learned to dislike mysql after dealing with the wide range of databases out there
Feb 22 18:55:46 <weierophinney> Thinkscape, on my end? Yes. PRs are typically not bad, and I hope to be through them by tomorrow regardless.
Feb 22 18:56:08 <ocramius> ralphschindler: you're late haven't you ever read the pgsql motto?
Feb 22 18:56:09 <ocramius>
Feb 22 18:56:13 <weierophinney> Thinkscape, but I think having the weekend for folks to review DB before we freeze the repo is a good idea.
Feb 22 18:56:16 <Thinkscape> ralphschindler: good for you postgresql is quite under-appreciated
Feb 22 18:56:26 <ralphschindler> ocramius: i'd been using postgres for postgis stuff in my spare time
Feb 22 18:56:29 <ralphschindler> i really like it
Feb 22 18:56:35 <Thinkscape> weierophinney: ok, worst case: some pr's wont go in
Feb 22 18:56:40 <Akrabat> has anyone got a plan to test config?
Feb 22 18:56:48 <ocramius> ralphschindler: the feature you need tomorrow, implemented yesterday
Feb 22 18:56:50 <weierophinney> Thinkscape, exactly. I'm not too worried abou tthem.
Feb 22 18:57:05 <weierophinney> Akrabat, ezimuel has written tests at this time, and is writing usage examples.
Feb 22 18:57:07 <Akrabat> a good use-case would be to redo the skeleton using config\reader
Feb 22 18:57:10 <ezimuel> Akrabat: I tested
Feb 22 18:57:16 <weierophinney> Akrabat, but we should do that part as well.
Feb 22 18:57:16 <DASPRiD> Akrabat, thankfully the new config layer is so simple, it can't really break
Feb 22 18:57:19 <ocramius> weierophinney: don't forget about the PR discussion later
Feb 22 18:57:27 <SpiffyJr> weierophinney, does the Zend\Config change require components consuming it to be refactored or has that already been done?
Feb 22 18:57:34 <weierophinney> ocramius, it didn't make the agenda. Will have to do it next week.
Feb 22 18:57:43 <weierophinney> ocramius, hint: you should add it.
Feb 22 18:57:43 <DASPRiD> EvanDotPro should use the Zend\Config\Factory in the module layer
Feb 22 18:57:45 <Thinkscape> i think I missed it - but have there been any developments with: 1) php5.4 poll 2) interface naming poll ?
Feb 22 18:57:46 <ocramius> oh, ok
Feb 22 18:57:54 <Akrabat> ezimuel: that's a good start
Feb 22 18:58:05 <EvanDotPro> DASPRiD: yep
Feb 22 18:58:12 <weierophinney> SpiffyJr, I think that no further work has to be done. DASPRiD, Thinkscape, and ezimuel can better answer that.
Feb 22 18:58:18 <DASPRiD> SpiffyJr, well, no, Config() object is still the same, and the readers only return arrays
Feb 22 18:58:20 <weierophinney> Thinkscape, yes, I can update on those.
Feb 22 18:58:27 <SpiffyJr> DASPRiD, okay, thanks.
Feb 22 18:58:38 <Thinkscape> weierophinney: we have to plan a fat refactor ...
Feb 22 18:58:43 »» SpiffyJr heads to the hospital for the gigantic baby ultrasound
Feb 22 18:58:45 <Akrabat> generally, for db and config, I personally would like to see that someone has implemented these into a test mvc app
Feb 22 18:58:46 <weierophinney> Thinkscape, official decision: not doing a poll on 5.4 usage. We'll target 5.3, and ship a variety of traits for 5.4 users.
Feb 22 18:58:47 <SpiffyJr> Ciao.
Feb 22 18:58:51 <DASPRiD> SpiffyJr, and we already changed most componetns to be not aware of config but Traversable
Feb 22 18:58:58 <DASPRiD> SpiffyJr, enjoy
Feb 22 18:59:06 <weierophinney> Thinkscape, as for interface poll: it's closed. Abstracts are prefixed, interfaces and traits are suffixed.
Feb 22 18:59:07 <SpiffyJr> DASPRiD, I noticed Zend\Navigation wasn't updated yet. I'll update that as well before I submit my PR.
Feb 22 18:59:15 <weierophinney> (which goes in line with other frameworks as well)
Feb 22 18:59:25 <Akrabat> weierophinney: we need to write that up and post it on the dev blog
Feb 22 18:59:26 <DASPRiD> SpiffyJr, updated?
Feb 22 18:59:31 <DASPRiD> you mean config wise?
Feb 22 18:59:32 <weierophinney> Thinkscape, which means refactoring components to do those things
Feb 22 18:59:33 <weierophinney> Akrabat, noted.
Feb 22 18:59:34 <Thinkscape> weierophinney:are we targeting beta4 for the interface naming refactor?
Feb 22 18:59:34 <SpiffyJr> DASPRiD, yes
Feb 22 18:59:38 <DASPRiD> SpiffyJr, ah sure
Feb 22 18:59:42 <SpiffyJr> DASPRiD, it's still looking for Zend\Config not Traversable
Feb 22 18:59:45 <DASPRiD> SpiffyJr, just steal the traversable snippet from another component
Feb 22 18:59:48 <DASPRiD>
Feb 22 18:59:58 <EvanDotPro> DASPRiD: added to agilezen (config factory in zend\module)
Feb 22 13:00:03 <weierophinney> Akrabat, I'll get my site refactored with latest config/view stuff. No DB there for me to work with, though.
Feb 22 13:00:13 <SpiffyJr> DASPRiD, fully plan on it.
Feb 22 13:00:15 »» SpiffyJr leaves, for real
Feb 22 13:00:43 <weierophinney> gl, SpiffyJr
Feb 22 13:00:45 <Akrabat> k
Feb 22 13:00:58 <weierophinney> who wants to try using Zend\Db in a test site for us?
Feb 22 13:01:04 <weierophinney> can I get a volunteer?
Feb 22 13:01:13 <weierophinney> please?
Feb 22 13:01:34 <Akrabat> do we have db\table still?
Feb 22 13:01:40 <DASPRiD> (hopefully not)
Feb 22 13:01:43 <Akrabat> or is that not refactored this round?
Feb 22 13:01:46 <weierophinney> Akrabat, yes – that was part of this beta.
Feb 22 13:01:51 <weierophinney> (and yes, refactored)
Feb 22 13:02:00 <weierophinney> ralphschindler, can you point Akrabat to table examples?
Feb 22 13:02:06 <Akrabat> I'll do db\table as part of my tutorial
Feb 22 13:02:12 <weierophinney> Akrabat, that's awesome, thanks
Feb 22 13:02:14 <EvanDotPro> weierophinney: we could try using zend\db in a ZfcUser branch
Feb 22 13:02:21 <Thinkscape> ralphschindler: does it have lastInsertId() ?
Feb 22 13:02:26 <ralphschindler> Thinkscape: yes
Feb 22 13:02:27 <Akrabat> afk - kids bedtime
Feb 22 13:02:29 <Akrabat> thanks guys
Feb 22 13:02:29 <ralphschindler> Akrabat: https://github.com/ralphschindler/Zend_Db-Examples/blob/master/example-06.php
Feb 22 13:02:29 <weierophinney> EvanDotPro, that would be awesome - do you have time?
Feb 22 13:02:31 <ralphschindler> 6-9
Feb 22 13:02:41 <ralphschindler> examples 6-9 that is
Feb 22 13:02:52 <weierophinney> kk, so:
Feb 22 13:02:56 <weierophinney> * code freeze Monday
Feb 22 13:03:00 <EvanDotPro> weierophinney: i might, i wanna knock out the few stories on agilezen that i have pending too but those are really minor.
Feb 22 13:03:05 <Thinkscape> ralphschindler: is query abstr. finished?
Feb 22 13:03:06 <DASPRiD> btw, i gotta leave here soon as well, can somebody post me the i18n log so i can update the RFC based on that?
Feb 22 13:03:14 <weierophinney> * Akrabat and EvanDotPro to try out Zend\Db on projects
Feb 22 13:03:21 <ralphschindler> Thinkscape: sql abstraction has basic implementation
Feb 22 13:03:25 <weierophinney> * Matthew to hit the PR queue
Feb 22 13:03:32 <weierophinney> * EVERYONE to help with docs.
Feb 22 13:03:34 <ralphschindler> trying to get the metadata component finished up
Feb 22 13:03:43 <DASPRiD> * DASPRiD to review Config
Feb 22 13:03:52 <weierophinney> DASPRiD, I'll get the log posted today.
Feb 22 13:03:58 <DASPRiD> weierophinney, perfect, thx
Feb 22 13:04:03 <weierophinney> DASPRiD, and, yes, good note on Config
Feb 22 13:04:37 <weierophinney> Thinkscape, you can see what ralphschindler has been working on on the board, btw – all are under the "completed" heading (except metadata)
Feb 22 13:04:37 <DASPRiD> are we through now?
Feb 22 13:04:42 <weierophinney> I think so, yes.
Feb 22 13:04:49 <weierophinney> Any last words, or do we call it a day?
Feb 22 13:04:59 <DASPRiD> i call it a meeting
Feb 22 13:05:00 <ocramius> awesome day, not just day
Feb 22 13:05:02 <Thinkscape> you rock!
Feb 22 13:05:04 <ocramius> very well done!
Feb 22 13:05:11 <EvanDotPro> good meeting
Feb 22 13:05:15 <EvanDotPro>
Feb 22 13:05:27 <weierophinney> I'll get the log up in a bit, and I've taken notes for the forms rfc.
Feb 22 13:05:32 <DASPRiD> mwop calls it his 4th meeting today
Feb 22 13:05:43 <weierophinney> everyone, start testing the view layer, and the DB stuff so we can merge.