Software Reality
Programming with
a dose of satire.

Site Map Search


Agile Development
 
Extreme Programming
 
Code Generation


Articles
Lifecycle
Design
Programming
Soapbox
Reviews
Cthulhu

Java Swing
Swing's greatest threat isn't SWT, it's Flash
Swing Survival Guide


 
Check out our ageing Reviews Section


Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:



Programming

JavaServer Faces 1.0 Early Access Draft (Page 7)

<< Page 6 (Internationalization)


Nice to Have

Section 3.1.2 presents a few interfaces and methods for determining a UIComponent's id.

The JSF interfaces should provide a way of determining a component's individual and absolute id (bar and /foo/bar). This will be useful in tools as well as debugging.

Readability

Certain portions of the EAD are very difficult to read and very confusing. Section JSF 2.6 and other sections dip into discussion of the Lifecycle management process before the user has been introduced to this.

Not only with Lifecycle management, but other topics as well, the EAD has a tendency to reference material before the reader has read about it. The writers should assume that the reader knows nothing except what you have already told them. Don't force the reader to read the entire document before they understand a specific section.

Section JSF 3.5.2, 4 and 7.6 seem misplaced. These sections break up the flow of reading. The previous sections discuss information about the interfaces, the JSF classes and specifics about what is required for each Phase. Then we need to down-shift quite a bit to talk about default/standard implementations that ship with JSF or are required to be implemented by JSF implementations. All discussion of default implementations should really be placed in its own section.

Section JSF 8.1 discusses custom actions when integrating with JSPs. This is possibly the most confusing and poorly written section in the entire document. This uses terms that don't relate to anything, old class names and undescribed tables. This needs to be rewritten in a more concise way.

I did not understand what a custom action was until I reached section 8.2.6 and realized that an action was really only a JSP custom tag. Action is a poor choice of word because not all tags equate to actions. What is the action of an input tag? I understand action when talking about for-loop tags, but not input tags.


>> Page 8 (Conclusion)

<< Back to Programming

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright © 1998-2008 Matt Stephens. ALL RIGHTS RESERVED.