View ioc and aggregation

Question

hi all,
by view ioc, I mean that the view as currently drawn by the examples, is responsible for the whole page production ( the view id are the jsp pages ). So the view must actively include the other jsp fragments, in order to build the site layout.
Isn't this a bad design?
Would'nt it be better, to keep the view jsp pages as simple as possible, with only containing the jsf form definition.
How would you design a complex site, composed from different jsp fragments leveraging java server faces?
Perhaps doing a kind of preprocessing by a Servlet. This could probably be done using a Phase Event Listener, at the Render Response phase....
The view id is generated from the ViewHandler, according to 2.2.1 by the URL Path, either by using the /faces/* or the *.faces method. Isn't that difficult for big sites, to always stick to the this page naming scheme.
I like the jsf principles, and would like to use it to upgrade some of my existing web applications to using jsf.
-- Jakob

Answer 1

hi all,
by view ioc, I mean that the view as currently drawn
by the examples, is responsible for the whole page
production ( the view id are the jsp pages ). So the
view must actively include the other jsp fragments, in
order to build the site layout.
Isn't this a bad design?
Would'nt it be better, to keep the view jsp pages as
simple as possible, with only containing the jsf form
definition.
How would you design a complex site, composed from
different jsp fragments leveraging java server faces?
Perhaps doing a kind of preprocessing by a Servlet.
This could probably be done using a Phase Event
Listener, at the Render Response phase....
Struts developers have found the Tiles framework to be an appropriate solution for this sort of problem, and you'll be able to use Tiles along with JavaServer Faces using the Struts-Faces integration library (see my other posting today about an update to this library that corresponds to the final release of JavaServer Faces 1.0). I'm sure that other solutions centered around templating approaches will also emerge from other places. I've also been doing some experiments with components to do layout management (akin to things like BorderLayout and CardLayout in Swing, and its also likely we will see JavaServer Faces based component libraries in this space as well.
For 1.0, we focused primarily on the APIs for the components themselves, so templating was out of scope. Standardization here is certainly something that can be considered in future versions, but we didn't feel it was a prerequisite for a 1.0 release of a UI component framework.
The view id is generated from the ViewHandler,
according to 2.2.1 by the URL Path, either by using
the /faces/* or the *.faces method. Isn't that
difficult for big sites, to always stick to the this
page naming scheme.
Having a common prefix or extension turns out not to be the significant issue (after all, does it really matter that all your JSP pages end with "*.jsp"?) A key scalability issue for large-page-count apps is separating the physical names of the pages from the business logic that drives the navigation. In JavaServer Faces, you accomplish this by leveraging the navigation rules, so that action event handlers return simple strings that indicate what happened, and let the configured rules define where to go next.
I like the jsf principles, and would like to use it to
upgrade some of my existing web applications to using
jsf.Sounds like a good plan :-).
>
-- JakobCraig