View Source

<p>This IRC Meeting is planned for 18:00 UTC on Wednesday, 8 February 2012.</p>

<ac:macro ac:name="html"><ac:plain-text-body><![CDATA[<iframe src="http://free.timeanddate.com/countdown/i2vpvyb9/cf12/cm0/cu4/ct0/cs0/ca0/cr0/ss0/cac000/cpc000/pcfff/tcfff/fs100/szw320/szh135/tatTime%20left%20to%20Event%20in/tac000/tptTime%20since%20Event%20started%20in/tpc000/mac000/mpc000/iso2012-02-08T18:00:00" frameborder="0" width="350" height="64"></iframe>]]></ac:plain-text-body></ac:macro>

<p>Please feel free to add topics, according to the template on the <ac:link><ri:page ri:content-title="IRC Meetings" /><ac:link-body>parent page</ac:link-body></ac:link>.</p>

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

<p>Artur Bodera (aka Thinkscape) is taking over the Console RFC, and has written a new/revised version: <ac:link><ri:page ri:content-title="RFC - Console 2.0" /><ac:link-body>Console &amp; CLI RFC</ac:link-body></ac:link>. He proposes we discuss whether or not it thoroughly captures requirements, as well as general readiness (though not necessarily vote on it this week).</p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{vote:Cli & Console RFC; should we discuss?|visibleVoters=true}
Yes
No
{vote}]]></ac:plain-text-body></ac:macro>

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

<p>Matthew has been working on the <ac:link><ri:page ri:content-title="RFC - View Layer" /><ac:link-body>View Layer RFC</ac:link-body></ac:link>, and some questions are beginning to recur, particularly as users begin testing and incorporating it (<strong>cough*Akrabat*cough</strong>). One such question is: should we allow returning simply arrays of variables to assign to the view from controllers, or enforce the idea of returning ViewModels? The latter idea could simplify both code and education, and involves less &quot;magic&quot;. However, it also makes the API slightly more verbose. Matthew and Rob would like to discuss this with others and come to a consensus.</p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{vote:Should we discuss Controllers returning View Models?|visibleVoters=true}
Yes
No
{vote}]]></ac:plain-text-body></ac:macro>

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

<p>One thing Matthew and other contributors have run into is that with the new Options paradigm, mutable options can often lead to problems. As an example, in the Cache component, changing options after an adapter has been instantiated can often lead to erratic behavior, and in other cases requires a ton of additional code in order to accommodate the change. One suggested solution for such situations is to only allow injecting an Options container in the constructor, and then having a mechanism to mark the container immutable. Does this make sense at the generic level?</p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{vote:Should we discuss immutable Options containers?|visibleVoters=true}
Yes
No
{vote}]]></ac:plain-text-body></ac:macro>