Ok, one other issue that just crossed my mind.<br><br>This is purely a technical concern, obviously configurations can be merged, but it would be nice if the configuration could be configured in a &quot;Beans&quot; like manner, so that the Seam3 XML configuration module could consume the Java artifacts and allow XML configuration (using the same classes, preventing duplication, all that good stuff...)<br>
<br>I&#39;m not sure if instantiating Enums and using them as beans is something that we can do at this time (looking for someone who knows to answer this?) so it may be worth sticking with a class interface or abstract class concept.<br>
<br>Just a thought, looking for confirmation or education ;)<br><br>--Lincoln<br><br><div class="gmail_quote">On Thu, Mar 4, 2010 at 4:53 PM, Gavin King <span dir="ltr">&lt;<a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Thu, Mar 4, 2010 at 3:46 PM, Lincoln Baxter, III<br>
&lt;<a href="mailto:lincolnbaxter@gmail.com">lincolnbaxter@gmail.com</a>&gt; wrote:<br>
&gt; Copying seam-dev because this seems very relevant ;)<br>
&gt; --<br>
&gt;<br>
&gt; A pitfall with the class/annotations configuration: the potential loss of<br>
&gt; ability for runtime modification during development.<br>
<br>
</div>Well, we can make this argument against *every* effort to improve<br>
typesafety of the system. We can make the same argument against using<br>
annotations to configure dependencies.<br>
<br>
The truth is that the benefits outweigh the downsides.<br>
<div class="im"><br>
&gt; This forces all navigation logic from a specific view into one Enum<br>
&gt; definition, which is nicely centralized; however, I&#39;m not sure what the<br>
&gt; intent is here: Is this a no-op navigation?<br>
&gt;<br>
&gt;       @View(.....)<br>
&gt;       main {<br>
&gt;          public MyAppPage next(MyAppPage page, Object outcome) {<br>
&gt;             return main;<br>
&gt;          }<br>
&gt;       },<br>
<br>
</div>Right, it&#39;s like returning null from a JSF action method.<br>
<div class="im"><br>
&gt; Also, how will this address the bookmarkability issue? How are parameters<br>
&gt; passed between pages? -- Pages.xml used explicit syntax for parameter<br>
&gt; passing:<br>
<br>
</div>I don&#39;t claim to have solved all problems yet, but I&#39;m sure they are<br>
solveable by provisions of appropriate APIs.<br>
<div class="im"><br>
&gt; I&#39;m probably going to lite a fire by saying this, but sometimes XML is more<br>
&gt; concise than Java. I&#39;d like to be convinced that this is a good option to<br>
&gt; provide, and that it will be simpler or more usable than XML. Right now my<br>
&gt; gut is telling me that it&#39;s going to be more complicated both for our<br>
&gt; development, and the users&#39;.<br>
&gt;<br>
&gt; I am a big fan of the Injectability, and I think that&#39;s a strong point<br>
&gt; toward a native Java solution, but I&#39;m not sure it&#39;s enough when you can<br>
&gt; already reference beans through EL in pages.xml and get direct access to<br>
&gt; both contexts and dependencies - giving you the best of both worlds in a<br>
&gt; pretty reusable way.<br>
<br>
</div>That&#39;s all very well, until something changes and you need to start<br>
refactoring things.<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">Gavin King<br>
<a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a><br>
<a href="http://in.relation.to/Bloggers/Gavin" target="_blank">http://in.relation.to/Bloggers/Gavin</a><br>
<a href="http://hibernate.org" target="_blank">http://hibernate.org</a><br>
<a href="http://seamframework.org" target="_blank">http://seamframework.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com">http://ocpsoft.com</a><br><a href="http://scrumshark.com">http://scrumshark.com</a><br>&quot;Keep it Simple&quot;<br>