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

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(a)yahoo.com&gt; 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/... > > The Query idea > > https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/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(a)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