I hear what you're saying, Craig. However, I still feel that JSF doesn't buy me much when building highly dynamic apps. Some points to consider:
* Since one of the goals of such apps is to minimise the number of full page refreshes, relatively little of the app can be constructed using tools such as Java Studio Creator. For example, if I need a tabbed pane where working within the tabs and switching between tabs do not cause page refreshes, then JSF might help me put that component on the page initially, but it does nothing for me with respect to user interaction with that pane. The latter is the bulk of my development effort, not the initial page layout. * As you mentioned, partial page refresh functionality is going to require a back channel that to some extent replaces what JSF would give me if I used a full page refresh scheme instead. This distinctly lessens the value of JSF to me, when much of my app is going to need to use this back channel, and so cannot take advantage of JSF. * The types of components I need in my apps today do not exist. So in order to use JSF tools, I have to build all my own JSF components first. Given how little of my development is going to be spent on initial page creation, that seems like a lot of work for not much value. * We don't have the concept of page authors as distinct from developers. We have user interaction designers, but they're not the kind of people who would use a tool like Creator. In fact, no company I've worked at has those types of people, and I've seen many people say the same thing on the Struts lists over the years. I don't doubt that they exist - I just have not personally encountered them, and obviously I'm not alone. ;-) Combine the above with the comments I've seen from people like Hans Bergsten and Adam Winer - both EG members - regarding the issues with using JSF in JSP pages, and JSF really doesn't look attractive to me right now. (Hans's comments are here http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html and I saw a similar comment from Adam about the need for custom view handlers in a mail message somewhere. I don't have that reference handy right now.) I actually want to be wrong about this. ;-) I would really like to be able to use a standard framework like JSF to build my apps, rather than having to do my own thing. However, I'm just not seeing how JSF would give me enough of a benefit to make it worth the cost. Just to be clear, I'm certainly not saying that JSF has no value. I do see that, if the components are there to use, and you're not building a highly dynamic app (or, if you are, you also have a lot of distinct pages to construct and a page designer person doing that), JSF would help you get there faster. Unfortunately, that's not the case for me, and probably for many people building next generation web apps. -- Martin Cooper On Sat, 30 Oct 2004 14:54:16 -0700, Craig McClanahan <[EMAIL PROTECTED]> wrote: > 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]
