Controls
Built with Seam
You can find the full source code for this website in the Seam package in the directory /examples/wiki. It is licensed under the LGPL.
| Online: | 4 Members of 9424 |
| Comparing current revision with historical revision 2. |
From line 16 deleted to line 16:
= [273=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=273] - EZComp umbrella issue
From lines 29 to 32 deleted to line 28:
+++View Exipry (P1)
TBD
TBD
From lines 39 to 40 deleted to line 34:
= [293=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=293] - Umbrella issue for Ajax
From lines 49 to 50 deleted to line 42:
From line 55 changed to line 46:
JSF's lack of facilities for exception handling is a major embarrassment, and totally ignorant of current best practices for exception handling in Java. It is impossible to do any centralized handling of exceptions without writing a servlet filter. Even worse, Unified EL has the totally pathological behaviour of wrapping all exceptions (even runtime exceptions) that occur during invocation of the managed beans in a totally useless |ELEvaluationException|. Both of these problems should be fixed.
JSF's lack of facilities for exception handling is a major embarrassment, and totally ignorant of current best practices for exception handling in Java. It is impossible to do any centralized handling of exceptions without writing a servlet filter. Specifically, JSF should provide a declarative exception handling facility, and in addition provide a way for an application/framework developer to register an exception handler class for more control.
From line 57 added to lines 48 to 49:
Even worse than the lack of exception handling in JSF, Unified EL has the totally pathological behaviour of wrapping all exceptions (even runtime exceptions) that occur during invocation of the managed beans in a totally useless |ELEvaluationException|. Both of these problems should be fixed.
From lines 59 to 60 deleted to line 52:
= [291=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=291] Umbrella issue
From line 63 deleted to line 54:
From line 98 changed to line 88:
+++ Improved orchestration (P1)
+++ Improved orchestration and Navigation controls(P1)
From line 128 added to lines 118 to 119:
JSF is currently missing *navigation* controls - you want to call an action or navigate to an outcome BUT you don't need to submit a form, and should be restful! Lots of toolkits have implemented these (e.g. Trinidad, Seam UI)
From line 130 deleted to line 122:
= [455=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=455] - umbrella issue
From line 132 added to lines 123 to 127:
= [484=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=484] - Parameters on redirect rules
= ~[170=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=170]~ - allow |<f:param />| as a child of |<h:commandButton />|
= [179=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=179] - alterations to navigation handler API
= [487=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=487] - add navigation controls
= [359=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=359] - allow EL in |<to-view-id />|
= ~[170=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=170]~ - allow |<f:param />| as a child of |<h:commandButton />|
= [179=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=179] - alterations to navigation handler API
= [487=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=487] - add navigation controls
= [359=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=359] - allow EL in |<to-view-id />|
From line 133 changed to line 129:
+++Navigation Controls (P1)
+++Validation (P1)
From line 135 changed to line 131:
*(Some discussion, no real progress made)*
The following proposals and discussions relate to improvements to the validation system. There are many styles of validation and these issues try to address poor assumptions made in JSF and ways to make validation more DRY.
From line 137 changed to line 133:
JSF is currently missing *navigation* controls - you want to call an action or navigate to an outcome BUT you don't need to submit a form, and should be restful! Lots of toolkits have implemented these (e.g. Trinidad, Seam UI)
++ Subtree validation (481)
From line 139 changed to line 135:
*Issues*:
Moved to [Subtree validation=>wiki://64561#SubtreeValidationP1] on the JSF 2.1 page.
From lines 141 to 142 changed to line 137:
= [170=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=170] - allow |<f:param />| as a child of |<h:commandButton />|
= [179=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=179] - alterations to navigation handler API
= [179=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=179] - alterations to navigation handler API
++ Inter-component validation
From lines 144 to 145 deleted to line 139:
+++Validation (P1)
From line 148 changed to line 141:
I'm not a fan of client side validation - but I really like ajax style validation (use server side validation, and just re-render the relevant field). But *if* client-side validation was used where possible (e.g. required fields) and then ajax was used if not possible, and the messages just completed as necessary this would be cool!
<hr/>
From line 150 changed to line 143:
CRUD - Field decoration, validation and conversion - easy CRUD is certainly good, field decoration - like Trinidad's label, help and message placement BUT it should templatable (for example, Facelets ui:decorate) so that you can easily change the layout of the decoration.
I (Dan) don't think that cross-field validation is a difficult problem to solve from the specification level. The reason cross-field validation is difficult today is because each field is converted individually, just prior to being validated. Therefore, when the validate() method is called on a UIInput component, there is no guarantee that any other component in the form will have been converted at that time. It depends on the relative placement of the components in the form, a fact which should not be relied on in a validator.
From line 152 changed to line 145:
Handling of JSF messages is also weak: A message is either global or bound to a particular component. On the view, you can show either all global messages or the message for a particular component. There is no way to say, "convert" a component-bound message to a global message. I should be able to display and bundle whatever messages I feel necessary to show in whatever location.
The current strategy puts the onus of having to convert the related field(s) on the validator that is attempting to perform a cross-field check. Naive developers will simply ignore the converters on that field. The developers that do use the proper converter logic may still get sloppy with exception handling. Refer to either the [EqualityValidator=>http://anonsvn.jboss.org/repos/seam/trunk/ui/src/main/java/org/jboss/seam/ui/validator/EqualityValidator.java] in Seam or Tomahawk to witness the ridiculous amount of code that must be used to handle all of these concerns properly.
From line 154 added to lines 147 to 157:
A better way to implement validation is to first convert all of the components in the form. Once all the conversions are complete, then the validators run. An extra walk of the component tree can be avoided by putting the input components that were converted into an ordered collection (or map) and then iterating over that collection (or map) to apply the validators. Using this suggested strategy, implementing a multi-component validator is no more difficult than implementing a validator on a single component. The validator tag would need to provide some way to declaratively refer to the related components, such as by ID or value expression.
Frankly, I don't feel it is the responsibility of the specification to create a multi-component validator solution. What the specification should do is make it easy to create such a solution. With that said, I do believe it would be a good idea to implement a couple of basic multi-component validators to demonstrate 1) how it's done and 2) the ease in which it can be done with conversion and validation happening in distinct steps. Reference validators would include an equality validator (one or more components), a greater and less than validator, and perhaps a switch validator (a boolean component toggles the required flag on another component).
<hr/>
I'm not a fan of client side validation - but I really like Ajax-style validation (use server side validation, and just re-render the relevant field). But *if* client-side validation was used where possible (e.g. required fields) and then Ajax was used if not possible, and the messages just completed as necessary this would be cool!
CRUD - Field decoration, validation and conversion - easy CRUD is certainly good, field decoration - like Trinidad's label, help and message placement BUT it should templatable (for example, Facelets ui:decorate) so that you can easily change the layout of the decoration.
Handling of JSF messages is also weak: A message is either global or bound to a particular component. On the view, you can show either all global messages or the message for a particular component. There is no way to say, "convert" a component-bound message to a global message. I should be able to display and bundle whatever messages I feel necessary to show in whatever location. What would really be cool is to be able to assign tags to a message so that it would be possible to group them by different aspects and possibility even use the same message in multiple places on the page by tag.
Frankly, I don't feel it is the responsibility of the specification to create a multi-component validator solution. What the specification should do is make it easy to create such a solution. With that said, I do believe it would be a good idea to implement a couple of basic multi-component validators to demonstrate 1) how it's done and 2) the ease in which it can be done with conversion and validation happening in distinct steps. Reference validators would include an equality validator (one or more components), a greater and less than validator, and perhaps a switch validator (a boolean component toggles the required flag on another component).
<hr/>
I'm not a fan of client side validation - but I really like Ajax-style validation (use server side validation, and just re-render the relevant field). But *if* client-side validation was used where possible (e.g. required fields) and then Ajax was used if not possible, and the messages just completed as necessary this would be cool!
CRUD - Field decoration, validation and conversion - easy CRUD is certainly good, field decoration - like Trinidad's label, help and message placement BUT it should templatable (for example, Facelets ui:decorate) so that you can easily change the layout of the decoration.
Handling of JSF messages is also weak: A message is either global or bound to a particular component. On the view, you can show either all global messages or the message for a particular component. There is no way to say, "convert" a component-bound message to a global message. I should be able to display and bundle whatever messages I feel necessary to show in whatever location. What would really be cool is to be able to assign tags to a message so that it would be possible to group them by different aspects and possibility even use the same message in multiple places on the page by tag.
From line 156 changed to line 160:
= [52=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=52] - Umbrella issue for validation
From line 158 added to lines 162 to 165:
= [480=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=480] - Validate null fields
= [481=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=481] - Validate entire subtrees
= [482=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=482] - A default validator
= [483=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=483] - s:decorate
= [481=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=481] - Validate entire subtrees
= [482=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=482] - A default validator
= [483=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=483] - s:decorate
From line 159 added to lines 167 to 183:
+++ Alternative stateless UI component lifecycle and View Exipry (P1)
JSF's UI component tree is stateful, meaning that the tree of components is maintained across faces requests (form submissions). This is a nice feature that lets JSF handle forms with conditionally rendered and repeated inputs, and forms with components that are manipulated programmatically. However, in the simple (and common) case, statefulness is overkill. Most forms don't have conditionally rendered controls or grids of controls. JSF needs an alternative stateless lifecycle to deal with the common case.
One possible option would be to copy Tapestry. Tapestry distinguishes between "simple" forms (which have no repeated or conditional controls) and "complex" forms (which do). For simple forms, Tapestry uses a stateless lifecycle. For complex forms, Tapestry serializes some information about the component tree to and from the client, and uses this when reconstructing the component tree during the "rewind" phase. (The handling of complex forms in Tapestry is very conceptually similar to the stateful model used in JSF.)
*Issues:*
= [139=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=139] - Stateless lifecycle
= [272=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=272] - State management revision
= [476=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=476] - View expiry problems
+++ Proper coverage of collections in UIData (P2)
The root of the Java collections class structure is java.util.Collection, yet this interface is not supported in the UIData family of components. Instead, developers are forced to use a List or wrap their collection in a custom DataModel implementation (which is what Seam does). The impedance mismatch is introduced by the fact that java.util.Set is likely the most common association mapping in ORM. Since the UIData model and ORM go hand-in-hand, there should be support for java.util.Set (and preferably java.util.Collection) in UIData. Granted, only a java.util.List can be accessed by index, which is why it would be acceptable to wrap any other collection in a List implementation internally. Basically, the developer should not have to care that they are creating a data table from a Set vs a List. This is an area where the JSF abstract just bleeds.
= [479=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=479] Collections in UIData
JSF's UI component tree is stateful, meaning that the tree of components is maintained across faces requests (form submissions). This is a nice feature that lets JSF handle forms with conditionally rendered and repeated inputs, and forms with components that are manipulated programmatically. However, in the simple (and common) case, statefulness is overkill. Most forms don't have conditionally rendered controls or grids of controls. JSF needs an alternative stateless lifecycle to deal with the common case.
One possible option would be to copy Tapestry. Tapestry distinguishes between "simple" forms (which have no repeated or conditional controls) and "complex" forms (which do). For simple forms, Tapestry uses a stateless lifecycle. For complex forms, Tapestry serializes some information about the component tree to and from the client, and uses this when reconstructing the component tree during the "rewind" phase. (The handling of complex forms in Tapestry is very conceptually similar to the stateful model used in JSF.)
*Issues:*
= [139=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=139] - Stateless lifecycle
= [272=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=272] - State management revision
= [476=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=476] - View expiry problems
+++ Proper coverage of collections in UIData (P2)
The root of the Java collections class structure is java.util.Collection, yet this interface is not supported in the UIData family of components. Instead, developers are forced to use a List or wrap their collection in a custom DataModel implementation (which is what Seam does). The impedance mismatch is introduced by the fact that java.util.Set is likely the most common association mapping in ORM. Since the UIData model and ORM go hand-in-hand, there should be support for java.util.Set (and preferably java.util.Collection) in UIData. Granted, only a java.util.List can be accessed by index, which is why it would be acceptable to wrap any other collection in a List implementation internally. Basically, the developer should not have to care that they are creating a data table from a Set vs a List. This is an area where the JSF abstract just bleeds.
= [479=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=479] Collections in UIData
From line 161 changed to line 186:
Move s:selectItems functionality into the spec
Move s:selectItems functionality into the spec and other minor selection enhancements
From lines 166 to 167 changed to lines 191 to 193:
=[451=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=451] - Support for a "noSelection" in h:select\*
=[226=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=226] - Decoding of SelectOne
=[226=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=226] - Decoding of SelectOne
=~[451=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=451]~ - Support for a "noSelection" in h:select\*
=~[226=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=226]~ - Decoding of SelectOne
=~[230=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=230]~ Native support for Collections
=~[226=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=226]~ - Decoding of SelectOne
=~[230=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=230]~ Native support for Collections
From line 176 added to lines 202 to 203:
= [485=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=485] - REST umbrella issue
= [487=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=486] - Integration with JAX-RS
= [487=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=486] - Integration with JAX-RS
From lines 177 to 187 deleted to line 205:
+++ Alternative stateless UI component lifecycle (P2)
JSF's UI component tree is stateful, meaning that the tree of components is maintained across faces requests (form submissions). This is a nice feature that lets JSF handle forms with conditionally rendered and repeated inputs, and forms with components that are manipulated programmatically. However, in the simple (and common) case, statefulness is overkill. Most forms don't have conditionally rendered controls or grids of controls. JSF needs an alternative stateless lifecycle to deal with the common case.
One possible option would be to copy Tapestry. Tapestry distinguishes between "simple" forms (which have no repeated or conditional controls) and "complex" forms (which do). For simple forms, Tapestry uses a stateless lifecycle. For complex forms, Tapestry serializes some information about the component tree to and from the client, and uses this when reconstructing the component tree during the "rewind" phase. (The handling of complex forms in Tapestry is very conceptually similar to the stateful model used in JSF.)
*Issues:*
= [139=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=139] - Stateless lifecycle
= [272=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=272] - State management revision
JSF's UI component tree is stateful, meaning that the tree of components is maintained across faces requests (form submissions). This is a nice feature that lets JSF handle forms with conditionally rendered and repeated inputs, and forms with components that are manipulated programmatically. However, in the simple (and common) case, statefulness is overkill. Most forms don't have conditionally rendered controls or grids of controls. JSF needs an alternative stateless lifecycle to deal with the common case.
One possible option would be to copy Tapestry. Tapestry distinguishes between "simple" forms (which have no repeated or conditional controls) and "complex" forms (which do). For simple forms, Tapestry uses a stateless lifecycle. For complex forms, Tapestry serializes some information about the component tree to and from the client, and uses this when reconstructing the component tree during the "rewind" phase. (The handling of complex forms in Tapestry is very conceptually similar to the stateful model used in JSF.)
*Issues:*
= [139=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=139] - Stateless lifecycle
= [272=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=272] - State management revision
From line 198 added to lines 215 to 220:
+++Default Application Time Zone (P2)
Moved to [Default application time zone=>wiki://64561#DefaultApplicationTimeZoneP1] on the JSF 2.1 page
<hr/>
Moved to [Default application time zone=>wiki://64561#DefaultApplicationTimeZoneP1] on the JSF 2.1 page
<hr/>
From line 200 changed to line 223:
= (P1) [323=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=323] Empty fields are submitted as an empty string, not null. Default should be null, with an option to override.
= (P1) [323=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=323] Empty fields are submitted as an empty string, not null. Default should be null, with an option to override. *Workaround implemented in JSF, try to get it fixed in EL properly*
From line 206 changed to line 229:
= (P1) Rendered attribute is overloaded
= (P1) [478=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=478] Rendered attribute is overloaded
From line 208 changed to line 231:
= (P2) [456=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=456] |saveAttachedState| and |restoreAttachedState| should automatically iterate over any java.lang.Iterable and attach/restore the state of each item (currently it just does this for lists)
= (P1) ~[161=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=161]~ Allow alteration of naming container separator character
From line 210 changed to line 233:
= (P2) [358=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=358] Amazing as it seems, JSF provides no API for invalidating the HTTPSession.
= (P1) [475=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=475]Ensure converters are run even if the value is null
From line 212 changed to line 235:
= (P2) [447=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=447] Make FacesEvent parameters optional
= (P2) ~[456=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=456]~ |saveAttachedState| and |restoreAttachedState| should automatically iterate over any java.lang.Iterable and attach/restore the state of each item (currently it just does this for lists)
From line 214 changed to line 237:
= (P2) [230=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=230], [456=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=456] Native support for Collections
= (P2) ~[358=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=358]~ Amazing as it seems, JSF provides no API for invalidating the HTTPSession.
From line 216 changed to line 239:
= (P2) Custom EL function repository. Existing Facelets |+| JSF is segregated, custom EL functions in Facelets can't be evaluated in JSF.
= (P2) ~[447=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=447]~ Make FacesEvent parameters optional
From line 218 changed to line 241:
= (P3) There should be convenience methods to render a JSF view programmatically - this would set up the lifecycle and render the view - after all, you can easily use an alternative ResponseWriter to writer to a StringBuffer. We do this in Seam to allow you to send an email (templated using facelets) from your backing beans - but, unless the request originated in a JSF request (it might be from another source like an MDB, a timer), we have to create our own JSF context.
= (P2) ~[456=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=456]~ Native support for Collections
From line 220 added to lines 243 to 244:
= (P3) [477=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=477]There should be convenience methods to render a JSF view programmatically - this would set up the lifecycle and render the view - after all, you can easily use an alternative ResponseWriter to writer to a StringBuffer. We do this in Seam to allow you to send an email (templated using facelets) from your backing beans - but, unless the request originated in a JSF request (it might be from another source like an MDB, a timer), we have to create our own JSF context.
From lines 224 to 226 changed to line 249:
= (P3) JSF doesn't provide any special functionality for authentication or authorization. I'm not sure what we should do here (if anything), but we need to at least discuss the problem.
= (P1) [161=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=161] Allow alteration of naming container separator character
= (P1) [161=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=161] Allow alteration of naming container separator character
= (P3) ~JSF doesn't provide any special functionality for authentication or authorization. I'm not sure what we should do here (if anything), but we need to at least discuss the problem.~ Spoke to Shane, no need for anything here
