On Mon, 2006-01-16 at 22:19 -0800, Craig McClanahan wrote: > > > On 1/16/06, Duong BaTien <[EMAIL PROTECTED]> wrote: > On Mon, 2006-01-16 at 12:27 -0800, Craig McClanahan wrote: > > On 1/16/06, Werner Punz <[EMAIL PROTECTED]> wrote: > > > > [snip] > > > > Well from the small project I have done, you > basically can > > take all your > > JSF knowledge with you, Seam is an extension which > simplifies > > many > > things in JSF. > > > > Yep ... like Shale, Seam is a layer of additional > functionality built > > on top of JSF, not a separate framework that just happens to > coexist > > with it. > > > > > > For instance you do not define any backing beans in > xml > > anymore, just a class which you then annotation as > session > > bean etc... > > > > If you like that idea, but for some reason don't want to buy > in to the > > whole Seam stack, Shale can do this now as well (in nightly > builds) > > when you add the shale-tiger.jar library to your > project. See the > > overall description of the Shale Tiger extensions[1], and > the javadocs > > for annotated managed beans[2] for more info. > > > Wow: shale-tiger and annotated viewController :-) Thanks for > your > effort. > > You're very welcome. I was delighted with how easy that came > together :-). > > > I will soon find some time to get back to > Shale-MyFaces-Facelets. I want > to change our work currently on Shale + MyFaces > tilesViewHandler into > Shale + MyFaces + Facelets. > > That seems like a very reasonable choice ... although you might want > to take a look at the Clay part of Shale too.
Competition and choice are good. :-) > I have looked at Seam and decided to stick to Jsf standard and > Shale to > tackle the issues of validation and state management. Here is > my reason: > > For validation, Seam tries to consolidate standard Jsf user > input > validation and business validation (besides standard Ejb3 data > model > constraints) by forcing user to use Hibernate Validation > Framework. For > state management, Seam creates its own context framework. > Using Shale > viewController and CoR context, our requestResponse framework > is > flexible and work out very nicely. Our business validation is > basically > a ruleFilter (Chain Filter) which is different from standard > Jsf > validation. > > I think there is definitely room for an annotation based validation > framework, where you could annotate the business rules that you want > enforced, and also make those rules available for the view tier to > validate where possible. Clearly, if you have a different scheme > already set up, you probably don't need this ... but it's a part of > Seam I am quite interested in. > It is good to have experts looking at different ways to make deliverable technologies a little easier. We always want more :-) Yes, Seam has some good innovations especially those related to Ejb3 that i hope also available in Ejb3 RI. Again competition will make things moving and good for developers using open sources. > > For state management, i use viewController and actionListener > to hook > backing beans with its corresponding data table (Seam calls > this > bi-directional injection). This can be done with POJO as i am > doing now, > and later with Ejb3. It is a nice state management at the > presentation > level. For state management at the enterprise business level, > i rather > stick to standards such as Jbi and conversational web services > rather > than using Seam state management which bypasses user session > and try to > consolidate both user state management and process state > management into > one piece. > > Question for Craig: What would be the best practice and its > use cases to > hook backing bean with its corresponding data table? When Jsf > or Spring > IoC inject a managed bean in with its settings, which phase of > the jsf > life cycle the bean is available or the whole bean is > available at the > point of injection. For example, Shale viewController (a > backing bean) > associated with a page has its init(), preprocess(), destroy() > so you > can have fine control of how data in the database should be > interacted > with Jsf state management. > > For acquiring resources in general, I find myself most often putting > the necessary hookup logic in the prerender() method of a view > controller -- that covers cases like "go do the query that provides > the data for the table I am about to display" -- with any > corresponding cleanup logic in the destroy() method. For example, if > you're using Hibernate, you could acquire the session in prerender and > call the query method, storing the result in a property of the > (request scope) backing bean that the data dtable is bound to. You'd > then release the session in the destroy() method. (Of course, you can > use any of the general solutions for allocating a Hibernate session in > a filter so that it's available for the entire request -- but you'll > still want to actually execute the query in the prerender() method.) > > For resource injection in general, the JSF managed beans support > provides basic DI service for you. It happens when the corresponding > backing bean is created, which in turn depends on a couple of > circumstances: > > * For a postback, it happens after Restore View phase (i.e. just > before the init() method is called). > > * For navigation to a new page, or for an initial request to a JSF > page where there is no previous > state to be restored, it happens before Render Response phase ( i.e. > just before the prerender() > method is called). > > If you need more sophisticated DI injection, it would be ideal if you > could use all of Spring's facilities for that, *plus* have the > instantiated bean instance placed in the appropriate scope. It would > be nice for Shale to support the jsf-spring project, or equivalent > functionality, for that purpose. But it's not there at the moment. > Thanks. Yes, i re-factor our work to the concept of SCA and use Spring as a light-weight tool without the new Tuscany framework. BaTien DBGROUPS > > Craig > >
