> Going back to the faces module, instead of continuing with the
> org.jboss.seam.jsf and org.jboss.seam.faces package split in Seam 3, I think
> we should put all the faces classes under org.jboss.seam.faces and use
> appropriate sub-package names. So in this case, I propose
> org.jboss.seam.faces.application.SeamApplicationFactory and
> org.jboss.seam.faces.application.SeamApplication for overriding the default
> Application impl. We will also need the org.jboss.seam.el package (perhaps
> module).
>
+1 for this idea. The module dependencies are turning out to be quite
difficult to unravel, if we put our foot down and say that all
faces-related/dependent functionality just goes in the faces module this
will greatly help to simplify things.
I think it's just a matter of zooming out to look at the bigger picture when
things seem like they are in a twist.
Instead of thinking of replacing the class 1-for-1, think if perhaps there
is base functionality that would be relevant for any environment and
specific functionality for a framework like JSF. Then, you can create a
generic class and then specialize it using a deployment type and
@Specializes. Two examples of this so far are
StatusMessages/FacesStatusMessages and Expressions/FacesExpressions. I
believe that Selector is another candidate for this. There is nothing
specific to JSF about a selector, but it just happens to be in the JSF
package in Seam 2.1.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.