Its an interesting idea. There are a lot of details to work out but it might not be a bad idea to start discussions about something like this.
I'm not sure I would agree that the MyFaces components belong in Shale. At the moment there seems to be three distinct projects: myfaces (jsf api + impl), components (jsf + shale-only), shale. Shale has the token component, which I like, but seems a little out of place. If there were to be any reorganizing of things I think we could like that component up with the stand alone components of myfaces. There definitely are some natural areas of overlap. I actually ended up here at MyFaces through my interest in what Craig was doing with Shale. Before Shale comes JSF so I ended up here. I think both projects might benefit from a closer relationship. Even if the projects never come under the same large "Apache Faces" umbrella, I think both projects could gain by collaborating more (which I notice is starting to happen recently.) I suggest we keep working together closely and keep the discussions going and see where that takes us. sean On Tue, 15 Mar 2005 18:58:56 -0800 (PST), Ray Clark <[EMAIL PROTECTED]> wrote: > +1 > > After all Shale is a JSF project along with MyFaces. > So organizing them in one place and making it so that > people can plug and play what they want sounds ideal. > > --- David Geary <[EMAIL PROTECTED]> wrote: > > > It would be great to have one-stop shopping of sorts > > for Apache > > projects related to JSF. I like grouping JSF-related > > projects and > > decoupling unrelated pieces at the same time. Apache > > Portals looks like > > a good candidate to emulate. > > > > > > david > > > > Le Mar 15, 2005, � 1:55 PM, Matthias Wessendorf a > > �crit : > > > > > 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 > > > === message truncated === > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com >
