And yes, ease-of-use is very important. That's one of the main reasons Windows and .NET platforms and RoR are widely popular and successful. I don't think Seam and the rest of the JBoss dev stack (JSF, RichFaces, EJB, JPA/Hibernate, etc) is easy-to-use or learn quickly unfortunately.<br>
<br>Power and flexibility vs. ease-of-use and productivity. Fine line?<br><br>After 10 years in Java EE dev, I still think our productivity is nowhere near where it can/should be. Hopefully Java EE 6 platform will prove me wrong...<br>
<br><div class="gmail_quote">On Mon, Mar 29, 2010 at 12:35 PM, Arbi Sookazian <span dir="ltr"><<a href="mailto:asookazian@gmail.com">asookazian@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
>From the POV of a professional Seam 2.x user (and potential Weld/Seam 3 user) I'd like to state that one of the things I like about Seam is the mostly static and minimal (e.g. components.xml, pages.xml, web.xml and faces-config.xml) XML files I need to touch. Focusing on ease-of-use is critical to adoption.<br>
<br>Regarding this particular argument, I'm going to side with GKing. Realistically, as a user of this frmwk, how many times per day/week, on average, would I have to update the beans.xml file for a large-sized project (i.e. multi-module Mavenized Seam project)? I don't touch the above mentioned Seam 2.x xml files every day or sometimes even every week/month (thanks to annotations).<br>
<br>And it is possible that we will write and use custom interceptors from time-to-time. So in this more complicated scenario (multiple portable extensions, etc.) how shall we avoid the "clusterfuck" that GKing envisions if we don't do it his (the spec's) way??<br>
<br>How much of an inconvenience is it to the dev on a daily basis??<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Mon, Mar 29, 2010 at 11:56 AM, Gavin King <span dir="ltr"><<a href="mailto:gavin.king@gmail.com" target="_blank">gavin.king@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>On Mon, Mar 29, 2010 at 2:47 PM, Lincoln Baxter, III<br>
<<a href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a>> wrote:<br>
> I understand the technical reasons why interceptor ordering is important,<br>
> but I disagree completely with the lack of options, or ability to ignore<br>
> said technical reasons. The reason the enabler jar works well is because it<br>
> provides a consistent way to order interceptors *within* the Seam framework.<br>
><br>
> 95% of the time that is going to be enough. 5% of the time it's not.<br>
<br>
</div>I just don't buy this. It's going to work fine when you ONLY have the<br>
Seam interceptors, and don't have any other interceptors. As soon as<br>
you start adding your own interceptors, or the interceptors of another<br>
framework, it's HIGHLY likely that you're going to need to specify<br>
their precedence w.r.t. the Seam interceptors.<br>
<div><br>
> Why should we force people to work extra hard to get things working, when<br>
> they should only have to work extra hard if there is a problem? Think of it<br>
> from the POV of a user: Do they want to fix things to get started? Or do<br>
> they want to fix things only if they are broken?<br>
<br>
</div>Thanks for the lecture on the need to make things easy for users.<br>
Clearly it's an issue that had not occurred to me before. Wow, I had<br>
never considered thinking of things from the POV of a user!<br>
<div><br>
> This isn't a matter of technical correctness, we can ensure technical<br>
> correctness by allowing users to exclude the Seam-enabler.jar from their POM<br>
> and fall back to Beans.xml for manual interceptor registration.<br>
<br>
</div>And how is this solution easier than just giving people a standard,<br>
pre-written beans.xml file that they include in their Seam projects as<br>
a starting point? It can even be added automatically by JBoss Tools or<br>
the Maven archectype. Then, when they come to add their own<br>
interceptors, it's easy to just edit this file.<br>
<br>
Including a jar in the classpath is actually much more work than<br>
including a pre-written beans.xml file!<br>
<font color="#888888"><br>
<br>
--<br>
</font><div><div></div><div>Gavin King<br>
<a href="mailto:gavin.king@gmail.com" target="_blank">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>
_______________________________________________<br>
seam-dev mailing list<br>
<a href="mailto:seam-dev@lists.jboss.org" target="_blank">seam-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>