p.s.: I know that's a really polemic opinion. ;) On Tue, Sep 20, 2011 at 4:36 PM, José Rodolfo Freitas < [email protected]> 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 <[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
