On 29 Apr 2009, at 07:10, Dan Allen wrote:
>
>
> 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.
Exactly, the compex dependency graph exist if you just dump everything
in one big heap, it's just not as visible :-)
--
Pete Muir
http://www.seamframework.orghttp://in.relation.to/Bloggers/Pete_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev