+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
