On 1/16/06, Duong BaTien <[EMAIL PROTECTED]> wrote:
You're very welcome. I was delighted with how easy that came together :-).
That seems like a very reasonable choice ... although you might want to take a look at the Clay part of Shale too.
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.
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.
Craig
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.
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.
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.
BaTien
DBGROUPS
Craig
