On Sat, 30 Oct 2004 11:03:29 -0700, Martin Cooper <[EMAIL PROTECTED]> wrote: > To my knowledge, anyway, JSF is page oriented, relies on a page's > component tree for rendering / processing, and does not provide for a > client-side component to communicate back to its server-side partner > without serialising and deserialising the page tree along with it. > That pretty much breaks the partial page rendering scheme right there, > unless you have the client and server parts of your components > communicate with each other "out of band" as it were, which kinda > defeats the purpose of having a component based framework.
There's more than one purpose for a server side component based framework, and more than one way to deal with client side scripting. One of the most important features of components on the server side is so that tools can know enough about a component that it's possible to create a high quality user experience at design time. For instance, when a page author manipulates a tool on a graphical design surface (as in Sun Java Studio Creator, for example), the tool has to know what properties are available, what the legal values for each property are (or, alternatively, provide type-specific property editors for complex things), and ... among other things ... how to persist the user's choice in code (either as attributes of a JSP tag, or initializations in an XML file, or perhaps some generated Java code in a backing bean class). JSF provides sufficient infrastructure to make this fairly straightforward. The standard JSF components don't do anything particular in terms of client side scripting (with minor exceptions). That doesn't mean a component can't do so -- it just means that (for JSF 1.0/1.1 at least) JSF doesn't provide you any particular help. It's pretty straightforward to think about some sort of a "panel" component that does layout management, with "label" and "field" components you can drop on it -- and some more complicated things ike a "tree control" or a "sortable table" that you can use to display volumes of data in interesting ways. It's also pretty easy to imagine a server side implementation of these sorts of components (the standard ones that come with JSF get you most of the way) that depend on a complete page refresh. But that's by no means the only thing that is possible. Switch your JSF renderers to something smarter and those same components can be used to render a description (in XML or JS objects or whatever you like) of what the panel should look like, along with its constituent parts, and pass that off to the client for actual processing. While you're at it, provide (inside your component definitions) a way to do back channel communication to the server so that the "submit button" doesn't really do that -- instead it marshalls all or part of your data and waits for incremental updates coming back. And, if you want to get fancier, make the scrolling controls on your tree control ask for the next or previous page's worth of data via the back channel, instead of rerendering the entire page. For JavaOne 2003, we built a primitive version of this for a demo that used SVG as a client side rendering technology -- the renderers just created an XML abstraction representing the page and sent that off to the client, where it was converted into actual SVG markup that was then executed. The test application was the standard "car demo" app that comes with the JSF RI -- we kept the components and the back end logic, but benefitted from cool stuff that SVG enabled on the client side. We didn't go as far as the back channel communication step, but there's prior art for how to do that, which JSF components can take advantage of. The key is that I can use a tool to build that application, or even code the tags into a JSP page by hand, and get *either* kind of support. JSF (in the current generation) doesn't provide you any API support for the client side components or the communications channel -- but it provides you a very easy way to capture the design intent of the page author, hiding the complexitly of the communications channel inside the renderers where it belongs. It's feasible to use technologies that require your page authors to be intimately familiar with serializing Javascript objects, or parsing XML, and so on -- but that limits the potential audience to those that have the technical skills to understand them. On the other hand, I've seen a demo of a JSF tree control whose backing tree had several thousands of elements in it, which did exactly the partial refresh trick (dynamically grabbing data as needed when you expand a node) -- but you'd never know it from looking at the couple of simple tags in the JSP page. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
