Help

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.

Major issues

A priority grouped list of more major issues that require extensive design and discussion:

Easy Component Creation, standardization of Facelets, Simple development of JSF UIComponents (P1)

(In progress)

It needs to be easy to create register new components written in Java, preferably through annotations

JSF needs its own templating language. Facelets is the perfect starting point. Support for JSP should be deprecated.

It's lucky that there are so many JSF component libraries out there, since developing controls yourself is a huge pain. The biggest problem is JSP, so introducing a standard JSF-specific template language should improve the situation dramatically and make JSF UI component development much more accessible to regular users. The template language could also make it easy to define components which are composed of other components, just like Facelets does today.

Issues:

  • 287 - Defining components via annotations umbrella issue
  • 274 - PDL Umbrella issue
  • 280 - Declarative PDL renderers

View Syntax (P1)

First and foremost, the preferred view syntax should be 100% valid XML and not some pseudo-XML that JSP let in the door. Going beyond basic XML syntax, standard and custom tags should be described using XML Schema, not another proprietary tag descriptor language (TLD). Nearly every XML editor on the planet understands, supports, and can provide tag completion with documentation for the XML document when an XML Schema is associated with it.

XML Schema also has the most advanced facility for describing the valid syntax for an element or attribute (permitted child elements, presence of EL expressions, etc). By standardizing on XML Schema, which itself is a W3C standard, developers don't have to wait for vendors to create tooling for basic XML editing capabilities. Also, developers have become very used to XML schema with it being supported in the Seam component and pages descriptor and Spring and Spring Web Flow configuration files.

In summary, importing a custom tag into a view template would involve defining an XML namespace and optionally (though preferably) associating that namespace with an XML schema document. Component libraries would be required to provide this XML Schema document (perhaps generated; and yes, it is worth doing!). Also, view templates should use the file extension .xml and not try to pretend like it is XHTML by using the .xhtml extension. A longer suffix like .view.xml might be even better. Thus, a view ID would be users.view.xml.

AJAX (P1)

(In progress)

Issues:

Pluggability (P1)

This is a meta issue

One of JSF's key strengths is the ability to easily swap out bits (e.g. the EL resolver, the navigation handler, even the Application. This needs to continue and be made stronger in JSF 2.0

For example, passing values from page-to-page could be good, but, if you are using another framework like Seam, you might want to swap out the implementation for your own. Another example is that the spec proposes solving the concurrent/lost submit problem - again, any solution MUST be pluggable.

Exception/Error Handling (P1)

(In progress)

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.

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.

Issues:

(P3) One very exciting and interesting solution to the first problem would be to redesign the JSF Lifecycle object using a chain-of-responsibility pattern. Each lifecycle phase would be an element of the chain and would be responsible for delegating to the next phase. The application would be able to add in new phases at any point in the chain, which would provide for the possibility of centralized exception handling via around-style interception. We could then deprecate the PhaseListener extension point which is useful but limited and inelegant. This approach would make JSF much more extensible.

Enhanced lifecycle for non-faces requests (P1)

JSF devotes much love and attention to the faces request lifecycle for JSF form submissions. It also talks briefly about something called a non-faces request. The most interesting kind of non-faces request is a HTTP GET request, which - when you think about it - is actually the most common kind of request. Here, the spec is a great disappointment. It's certainly possible to create bookmarkable JSF pages with request parameters, but you lose a level of abstraction, and end up writing servlet-like code.

Seam solves this problem by providing page actions and page parameters, which are similar to the abstractions provided for faces requests. (They also look a lot like the functionality provided by an action-based web framework such as Struts or WebWork.)

JSF 2.0 should define a lifecycle for non-faces requests that includes:

  • validation and model update for request parameters
  • some mechanism for handling validation failures
  • action invocation (Discussion started)
  • some facility to redirect the request to a different URL

In other words, non-faces requests are going to need to provide all the things that faces requests currently provide. The only difference being that the submitted values are not coming from JSF input components, but rather from plain HTTP parameters (in a bookmarkable URL, for example).

The interesting question is exactly where should these actions, the mapping of request parameters to model attributes and validation be declared. The solution provided by Seam today is to declare this in an XML document along with the orchestration logic (navigation). But I'm increasingly favorable to the idea of embedding this in the page definition. For example:

<f:view>
   <f:parameter name="customerName" value="#{customerFinder.name}" required="true">
      <f:validateLength max="100"/>
   </f:parameter>
   <f:onRender action="#{customerFinder.findByName}"/>
   ...
</f:view>

This ties into navigation controls and improvements to the navigation system

Improved orchestration and Navigation controls(P1)

JSF navigation rules provide the basic functionality you expect if you've ever used something like Struts or WebWork. You can write an action method which returns a String-valued outcome, and define navigation rules in XML that determine the view to be rendered or redirected to. The following improvements are sorely needed:

  • Outcomes shouldn't need to be Strings - anything with a toString() method should work Done in JSF 1.2
  • It's much more transparent and elegant if the action method does not need to return an outcome at all - instead, the navigation rule could specify a value expression to be evaluated
  • Navigation rules which perform redirects should be able to specify a list of request parameters to use in the redirect (where the parameter values are defined using value expressions)
  • Navigation rules should be able to specify a HTTP error code as the result Won't fix.

The following kind of thing would be possible:

<navigation-rule>
   <from-action>#{customerFinder.findByName}</from-action>
   <navigation-case>
      <if>#{customerFinder.result!=null}</if>
      <to-view-id>/displayCustomer.xhtml</to-view-id>
      <redirect>
         <parameter-name>customerId</parameter-name>
         <parameter-value>#{customerFinder.result.id}</parameter-value>
      </redirect>
   </navigation-case>
</navigation-rule>

(Seam provides all this functionality today by defining it's own XML-based language for navigation rules.)

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)

Issues:

  • 454 - add <if /> element
  • 484 - Parameters on redirect rules
  • 170 - allow <f:param /> as a child of <h:commandButton />
  • 179 - alterations to navigation handler API
  • 487 - add navigation controls
  • 359 - allow EL in <to-view-id />

Validation (P1)

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.

Subtree validation (481)

Moved to Subtree validation on the JSF 2.1 page.

Inter-component validation

Inter-component validation is a big hole currently - it's fine to do more complex validations in the action method apart from the fact it means validation errors occur in two phases which is confusing for the user.


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.

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 in Seam or Tomahawk to witness the ridiculous amount of code that must be used to handle all of these concerns properly.

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).


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. Issues:

  • 426 - Integration with Bean Validation
  • 480 - Validate null fields
  • 481 - Validate entire subtrees
  • 482 - A default validator
  • 483 - s:decorate

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 - Stateless lifecycle
  • 272 - State management revision
  • 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 Collections in UIData

SelectItems (P2)

Move s:selectItems functionality into the spec and other minor selection enhancements

Related issues:

  • 450 - Allow f:selectItems to reference any Collection or array (not just those of SelectItem)
  • 451 - Support for a noSelection in h:select*
  • 226 - Decoding of SelectOne
  • 230 Native support for Collections

REST (P2)

The JSF2 expert group should work closely with the JSR 311 expert group to define overlapping integration points (unified configuration) and programming models, so that a JSF implementation can work seamlessly with a JAX-RS implementation. For example, a @Path annotated POJO should work as a JSF backing bean without any additional configuration. A JSF application programmer should be able to expose RESTful remote APIs easily.

Related Issues:

  • 146 - Add a pathinfo handling & URL friendly state/param holding
  • 485 - REST umbrella issue
  • 487 - Integration with JAX-RS

Theming/Skinning (P3)

(IMO we are out of time to address this, so should be slipped)

Currently there are themes/skins for most component sets - so that using e.g. Trinidad and RichFaces together looks nasty, without considerable CSS hacking.

Issues:

  • 316 - Skinning umbrella issue

Default Application Time Zone (P2)

Moved to Default application time zone on the JSF 2.1 page


Minor Issues

  • (P1) 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
  • (P1) 428 - Deprecate required="true" in favour of proper validation
  • (P1) Meta issue In general the proposed draft at times appears to be drifting from being a user interface orientated to addressing other problems (for example persistence integration) - sure, make integration possible or even easy, but don't spend too much time on this!
  • (P1) 478 Rendered attribute is overloaded
  • (P1) 161 Allow alteration of naming container separator character
  • (P1) 475Ensure converters are run even if the value is null
  • (P2) 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)
  • (P2) 358 Amazing as it seems, JSF provides no API for invalidating the HTTPSession.
  • (P2) 447 Make FacesEvent parameters optional
  • (P2) 456 Native support for Collections
  • (P3) 477There 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.
  • (P3) 143 - Use generics in validators and converters - very minor, but would save a few casts!
  • (P3) 457 Allow use of EL in messages - JSF's use of EL is a really strong point of the whole architecture. However, one minor thing is missing: messages defined in resource bundles and in FacesMessages should support interpolation of embedded value expressions. (Seam already supports this.)
  • (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

Key

  • P1 - top priority, the problem must be solved for JSF 2 to be a success in our opinion
  • P2 - middle priority, problem should be solved e.g. if other matters are more pressing or the EG is opposed to the idea
  • P3 - low priority, would be nice to get a solution in
22 comments:
26. Aug 2008, 09:11 America/New_York | Link
Daniel

Facelets is great at creating components which are composed of other components, but sometimes it simply doesn’t cut it. You might need to pass a method binding to a component (in a clean, simple way), at other times you simply need to get down to the low-level gritty details of “regular” component development for whatever reason.

Currently, it’s a huge pain and very error prone to create components which are composed of other components without using Facelets. This is the number one issue for me when it comes to component development. It would be great to see some work done to simplify this.

26. Aug 2008, 16:03 America/New_York | Link
Daniel wrote on Aug 26, 2008 09:11:
Facelets is great at creating components which are composed of other components, but sometimes it simply doesn’t cut it. You might need to pass a method binding to a component (in a clean, simple way)

This specific issue is fixed in JSF2.

, at other times you simply need to get down to the low-level gritty details of “regular” component development for whatever reason. Currently, it’s a huge pain and very error prone to create components which are composed of other components without using Facelets. This is the number one issue for me when it comes to component development. It would be great to see some work done to simplify this.

JSF2 also simplifies creating components without using facelets (allowing you to use annotations to register components).

 

Read about how to report a bug.

26. Aug 2008, 16:44 America/New_York | Link
Dave Whittaker

The one thing I see missing here would be extending the templating language to component rendering as well. I'd love to be able to just create a facelets document that referenced my custom component through EL and was responsible for rendering it.

26. Aug 2008, 20:24 America/New_York | Link
Dave Whittaker wrote on Aug 26, 2008 16:44:
The one thing I see missing here would be extending the templating language to component rendering as well. I'd love to be able to just create a facelets document that referenced my custom component through EL and was responsible for rendering it.

It's planned that JSF2 will include support for declarative renderers.

 

Read about how to report a bug.

 
27. Aug 2008, 08:39 America/New_York | Link
Nik

Looks very promising (and ambitious)!

Do you have any estimate on how the timetable of Java EE 6 is holding up to its estimate considering that there is a number of other JSRs that you are coordinating with?

 
28. Aug 2008, 06:27 America/New_York | Link
J-F

To me, it seams that complex validations at the validation level are very hard and not well isolated.

Also, the immediate property really not seams the right thing for what it should do. Something better and more flexible is needed if the goal is to change the flow.

I also think that localization needs a lot more love and standardization. The locale is kind of part of the environment, if it is changed, it has a lot of impacts usually (mostly on ui, but some times in other places). Managing the side effects of localization changes is not as easy at it could be. Particularly, already sent and cached (components, subsystems) values are not that easy to manage.

Isn't conversations part of the deal? They don't need to be directly related to EJB/JPA and are a really useful piece overall.

Finally I think that current navigation sucks really bad and I'm glad that your pulling from seam. I could also see a navigation java object component.

 
29. Aug 2008, 14:10 America/New_York | Link
Daniel
Why use navigation rules at all? IMO they do not provide anything i can't achive with an NavigationHandler which can treat the outcome as a real URL. You can even pass parameters through circumventing the NavigationRules.

I wouldn't say that NavigationRules are useless at a,ll but I haven't come across a situation where I absolutely needed them.
29. Aug 2008, 22:10 America/New_York | Link
Stephen Friedrich
Not terribly important, but not hard to implement either:
A tag that takes a variable number of request parameters from a backing bean, for example
<f:params model="#{paramList}" var="param" name="#{param.name} value="#{param.value}"/>

Currently I think it is simply not possible at all to pass a dynamic list of request parameters.
 
30. Aug 2008, 22:02 America/New_York | Link
Daniel wrote on Aug 29, 2008 14:10:
I wouldn't say that NavigationRules are useless at a,ll but I haven't come across a situation where I absolutely needed them.

I would say they are essential to provide proper separation of concerns.

 

Read about how to report a bug.

30. Aug 2008, 22:17 America/New_York | Link
Stephen Friedrich wrote on Aug 29, 2008 22:10:
Not terribly important, but not hard to implement either: A tag that takes a variable number of request parameters from a backing bean, for example <f:params model="#{paramList}" var="param" name="#{param.name} value="#{param.value}"/> Currently I think it is simply not possible at all to pass a dynamic list of request parameters.

Interesting request. It's not valid XML to repeat an attribute that, but we could probably nest the <f:param> inside a <c:forEach> - I suggest you report it here.

 

Read about how to report a bug.

 
01. Sep 2008, 15:17 America/New_York | Link
Daniel
Pete Muir wrote on Aug 30, 2008 22:02:
I would say they are essential to provide proper separation of concerns.

Then why did you drop it or at least allow the mechanism I supposed in Seam? It was not my intention to drop navigation rules at all but just to enable the sam navigation model in JSF 2.0 which is available in Seam.

 
02. Sep 2008, 00:14 America/New_York | Link
tonyherstell

Is notnull on the entity going to get auto mapped to required=true in the xhtml or is that too seamy?

 
05. Sep 2008, 13:52 America/New_York | Link
tonyherstell wrote on Sep 02, 2008 00:14:
Is notnull on the entity going to get auto mapped to required=true in the xhtml or is that too seamy?

This is up for discussion as part of bean validation integration. I suspect that we'll go with having an <context-param> in web.xml that allows required verification to be delegated to the validation layer.

 

Read about how to report a bug.

 
05. Sep 2008, 13:55 America/New_York | Link
Daniel wrote on Sep 01, 2008 15:17:
Pete Muir wrote on Aug 30, 2008 22:02:
I would say they are essential to provide proper separation of concerns.
Then why did you drop it or at least allow the mechanism I supposed in Seam? It was not my intention to drop navigation rules at all but just to enable the sam navigation model in JSF 2.0 which is available in Seam.

I don't really understand? Drop what? I want to include the semantic changes we made in Seam (support for the if attribute), but I don't think we'll be able to change to the alternative xml structure we have in Seam (attributes rather than elements). I'm not proposing we support the evaluate attribute as don't get the use case for it.

 

Read about how to report a bug.

 
05. Sep 2008, 14:12 America/New_York | Link
J-F wrote on Aug 28, 2008 06:27:
To me, it seams that complex validations at the validation level are very hard and not well isolated.

Agreed, I've yet to see a good solution to this that fits with the JSF concepts.

Also, the immediate property really not seams the right thing for what it should do. Something better and more flexible is needed if the goal is to change the flow.

Yup, I've always avoided this in apps, and never hit a use case where I have to have it. Have you got a use case where you had to use it?

I also think that localization needs a lot more love and standardization. The locale is kind of part of the environment, if it is changed, it has a lot of impacts usually (mostly on ui, but some times in other places). Managing the side effects of localization changes is not as easy at it could be. Particularly, already sent and cached (components, subsystems) values are not that easy to manage.

Can you elaborate some more? Add some concrete use cases.

Isn't conversations part of the deal? They don't need to be directly related to EJB/JPA and are a really useful piece overall.

These are in Web Beans, which will become the preferred component model for JSF.

Finally I think that current navigation sucks really bad and I'm glad that your pulling from seam.

What sucks about it?

I could also see a navigation java object component.

Can you elaborate?

 

Read about how to report a bug.

 
24. Sep 2008, 01:06 America/New_York | Link
Pete Muir wrote on Sep 05, 2008 14:12:
Also, the immediate property really not seams the right thing for what it should do. Something better and more flexible is needed if the goal is to change the flow.
Yup, I've always avoided this in apps, and never hit a use case where I have to have it. Have you got a use case where you had to use it?

I don't really understand never hit a use: You never needed immediate=true or you never had a situation where immediate=true was not sufficient?

In each of my JSF project (four so far) I had a least one UI design for a page where the limitations of the JSF lifecycle prevented me from doing JSF-level validations and I had to do validations in an action listener programmatically. That it turn prevented me from using managed entities as backing beans (invalid values would be written to DB on next flush()).

Here's the most simple use case I had so far: The user is required to select a town. To do that she should make selections in three cascaded drop downs:

1) Region (Europe, Asia, ...)

