On Apr 2, 2005 11:25 AM, NetSQL <[EMAIL PROTECTED]> wrote: > Craig McClanahan wrote: > > > > > And there's even JSF components around that do this sort of thing too :-). > > > > AFAIK JSF was not designed for client rendering (hence "Server" faces, > not "Client" faces). It can be done in the same way one can get JSP or > Servlet API to render on the Client.
See my response to BaTien for some pointers to existing libraries of JSF components that already do the kind of thing we are talking about. > > Please somone correct me if I am wrong. The "server" part of the name JavaServer Faces refers to the fact that you are constructing components that do two things on the server side: * Render some sort of representation of themselves * Trigger events on an HTTP request (after restoring the previous server side state, if any). plus a standard MVC-style front controller framework to manage the HTTP transactions (including a request processing lifecycle, event management, server-side validation, and navigation that anyone familiar with Struts will see is similar to what any front controller framework provides). The key thing many newcomers miss is that JSF itself is totally agnostic about what kind of representation is created (other than the fact that there are a few standard components that are HTML specific, primarily to get you started). You can certainly render simple HTML widgets directly on the server, as these standard components do. But you can do a lot more. Let's say you wanted to build a dropdown control that, in addition to the typical behavior of a dropdown list, had a way to refresh the dropdown list contents via an asynchronous call to the server (so you don't have to refresh the entire page). Instead of creating the markup itself, you'd generate the JavaScript code (or, more likely, a call into some JavaScript library that is already included in your application). The JavaScript code would use DHTML to construct the dropdown list component and dynamically add it to the client side DOM, and would also offer a method that could be triggered (from some other client side JavaScript) to go refill the list asynchronously. It's still a server side component, but instead of rendering markup you are rendering client side code that creates markup. However, because it conforms to a standard component API, you have made it easy for a page developer to construct a user interface using these components, without that developer having to understand all the intricacies of JavaScript and DHTML, and how it actually works under the covers. And, that developer can intermix components from other JSF component libraries as well, because they all share a common API and runtime environment. The developer can even use a tool like Creator that makes assembling a page an exercise in drag-n-drop, and configuring the component properties. Finally, with JSF you get to leverage the front controller both for form submits and for responding to the background XmlHttpRequest calls. Readers familiar with Tapestry will be chuckling about now, saying "we can do that too". And they are right ... Tapestry provides a server side UI component framework that can do all this as well -- demonstrating that a component oriented architecture can provide a powerful basis for creating sophisticated applications, without exposing all the nitty gritty details to the developer. Indeed, it is the lack of a component architecture in Strust 1.x that requires you to go assemble all of the pieces as tag libraries and filters and such, as well as have to do other things like data conversion yourself. JSF (at least in version 1.0 and 1.1) doesn't offer any of the standard JavaScript libraries to help you build components like this. Instead, it lets you write components that leverage such libraries that already exist in order to allow page authors to easily construct pages that use such libraries, without having to have a deep understanding of how all that JavaScript and DHTML stuff actually functions. Doing more to support building components like this more easily, however, is definitely on the table in JSF 2.0. In the mean time, I'll be doing more in Shale to provide a JSF-based runtime environment for these kinds of components -- after all, an XmlHttpRequest request can be processed through a front controller just like a form submit can be, and mapping the incoming event to the corresponding processing logic is pretty much the same for both cases. > > .V > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
