Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="toc" />


<li>Date: 08 February 2012, 18:00-19:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2012-02-08 Meeting Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Matthew Weier O'Phinney (nickname weierophinney)</li>
<li>Next meeting: 15 February 2012</li>


<h3>Discuss readiness of Console/CLI RFC</h3>

<p>Artur Bodera (aka Thinkscape) has taken over the Console RFC, and has written <ac:link><ri:page ri:content-title="RFC - Console 2.0" /><ac:link-body>a new/revised version</ac:link-body></ac:link>. During the meeting, we discussed readiness of the proposals, and provided initial feedback.</p>

<p>The primary feedback was:</p>

<li>Merge the concepts of CLI and Console into a single component to avoid confusion; vote was for "Console".</li>
<li>There's some concern about having ViewModels compose prompts, as it may create added complexity both for end users and for dispatching. However, Thinkscape indicated that prompts did not <em>need</em> to go through ViewModels, and could be executed directly in an action if desired; as such, the proposed solution provides flexibility of implementation for users.</li>
<li>All agreed that examples/use cases detailing each of the following need to be added to the RFC:
<li>Usage of Console in standalone scripts</li>
<li>Usage of Console in the MVC as console-only controllers/actions</li>
<li>Usage of Console in the MVC in a mixed console/HTTP paradigm</li>

<p><strong>tl;dr</strong>: The new Console RFC is looking solid, and development is on track for beta3; we can vote on inclusion next week.</p>

<h3>ViewModels and Controller return values</h3>

<p>(Search for "18:26:16" in the log.)</p>

<p>Matthew raised a discussion based on prototyping the View Layer. His argument was:</p>

<p><ac:link><ri:page ri:content-title="T" /></ac:link>he original discussion of the View Layer RFC included some folks indicating they'd like to be able to return simply arrays from their controllers, and have the view layer transform those to View Model objects automatically. In usage, however, I find a few potential issues with it. First, it's "magic", and that means more code is running (performance degradation), and harder to debug workflows ("I don't know where this is happening"). I think we can still accommodate simple scalars and arrays – but I'd like to suggest that we <em>recommend</em> always returning a View Model. Which would mean all examples would show this, and we'd recommend this practice for distributing your modules.</p></blockquote>

<p>Discussion generally favored this approach, though Artur (aka Thinkscape) argued that he felt returning arrays is a simpler story. (The counter-argument to this is that it means educating users in conventions that are ultimately configurable and/or even ignored; additionally, it means invalidating what was taught later when teaching about ViewModels.)</p>

<p>In the end, despite most participants agreeing with the proposal, we decided to move the discussion to the list.</p>

<p><strong>tl;dr</strong>: Everybody has strong opinions when it comes to the view layer.</p>

<h3>Options: should they be mutable?</h3>

<p>(Search for "18:57:45" in the log.)</p>

<p>Matthew raised the idea of allowing Options classes to be immutable, indicating he's run into a number of situations recently where allowing changes leads to either code complexity or exceptional conditions. He proposed adding a flag to the base Options class to allow marking the instance immutable if desired (something that would be done when accepting an Options instance in a constructor, for instance).</p>

<p>Several indicated it might be nice to be able to have granularity of this within Options classes – some options might need to be immutable, while others could allow changes.</p>

<p>Ralph (aka ralphschindler) noted towards the end of the discussion that he felt the various options inside an Options class should be pulled and composed directly as properties – a solution that would solve the mutability problem, but require refactoring a number of classes currently using Options at this time.</p>

<p>In the end, we decided to take this topic to the mailing list, too.</p>

<p><strong>tl;dr</strong>: Immutability seems like a good option, but the community has a number of different ideas on how to accomplish it.</p>


