[seam-dev] Module reviews

[Pete Muir]

On 14 Jun 2010, at 16:23, Lincoln Baxter, III wrote:

> On Fri, Jun 11, 2010 at 9:20 AM, Pete Muir <pmuir at redhat.com> wrote:
> All,
> 
> A series of notes from the review Gavin and I did of the work so far on Seam 3 and what needs to be done.
> 
> Faces
> --------
> 
> * Attaching a FormValidator would work better if we attached by form id. For example:
> 
> <h:form id="locationForm">
>   ...
> </h:form>
> 
> @FacesValidator("locationForm")
> public class LocationValidator implements Validator {
>   ...
> }
> 
> would automatically cause this validator to be used. 
> 
> On PreValidateComponentEvent -- 
> if component == UIForm, search for validator with same ID as name of form
> attach UIFormValidator as child element, and attach validator instance to UIFormValidator instance.
> 
> Unfortunately, this assumes the existance of only 1 FormValidator per form, which is likely not the case in many scenarios; It encourages breaking separation of concerns (where now you have only 1 validator handling multiple scenarios per form -- if you do have multiple scenarios-- and many different combinations of fields that may or may not be related.This also breaks re-use of FormValidators by hard-binding form field IDs to validator field names.
> 
> There is also the danger of bleeding across views, where a formValidator is created that "accidentally" becomes attached to another form with the same name on a different page, or when you want to use the same form-name, but can't because you will automatically trigger form validation (that would likely fail (forcing you to disable it in some way, or choose a different name.)
> 
> This could also have the undesired effect of attaching validators that are not intended to be form validators (perhaps validators that were not even defined by the developer themselves -- e.g.: included in a JAR file.) 
> 
> Does this feature really buy us much?

Right, this would make more sense if it was a @FormValidator() with the value representing the formId.

> 
> https://jira.jboss.org/browse/SEAMFACES-37
> 
> 
> * We need a pages.xml replacement still. Gavin posted to seam-dev about an enum-based navigation system called "Replacing pages.xml" on 29th Feb 2010. The concept here is pretty elegant and well proven (e.g. Wicket).   
> 
> https://jira.jboss.org/browse/SEAMFACES-33
>  
> 
> * Page fragment caching 
>  
> https://jira.jboss.org/browse/SEAMFACES-30 
>  
> * URL Rewriting
> 
> https://jira.jboss.org/browse/SEAMFACES-31 
>  
> * conversationId tag
> 
> https://jira.jboss.org/browse/SEAMFACES-32
>  
> 
> * object/entity converter -
>  
> I'm investigating if this is still required. Also, if it is, there's a good chance that we no longer have a scope capable of explicitly providing this support (there'll have to be a custom solution.) FlashScope doesn't work because it dies after render, and conversation scope has the same problem unless you're in an LRC. This means we are left with SessionScope or a new custom scope.

EntityConverter really only worked well in a LRC anyway IIRC.