A lot of the tools us architects and developers use these days really only make sense in cases where you have a separation of activities in terms of page authors and developers. I echo your experience in that no organization I've ever worked in has had this separation. I know that such places exist, but my experience (and having talked to others) leads me to believe they are not the usual state of things.
I personally have a dislike of taglibs in general. It's not that I won't use them and it's not that I don't recognize the benefit in some cases, but I truly believe that we use them way too much. If your in one of those organizations where you have page developers vs. back-end developers, then taglibs make total sense. In the types of organizations you and I seem to have had experience in though, they don't really buy you as much as some claim.
In fact, I think they hinder you many times. I mean, if I write scriplets (assuming I do so in a resonably clear way and try and minimize it as much as possible), I find that to be easier to understand that having to go off and look at some tag handler source code. All the code in one place, namely the JSP, in other words.
JSF struck me in the same way... It didn't seem that the added complexity was going to buy me much, if anything.
My point, which I think I made before in this thread, is simply that a lot of the relatively recent developments that are billed as making our lives so much easier and less complex in fact do just the opposite. Rather than constantly trying to reinvent or improve upon the wheel, people should spend more time understanding what capabilities they already have without adding all the outside stuff.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Martin Cooper wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
