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. * 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). * Page fragment caching * URL Rewriting * conversationId tag * object/entity converter * review how many of the ancillary support tags (e.g. label) actually made it into JSF. * support for Seam Managed Transactions Lincoln - please can you make sure we have the relevant JIRAs to track these and post for trackback. --------- Servlet --------- All looks good. --------- Seam XML --------- * CDI annotations need to come from the CDI namespace, not the Seam namespace. For example:   <s:Qualifier /> or <s:Specializes /> -> <cdi:Qualifier /> or <cdi:Specializes /> * A few deviations from the original spec, we should double check each one. Otherwise, looking great. Stuart, will you make sure we have a JIRA for both of these, and post for trackback. --------- i8ln --------- * Currently, all the examples show using XML to set up the locales and default system locale. Need some examples showing how to set this in Java (does this exist? probably use the same approach as for setting the client locale - events) * Approach of treating messages like a logger is good * Resource bundle handling is wrong, it produces far to strong coupling between specifying the key and specifying which method to log (bundle key specification is totally orthognal to actual logging call) * In general, rewrite the messages API along the lines of JBoss Logging 3 - I will take the lead on this. This will then be totally consistent with our logging approach once we switch from slf4j to JBoss Logging 3. Ken, can you make sure there are JIRAs and post for trackback --------- WeldX --------- * Support for @Introduces * Bean declaration at constructor level I will create JIRAs and post for trackback. Stuart, are you interested in working on some of this? --------- Persistence --------- * Currently languishing. I will take the lead. * Make sure it contains @TransactionScoped * Support for SMPC * Support for persistence and TX outside Java EE * Hibernate search support ---------- CRUD framework ---------- * Gavin will jot down some notes in a blog to get this started. --------- Compatibility --------- * Target is Seam 3.1 * Conversion tool may be useful, but we need a bridge * If Seam 2 is present, may have to disable Seam 3 modules --------- JMS --------- * Change back to original design from spec draft from 20090520 where we use the producer field pattern to provide access JMS artifacts (I will follow up with a copy). This is much more flexible, as it allows the use of @Alternative etc. * Routing of events - change back to original design from spec draft (as above) where we generate proxies for relevant interfaces with @Observes: interface JMSMapping {   void myMapping(@Observes @SomeQualifier SomeType type, @MyTopic Topic topic); } and support the use of @Alternative on this to enable disable/disable it. ---------- Security ---------- * Review held back until more details emerge Other modules we didn't discuss in any detail, but include: Remoting, jBPM, Drools, seam-gen Pete _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

In the meeting on IRC yesterday we spoke at length about the CRUD framework, I don't know if that discussion was written down anywhere or put up on the wiki. I know Dan Allen pretty much lead the conversation.

On Fri, Jun 11, 2010 at 7:00 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: On Fri, Jun 11, 2010 at 1:57 PM, Jason Porter <lightguard.jp(a)gmail.com&gt; wrote: In the meeting on IRC yesterday we spoke at length about the CRUD framework, I don't know if that discussion was written down anywhere or put up on the wiki. I know Dan Allen pretty much lead the conversation. Primarily, my message was that we had a lot of ideas floating around and consolidation was needed, followed by action ;) We mostly talked about: 1. Not coupling it with UI controllers (that's an orthogonal concern)

2. Home is a word which few people really get, we should pick something more applicable like EntityFacade or EntityCRUD

3. The query framework should provide an API which is technology agnostic, with implementations for JPA and others (room for JDO, nosql, REST)

4. We proposed renaming it to the Seam data framework, since the core features revolve around reading and writing entities/resources to persistence storage (i.e., data) The UI controllers would likely be more suitable in the UI modules, such as faces and wicket

