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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/seam-dev > >
_______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
