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 ;)
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(a)yahoo.com> wrote:
Hi all.. I know that I never involved on this mailing-list so much,
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
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
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.
The Home idea
The Query idea
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 (
) to have Forge generate this
via the JPA plugin or perhaps Seam Persistence plugin.
seam-dev mailing list
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597