Ok, Dan, please write up whatever you came up with. Thanks Jason :-) On 11 Jun 2010, at 18:57, Jason Porter wrote: > In the meeting on IRC yesterday we spoke at length about the CRUD > framework, I don't know if that discussion was written down anywhere > or put up on the wiki. I know Dan Allen pretty much lead the > conversation. > > On Fri, Jun 11, 2010 at 11:44, Gavin King <gavin.king(a)gmail.com&gt; wrote: >> Thanks for writing up this stuff, Pete. >> >> On Fri, Jun 11, 2010 at 3:20 PM, 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. >>> >>> * 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). >>> >>> * Page fragment caching >>> >>> * URL Rewriting >>> >>> * conversationId tag >>> >>> * object/entity converter >>> >>> * review how many of the ancillary support tags (e.g. label) actually made it into JSF. >>> >>> * support for Seam Managed Transactions >>> >>> Lincoln - please can you make sure we have the relevant JIRAs to track these and post for trackback. >>> >>> >>> --------- >>> Servlet >>> --------- >>> >>> All looks good. >>> >>> >>> --------- >>> Seam XML >>> --------- >>> >>> * CDI annotations need to come from the CDI namespace, not the Seam namespace. For example: >>> >>> <s:Qualifier /> or <s:Specializes /> -> <cdi:Qualifier /> or <cdi:Specializes /> >>> >>> * A few deviations from the original spec, we should double check each one. >>> >>> Otherwise, looking great. Stuart, will you make sure we have a JIRA for both of these, and post for trackback. >>> >>> >>> --------- >>> i8ln >>> --------- >>> >>> * Currently, all the examples show using XML to set up the locales and default system locale. Need some examples showing how to set this in Java (does this exist? probably use the same approach as for setting the client locale - events) >>> * Approach of treating messages like a logger is good >>> * Resource bundle handling is wrong, it produces far to strong coupling between specifying the key and specifying which method to log (bundle key specification is totally orthognal to actual logging call) >>> * In general, rewrite the messages API along the lines of JBoss Logging 3 - I will take the lead on this. This will then be totally consistent with our logging approach once we switch from slf4j to JBoss Logging 3. >>> >>> Ken, can you make sure there are JIRAs and post for trackback >>> >>> >>> --------- >>> WeldX >>> --------- >>> >>> * Support for @Introduces >>> * Bean declaration at constructor level >>> >>> I will create JIRAs and post for trackback. Stuart, are you interested in working on some of this? >>> >>> >>> --------- >>> Persistence >>> --------- >>> >>> * Currently languishing. I will take the lead. >>> * Make sure it contains @TransactionScoped >>> * Support for SMPC >>> * Support for persistence and TX outside Java EE >>> * Hibernate search support >>> >>> >>> ---------- >>> CRUD framework >>> ---------- >>> >>> * Gavin will jot down some notes in a blog to get this started. >>> >>> >>> --------- >>> Compatibility >>> --------- >>> >>> * Target is Seam 3.1 >>> * Conversion tool may be useful, but we need a bridge >>> * If Seam 2 is present, may have to disable Seam 3 modules >>> >>> >>> --------- >>> JMS >>> --------- >>> >>> * Change back to original design from spec draft from 20090520 where we use the producer field pattern to provide access JMS artifacts (I will follow up with a copy). This is much more flexible, as it allows the use of @Alternative etc. >>> * Routing of events - change back to original design from spec draft (as above) where we generate proxies for relevant interfaces with @Observes: >>> >>> interface JMSMapping { >>> >>> void myMapping(@Observes @SomeQualifier SomeType type, @MyTopic Topic topic); >>> >>> } >>> >>> and support the use of @Alternative on this to enable disable/disable it. >>> >>> >>> ---------- >>> Security >>> ---------- >>> >>> * Review held back until more details emerge >>> >>> >>> Other modules we didn't discuss in any detail, but include: Remoting, jBPM, Drools, seam-gen >>> >>> Pete >>> _______________________________________________ >>> seam-dev mailing list >>> seam-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/seam-dev >>> >> >> >> >> -- >> Gavin King >> gavin.king(a)gmail.com >> http://in.relation.to/Bloggers/Gavin >> http://hibernate.org >> http://seamframework.org >> >> _______________________________________________ >> seam-dev mailing list >> seam-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> > > > > -- > Jason Porter > http://lightguard-jp.blogspot.com > http://twitter.com/lightguardjp > > Software Engineer > Open Source Advocate > > PGP key id: 926CCFF5 > PGP key available at: keyserver.net, pgp.mit.edu _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

From: Pete Muir <pmuir(a)redhat.com&gt; Date: 12 June 2010 16:13:36 EDT To: Pete Muir <pmuir(a)redhat.com&gt; Cc: "seam-dev >> seam-dev(a)lists.jboss.org Development List" <seam-dev(a)lists.jboss.org&gt; Subject: Re: [seam-dev] Module reviews See 10.7 and 3.8

On 11 Jun 2010, at 14:20, Pete Muir wrote: > --------- > JMS > --------- > > * Change back to original design from spec draft from 20090520 where we use the producer field pattern to provide access JMS artifacts (I will follow up with a copy). This is much more flexible, as it allows the use of @Alternative etc. > * Routing of events - change back to original design from spec draft (as above) where we generate proxies for relevant interfaces with @Observes: > > interface JMSMapping { > > void myMapping(@Observes @SomeQualifier SomeType type, @MyTopic Topic topic); > > } > > and support the use of @Alternative on this to enable disable/disable it.

--------- WeldX --------- * Support for @Introduces

* Bean declaration at constructor level

> --------- > Seam XML > --------- > > * CDI annotations need to come from the CDI namespace, not the Seam namespace. For example: > >   <s:Qualifier /> or <s:Specializes /> -> <cdi:Qualifier /> or <cdi:Specializes /> What namespace is <cdi: bound to? http://java.sun.com/xml/ns/javaee? If so should I dump the seam namespace entirely, or just move the annotations into a different namespace?

Currently it is: "java.lang", "java.util", "javax.annotation", "javax.inject", "javax.enterprise.inject", "javax.enterprise.context", "javax.enterprise.event", "javax.decorator", "javax.interceptor", Should the root namespace for seam-xml be changed to http://java.sun.com/xml/ns/javaee? I did not use this originally for portability reasons, as other CDI implementations might not like having 'foreign' elements in this namespace in beans.xml.

Stuart On 14/06/2010, at 4:43 PM, Gavin King wrote: > On Mon, Jun 14, 2010 at 8:21 AM, Stuart Douglas > <stuart(a)baileyroberts.com.au&gt; wrote: > >>> --------- >>> Seam XML >>> --------- >>> >>> * CDI annotations need to come from the CDI namespace, not the Seam namespace. For example: >>> >>> <s:Qualifier /> or <s:Specializes /> -> <cdi:Qualifier /> or <cdi:Specializes /> >> >> What namespace is <cdi: bound to? http://java.sun.com/xml/ns/javaee? >> >> If so should I dump the seam namespace entirely, or just move the annotations into a different namespace? > > > Things that are annotations or types from the CDI/EE packages > javax.enterprise.inject, javax.inject, etc, should all live in the > default namespace. Not quite sure what it should be called, but the > spec used to say: > > The Java EE namespace urn:java:ee represents the following packages: > > • java.lang > • java.util > • javax.annotation > • javax.enterprise.inject > • javax.enterprise.context > • javax.interceptor > • javax.decorator > • javax.enterprise.event > • javax.ejb > • javax.persistence > • javax.xml.ws > • javax.jms > • javax.sql > > Now, for what we're doing, that list is probably a bit long and could > be trimmed. > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org

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.

