David,
I am just about to answer Craig regarding his post... But you said it very very clear to something I just thought... So here is my post...
Take a look at Apache Portals, that is something I have in mind on *long term*
There could be a similar Toplevel Project btw. name it "Apache Faces". One of the subprojects could be MyFaces, since it is a implementation of the Faces Spec.
Another could subprojects could contain only custom components
Another could host some sample apps that explain the "usage" of Faces (with and without the custom components)
And also Shale could be a subproject of that Apache Faces project, since Shale is a (cool) framework that leverages JSF.
Let me come back to Portals, they host pluto (portlet impl. (yes RI)) and some usages like remote portals and Jetspeed portal stuff.
So why not "copy" that what strutcture, since it was/is good for Portlet technology, for the JavaServer Faces technology ?
BTW. I hope it's not to radical ;)
-Matthias
David Geary wrote:
This begs the question of why MyFaces components aren't a project of their own. An FAQ on this mailing list is whether the MyFaces components will work with the RI, so there's some confusion as to why MyFaces has components that aren't MyFaces-specific.
Perhaps Shale should absorb the MyFaces components. 8-)
david
Le Mar 15, 2005, � 11:32 AM, Craig McClanahan a �crit :
On Tue, 15 Mar 2005 13:43:08 +0100, Matthias Wessendorf
[snip]
Fine! Working together should be the best JSF user could get, independent from which Impl of JSF Spec they might use.
Absolutely.
It is very important, that Shale works with MyFaces (it does, I am "playing" with both during learning Shale ;))
Shale tries to make zero non-spec assumptions about the underlying implementation, so working with both MyFaces and the RI will keep me honest too :-).
Also MyFaces' extra components should work with Shale; haven't looked at the remote thing in Shale. "Only" looked in "ViewController" and I am fascinated about that! But session scoped "DialogController" seams also to be very usefull.
Word of caution -- DialogController is likely to be undergoing some revisions.
As you also pointed out, that we are discussing the subproject issue, does it make sense for you, to host Shale at MyFaces?
If the scope of MyFaces had been "We want to create a JSF spec-compliant implementation, *and* we want to build other things that depend on JSF" it might be a good fit. Since the scope actually seems to be "We want to create a JSF spec-compliant implementation, and oh by the way here are some cool components" that wasn't as good a fit as Struts, where the mission is to create a web app framework.
For now, Shale got accepted as a Struts sub-project. Whether it stays there, or migrates here, or graduates to its own status in the future -- that's going to depend on what actually happens. In the mean time, we can work together on value adds, and figure out how to share as we go.
Shale should be build on top of JSF API, like our components.
Yep.
Since Shale is a framework that tries to leverages JSF, I see some "overlap" in MyFaces' custom components and Shale (and its components). Also both "teams" will have some util classes, that do the same stuff for providing helper methods, independent from a specific implementation.
see: http://tinyurl.com/4zhd7
Although, as I remarked in reponse to this particular post, I'm tired of getting burned by implementing static helper classes :-).
But your point is well taken. Where does one create components that have Shale dependencies, for example?
or the mentioned "client side validation" or "file upload component" for instance.
It's going to be interesting to work these things out.
-Matthias
Craig
-- Matthias We�endorf Aechterhoek 18 DE-48282 Emsdetten Germany phone: +49-2572-9170275 cell phone: +49-179-1118979 email: matzew AT apache DOT org url: http://www.wessendorf.net callto://mwessendorf (Skype) icq: 47016183
