On 14 Jun 2010, at 16:23, Lincoln Baxter, III wrote: > On Fri, Jun 11, 2010 at 9:20 AM, Pete Muir <[email protected]> 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. _______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
