Re: [seam-dev] Module reviews

On Fri, Jun 11, 2010 at 9:20 AM, Pete Muir <pmuir(a)redhat.com&gt; 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?

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.