[seam-dev] Interceptor packaging convention

[Arbi Sookazian]

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.

Power and flexibility vs. ease-of-use and productivity.  Fine line?

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...

On Mon, Mar 29, 2010 at 12:35 PM, Arbi Sookazian <asookazian at gmail.com>wrote:

> 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.
>
> 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).
>
> 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??
>
> How much of an inconvenience is it to the dev on a daily basis??
>
>
> On Mon, Mar 29, 2010 at 11:56 AM, Gavin King <gavin.king at gmail.com> wrote:
>
>> On Mon, Mar 29, 2010 at 2:47 PM, Lincoln Baxter, III
>> <lincolnbaxter at gmail.com> wrote:
>> > I understand the technical reasons why interceptor ordering is
>> important,
>> > but I disagree completely with the lack of options, or ability to ignore
>> > said technical reasons. The reason the enabler jar works well is because
>> it
>> > provides a consistent way to order interceptors *within* the Seam
>> framework.
>> >
>> > 95% of the time that is going to be enough. 5% of the time it's not.
>>
>> I just don't buy this. It's going to work fine when you ONLY have the
>> Seam interceptors, and don't have any other interceptors. As soon as
>> you start adding your own interceptors, or the interceptors of another
>> framework, it's HIGHLY likely that you're going to need to specify
>> their precedence w.r.t. the Seam interceptors.
>>
>> > Why should we force people to work extra hard to get things working,
>> when
>> > they should only have to work extra hard if there is a problem? Think of
>> it
>> > from the POV of a user: Do they want to fix things to get started? Or do
>> > they want to fix things only if they are broken?
>>
>> Thanks for the lecture on the need to make things easy for users.
>> Clearly it's an issue that had not occurred to me before. Wow, I had
>> never considered thinking of things from the POV of a user!
>>
>> > This isn't a matter of technical correctness, we can ensure technical
>> > correctness by allowing users to exclude the Seam-enabler.jar from their
>> POM
>> > and fall back to Beans.xml for manual interceptor registration.
>>
>> And how is this solution easier than just giving people a standard,
>> pre-written beans.xml file that they include in their Seam projects as
>> a starting point? It can even be added automatically by JBoss Tools or
>> the Maven archectype. Then, when they come to add their own
>> interceptors, it's easy to just edit this file.
>>
>> Including a jar in the classpath is actually much more work than
>> including a pre-written beans.xml file!
>>
>>
>> --
>> Gavin King
>> gavin.king at gmail.com
>> http://in.relation.to/Bloggers/Gavin
>> http://hibernate.org
>> http://seamframework.org
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100329/1563f6c9/attachment-0001.html