compared with
Current by Artur Bodera
on Feb 20, 2012 14:30.

(show comment)
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (51)

View Page History
{toc}
<ac:macro ac:name="toc" />

h2. Information
<h2>Information</h2>

* Date: 08 February 2012, 18:00-19:00 UTC
* [Agenda|2012-02-08 Meeting Agenda]
* Moderator: Matthew Weier O'Phinney (nickname weierophinney)
* Next meeting: 15 February 2012
<ul>
<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>
</ul>

h2. Summary

h3. Discuss readiness of Console/CLI RFC
<h2>Summary</h2>

Artur Bodera (aka Thinkscape) has taken over the Console RFC, and has written [a new/revised version|RFC - Console 2.0]. During the meeting, we discussed readiness of the proposals, and provided initial feedback.
<h3>Discuss readiness of Console/CLI RFC</h3>

The primary feedback was:
<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>

* Merge the concepts of CLI and Console into a single component to avoid confusion; vote was for "Console".
* 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 _need_ 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.
* All agreed that examples/use cases detailing each of the following need to be added to the RFC:
** Usage of Console in standalone scripts
** Usage of Console in the MVC as console-only controllers/actions
** Usage of Console in the MVC in a mixed console/HTTP paradigm
<p>The primary feedback was:</p>

*tl;dr*: The new Console RFC is looking solid, and development is on track for beta3; we can vote on inclusion next week.
<ul>
<li>Merge the concepts of CLI and Console into a single component to avoid confusion; vote was for &quot;Console&quot;.</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:
<ul>
<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>
</ul>
</li>
</ul>

h3. ViewModels and Controller return values

(Search for "18:26:16" in the log.)
<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>

Matthew raised a discussion based on prototyping the View Layer. His argument was:
<h3>ViewModels and Controller return values</h3>

{quote}
[T]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 _recommend_ always returning a View Model. Which would mean all examples would show this, and we'd recommend this practice for distributing your modules.
{quote}
<p>(Search for &quot;18:26:16&quot; in the log.)</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>Matthew raised a discussion based on prototyping the View Layer. His argument was:</p>

In the end, despite most participants agreeing with the proposal, we decided to move the discussion to the list.
<blockquote>
<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 &quot;magic&quot;, and that means more code is running (performance degradation), and harder to debug workflows (&quot;I don't know where this is happening&quot;). I think we can still accommodate simple scalars and arrays &ndash; 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>

*tl;dr*: Everybody has strong opinions when it comes to the view layer.
<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>

h3. Options: should they be mutable?
<p>In the end, despite most participants agreeing with the proposal, we decided to move the discussion to the list.</p>

(Search for "18:57:45" in the log.)
<p><strong>tl;dr</strong>: Everybody has strong opinions when it comes to the view layer.</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).
<h3>Options: should they be mutable?</h3>

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>(Search for &quot;18:57:45&quot; in the log.)</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>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>

In the end, we decided to take this topic to the mailing list, too.
<p>Several indicated it might be nice to be able to have granularity of this within Options classes &ndash; some options might need to be immutable, while others could allow changes.</p>

*tl;dr*: Immutability seems like a good option, but the community has a number of different ideas on how to accomplish it.
<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 &ndash; a solution that would solve the mutability problem, but require refactoring a number of classes currently using Options at this time.</p>

h2. Log
<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>
{html:output=html}
<h2>Log</h2>

<ac:macro ac:name="html"><ac:parameter ac:name="output">html</ac:parameter><ac:plain-text-body><![CDATA[
<style>
pre.log {
Feb 08 19:08:15 &lt;weierophinney&gt; Meeting is OVER
</pre>
{html}
]]></ac:plain-text-body></ac:macro>