2) Country

3) Town

All three selectOneChoice's must be required=true, region and country must auto submit (the page should refresh using ajax with the next dropdown filled) and must also be immediate=true (selections should be possible even if other fields are invalid).

But that just won't work: As soon as the user selects a region, she can't just change her mind and select another region without first selecting a country, because both of those fields are immediate, both required=true conditions must be met, before one of them gets its value changed.

This is a point where the JSF lifecycle has a serious shortcoming.

IMHO this use case (handling value changes from exactly one component) is so common, that there should be a way in JSF to traverse the life cycle for exactly one component while ignoring any other components.

24. Sep 2008, 01:11 America/New_York | Link
Pete Muir wrote on Aug 30, 2008 22:17:
Stephen Friedrich wrote on Aug 29, 2008 22:10:
Not terribly important, but not hard to implement either: A tag that takes a variable number of request parameters from a backing bean, for example <f:params model="#{paramList}" var="param" name="#{param.name} value="#{param.value}"/> Currently I think it is simply not possible at all to pass a dynamic list of request parameters.
Interesting request. It's not valid XML to repeat an attribute that, but we could probably nest the <f:param> inside a <c:forEach> - I suggest you report it here.

Hm, which part of

<f:params model="#{paramList}" var="param" name="#{param.name} value="#{param.value}"/>

