[seam-dev] SAF (aka Entity Framework) idea in Seam 3

Tue Sep 20 15:36:21 EDT 2011

What I like most in CDI and Seam3 is that it's very easy to keep things
simple and that's something I strongly advocate.

For me when you have a lot of layers that just delegate calls, something is
wrong, and you're probably writing that classes(layers) just to satisfy an
unnecessary pattern. If we create a Seam Application Framework like that for
Seam3, I'm afraid we're going to fall in that hole. IMHO we should avoid
that. JEE6 carries the design by simplicity flag and I think we should
support that.

I know that a lot of people want to have a happy and safe way to achieve a
simple CRUD. But I think we should encourage them to enjoy the CDI
programming model and use layers only when they're needed to be used.

Of course there're still boilerplate code, but I think it's minimal
(compared to the JEE generations before), and that's something forge can
create without the need to satisfy a "framework". Yes, I admitedly am afraid
of that word.

On Tue, Sep 20, 2011 at 2:54 PM, Dan Allen <dan.j.allen at gmail.com> wrote:

> xsalefter,
>
> Thanks, this is valuable feedback and certainly usage patterns to keep in
> mind when designing the new iteration of these components.
>
> In numerous conversations that I've had with developers familiar with Seam
> 2, the common theme is that *Home and *Query components are not the ideal
> design. They lead developers into tight corners exactly in the way you are
> describing. Thus, we likely won't be following the status quo (though, it's
> not too big of an effort to port the existing functionality to CDI, so if
> someone would like to work on that, we won't discourage it).
>
> Instead, I think these components should provide boilerplate functionality,
> yet be flexible and easily tuned to the needs of the developer. I think
> you're right in that going back to a generic DAO design might be a more
> reasonable strategy. I don't think developer expect to code entirely in XML,
> they simply don't want to type the same boilerplate over and over again.
>
> I like Jason's idea of using named queries. Keep in mind we could read the
> queries as a suggestion and produce more sophisticated queries in an
> extension...so we aren't limited to what named queries support today. We've
> also been considering supporting finder "missing" methods that build a query
> from the name of the method (or a set of annotations on the method).
>
> Whatever we decide, this should be the framework code that forge uses when
> generating CRUD applications. Let's make it something that we aren't ashamed
> of having in our projects ;)
>
> -Dan
>
> p.s. I also recommend renaming SAF, because it's a really confusing term.
> Something like "entity framework" is far more sensible.
>
> On Tue, Sep 20, 2011 at 03:47, xsalefter <xsalefter at yahoo.com> wrote:
>
>> Hi all.. I know that I never involved on this mailing-list so much, nor
>> contribute things to the community. But because I have an experience with
>> seam 2 and used seam gen extensively (and thus use seam's EntityQuery and
>> EntityHome a lot) in some project, I have a thought about this.
>>
>> EntityQuery anda EntityHome is perfect in case you want to creating an
>> simple CRUD application. Well, not as simple as is. I ever involved in a
>> project with 40 more database tables with quite extensive financial
>> transaction, and use an EntityQuery and EntityHome a lot. The main problem
>> with these classes is that, It's hard (well, at least, for me) to make your
>> code consistent. What I mean by consistent is that, it is confusing to
>> determine whether the classes is a part of your UI layer, or
>> service/domain-model layer. Or where you add new functionality to satisfied
>> a specifics requirement. The study case is maybe like this:
>>
>> Let say that we have a module named accounting transaction. And we want to
>> create a input transaction page, thus we have a TransactionHome.xhtml backed
>> with TransactionHome.java. Now the problems occurs. Because we want a chart
>> of account list in the TransactionHome.xhtml, where is better place to put
>> the logic to call the chart of account list? In the TransactionHome.java, or
>> ChartOfAccountList.java?
>>
>> In the beginning I put it in the ChartOfAccountList.java, and start to
>> realize that seam's EntityList is specialized class to create a page with
>> contains a rich datatable search option, paging, and sorting. It will be
>> strange to the code if try to add non searching/sorting/paging on it. Then I
>> think to back to good-old DAO object, and thinking again about the backing
>> bean: I need to call/inject the DAO in some backing-bean, but where?
>> TransactionHome.java? Well, TransactionHome already have getEntityManager(),
>> so if I put the DAO in the ***Home, it will looks overlapping, and bit odd.
>> Then when I thinking again about the EntityHome, I'm not sure whether I need
>> to treat this class as UI or Service class. You see, this is simple case
>> study (don't get me start with "The list of Chart Of Account need to
>> aligning with the logged in user's departments and user's role. And make
>> sure that an user with level A have a $xxx limit transaction, where level B
>> have $xxx limit").
>>
>> My purpose is not to blame something or rant to something, but instead,
>> give an idea whether is it good enough to leave ***Home and ***Query
>> concept, and back to at least
>> Entity-Service-BackingBean-View model? It looks "verbose", I know, but at
>> least we have a "service" layer, which is "centralized" place to write a
>> business logic in our application. We could treat the "service" as
>> just-plain-stateless classes (EJB 3.1 classes or only seam-persistence
>> classes with minimal coupled with the front-end layer), and put the richness
>> of Weld and Seam 3 maybe in the UI and view layer.
>>
>> Well, I know this is personal view, from me, and my experience. Thus, just
>> ignore if in case this is annoying and not fit with your purpose/target.
>>
>> Thanks,
>> xsalefter
>>
>> *
>> *
>> The Home idea
>>
>> https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/ConferenceInstance.java
>>
>> The Query idea
>>
>> https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/java/seam/example/confbuzz/TodaysConferencesQuery.java
>>
>> The main thing that I would change with the Query class above is to use
>> named queries, thus espousing the generally accepted best practice in
>> default applications. I understand this doesn't fill all the gaps of the
>> older SAF from Seam 2, but I think it works for the majority of cases, and
>> it also helps people understand the best way to do things instead of relying
>> on the magic of SAF from Seam 2 (which I have found to be a major problem in
>> projects and teams I have worked with over the last three years).
>>
>> I've spoken with Lincoln about this and there are two JIRAs (
>> https://issues.jboss.org/browse/SEAMFORGE-280 and
>> https://issues.jboss.org/browse/SEAMFORGE-279) to have Forge generate
>> this via the JPA plugin or perhaps Seam Persistence plugin.
>>
>> Discuss.
>>
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://www.google.com/profiles/dan.j.allen#about
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
>
> _______________________________________________
> 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/20110920/4b1044bb/attachment.html 