On Thu, 11 Nov 2004 11:13:57 +0000, Adam Hardy <[EMAIL PROTECTED]> wrote: > A lightweight framework must be simple to implement, for RAD or for > prototyping or for web newbies. Given a large complicated application, > should an architect choose a lightweight framework? No. She / he must > recognise the limitations of the framework.
JSF does not propose to be an application tier controller -- it's totally about the view tier. For simple apps, that is enough. For complicated apps, feel free to add application tier stuff (as I did in Shale). > > JSF seems to be lightweight. It simplifies and speeds up development. So > what limitations does it have? I don't know JSF (I must download it (and > shale)), but it sounds like you've sacrificed the ability to deal with > multiple Command scenarios (submit buttons) on a robust controller. Not correct, but you'll need to catch up on JSF to ujnderstand why. > > The last page I saw on my previous project had 10 submit buttons. What I > see is developers writing monolithic tracts of code in their Action > classes to handle all Commands at once. E.g. a search page with search > again, back, fwd, begin, end etc. The best practice for JSF would be to bind each submit button to a separate action method. If/else chains, or a DispatchAction like thing, are not necessary. Note that there are cases where you really do want multiple buttons to invoke the same action. For example, I'm writing this reply using GMail, which has a Send button at the top and the bottom of the textarea that I'm typing in. Both do the same thing, so they would both be mapped (if GMail were written using JSF) into the same action method. > > I think page-driven development frameworks would exacerbate this problem > unless they clarify with eloquence up-front how to make a clear > seperation of the POST processing from the page preparation required for > the next page. > Yep, that is definitely a key point. Here is why Shale's view controller helps you do that. The key point is this: The initialization code for any page (no matter how you got there) goes in the prepare() method of the corresponding ViewController. The only thing you should do in the action method for processing a request is to perform the necessary business transaction (save a record to the database or whatever), then return the outcome code used for navigation. The next page is responsible for taking care of itself. Simple enough? > Otherwise the uninitiated are always going to write brittle, > hard-to-maintain, hard-to-extend apps. > > What I want to see in the future for big apps is a DTD or xml schema > that brings JSP code and XHTML mark-up under control. Something that is > easily editable by my editor of choice, using syntax-highlighting to > show me where my XHTML is up the swanny. You can already edit JSF-including JSP pages in any editor that understands JSP syntax, but doing so misses out on the extra benefits you can get from an editor that knows it is editing components. For example, Sun Java Studio Creator (the product I'm architect for) knows you are working with JSF components, and calls the actual renderers at design time in order to get faithful WSYWIG. Plus, it has lots of special design time behavior that makes the developer more productive. > > If JSF provides some view components that will output decent table-less > XHTML, then I'll jump at it. Feel free to write a few. That's what JSF is for :-). Or, use a tool like Creator that defaults to using CSS absolute positioning with the standard JSF components, so it doesn't need <table> elements unless you are really doing a table. > > Adam > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