is not valid XML?

It should work a little like selectItems (iterating over a list and retrieving name/value pairs). The parent components that currently accept f:param would have to be extended to accept f:params, also.

02. Oct 2008, 16:42 America/New_York | Link
Stephen Friedrich wrote on Sep 24, 2008 01:11:
Pete Muir wrote on Aug 30, 2008 22:17:
Stephen Friedrich wrote on Aug 29, 2008 22:10:
Not terribly important, but not hard to implement either: A tag that takes a variable number of request parameters from a backing bean, for example <f:params model="#{paramList}" var="param" name="#{param.name} value="#{param.value}"/> Currently I think it is simply not possible at all to pass a dynamic list of request parameters.
Interesting request. It's not valid XML to repeat an attribute that, but we could probably nest the <f:param> inside a <c:forEach> - I suggest you report it here.
Hm, which part of
<f:params model="#{paramList}" var="param" name="#{param.name} value="#{param.value}"/>
is not valid XML? It should work a little like selectItems (iterating over a list and retrieving name/value pairs). The parent components that currently accept f:param would have to be extended to accept f:params, also.

Misread your post - sorry.

Can you file an issue at http://javaserverfaces-spec-public.dev.java.net?

 

Read about how to report a bug.

 
09. Oct 2008, 03:57 America/New_York | Link
OtengiM

JSF is over-engineered, It is garbage. Better use Wicket and Seam 2.1 support Wicket already as first class citizen. Also there is the project web beans for Wicket, Wicket should be the standard component framework for Java because is very well designed and clean. I don't understand why some people keep playing with JSF, it does not make sense.

 
02. Jun 2009, 16:23 America/New_York | Link
Serkan

It should be great if XHTML Strict support is also available in JSF2.x. AFAIK, only XHTML Transitional is supported at the moment, but that's not always needed.

Especially governments and those who want to build webpages according to the web guidelines need XHTML Strict pages.

And this lack makes it hard to use JSF in those kind of projects.

 
05. Mar 2010, 11:43 America/New_York | Link
<blockquote>
_Stephen Friedrich wrote on Sep 24, 2008 01:06:_<br/>

<blockquote>
_Pete Muir wrote on Sep 05, 2008 14:12:_<br/>

<blockquote>
Also, the immediate property really not seams the right thing for what it should do. Something better and more flexible is needed if the goal is to change the flow.
</blockquote>

Yup, I've always avoided this in apps, and never hit a use case where I have to have it. Have you got a use case where you had to use it?


</blockquote>

I don't really understand "never hit a use": You never needed immediate\="true" or you never had a situation where immediate\="true" was not sufficient?

In each of my JSF project (four so far) I had a least one UI design for a page where the limitations of the JSF lifecycle prevented me from doing JSF-level validations and I had to do validations in an action listener programmatically.
That it turn prevented me from using managed entities as backing beans (invalid values would be written to DB on next flush()).

Here's the most simple use case I had so far: The user is required to select a town. To do that she should make selections in three cascaded drop downs:

1) Region (Europe, Asia, ...)

2) Country

3) Town

All three selectOneChoice's must be required\="true", region and country must auto submit (the page should refresh using ajax with the next dropdown filled) and must also be immediate\="true" (selections should be possible even if other fields are invalid).

But that just won't work: As soon as the user selects a region, she can't just change her mind and select another region without first selecting a country, because both of those fields are immediate, both required\="true" conditions must be met, before one of them gets its value changed.

This is a point where the JSF lifecycle has a serious shortcoming.

IMHO this use case (handling value changes from exactly one component) is so common, that there should be a way in JSF to traverse the life cycle for _exactly one_ component while ignoring any other components.
</blockquote>

<blockquote>
 I have also strugled with this aanoying JSF feature. But is one workaround to use <form> around
 components ?
</blockquote>

 
10. Mar 2011, 03:33 America/New_York | Link

how can we make Seam 2.2.1 Final work with JSF 2??????