<ac:macro ac:name="html"><ac:parameter ac:name="output">html</ac:parameter><ac:plain-text-body><![CDATA[
pre.log {
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) */
word-wrap: break-word; /* IE 5.5+ */
border: 1px solid darkgray;
padding: 0.5em;
<pre class="log">
Feb 08 18:02:21 <weierophinney> FIRST TOPIC: Readiness of Cli/Console RFC.
Feb 08 18:02:22 <Thinkscape> And in a week or two they will be crying out: "WHY DOES MY CODEZ THROW EXCEPTIONZES?"
Feb 08 18:02:30 <DASPRiD> i'd like to do it, but coding parallely stops me frm it
Feb 08 18:02:30 <weierophinney> URL is here:
Feb 08 18:02:45 <weierophinney> Thinkscape, want to take it from here?
Feb 08 18:02:51 <Thinkscape> Sure.
Feb 08 18:02:57 <Thinkscape> There is a lot to describe.
Feb 08 18:03:02 <Thinkscape> I assume you've read it
Feb 08 18:03:06 <weierophinney> My first question: can it be done in the next 2 - 2.5 weeks?
Feb 08 18:03:10 <Thinkscape> or skim at least
Feb 08 18:03:16 <Thinkscape> Yes it can.
Feb 08 18:03:19 <weierophinney> or at least mostly feature complete.
Feb 08 18:03:22 <weierophinney> awesome.
Feb 08 18:03:26 <Thinkscape> My followup -is view rendering ready for it ?
Feb 08 18:03:45 <Thinkscape> i.e. renderingstrategies to handle my rendering logic
Feb 08 18:03:52 <weierophinney> Thinkscape, all you need to do is write a rendering strategy.
Feb 08 18:03:57 <weierophinney> and a renderer
Feb 08 18:04:00 <weierophinney> and you're good to go.
Feb 08 18:04:04 <Thinkscape> ok
Feb 08 18:04:06 <Thinkscape> I'd like to ask everyone to relate to the CLI APPLICATION WORKFLOW first
Feb 08 18:04:09 <Thinkscape> it's in RFC.
Feb 08 18:04:20 <Thinkscape> It describes how the application will work.
Feb 08 18:04:29 <Thinkscape> Very short:
Feb 08 18:04:34 <Thinkscape> 1. arguments fly in
Feb 08 18:04:40 <Thinkscape> 2. They are routed, so a route matches
Feb 08 18:04:49 <Thinkscape> 3. Route points to a specific controller (in module) and action
Feb 08 18:05:03 <Thinkscape> 4. Action receives a $cliRequest containing all parameters the user supplied
Feb 08 18:05:08 <Thinkscape> 5. Action performs some tasks
Feb 08 18:05:20 <Thinkscape> 6. It returns a string — that is then output to the terminal
Feb 08 18:05:21 <Thinkscape> [end]
Feb 08 18:05:22 <Thinkscape> OR
Feb 08 18:05:27 <Thinkscape> 6a.
Feb 08 18:05:39 <Thinkscape> The Action returns a ViewModel that includes prompt definitions
Feb 08 18:05:50 <DASPRiD> objection
Feb 08 18:05:53 <Thinkscape> i.e. Prompt the user for his name, then his age, then his gender (+ validators)
Feb 08 18:05:57 <Thinkscape> wait
Feb 08 18:06:00 <DASPRiD> k
Feb 08 18:06:18 <Thinkscape> 7. This ViewModel is then parsed by a Strategy, and it creates and shows prompts to the user
Feb 08 18:06:34 <Thinkscape> 8. Prompt responses (i.e. name, age, gender) are merged into the $cliRequest
Feb 08 18:06:43 <Thinkscape> 9. It is fed BACK into the Action, so it can continue its work.
Feb 08 18:06:50 <Thinkscape> 10. If more data is needed - repeat
Feb 08 18:06:55 <EvanDotPro> +1 for 6a, i could imagine that would leave it much more flexible for customizations by users than simply outputting strings.
Feb 08 18:06:57 <Thinkscape> 10b. If not — return result and end application
Feb 08 18:07:15 <DASPRiD> 6a way is more the direction i like
Feb 08 18:07:30 <Thinkscape> Both are options
Feb 08 18:07:37 <DASPRiD> what about continious output? doing a task (maybe displaying zend\progressbar while doing), outputing some text, doing next action, etc.
Feb 08 18:07:42 <Thinkscape> for simple requests - you just return "All went well";
Feb 08 18:07:42 <weierophinney> Thinkscape, I'd argue that 6a is not the per-view of the view, however. I'd call that input – though it obviously has a "view" element in order to display the prompts.
Feb 08 18:07:50 <Thinkscape> for complex ones - you need more data (prompts)
Feb 08 18:07:52 <EvanDotPro> now – for multi-prompt cli apps, we'll have multiple request-response-render cycles?
Feb 08 18:07:53 <prolic> short question: why not add php-gtk to zend\console then ? sounds great
Feb 08 18:08:10 <robertbasic> good evening. will just lurk around tonight ...
Feb 08 18:08:13 <DASPRiD> prolic, gtk to console?
Feb 08 18:08:16 <ralphschindler> question: does Zend\Console have any dependencies on other components?
Feb 08 18:08:17 <DASPRiD> u r doing it wrong, sir
Feb 08 18:08:18 <lubs> prolic: -l
Feb 08 18:08:22 <weierophinney> EvanDotPro, not sure if we'd need that. Prompting is usually done to gather input in order to determine what action to take.
Feb 08 18:08:24 <Thinkscape> prolic: i've got nothing against it. It can be a Console\Adapter
Feb 08 18:08:26 <lubs> no good lol
Feb 08 18:08:32 <Thinkscape> ralphschindler: not really
Feb 08 18:08:46 <weierophinney> prolic, that could be done at a later date. Kind of out-of-scope for the initial work.
Feb 08 18:08:46 <ralphschindler> the only dependencies are Zend\Mvc\Cli* to Zend\Console, right?
Feb 08 18:08:48 <Thinkscape> ralphschindler: but Cli yes — mainly validators, filters and Text
Feb 08 18:08:49 <lubs> gtk... is not exactly a console app anymore... yes could be booted from the console but why?
Feb 08 18:08:51 <EvanDotPro> weierophinney: true
Feb 08 18:09:19 <Thinkscape> ralphschindler: yes, Zend\Mvc*Cli* depends on Zend\Cli — Zend\Cli depends on Zend\Console\Adapter
Feb 08 18:09:39 <DASPRiD> Thinkscape, read my message?
Feb 08 18:09:39 <Thinkscape> EvanDotPro: yes, you can have multiple (looped) request dispatched
Feb 08 18:09:48 <ralphschindler> from an uneducated user perspective, will people understand the responsibilities of CLI vs. Console ?
Feb 08 18:09:53 <Thinkscape> You could have a text-based RPG game handled by that request loop... for example.
Feb 08 18:10:02 <prolic> i am just asking because i'm not sure the console adapter interface valuable enough to work with php-gtk
Feb 08 18:10:05 <weierophinney> Why are we differentiating between CLI and Console, again (I guess I'm +1'ing ralphschindler now, since I'm a slow typist)
Feb 08 18:10:18 <Thinkscape> DASPRiD: yes, later, it's implementation details.
Feb 08 18:10:25 <DASPRiD> +1, cli and console is the same for me
Feb 08 18:10:29 <Thinkscape> Cli vs Console —
Feb 08 18:10:33 <EvanDotPro> Zend\Cli\Console anyone?
Feb 08 18:10:41 <EvanDotPro> or just merge them altogether
Feb 08 18:10:42 <Thinkscape> Console is low-level access... such as Input/Output ....
Feb 08 18:10:44 <prolic> +1 evan
Feb 08 18:10:54 <weierophinney> Thinkscape, then what is CLI?
Feb 08 18:10:56 <Thinkscape> CLI is INTERFACE and contains Widgets, Prompts, logic-related Interactive stuff...
Feb 08 18:11:02 <Thinkscape> Command Line Interface
Feb 08 18:11:16 <Thinkscape> It's per original RFC
Feb 08 18:11:21 <weierophinney> I KNOW what CLI stands for – I'm simply not sure why we're differentiating them.
Feb 08 18:11:26 <DASPRiD> Thinkscape, so command line parser goes into console?
Feb 08 18:11:32 <weierophinney> I didn't understand the differentiation in the original RFC, either.
Feb 08 18:11:36 <ralphschindler> from the perspective of PHP, cli and console are the same thing
Feb 08 18:11:54 »» DASPRiD votes for merging cli and console
Feb 08 18:11:58 <ralphschindler> that level of abstraction doesn't really offer much (trust me, I know from experience in Zend_Tool )
Feb 08 18:11:59 <prolic> agreed, that's confusing
Feb 08 18:12:05 <Thinkscape> DASPRiD: Yes, because command line options are console options by the original RFC definition.
Feb 08 18:12:12 <Thinkscape> hmm.... ok
Feb 08 18:12:13 <Thinkscape> then propose
Feb 08 18:12:15 <Thinkscape> CLI
Feb 08 18:12:17 <Thinkscape> or CONSOLE ?
Feb 08 18:12:19 <Thinkscape> which one ?
Feb 08 18:12:26 <ralphschindler> Zend_Tool has layers of abstract that have gone completely unused
Feb 08 18:12:28 <DASPRiD> Zend\CommandLine ?
Feb 08 18:12:32 <weierophinney> I'd go with console. I'm not a fan of acronyms as namespaces.
Feb 08 18:12:34 <EvanDotPro> anything console with php will be accesed via a CLI..
Feb 08 18:12:36 <ralphschindler> if the Mvc has Cli in it
Feb 08 18:12:40 <ralphschindler> then there should be Zend\Cli
Feb 08 18:12:46 <MikeA_> Console +1
Feb 08 18:12:47 <ralphschindler> if mvc has console, then Zend\COnsole
Feb 08 18:12:47 <weierophinney> and the component namespace already exists (Console)
Feb 08 18:13:03 <Thinkscape> ralphschindler: it's a mixture.... because currently Mvc contains HTTP routes
Feb 08 18:13:08 <Thinkscape> so that's why I put CLI routes beside them
Feb 08 18:13:14 <EvanDotPro> +1 for whichever one has mojority vote
Feb 08 18:13:22 <DASPRiD> +1 for console then tho
Feb 08 18:13:31 <DASPRiD> because it's already Zend\ProgressBar\Adapter\Console as well
Feb 08 18:13:42 <ralphschindler> +1 on majority, so long as Zend\Mvc*name* and Zend\name are the same
Feb 08 18:13:43 <weierophinney> +1 for console
Feb 08 18:13:56 <prolic> +1 for console
Feb 08 18:13:57 <Thinkscape> How about a vote on wiki ?
Feb 08 18:13:57 <ezimuel> +1 for console
Feb 08 18:14:16 <prolic> anybody for cli? otherwise it's obvious
Feb 08 18:14:19 <Thinkscape> short one. I'll refactor everything to Console in the meantime ....
Feb 08 18:14:21 <weierophinney> Thinkscape, I'd argue we should decide now, so you don't have to waste time later renaming.
Feb 08 18:14:40 <Thinkscape> Not very democratic, but ok
Feb 08 18:14:40 <lubs> yes let's use console
Feb 08 18:14:46 <lubs> although it's more to type
Feb 08 18:14:47 <Thinkscape> Will do
Feb 08 18:14:51 <ralphschindler> as i said, if its Zend\Console, I'd also expect to see Zend\Mvc\ConsoleApplication not Zend\Mvc\CliApplication
Feb 08 18:14:54 <Thinkscape> lubs: use USE
Feb 08 18:15:02 <Thinkscape> ralphschindler: correct
Feb 08 18:15:03 <weierophinney> Thinkscape, next question: I mentioned earlier that I'd see doing prompts as part of your action's body, not via ViewModel. THoughts?
Feb 08 18:15:05 <lubs> i know i know lol
Feb 08 18:15:11 <ralphschindler> +1 on console from me then
Feb 08 18:16:05 <Thinkscape> weierophinney: one of the advantages of streamlined prompts support is the automation and removal of boilerplate — for example, your prompts can come with validators and filters that are handled implicitly (and never pass unfiltered values) by ConsoleApplication.
Feb 08 18:16:14 <Thinkscape> Also - this allows for later branching.
Feb 08 18:16:35 <weierophinney> Thinkscape, right – but that could still be done outside ViewModels, right?
Feb 08 18:16:43 <Thinkscape> For example: you could have interactiveAction() — that generates a series of prompts, but the data is then fed into performtaskAction()
Feb 08 18:16:50 <DASPRiD> Thinkscape, btw, this may be useful for you in the close future:
Feb 08 18:17:15 <Thinkscape> yes! You can always use prompts manually: $prompt = new Prompt\Line("What is your name?"); $name = $prompt->show();
Feb 08 18:17:18 <weierophinney> Thinkscape, right – but in that case, I'd have interactiveAction generate and execute the prompts, and then decide from there what to execute. If it's another action method in the same controller, you just call it.
Feb 08 18:17:50 <Thinkscape> DASPRiD: this will fail under windows for non ascii-80 chars
Feb 08 18:18:04 <weierophinney> Thinkscape, That would also keep the decision-making in a discoverable place.
Feb 08 18:18:10 <DASPRiD> Thinkscape, needs some optimizations certainly
Feb 08 18:18:28 <Thinkscape> DASPRiD: no, "impossible" as cannot-do without third-party EXE helper.
Feb 08 18:18:42 <DASPRiD> Thinkscape, that one is meant for *nix only anyway
Feb 08 18:18:44 <Thinkscape> I've read through ALL available dos and windows commands And I use all of them (which are fit)
Feb 08 18:18:57 <Thinkscape> DASPRiD: no, Zend\Console is cross platform
Feb 08 18:19:07 <Thinkscape> Why would passwords be not-obscured in windows ?
Feb 08 18:19:13 <Thinkscape> weierophinney: hmm... managable, yes
Feb 08 18:19:17 <weierophinney> DASPRiD, off topic for right now, regardless. The main point right now is to discuss the RFC.
Feb 08 18:19:20 <DASPRiD> Thinkscape, zend\console\process\unix…
Feb 08 18:19:24 <DASPRiD> weierophinney, agreed
Feb 08 18:19:43 <Thinkscape> weierophinney: good point on that, but this negates the whole idea of cli request loop.
Feb 08 18:19:52 <Thinkscape> And you must do it all manually
Feb 08 18:19:59 <Thinkscape> and it will fail with universal (cli+http) controllers.
Feb 08 18:20:00 <weierophinney> Thinkscape, not necessarily – but it may obviate the need for one as well.
Feb 08 18:20:09 <Thinkscape> I.e. - you can have installModule controller with installAction()
Feb 08 18:20:23 <weierophinney> Thinkscape, as long as both are possible, I'm happy, tbh.
Feb 08 18:20:30 <Thinkscape> if we have prompts automated with ConsoleApp you could use the same controller with BOTH web-based installer AND CLI
Feb 08 18:20:40 <weierophinney> I just think that having the prompts in the view model may be hard for many to decipher.
Feb 08 18:20:48 <Thinkscape> no need for if(PHPSAPI == "foo"0
Feb 08 18:21:04 <Thinkscape> weierophinney: why? We do it with layout hints too
Feb 08 18:21:18 <Thinkscape> layout=>"foo" — where does THAT come from ? how does it work ?
Feb 08 18:21:19 <Thinkscape> etc.
Feb 08 18:21:19 <weierophinney> I'm moving away from that. See the email from last night.
Feb 08 18:21:29 <Thinkscape> hmm... I will.
Feb 08 18:21:40 <Thinkscape> I think I'll focus on semi-interactive for now
Feb 08 18:21:44 <weierophinney> kk
Feb 08 18:21:47 <Thinkscape> and we'll get back to it in one week
Feb 08 18:21:56 <Thinkscape> I'll show how it might look like
Feb 08 18:21:58 <Thinkscape> and we'll decide
Feb 08 18:22:00 <Thinkscape> if it's:
Feb 08 18:22:03 <Thinkscape> 1) easy to use
Feb 08 18:22:05 <weierophinney> Those were the only bits I wasn't really sure of in the RFC (cli vs console naming, prompts in view models)
Feb 08 18:22:06 <Thinkscape> 2) useful
Feb 08 18:22:22 <weierophinney> Anybody else have any concerns or suggestions for Thinkscape ?
Feb 08 18:22:43 <ralphschindler> I think 3 primary use-cases need to be identified by pseudo code:
Feb 08 18:23:11 <ralphschindler> 1) using Console by itself, 2) developing a console only application and 3) developing an http and console application within the same codebase
Feb 08 18:23:13 <Thinkscape> I'll keep sending updates to ML about changes to Zend\Console. I'll also keep adding demos to illustrate them.
Feb 08 18:23:23 <Thinkscape> ralphschindler: roger
Feb 08 18:23:39 <weierophinney> kk, so, going once...
Feb 08 18:23:40 <Thinkscape> I like the difficulty graduation you've done here
Feb 08 18:23:54 <weierophinney> twice....
Feb 08 18:24:08 <weierophinney> done!
Feb 08 18:24:11 <weierophinney> Next topic!
Feb 08 18:24:14 <ralphschindler> if 3 means theres too much abstraction that is too hard to follow, we'd need to discuss that next week
Feb 08 18:24:19 <weierophinney> ViewModels and Controller return values
Feb 08 18:24:24 »» Thinkscape is open to suggestions - feel free to mail me or post to ML
Feb 08 18:24:33 <Thinkscape> ralphschindler: agreed.
Feb 08 18:24:42 <ralphschindler> Cli apps and Http apps have completely different workflows that may or may not be worthwhile combining
Feb 08 18:24:52 <EvanDotPro> ralphschindler: another thing to consider is console-only modules
Feb 08 18:25:06 »» ralphschindler is done throwing out his 2c pieces
Feb 08 18:25:22 <weierophinney> from what I can see, Thinkscape is addressing each style – mixed-use controllers, console-specific controllers, and standalone scripts.
Feb 08 18:25:25 <Thinkscape> ralphschindler: it depends on the task you want to perform though
Feb 08 18:25:40 <Thinkscape> weierophinney: the next one on Agenda relates to that
Feb 08 18:25:41 <weierophinney> the main thing is getting some examples up for folks to look at and comment on.
Feb 08 18:25:47 <Thinkscape> can my CLI actions return "string"; ?
Feb 08 18:25:48 <EvanDotPro> weierophinney: +1, i can see how all the workflows could work at this point.. i'm not identifying any gaps.
Feb 08 18:25:52 <ralphschindler> i thnk weierophinney wants to move on, we can discuss #3 in the zftalk room
Feb 08 18:25:58 <weierophinney> hehe
Feb 08 18:26:08 <weierophinney> So, really, NEXT TOPIC
Feb 08 18:26:13 <Thinkscape> weierophinney: ^^
Feb 08 18:26:14 <Solow> :')
Feb 08 18:26:16 <weierophinney> ViewModels and controller return values.
Feb 08 18:26:58 <Thinkscape> I do feel like controllers should be able to return arrays() and "strings" — the main caveat here is to make Application behavior consistent in this scenario.
Feb 08 18:26:59 <weierophinney> so, the original discussion of the View Layer RFC included some folks indicating they'd like to be able to return simply arrays from their controllers, and have the view layer transform those to View Model objects automatically.
Feb 08 18:27:23 <weierophinney> In usage, however, I find a few potential issues with it.
Feb 08 18:27:57 <weierophinney> First, it's "magic", and that means more code is running (performance degradation), and harder to debug workflows ("I don't know where this is happening").
Feb 08 18:28:18 <prolic> yes, better we'd be returning view model objects
Feb 08 18:29:14 <EvanDotPro> +1 on consistently returning view models. makes education easier.
Feb 08 18:29:15 <weierophinney> I think we can still accommodate simple scalars and arrays – but I'd like to suggest that we recommend always returning a View Model. Which would mean all examples would show this, and we'd recommend this practice for distributing your modules.
Feb 08 18:29:42 <ralphschindler> weierophinney: wouldn't that be a feature of the ActionController itself?
Feb 08 18:29:45 <Thinkscape> On the contrary - it's intuitive, easy to use, self-explanatory for most applications (return array( of arguments for template ) )
Feb 08 18:29:52 <weierophinney> This would also make it possible to turn off a listener that transforms these alternate return values.
Feb 08 18:30:06 <ralphschindler> $this->castArrayToViewModel = true ?
Feb 08 18:30:34 <Thinkscape> ralphschindler: weierophinney: may I ask, what would happen if that listener/feature was turned off and user's code STILL returned array ?
Feb 08 18:30:35 <weierophinney> Thinkscape, what's not intuitive is that it becomes a ViewModel object. It's also not intuitive as to what template would be selected for that object.
Feb 08 18:30:36 <Solow> Is this returning vs setting?
Feb 08 18:30:38 <Thinkscape> what would happen ?
Feb 08 18:30:51 <weierophinney> Thinkscape, likely an exception or error page.
Feb 08 18:30:58 <weierophinney> Solow, returning
Feb 08 18:30:59 <Thinkscape> then I dislike it ...
Feb 08 18:31:07 <Thinkscape> changing view template is a "feature"
Feb 08 18:31:11 <Thinkscape> layouts — too
Feb 08 18:31:26 <weierophinney> Thinkscape, changing view templates is simpler if we have a view model object.
Feb 08 18:31:33 <weierophinney> it's also easier
Feb 08 18:31:41 <weierophinney> to understand (sorry, hit return early)
Feb 08 18:31:47 <Thinkscape> i.e. view template selection should be a responsiblity of a strategy. If user want's to short-circuit that (by forcing another view template) then it's not "standard".
Feb 08 18:31:53 <weierophinney> $model->setOption('template', 'new/template')
Feb 08 18:32:01 <Thinkscape> I know
Feb 08 18:32:03 <ralphschindler> Thinkscape: I'm saying its not done in a listener, its done in execute()
Feb 08 18:32:07 <Thinkscape> but most people will NOT change them
Feb 08 18:32:44 <weierophinney> Thinkscape, also, remember we have resolvers – which provide another opportunity for changing what template is actually rendered – you can map the identifier for the template to another location or resource.
Feb 08 18:32:54 <ralphschindler> instead of this: , you'd be converting it to a ViewModel
Feb 08 18:33:02 <Thinkscape> i.e. – zf1 basic examples revolve around using views (templates). Then (at next tutorial topic) we introduce layout changes and view script changes.
Feb 08 18:33:13 <Thinkscape> weierophinney: yes
Feb 08 18:34:01 <Thinkscape> ralphschindler: why is it there ? Shouldn't it be in some listener ?
Feb 08 18:34:13 <ralphschindler> as i said, it would be a feature of ActionController
Feb 08 18:34:37 <ralphschindler> if you're extending ActionController in the first place, then you're also subscribing to its features
Feb 08 18:34:50 <Thinkscape> it could also not be a feature of ActionController
Feb 08 18:35:00 <ralphschindler> then you don't have to worry with 3rd party objects (listeners) , you know your action when returning an array, will cast it to a ViewModel
Feb 08 18:35:04 <weierophinney> Thinkscape, I'm saying we have that listener available that can convert non ViewModel returns to ViewModels, and inject the template if none is already present. I'm simply saying that (a) this should be something that can be opt'd out of, and (b) we should recommend returning a ViewModel to ensure explicitness of intent.
Feb 08 18:36:30 <Thinkscape> hmm... i'm not sure about (a). That is because it's a behavior that prevents exceptions. Exceptions are more quirky than just handling a view request with wrong view template (which should not happen if you configure your resolvers correctly).
Feb 08 18:36:36 <Thinkscape> Why would anyone disable (a) ?
Feb 08 18:36:51 <Thinkscape> (risking failure of some modules, including his/her own)
Feb 08 18:37:29 <weierophinney> Thinkscape, I'd disable it for performance reasons.
Feb 08 18:37:39 <Thinkscape> small gain. One if()
Feb 08 18:38:14 <Thinkscape> + listener overhead, I know.
Feb 08 18:38:17 <weierophinney> Thinkscape, not just site performance, but developer performance. I'd measure the code quality of the site by the explicitness of my action methods.
Feb 08 18:38:22 <Thinkscape> (unless it stays where ralphschindler suggested)
Feb 08 18:38:57 <weierophinney> Thinkscape, btw... you seem to be the only one arguing for looser returns.
Feb 08 18:38:58 <weierophinney>
Feb 08 18:39:03 <Thinkscape> weierophinney: yes, but it should not be forced in such self-explanatory use case.
Feb 08 18:39:11 »» Thinkscape scratches his head wondering why ?
Feb 08 18:39:31 <Thinkscape> I'm fine with being able to disable that.
Feb 08 18:39:33 <prolic> weierophinney: how do you measure your code quality with explicitness? do you have any tools for that?
Feb 08 18:39:38 <Thinkscape> Actually with EM, you can do anything.
Feb 08 18:39:45 <weierophinney> prolic, unit tests.
Feb 08 18:40:18 <Thinkscape> You could even unshift that listener... but I'd not recommend that if we allow for returning arrays.
Feb 08 18:40:46 <Thinkscape> It's kinda incosistent, but It's either a feature that is there, or it's removed and we never speak of it again (to avoid confusion)
Feb 08 18:40:57 <weierophinney> Thinkscape, I'd argue we would register the listener in the SkeletonApp – which then allows somebody to remove that line later.
Feb 08 18:41:11 <prolic> weierophinney: i never get explicit: xx%, non-explicit xx% back from phpunit
Feb 08 18:41:12 <Thinkscape> naah.. that's too far of explicitness.
Feb 08 18:41:21 <Thinkscape> think: basic zf2 tutorial (without skeleton)
Feb 08 18:41:34 <weierophinney> prolic, that's not the point – I'm saying that having explicit returns makes unit testing easier. That's my measure.
Feb 08 18:41:48 <weierophinney> Thinkscape, the basic zf2 tutorial uses the skeleton.
Feb 08 18:41:51 <prolic> ok
Feb 08 18:42:02 <Thinkscape> I know, that's not good IMO.
Feb 08 18:42:04 <Thinkscape> For example - each php framework has got it's quickstart, basic tutorial.
Feb 08 18:42:10 <Thinkscape> i.e. SIMPLEST Action controller
Feb 08 18:42:13 <weierophinney> greets PadraicB – we're on the viewmodels section of the agenda right now.
Feb 08 18:42:21 <Thinkscape> I'd hate for it to use something like ViewModel (which is complex by it's nature)
Feb 08 18:42:23 <weierophinney> Thinkscape, and that tutorial would show returning a ViewModel.
Feb 08 18:42:33 <Thinkscape> weierophinney: convoluted...
Feb 08 18:42:38 <weierophinney> I think that properly shows separation of concerns.
Feb 08 18:42:46 <weierophinney> and shows what objects are at play
Feb 08 18:43:08 <Thinkscape> explicit: yes.... easy to explain: no .... easy to read: no ... easy to understand from the example: no
Feb 08 18:43:13 <weierophinney> "controllers return information a view can use to render"
Feb 08 18:43:27 <Thinkscape> but you use the term ViewModel – you need to explain that...
Feb 08 18:43:35 <Thinkscape> (at the point the user creates his FIRST action controller)
Feb 08 18:43:37 <prolic> link martin fowler?
Feb 08 18:43:45 <Thinkscape> read: beginner developer
Feb 08 18:43:50 <Thinkscape> prolic: lol
Feb 08 18:44:11 <weierophinney> Thinkscape, returning an array means you then have to explain how the requested controller/action are then mapped to a view script, and how those variables are then injected.
Feb 08 18:44:15 <weierophinney> It's trade-offs.
Feb 08 18:44:37 <Thinkscape> wait wait.... view script mapping is NOT primary responsibility of ViewModel
Feb 08 18:44:40 <Thinkscape> you STILL have to explain that
Feb 08 18:44:42 <Thinkscape> arrays or otherwise )
Feb 08 18:44:57 <Thinkscape> how variables are injected — who cares "how" ?
Feb 08 18:45:08 <DASPRiD> (still on console?)
Feb 08 18:45:09 <Thinkscape> as long as I can write echo $this->variable
Feb 08 18:45:16 <Thinkscape> DASPRiD: long gone
Feb 08 18:45:17 <weierophinney> Thinkscape, returning an array means that I'm not explicitly telling which view script I want to use – it's being selected for me. So now you need to explain those rules.
Feb 08 18:45:26 <DASPRiD> Thinkscape, k
Feb 08 18:45:29 <ralphschindler> Thinkscape: with EM, can't you just inject your own array->viewmodel casting listener?
Feb 08 18:45:33 <weierophinney> If you return an explicit view model, and indicate the template to use, nothing to explain.
Feb 08 18:45:57 <Thinkscape> weierophinney: I thought resolver was the primary mapping mechanism
Feb 08 18:46:04 <Thinkscape> not explicit view template name definition
Feb 08 18:46:12 <MikeA_> Thinkscape: I'm writing a detailed tutorial ATM – it's not the View that's complicated – it's whats happening beforehand, say at dispatch level
Feb 08 18:46:16 <weierophinney> Thinkscape, we're talking two separate things here.
Feb 08 18:46:33 <PadraicB> No idea what way the vote goes - but returning some kind of object makes more sense if we have to return something
Feb 08 18:46:46 <Thinkscape> i.e. in the first, simplest tutorial, do we want to teach people how to change the behavior of the mapper ? or just show how to write a simple controller action (that yes, is automatically mapped to fooAction() -> foo.phtml)
Feb 08 18:46:48 <weierophinney> Thinkscape, the ViewModel should have the name of a template to use in it. This is passed to a resolver by the renderer in order to get a resource/template/whatever the renderer can use.
Feb 08 18:47:03 <ocra|afk> re
Feb 08 18:47:07 »» ocra|afk is now known as ocramius
Feb 08 18:47:10 <weierophinney> If that template name is NOT in the ViewModel, then we have two options:
Feb 08 18:47:22 <MikeA_> FWIW, I'm for ViewModel and discuss how to deal with the array issue once we've had time to use it
Feb 08 18:47:23 <Akrabat> I'm of the opinion that the ViewModel should only return a template if you need one that is not the default
Feb 08 18:47:28 <weierophinney> 1) raise an exception ("FooRenderer cannot render – no template specified")
Feb 08 18:47:31 <Thinkscape> are you implying, that standard fooAction() ----> foo.phtml will not work with skeleton ?
Feb 08 18:47:50 <weierophinney> 2) Have a listener that auto-injects the template name based on the requested controller/action/whatever routematch criteria.
Feb 08 18:48:12 <Evil_Otto> configuration versus convention strikes again
Feb 08 18:48:18 <Thinkscape> 2) was numer 1 in zf1 — when did that change ?
Feb 08 18:48:26 <weierophinney> Thinkscape, if you return an assoc array, this criteria must be explained in the tutorial. I'd argue the tutorial should show explicit first, and later show conventions-based.
Feb 08 18:48:42 <MikeA_> weierophinney: +1
Feb 08 18:48:48 <weierophinney> Thinkscape, we'll still be offering that functionality.
Feb 08 18:48:50 <PadraicB> Thinkscape, because it sucked?
Feb 08 18:49:11 <Thinkscape> that means there will be no quickstart tutorial for zf2..... or there will be slowstart (after reading "zf2 configuration manual").
Feb 08 18:49:21 <Thinkscape>
Feb 08 18:49:41 <ocramius> Thinkscape: cloning the skeleton should always be enough, or?
Feb 08 18:49:46 <weierophinney> The whole point of this discussion, though, is what I said at the start: I think we should recommend returning ViewModels from controllers, and do that in all examples (and recommend it for distributed modules)
Feb 08 18:49:55 <Thinkscape> ocramius: yes, but per weierophinney, it will not work as in zf1
Feb 08 18:50:00 <catalinciupic> what about an action performed by console? what should return?
Feb 08 18:50:06 <weierophinney> It's much easier to adopt a convention if you already know how to do it explicitly.
Feb 08 18:50:17 <weierophinney> Thinkscape, you're misunderstanding me, I think.
Feb 08 18:50:21 <Thinkscape> weierophinney: it increases learning curve drastically
Feb 08 18:50:27 <ocramius> Thinkscape: I'll have to read backlog, I lot a bit here
Feb 08 18:50:57 <weierophinney> Thinkscape, obviously, you haven't had to answer as many questions as I have about "where should I put my view script? what should I call it? why isn't the one I think being rendered?"
Feb 08 18:51:14 <prolic> thinkscape: no, returning assoc array needs more education, because i need to know how it looks like, returning an object with explicit methods will decrease learning curve
Feb 08 18:51:19 <Evil_Otto> That's all explained in the quickstart, so you just point them to that
Feb 08 18:51:32 <weierophinney> Evil_Otto, I wish that worked.
Feb 08 18:52:03 <Thinkscape> difference:
Feb 08 18:52:04 <Thinkscape> ZF1: step 1) throw a few lines of code 2) run it, and you see hello world 3) learn how to change default behavior (change layout, change view script etc.)
Feb 08 18:52:09 <Thinkscape> ZF2: step 1) learn how to explicitly configure all view-related stuff 2) try to use this knowledge to display hello world 3) learn how this can be simplified
Feb 08 18:52:24 <Evil_Otto> my point is that having it by-convention first, then you can show how to set it explicitly, is a smoother curve
Feb 08 18:52:41 <Thinkscape> weierophinney: I feel your pain, but now it's being turned around and we'll have other problems
Feb 08 18:52:59 <Thinkscape> i.e. "zf2 is more complicated than other frameworks, I refuse to learn it"
Feb 08 18:53:00 <weierophinney> Thinkscape, you wouldn't be having to explicitly configure all view related stuff. You'd simply show returning a ViewModel. It's something like 10-12 characters more typing at most.
Feb 08 18:53:16 <Thinkscape> It's not about characters
Feb 08 18:53:20 <Thinkscape> it's about education
Feb 08 18:53:21 <PadraicB> I'm lost, what's the downside to returning an object?
Feb 08 18:53:23 <Thinkscape> (how it's flipped with zf2)
Feb 08 18:53:30 <weierophinney> from "return array(...) to return new ViewModel(array(...));" (optionally with an additoinal array with the template name)
Feb 08 18:53:45 <weierophinney> PadraicB, Thinkscape believes it will be harder to learn and less intuitive.
Feb 08 18:53:57 <prolic> the opposite is true, imho
Feb 08 18:53:58 <Thinkscape> It already is
Feb 08 18:53:59 <robertbasic> fwiw, after 3 years with zf1, I'm still being bitten sometimes by what view script gets rendered.
Feb 08 18:54:27 <PadraicB> Nonsense, just make the default use case (assigning vars) as simple as possible - then tell everyone this is the recommended convention and naughty programmers are on their own.
Feb 08 18:54:29 <PadraicB> Problem solves
Feb 08 18:54:41 <Thinkscape> disclaimer: I understand the downsides of zf1 and lack of verbosiness in critical app logic.
Feb 08 18:54:59 <ocramius> actually, returning an array is imho counter intuitive
Feb 08 18:55:11 <ocramius> returning a ViewModel makes it explicit
Feb 08 18:55:14 <Thinkscape> But making it all-verbose will be offputting to many, many developers (not only newcomers)
Feb 08 18:55:20 <weierophinney> we've spent a ton of time on this already – let's take it to the list.
Feb 08 18:55:36 <prolic> let's vote for it
Feb 08 18:55:39 <ralphschindler> +1 weierophinney
Feb 08 18:55:43 <MikeA_> robertbasic: that's why I canned ZF1 – Thinkscape's points are valid and important but I believe starting education with ViewModel and developing from there is a matter for the tutorial writer, not ldevelopment leads
Feb 08 18:55:43 <weierophinney> LAST ITEM: options and mutability.
Feb 08 18:55:47 <PadraicB> Returning an array IS counter intuitive - where in the array do you set the template? <-- Soon to be asked way too much
Feb 08 18:55:48 <Akrabat> the new default usecase is return new ViewModel(arrray('form'=>$form));
Feb 08 18:55:53 <Akrabat> I don't see what's complicated
Feb 08 18:56:12 <ocramius> actually, until it's in the interface...
Feb 08 18:56:26 <ocramius> PHP interfaces aren't typed for returned values, but heh
Feb 08 18:56:59 <prolic> ocramius: you can achieve that with phpstorm, a pretty good ide
Feb 08 18:57:13 <Akrabat> if you need a layout change: return new ViewModel(array('form'=>$form), array('layout'=>'layouts/cooler.phtml'); <- much easier than dealing with action helpers
Feb 08 18:57:27 <ocramius> prolic: ya, I know
Feb 08 18:57:45 <weierophinney> For the last item... we can actually take it to the list. Basically, I've run into a number of situations where options mutability has either been tricky or entirely a PITA (cough*caching*cough). I just wanted to suggest that we have some functionality in the Options class to be able to mark options as immutable, and that we don't enforce that a class that accepts options also have a "setOptions()" method (because if they nee
Feb 08 18:57:45 <weierophinney> d to be immutable, setOptions() is a bit of a contradiction)
Feb 08 18:58:00 <Thinkscape> Akrabat: you've missed one bit- if you forget template=>"" in viewmodel it might crash
Feb 08 18:58:09 <Akrabat> Thinkscape: not at all
Feb 08 18:58:35 <weierophinney> Thinkscape, again, I said we'd likely ship a listener for that bit – I just think it should be opt-in (and we'd opt-in in the skeleton app)
Feb 08 18:58:36 <Akrabat> it's a certainty that it will try to find controller/action.phtml
Feb 08 18:58:46 <ocramius> were immutable options already discussed? (sorry, I'm late)
Feb 08 18:58:46 <prolic> weierophinney: setOptions could be protected then
Feb 08 18:58:48 <Thinkscape> weierophinney: how does it relate to me and DASPRiD removing read-only flag from Config ?
Feb 08 18:58:51 <weierophinney> ocramius, just started.
Feb 08 18:59:01 <ocramius> aw, sry
Feb 08 18:59:06 <weierophinney> Thinkscape, completely different – this is for the individual component Options classes.
Feb 08 18:59:24 <weierophinney> prolic, yes – or simply not necessary (set the property via the constructor)
Feb 08 18:59:51 <weierophinney> Anybody have any thoughts right now, or should I take it to the ML?
Feb 08 18:59:58 <PadraicB> Seems fine to allow marking them immutable
Feb 08 19:00:03 <Thinkscape> weierophinney: I know, but that functionality existed in config, which is similar
Feb 08 19:00:04 <prolic> let's ask the other way round: why would one reconfigure an object?
Feb 08 19:00:16 <Evil_Otto> they're not very good coders?
Feb 08 19:00:21 <MikeA_> lol
Feb 08 19:00:22 <Thinkscape> prolic: I can imagine components that you want to reconfigure at runtime
Feb 08 19:00:26 <Evil_Otto> (i know a thing or two about that...)
Feb 08 19:00:30 <DASPRiD> component option classes? damn i really missed something
Feb 08 19:00:38 <ralphschindler> weierophinney: correction, its not per-component options, its per object options
Feb 08 19:00:56 <ralphschindler>
Feb 08 19:00:56 <Akrabat> for starters, the ViewLayer Options class may want to change which layout file to use...
Feb 08 19:01:00 <prolic> dasprid: take a look a zend\stdlib\options
Feb 08 19:01:04 <Thinkscape> i.e. I want to perform a big batch of select's on DB, and I want to change default return style ....
Feb 08 19:01:14 <weierophinney> prolic, as Akrabat said, View Layer is one place where options may change during the app lifetime.
Feb 08 19:01:39 <weierophinney> ralphschindler, well, in some cases, it's component – look at the module listeners.
Feb 08 19:01:48 <Akrabat> you may want to reconfigure the db adapter's logging
Feb 08 19:01:49 <prolic> okay, so options can have the immutability flag
Feb 08 19:01:51 <Thinkscape> IMO Options could provide this feature. Component-specific classes that "extends Stdlib\Options" will also provide protected $lockedOptions = array(...)
Feb 08 19:01:53 <prolic> i'm okay with that
Feb 08 19:02:01 <Thinkscape> Component decides which options should be immutable
Feb 08 19:02:08 <Thinkscape> exception is better than unexpected behavior...
Feb 08 19:02:30 <prolic> +1 thinkscape
Feb 08 19:02:44 <ocramius> agreed with Thinkscape
Feb 08 19:03:18 <Akrabat> Thinkscape: you mean that each options property can be either mutable or immutable?
Feb 08 19:03:22 <weierophinney> kk, I'll take to list, and maybe Thinkscape can elaborate on that there. Clearly there's support for the idea.
Feb 08 19:03:24 <prolic> but that should be done a standardised way
Feb 08 19:03:46 <ocramius> Akrabat: yes, and it looks like a nice idea imo
Feb 08 19:03:56 <Thinkscape> Akrabat: yes
Feb 08 19:04:09 <PadraicB> It's a bit of a fudge to assume options should change out of a user's control however.
Feb 08 19:04:13 <Akrabat> would have to see code/performance to create a view
Feb 08 19:04:15 <ocramius> Akrabat: for instance option keys for autoloading could be immutable, while options keys for caches could swap at runtime
Feb 08 19:04:49 <weierophinney> sounds complex. I was thinking simply a flag, "dontChangeMeAnymore!"
Feb 08 19:05:10 <prolic> agreed
Feb 08 19:05:13 <ocramius> weierophinney: also not always performant
Feb 08 19:05:28 <MikeA_> weierophinney: defaults to canChangeMe?
Feb 08 19:05:44 <ralphschindler> actually- lets back up a second
Feb 08 19:05:56 <ocramius> MikeA_: actually, changing options at runtime is something you do rarely
Feb 08 19:05:59 <ralphschindler> it seems to me that construction options are always unmutable
Feb 08 19:06:12 <weierophinney> MikeA_, yes – I was proposing that you'd set the flag in the constructor of the class accepting the Options instance, which helps guarantee that anybody else with an instance of it can't modify the options.
Feb 08 19:06:16 <ralphschindler> which layout to use is not so much an option as its a property of the layout object
Feb 08 19:06:37 <weierophinney> ralphschindler, that's the paradigm I want to be able make possible.
Feb 08 19:06:57 <weierophinney> ralphschindler, right now, somebody with that Options instance could change an option, AFTER it's been passed to the object composing it.
Feb 08 19:07:04 <ralphschindler> the difference in code, is that it sounds like when people are using options, they are moving all object properties into that parameter object
Feb 08 19:07:14 <weierophinney> ralphschindler, exactly.
Feb 08 19:07:15 <ralphschindler> and that seems, well, wrong to me
Feb 08 19:07:17 <ocramius> hmm
Feb 08 19:07:20 <ralphschindler> from an OO perspective
Feb 08 19:07:20 <weierophinney> That was kind of the original point.
Feb 08 19:07:34 <weierophinney> ralphschindler, we could, of course, take those options and compose them directly into the object.
Feb 08 19:07:37 <MikeA_> weierophinney, ocramius: I tend to think in Cobol "environment" terms – there's often times for change, especially as Akrabat mentioned, in View related stuff
Feb 08 19:07:44 <ralphschindler> i was just putting 2 and 2 together, after Akrabat made that what-if use case
Feb 08 19:07:47 <weierophinney> like I said... let's put this in the ML and discuss there.
Feb 08 19:08:05 <Akrabat> yes - ML. I want to see use-cases both ways really
Feb 08 19:08:09 <weierophinney> kk
Feb 08 19:08:12 <weierophinney> so, I'm calling it.
Feb 08 19:08:14 <ralphschindler> weierophinney: that is what i'd expect (pushing from parameter object into consuming object)
Feb 08 19:08:15 <weierophinney> Meeting is OVER

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.