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

Tue Sep 20 15:39:09 EDT 2011

p.s.:  I know that's a really polemic opinion. ;)

On Tue, Sep 20, 2011 at 4:36 PM, José Rodolfo Freitas <
joserodolfo.freitas at gmail.com> wrote:

> 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/376f2a5d/attachment-0001.html 