> -----Original Message----- > From: Mike Stanley [mailto:[EMAIL PROTECTED] > > <snip> > > The other thing I would add is strong debuggability. Is it > true that Tapestry's web > > debugging is the best of the current crop of web > application frameworks? > "Line precise error messages" - are very useful. This however, is not > as easy with a JSP engine, given the nature of JSP (template -> source > -> compile -> class). Tapestry has the benefit of using it's own html > template parser. This provides greater flexibility in terms of > "knowing" where something goes wrong. > Struts could improve it's configuration error messages. > Perhaps someone could write a utility for describing a JspException. > Those can be confusing. lots of nested, stacks. > But I'm afraid, as long as JSP is the "view", error messages > will always > lack that of Tapestry. > - Mike
When JSP is the view then JSP bug fixing and debugging can be quite difficult. Having your own HTML template parser or parser technology is the ticket I think. Struts relies on Jakarta Commons stuff. So I think the pizza base is only good as the quality of the ingredients on top of it. Is there a way, for example, to get precise line error when, say the Digester cant intercept the struts-config.xml file, or when the underlying SAX XML Parser finds fault. For error messages to be better, the actual low level module has to raise comprehensible error messages, because most exceptions should be rethrown rather than wrapped and logged. > > > > > > > > > -- > > > > > > Personally, I believe the original Struts scenario is > sound, which is why it has lasted so > > > long. > > > > > > (0) Client submits request (1) System receives the > incoming request (2) System transfers > > > matching values to a form object (3) System validates the > object (4) System branches to > > > success or failure. (4a) On success, system > executes/delegates the business logic. (4b) On > > > failure, system returns the faulty input. (5) A view > displays the nominal result or > > > redisplays faulty input. > > > > > > We just need to identify what improvements we need to > make at each step, and any additional > > > steps we'd like to add. > > > > > > It might be interesting to expand this quick list into a > formal set of use-case scenarios. If > > > you have UML Distilled, Fowler mentions scenarios at the > opening of Chapter 3. > > > > > > -Ted. > > > -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44 (0)207 883 4447 ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ============================================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
