Detailed comments

Question

I've gone through the EAD spec. and I've come up with a detailed list of comments that I'd like to post here and also will post over at TheServerSide.com and send directly to the JSR group. This area will give the community a chance to discuss this more. There are a few things that I did not finish commenting on, but over-all this document is fairly complete with my comments thus far. But then again, I've only read the spec twice and spent a day considering it.
I'll continue to add to this thread as I think of more.
Brian Pontarelli
Included document
JSF 2.1
Assuming that most applications will be setup like:
HTML->HTTP->FacesServlet->reconstitute phase->validation phase->model phase
This leads to an enormous amount of duplication as well as overhead. The information for each form component will be stored in the HttpServletRequest, expanded into the UIComponent Tree and stored in the FacesContext and finally migrated to the Application�s Model. Although this seems to be a small amount of work when considering smaller forms with two or three fields, it could become larger with 20-30 field forms. This continues to grow when considering an intensive web application with many users (i.e. 20+ requests per minute). In addition, the cost of the UIComponent and Application�s Model classes themselves might further increase the amount of memory consumed by this triple duplication as they may contain other member variables that increase each instances foot-print. In addition, without some comparison mechanism, the HttpSerlvetRequest parameters will be copied to the UIComponents local values, which will be copied to the Application�s Model each request. If, for example, the request goes all the way to the Invoke Application phase and then encounters an error, which will redirect the user back to the form so that they can fix some values, after they have fixed the values and resubmitted, the triple transfer happens, in its entirety, again (unless the application program is exceptionally savvy and is willing to build in an update recognition component that could skip application model updates when they are not needed).
The simpler and more concise design seems to be a single duplication of data. This would be from the HttpServletRequest to the Application�s Model. This would remove the UIComponent�s local values entirely. The UIComponent tree could still be constructed and optimized however the JSF spec allows. Likewise, the UIComponent�s themselves could be �backed� by the Application�s Model classes as is the case in the MVC design of Java�s Swing APIs.
The decoding process would work the same but would store the decoded information in the Application�s Model. Likewise, the encoding would retrieve it from the Application�s Model. This mimics other frameworks such as Jakarta Struts with their ActionForm classes that are essentially the Application�s Model (or at least positioned in such a way that they could be).
JSF 2.3
This has been tried many times and shown to be lacking. Server-side event models do not scale well because of the overhead of marshalling and unmarshalling the entire HttpServletRequest including all the form parameters, so that a single checkbox can change the values in a single selectbox (for example). The only solution to this problem seems to be the use of contained transmission systems, which transmit only the needed components state to the server. The server can respond with updates to any component, or whatever it needs. In order to attempt to accomplish this in a web browser, some very extensive JavaScript needs to be written which can cause enormous amounts of support issues. I think that you�ll find very little need for RequestEventHandlers and find that nearly 98%+ of the work will be done in the ApplicationEventHandlers.
JSF 2.6
This needs to be rewritten. This contains information about the Lifecycle management process before the reader knows what that is.
JSF 2.7
I don�t really like the concept of 1 Tree to 1 page yet, but I don�t know why. Need to think about this and draw some concrete conclusions about how this is lacking and what impacts it will have.
How will applications be able to forward to HTML pages? It doesn�t seem possible in the current setup without creating Tree objects for pages that don�t contain JSF code. Likewise, it seems that the requirement of having response Trees dictate the outbound page require that every JSP page in the entire application use JSF code (in order to seem conceptually correct). This seems like a large requirement for businesses with existing info-structure. Not to mention the need to be redirected out of the J2EE application server to an ASP server. Of course no one wants that, but it is a reality. This seems very restricting. The flow should be flexible enough to support forwards and redirects to any resource inside and outside the container.
JSF 2.8
The requirement on forcing the Tree to be saved to the response or the session seems very restricting. This section is very ambiguous about what writing the Tree to the response means. Does this mean doing nothing because the JSF tags will do everything for you? Or does it mean adding additional information to the HTML about the state of the JSF system? In the latter case, this is simply duplication of the information that the JSF tags write out, is it not? And there might be implementations with large Trees and many users that do not want to bug down the session with this information and would rather spend the computing cycles to reconstruct it each time from the request. Additionally, would there be cases where a developer would want to send the information from a normal HTML page to the JSF system and have it construct a UIComponent Tree? This seems likely and not possible (?) with the requirement from this section.
If you decide to leave in the local values and model values that I disagreed with above, you�ll need to be specific about where the values for the response come from when encode is called. It they come from the local values of the UIComponent, then the application logic will need to be responsible for migrating the values from the Application�s Model to the UIComponent�s local values. If they come from the Application�s Model, then every component will need to supply model references (I think). Or a better solution to this problem would be to add another phase to the lifecycle called �Update Local Values� which is designed to update the UIComponent�s local values from the Application�s Model if necessary. Or you could simply do away with the UIComponent�s local values altogether in favor of a more MVC oriented system where the view is directly backed by the Application�s Model (similar to Swing).
JSF 3.1.2
You probably want to add a way to determine a components individual and absolute id (bar and /foo/bar). This will be useful in tools as well as debugging.
JSF 3.1.5-3.1.6
See above about my issues with model references and local values. What if I write a JavaScript Tree component? This would mean that UIComponent�s local value would be of type com.foo.util.Btree (or something) and my Application�s Model might be the same. There is a lot of overhead doing things this way. What if my tree stores the groups and all the employees for a company with 50,000 people and 500 groups (not the best way to do things, but possible)? What if the Tree is roughly 1K in size (Java object size) and 2000 users are banging away at the system all day? Let�s see that�s 1K for the UIComponent�s local value, 1K for the Application�s Model, 2000 users, and roughly 4 Megs consistent memory usage for a single component.
JSF 3.5.x
This was a major concern to me when I wrote both of my frameworks. A reusable Validator is excellent because it reduces the amount of code duplication. However, it is very difficult to tailor messages for specific UIComponents using a reusable Vaildator. For example, on one page I just a text box for age and on another I use if for income. I don�t want my error messages to be generic stating that, �This value must be greater than 0 and less than X�. I want the user to know what must be within the range.
One solution is to use the name of the input in the error message. This forces the user to name inputs in human readable form, which might not be possible. For example, I have an input for monthly overhead and I name it monthlyOverhead so that it is a legal variable name. You can�t have a message that reads, �monthlyOverhead must be greater than 0�. This just won�t fly in a production environment. It needs to be nice and human readable and say, �Your monthly overhead must be greater than zero.� However, you can�t name your UIComponent �Your monthly overhead� especially I you intend to do JavaScript on the page. Besides, it�s just bad style.
Another solution is requiring specific sub-classes for each message required, or some parameter from the page to denote the specific message to use. The former clutters up the packages with tons of Validators and also requires way too much coding. The latter completely negates the ability to use parameterized messages without further bogging down the page with all the (un-localized) parameters to the error message or forces the placing of all the parameters inside the resource bundle for the error messages with a standard naming scheme (i.e. for the first parameter to the message �longRange.montlyOverhead.0=Your monthly overhead�). Since 1/3 of any application is really the view and interaction of which a large chunk is error messages, this is a major issue that must be considered. Because it always happens that the CEO plays around with the application one day and says, �I really wish this error message read this �� and then you�re in for some major headaches, unless this problem is solved up front.
JSF 3.5.2.x and 4.x and 7.6.x
These sections seem to break up the flow of reading. The previous sections were charging forward with 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 implementers. I think that these should be contained in a later section after 5, 6, 7 and 8.
JSF 5.1.2
What are the implications of this decision on Internationalization? When different UIComponents encode using different Locales and the HttpServletResponse�s content type has already been set, there could be rendering problems on the client side in the browser.
JSF 5.1.5
Messages added to the message queue during validation or processing contain Unicode String Objects and could be written in any language. The Message Object does not contain information about the Locale that the message needs to be converted to and this is needed for internationalization. If I have a multi-lingual portal and output error messages in multiple languages, the spec needs to really consider what and where the charset for the HTTP header is going to be set. What if JSF realizes it needs to use UTF-8 but another tag library an application is using assumes fr_FR, who is correct and what will happen? How will JSF determine what encoding to use when it has Messages in ten different languages? What if the container starts writing the output to the stream before the header is set? Etc. etc.
JSF 8.1
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 un-described tables. This needs to be re-written 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 a tag implementation. Action is a poor choice of words 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.
JSF 8.3
This seems quite contradictory to section JSF 2.8 because it leads the reader to believe that they have no control over the implementation of the use_faces tag and the method of saving the JSF state. That is UNTIL they read section 8.5. These two sections need to be combined to clarify the document.
Comments:
I think that JSF is a very good idea in general and that it is a very complicated thing to define (due mostly to the use of HTTP, which is a stateless protocol). There are so many frameworks out there and each has its own benefits and downfalls. However, it is imperative that this specification attempt to solve as many problems as possible and not introduce any more. The spec must be flexible enough to support implementations that drive for speed and those that drive for flexibility. It must also support enormous amounts of flexibility internally because as vendors attempt to comply with it, they want to make as few changes to their own code base as possible.
Right now, JSF has not accomplished these goals. I think that it needs to consider a lot more than it has and really needs to address the more complex issues.