On Mon, Jun 14, 2010 at 5:23 PM, Lincoln Baxter, III <lincolnbaxter(a)gmail.com&gt; wrote: > Unfortunately, this assumes the existance of only 1 FormValidator per form, > which is likely not the case in many scenarios; I don't see how or why it assumes that. Why could I not have multiple validators which all specified that they belonged to the same form? Or are you trying to say that it encourages one form per form validator? (That's not what you wrote.) > 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. So the intention here is that you would create reusable form validators that would attach to common, repeated combinations of input fields that appear in many forms? This seems deeply, deeply doubtful to me. It seems that in this case you should be composing a reusable JSF component out of the smaller fields and attaching a single validator to it. Cross-field validation is usually something that is very specific to a single form in the application, in my experience. > This also > breaks re-use of FormValidators by hard-binding form field IDs to validator > field names. Again, I don't see that cross-field validation is something that is often reusable. On the contrary, it's highly uncommon to see repeated combinations of fields in several different forms, and when you do see it, it's usually a case where you should factor out some higher-level control (like a datetime control or whatever). I'm not saying that it's unimaginable, just that it's not at all the common case. > 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.) That all sounds totally trivial to solve via a combination of view id and form id. @FormValidator(view="login.jsf", form="loginForm") > 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.) huh? > Does this feature really buy us much? Well, it lets you encapsulate all the information about the form validator in exactly one place, saving you the need to add a special tag to your JSF page. And keeping all information about validation outside of the view definition (which is the case with single-field validation via bean validation annotations). Now, I would not argue that this is something super-important from a software engineering perspective, but it certainly looks clean and is convenient in the common case. When I looked at the <formValidator/> tag in the JSF view, it looked anything but clean. I'm talking pure aesthetics here. -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

I don't see how or why it assumes that. Why could I not have multiple validators which all specified that they belonged to the same form?

Hehe :) I'm in favor of the @FormValidator(...) annotation. Sold, for an annotation. --Lincoln On Mon, Jun 14, 2010 at 8:19 PM, Gavin King <gavin.king(a)gmail.com&gt; wrote: > P.S. shouldn't FormValidator be called ActionForm? > > *ducks* > > On Tue, Jun 15, 2010 at 2:17 AM, Gavin King <gavin.king(a)gmail.com&gt; wrote: > > On Mon, Jun 14, 2010 at 5:23 PM, Lincoln Baxter, III > > <lincolnbaxter(a)gmail.com&gt; wrote: > > > >> Unfortunately, this assumes the existance of only 1 FormValidator per > form, > >> which is likely not the case in many scenarios; > > > > I don't see how or why it assumes that. Why could I not have multiple > > validators which all specified that they belonged to the same form? > > > > Or are you trying to say that it encourages one form per form > > validator? (That's not what you wrote.) > > > >> 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. > > > > So the intention here is that you would create reusable form > > validators that would attach to common, repeated combinations of input > > fields that appear in many forms? This seems deeply, deeply doubtful > > to me. It seems that in this case you should be composing a reusable > > JSF component out of the smaller fields and attaching a single > > validator to it. Cross-field validation is usually something that is > > very specific to a single form in the application, in my experience. > > > >> This also > >> breaks re-use of FormValidators by hard-binding form field IDs to > validator > >> field names. > > > > Again, I don't see that cross-field validation is something that is > > often reusable. On the contrary, it's highly uncommon to see repeated > > combinations of fields in several different forms, and when you do see > > it, it's usually a case where you should factor out some higher-level > > control (like a datetime control or whatever). > > > > I'm not saying that it's unimaginable, just that it's not at all the > > common case. > > > >> 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.) > > > > That all sounds totally trivial to solve via a combination of view id > > and form id. > > > > @FormValidator(view="login.jsf", form="loginForm") > > > >> 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.) > > > > huh? > > > >> Does this feature really buy us much? > > > > Well, it lets you encapsulate all the information about the form > > validator in exactly one place, saving you the need to add a special > > tag to your JSF page. And keeping all information about validation > > outside of the view definition (which is the case with single-field > > validation via bean validation annotations). Now, I would not argue > > that this is something super-important from a software engineering > > perspective, but it certainly looks clean and is convenient in the > > common case. When I looked at the <formValidator/> tag in the JSF > > view, it looked anything but clean. I'm talking pure aesthetics here. > > > > > > -- > > Gavin King > > gavin.king(a)gmail.com > > http://in.relation.to/Bloggers/Gavin > > http://hibernate.org > > http://seamframework.org > > > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"