On Fri, Jun 11, 2010 at 9:20 AM, Pete Muir <pmuir(a)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?
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.
https://jira.jboss.org/browse/SEAMFACES-28
* review how many of the ancillary support tags (e.g. label) actually
made
it into JSF.
https://jira.jboss.org/browse/SEAMFACES-36
https://jira.jboss.org/browse/SEAMFACES-32
https://jira.jboss.org/browse/SEAMFACES-34
https://jira.jboss.org/browse/SEAMFACES-35
* support for Seam Managed Transactions
https://jira.jboss.org/browse/SEAMFACES-29
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
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"