Answer 1

Brian,
I've gone through the EAD spec. and I've come up with
a detailed list of comments that I'd like to post here
and also will post over at TheServerSide.com and send
directly to the JSR group. Thanks for the feedback, it's really appreciated. I've included some comments below. Even though I'm a member of the spec group, these are just my personal comments and do not represent any official position of the group. It's very important that you send feedback you want the spec group to consider to the mail address listed in the spec draft. Some of us read this forum, and try to answer questions and clarify things as best we can, but the only way to make sure the feedback is considered is to send it to the JSR-127 mail address.
Included document
JSF 2.1
Assuming that most applications will be setup like:
HTML->HTTP->FacesServlet->reconstitute
phase->validation phase->model phase
This leads to an enormous amount of duplication as
well as overhead. The information for each form
component will be stored in the HttpServletRequest,
expanded into the UIComponent Tree and stored in the
FacesContext and finally migrated to the Application�s
Model. [...]This is not so bad as it may seem, since typically it's not copies of the information that get stored in multiple places, just references to the same object that represents the information.
Consider a simple text field component that is associated with a model object. The text value arrives with the request to the server which creates a String object to hold it. The UI component that represents the text saves a reference to the same String object and eventually updates the model's reference to point to the same String object. The application back-end eventually gets a reference to the value from the model and, say, saves it in a database. Not until you hit the database do you need to make a copy of the bytes (in the database, not in the JVM).
JSF 2.3
This has been tried many times and shown to be
lacking. Server-side event models do not scale well
because of the overhead of marshalling and
unmarshalling the entire HttpServletRequest including
all the form parameters, so that a single checkbox can
change the values in a single selectbox (for example).
The only solution to this problem seems to be the use
of contained transmission systems, which transmit only
the needed components state to the server. The server
can respond with updates to any component, or whatever
it needs. In order to attempt to accomplish this in a
web browser, some very extensive JavaScript needs to
be written which can cause enormous amounts of support
issues. I think that you�ll find very little need for
RequestEventHandlers and find that nearly 98%+ of the
work will be done in the ApplicationEventHandlers.I agree with you that a web app can never be as responsive as a thick-client app unless client-side code (JavaScript) is used. Web apps must be designed with this in mind, which can be a challenge in itself.
But there are still advantages with an event-based model, namely that it provides a higher abstraction layer than coding directly to the HTTP request data. And even in a web app, having stateful components that generate events simplifies the UI development. As an example, say you have a large set of rows from a database query you want to display a few rows at a time. A stateful component bound to this query result can take care of all the details involved, rendering Next/Previous buttons as needed. Clicking on one of the buttons fires an event that the component itself can handle to adjust the display to the selected row subset.
Coding the logic for this over and over in each application that needs it (as you need to do without access to powerful components like this) is error prone and boring ;-)
Finally, JSF components can be smart and generate client-side code as well to provide a more responsive user interface.
JSF 2.6
This needs to be rewritten. This contains information
about the Lifecycle management process before the
reader knows what that is.Many parts of the draft needs to be rewritten; it's still a work in progress.
JSF 2.7
I don�t really like the concept of 1 Tree to 1 page
yet, but I don�t know why. Need to think about this
and draw some concrete conclusions about how this is
lacking and what impacts it will have.I have the same concerns, and think we need to take a close look at how a response can be composed from multiple JSF Trees, or a combination of regular JSP pages and JSF Trees, etc. I know others in the spec group agree that this is a vague area that needs more attention.
How will applications be able to forward to HTML
pages? It doesn�t seem possible in the current setup
without creating Tree objects for pages that don�t
contain JSF code. Likewise, it seems that the
requirement of having response Trees dictate the
outbound page require that every JSP page in the
entire application use JSF code (in order to seem
conceptually correct). [...]I don't think this is a problem. The application can decide to redirect (or forward) to any resource it wants when it processes an application event; it doesn't have to generate a new JSF response. But yes, navigation is also an area that needs attention in general.
JSF 2.8
The requirement on forcing the Tree to be saved to the
response or the session seems very restricting. This
section is very ambiguous about what writing the Tree
to the response means. [...]It is, isn't it ;-) Again, this is an area that still needs work, and I believe we must be able to provide a lot of flexibility here. Depending on the type of components in the Tree, the size of the Tree, the number of concurrent users and size of the application, etc. different approaches will be needed. How much data must be saved is also dependent on the type of component.
Additionally, would there be cases where a developer
would want to send the information from a normal HTML
page to the JSF system and have it construct a
UIComponent Tree? This seems likely and not possible
(?) with the requirement from this section.In that case the request initiated from the HTML page would be directed directly to application code (a servlet, maybe) which would create an appropriate JSF component Tree and generate a response from it.
If you decide to leave in the local values and model
values that I disagreed with above, you�ll need to be
specific about where the values for the response come
from when encode is called. It they come from the
local values of the UIComponent, then the application
logic will need to be responsible for migrating the
values from the Application�s Model to the
UIComponent�s local values. If they come from the
Application�s Model, then every component will need to
supply model references (I think). [...]I think this is pretty clear in the current EA draft. First, a model is optional for the basic component types (while more complex things, like a DataGrid, may require it). The draft says (in 3.16): "For components that are associated with an object in the model data of an application (that is, components with a non-null model reference expression in the modelReference property), the currentValue() method is used to retrieve the local value if there is one, or to retrieve the underlying model object if there is no local value. If there is no model reference expression, currentValue() returns the local value if any; otherwise it returns null."
Other parts of the spec (can't find it now) deals with how the local value is set and reset. The effect for the normal case is that if there's a non-null model reference, its value is used, otherwise the local value is used. In special cases, a local value can be set to explicitly ignore the model value.
JSF 3.5.x
This was a major concern to me when I wrote both of my
frameworks. A reusable Validator is excellent because
it reduces the amount of code duplication. However, it
is very difficult to tailor messages for specific
UIComponents using a reusable Vaildator. For example,
on one page I just a text box for age and on another I
use if for income. I don�t want my error messages to
be generic stating that, �This value must be greater
than 0 and less than X�. I want the user to know what
must be within the range. [...]I agree that this is a concern. In addition to the solutions you have suggested, I think a way to solve it is by letting validators fire "invalid value" events of different types. These events would contain a default message but also getter method for the interesting parts (e.g. the invalid value, the start and the stop value for an "invalid range" event). An event handler can use the getter methods for the individual values and build a message that's appropriate for the application,
JSF 5.1.2
What are the implications of this decision on
Internationalization? [...]
JSF 5.1.5
Messages added to the message queue during validation
or processing contain Unicode String Objects and could
be written in any language. The Message Object does
not contain information about the Locale that the
message needs to be converted to and this is needed
for internationalization. [...]I need to read up on the latest i18n proposals, but in general I think you're right that there's more work to do in this area.
JSF 8.1
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
un-described tables. [...]The whole JSP layer is still immature, but IMHO, we need to get the API right before we address the JSP issues.
I did not understand what a custom
action was until I reached section 8.2.6 and realized
that an action was really a tag implementation. Action
is a poor choice of words 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. [...]Actually, "action" is the proper name defined by the JSP specification for what's described in this section. A "JSP action" is represented by an "XML element" in a page, which in turn consists of a "start tag", a "body" and an "end tag", or just an "empty tag".
Comments:
I think that JSF is a very good idea in general and
that it is a very complicated thing to define (due
mostly to the use of HTTP, which is a stateless
protocol). There are so many frameworks out there and
each has its own benefits and downfalls. However, it
is imperative that this specification attempt to solve
as many problems as possible and not introduce any
more. The spec must be flexible enough to support
implementations that drive for speed and those that
drive for flexibility. It must also support enormous
amounts of flexibility internally because as vendors
attempt to comply with it, they want to make as few
changes to their own code base as possible.
Right now, JSF has not accomplished these goals. I
think that it needs to consider a lot more than it has
and really needs to address the more complex issues.I agree, and thank you for the feedback. There are many holes yet to be filled and many details to nail down. All of this takes time, since you must build support for the spec among a large number of vendors and other market groups, as well as among developers; this is one of the most important goals for any specification.