You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by David Geary <sa...@earthlink.net> on 2005/03/15 21:45:51 UTC
Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
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
>
Re: Shale and MyFaces (was Re: How to execute bean method before
JSF page is loaded?)
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
Kito-
I haven't said that Shale should be integrated into MyFaces
or a subproject of MyFaces.
I was talking about a *generell* JavaServer Faces Project
under the umbrella of Apache Software Foundation.
Called "Apache Faces" or something similar to that.
(like "Apache Portals" is for the Portlet-API (http://portals.apache.org)
Apache Faces could have subprojects like:
-Shale, a framework for leveraging JSF technology
-Components, open source components for enhancing JSF standard
-MyFaces, the JSF impl from ASF
Shale and Components should be independend from MyFaces implementation.
Since it makes sense to use that software with any JSF impl.
(SUN, IBM, etc)
-Matthias
Kito D. Mann wrote:
> Personally, I'm not convinced that Shale really should be part of the
> MyFaces project. If you look at JSF as a foundation for UI frameworks
> (and more sophisticated web frameworks in general), then hopefully we'll
> see it pop up in lots of different places (in my perfect world, even
> Tapestry would use JSF components). Placing all projects that use JSF
> under one umbrella may break over time as JSF grows. (For example, all
> Java projects are no longer part of Jakarta.)
>
> Moreover, although Shale is based on JSF, it will hopefully be the next
> major revision of Struts. Struts has its own very strong brand, and it
> seems strange to pull Shale away from that.
>
> That's my $0.02.
>
> Kito D. Mann
> Author, JavaServer Faces in Action
> http://www.JSFCentral.com - JSF FAQ, news, and info
>
> Are you using JSF in a project? Send an e-mail to
> trenches@jsfcentral.com and you could win a free copy of JavaServer
> Faces in Action!
>
> At 02:29 AM 3/16/2005, you wrote:
>
>>> 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.
>>
>>
>> Nice to hear that some of you like the *idea*. It was just only a idea
>> for now and yes there must be provided more to be concret on something
>> like that. Since there seams to be interesst it is worth to go that road.
>>
>>> 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.
>>
>>
>>
>> yes that's the best as far as I see. And perhaps a fourth subproject
>> for sample apps; all JSF users could benefit from a wide range of sample
>> apps
>>
>>> 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.
>>
>>
>>
>> yes token could also be inside of "JSF Components" (or how you could
>> call such a subproject)
>>
>>> I suggest we keep working together closely and keep the discussions
>>> going and see where that takes us.
>>
>>
>> Yes, that is right! It is should be the best for the users of the JSF
>> spec.
>>
>> The benefit from a *big* Apache Faces project is
>> a) users *can* (not must) use a impl. that is shipped under a liberal
>> licence (Apache2.0)
>> b)Having lot's of cool components for a usage with *any* JSF impl.
>> c)Having a framework ontop of JSF to leverage the development of JSF
>> web app (also not bound to a specific JSF impl)
>>
>> -Matthias
>>
>>
>>> sean
>>>
>>> On Tue, 15 Mar 2005 18:58:56 -0800 (PST), Ray Clark
>>> <rc...@yahoo.com> 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 <sa...@earthlink.net> 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
>>
>>
>> "Existence doesn't necessarily mean living..."
>
>
>
--
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
Re: Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
Posted by Bruno Aranda <br...@gmail.com>.
Also a FAQ was added recently answering to this question, but we
should made the issue more visible as Sean points out,
Bruno
On Wed, 16 Mar 2005 14:30:15 -0500, Sean Schofield
<se...@gmail.com> wrote:
> I agree 100% with Martin on this one.
>
> On one of these threads Kito made a comment about people being
> confused about the myfaces components and whether or not they require
> myfaces. We should do our best to promote the fact that the
> components are independent of the implementation. Improvements to our
> documentation will help with that.
>
> There is a place holder "overview" page on the myfaces site where just
> such documentation should go. I will add some shortly.
>
> sean
>
> On Wed, 16 Mar 2005 20:18:23 +0100, Martin Marinschek
> <ma...@gmail.com> wrote:
> > I am replying to several postings on the mailing list in the last time
> > at once, so sorry if I puzzle someone.
> >
> > With all this discussion on toplevel or sublevel or whatever level
> > projects we should still try to get our infrastructure up-to-date
> > first (I agree with Matthias and his former postings on this topic).
> >
> > In the last one and a half years, we have had (4) different homepages,
> > we should finally try to get the dust cloud to settle down.
> >
> > For the meantime, I believe that all is quite good as it is right now,
> > even with the components being part of MyFaces.
> >
> > The thing is that it is much easier to work on the components if they
> > are at least part of the common source base of the framework, and this
> > might be a reason why the components of MyFaces are indeed thriving as
> > much as they do.
> >
> > As soon as we get to be a large bureaucratic body, we should stop,
> > rethink our ways and move the components out to a subproject.
> >
> > regards,
> >
> > Martin
> >
> >
> > On Wed, 16 Mar 2005 13:16:53 -0500, Sean Schofield
> > <se...@gmail.com> wrote:
> > > On Wed, 16 Mar 2005 12:46:58 -0500, Kito D. Mann <km...@virtua.com> wrote:
> > > > Personally, I'm not convinced that Shale really should be part of the
> > > > MyFaces project. If you look at JSF as a foundation for UI frameworks (and
> > > > more sophisticated web frameworks in general), then hopefully we'll see it
> > > > pop up in lots of different places (in my perfect world, even Tapestry
> > > > would use JSF components). Placing all projects that use JSF under one
> > > > umbrella may break over time as JSF grows. (For example, all Java projects
> > > > are no longer part of Jakarta.)
> > >
> > > Good point. We definitely don't want to rush into something like
> > > this. There are potential drawbacks as you pointed out.
> > >
> > > > Moreover, although Shale is based on JSF, it will hopefully be the next
> > > > major revision of Struts. Struts has its own very strong brand, and it
> > > > seems strange to pull Shale away from that.
> > >
> > > That is a big question mark but I happen to agree with you (and Craig)
> > > on the desirability of that outcome. Moving Shale to a new project
> > > does pretty much give up on that idea so I can see that as a drawback.
> > >
> > > sean
> > >
> >
>
Re: Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
Posted by Sean Schofield <se...@gmail.com>.
> Shale is an accepted Struts sub-project (a project that is focused on
> providing a web MVC framework). If I get my way (in the long term),
> it will become the next generation of Struts. If its clear that this
> won't happen, only then is it reasonable to think about alternative
> homes.
I am still rooting for the Struts 2.0 outcome of course.
[snip]
> In the mean time, let's work on some code instead of committees and
> projects :-). After all, organizational lines do not have to
> represent barriers to cooperation.
Yes. Hopefully all of this talk of cooperation will result in some actual code!
> Craig
sean
Re: Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
Posted by Craig McClanahan <cr...@gmail.com>.
On Thu, 17 Mar 2005 13:38:02 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > I prefer Matthias' proposal for Apache Faces. I think it'd be great to
> > have all JSF-related technologies in one project.
>
> Yes. This is a good idea if we can get buy in from Shale folks, etc.
>
Shale is an accepted Struts sub-project (a project that is focused on
providing a web MVC framework). If I get my way (in the long term),
it will become the next generation of Struts. If its clear that this
won't happen, only then is it reasonable to think about alternative
homes.
Technology-specific Apache projects tend not to scale well (Jakarta,
for example, is a mishmash that has little formal cohesion), and top
level projects (like Struts) have spun out of it to stay focused on
their own goals. Even if we created Apache Faces along the lines
being discussed, there will always be cases where a technology
"belongs" there (because of use of JSF) and "belongs" elsewhere
(because the use of JSF is ancillary to the primary mission). From
the Apache perspective, starting another "umbrella" thing like this
one would likely be frowned on.
In the mean time, let's work on some code instead of committees and
projects :-). After all, organizational lines do not have to
represent barriers to cooperation.
Craig
Re: Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
Posted by Sean Schofield <se...@gmail.com>.
> I prefer Matthias' proposal for Apache Faces. I think it'd be great to
> have all JSF-related technologies in one project.
Yes. This is a good idea if we can get buy in from Shale folks, etc.
> As for the Faces components, as long as they're MyFaces components,
> people will be confused about using them standalone. We can add
> documentation, but people will still be confused. The only way to
> eliminate the confusion is to put them in a separate project.
I disagree. Having a big Apache Faces project with lots of little
subprojects is also likely to confuse people. I imagine there are
people confused by the jakarta project and all of its subprojects.
"Do I have to use all of the jakarta projects if I just want
digester?"
> I think the components will thrive independent of MyFaces. The JSF
> community needs a good open-source component set independent of a
> particular JSF implementation and I feel like we're hiding one inside
> MyFaces at the moment.
I agree the components could thrive independent of the MyFaces
implementation. Right now I think the components serve as a "hook" to
get people interested in the implementation.
As I think about it, its starting to make more and more sense that
components be their own project (at least within myfaces if not a
larger apache faces project.) There are still some issues to be
worked out and a move to subversion would definitely be a good step at
some point.
> Finally, I don't think Shale should be part of MyFaces. If Shale is
> absorbed with MyFaces, we'll have exactly the same problem that we have
> with the components: people will wonder if they can use Shale with
> other JSF implementations. A certain percentage will eschew Shale (and
> the components) because they will assume they're MyFaces specific and
> never take the time to investigate, or read the documentation.
I agree that Shale should not be part of MyFaces. I think it would be
a companion subproject in the larger Apache Faces project along with
MyFaces and the components. If the Shale folks don't want to do this
then there would be no point in a larger Apache Faces project until
there were some other related technology besides what is already
available in MyFaces. In other words, lets not move to a larger
Apache Faces project that just has components and MyFaces. That is
just a labeling change. MyFaces would not be combining forces with
any other JSF realted project.
> IMO, MyFaces should strictly adhere to providing a robust JSF
> implementation. Some extensions that are tied to the framework, such as
> Tiles support, are fine, but adding things to MyFaces that have nothing
> to do with MyFaces, per se, invites confusion and limits the adoption
> of those technologies.
Here is a possible roadmap:
1.) MyFaces releases 1.0.9 as currently structured
2.) MyFaces splits into two or three subprojects: api + impl (or api
and impl as two separate subprojects) and components (also source is
migrated to SVN)
3.) Apache Faces project with the MyFaces and components subprojects
4.) Shale as part of Apache Faces project
Steps 1. and 2. seem to have a lot of support and would seem to be
prudent intermediate steps before we attempt anything more ambitious.
Step 3 doesn't make much sense without Step 4. And Step 4 depends on
the Shale team and also on whether or not Shale becomes Struts 2.0.
> david
sean
Re: Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
Posted by David Geary <sa...@earthlink.net>.
I prefer Matthias' proposal for Apache Faces. I think it'd be great to
have all JSF-related technologies in one project.
As for the Faces components, as long as they're MyFaces components,
people will be confused about using them standalone. We can add
documentation, but people will still be confused. The only way to
eliminate the confusion is to put them in a separate project.
I think the components will thrive independent of MyFaces. The JSF
community needs a good open-source component set independent of a
particular JSF implementation and I feel like we're hiding one inside
MyFaces at the moment.
Finally, I don't think Shale should be part of MyFaces. If Shale is
absorbed with MyFaces, we'll have exactly the same problem that we have
with the components: people will wonder if they can use Shale with
other JSF implementations. A certain percentage will eschew Shale (and
the components) because they will assume they're MyFaces specific and
never take the time to investigate, or read the documentation.
IMO, MyFaces should strictly adhere to providing a robust JSF
implementation. Some extensions that are tied to the framework, such as
Tiles support, are fine, but adding things to MyFaces that have nothing
to do with MyFaces, per se, invites confusion and limits the adoption
of those technologies.
david
Le Mar 16, 2005, à 12:30 PM, Sean Schofield a écrit :
> I agree 100% with Martin on this one.
>
> On one of these threads Kito made a comment about people being
> confused about the myfaces components and whether or not they require
> myfaces. We should do our best to promote the fact that the
> components are independent of the implementation. Improvements to our
> documentation will help with that.
>
> There is a place holder "overview" page on the myfaces site where just
> such documentation should go. I will add some shortly.
>
> sean
>
>
> On Wed, 16 Mar 2005 20:18:23 +0100, Martin Marinschek
> <ma...@gmail.com> wrote:
>> I am replying to several postings on the mailing list in the last time
>> at once, so sorry if I puzzle someone.
>>
>> With all this discussion on toplevel or sublevel or whatever level
>> projects we should still try to get our infrastructure up-to-date
>> first (I agree with Matthias and his former postings on this topic).
>>
>> In the last one and a half years, we have had (4) different homepages,
>> we should finally try to get the dust cloud to settle down.
>>
>> For the meantime, I believe that all is quite good as it is right now,
>> even with the components being part of MyFaces.
>>
>> The thing is that it is much easier to work on the components if they
>> are at least part of the common source base of the framework, and this
>> might be a reason why the components of MyFaces are indeed thriving as
>> much as they do.
>>
>> As soon as we get to be a large bureaucratic body, we should stop,
>> rethink our ways and move the components out to a subproject.
>>
>> regards,
>>
>> Martin
>>
>>
>> On Wed, 16 Mar 2005 13:16:53 -0500, Sean Schofield
>> <se...@gmail.com> wrote:
>>> On Wed, 16 Mar 2005 12:46:58 -0500, Kito D. Mann <km...@virtua.com>
>>> wrote:
>>>> Personally, I'm not convinced that Shale really should be part of
>>>> the
>>>> MyFaces project. If you look at JSF as a foundation for UI
>>>> frameworks (and
>>>> more sophisticated web frameworks in general), then hopefully we'll
>>>> see it
>>>> pop up in lots of different places (in my perfect world, even
>>>> Tapestry
>>>> would use JSF components). Placing all projects that use JSF under
>>>> one
>>>> umbrella may break over time as JSF grows. (For example, all Java
>>>> projects
>>>> are no longer part of Jakarta.)
>>>
>>> Good point. We definitely don't want to rush into something like
>>> this. There are potential drawbacks as you pointed out.
>>>
>>>> Moreover, although Shale is based on JSF, it will hopefully be the
>>>> next
>>>> major revision of Struts. Struts has its own very strong brand, and
>>>> it
>>>> seems strange to pull Shale away from that.
>>>
>>> That is a big question mark but I happen to agree with you (and
>>> Craig)
>>> on the desirability of that outcome. Moving Shale to a new project
>>> does pretty much give up on that idea so I can see that as a
>>> drawback.
>>>
>>> sean
>>>
>>
>
Re: Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
Posted by Sean Schofield <se...@gmail.com>.
I agree 100% with Martin on this one.
On one of these threads Kito made a comment about people being
confused about the myfaces components and whether or not they require
myfaces. We should do our best to promote the fact that the
components are independent of the implementation. Improvements to our
documentation will help with that.
There is a place holder "overview" page on the myfaces site where just
such documentation should go. I will add some shortly.
sean
On Wed, 16 Mar 2005 20:18:23 +0100, Martin Marinschek
<ma...@gmail.com> wrote:
> I am replying to several postings on the mailing list in the last time
> at once, so sorry if I puzzle someone.
>
> With all this discussion on toplevel or sublevel or whatever level
> projects we should still try to get our infrastructure up-to-date
> first (I agree with Matthias and his former postings on this topic).
>
> In the last one and a half years, we have had (4) different homepages,
> we should finally try to get the dust cloud to settle down.
>
> For the meantime, I believe that all is quite good as it is right now,
> even with the components being part of MyFaces.
>
> The thing is that it is much easier to work on the components if they
> are at least part of the common source base of the framework, and this
> might be a reason why the components of MyFaces are indeed thriving as
> much as they do.
>
> As soon as we get to be a large bureaucratic body, we should stop,
> rethink our ways and move the components out to a subproject.
>
> regards,
>
> Martin
>
>
> On Wed, 16 Mar 2005 13:16:53 -0500, Sean Schofield
> <se...@gmail.com> wrote:
> > On Wed, 16 Mar 2005 12:46:58 -0500, Kito D. Mann <km...@virtua.com> wrote:
> > > Personally, I'm not convinced that Shale really should be part of the
> > > MyFaces project. If you look at JSF as a foundation for UI frameworks (and
> > > more sophisticated web frameworks in general), then hopefully we'll see it
> > > pop up in lots of different places (in my perfect world, even Tapestry
> > > would use JSF components). Placing all projects that use JSF under one
> > > umbrella may break over time as JSF grows. (For example, all Java projects
> > > are no longer part of Jakarta.)
> >
> > Good point. We definitely don't want to rush into something like
> > this. There are potential drawbacks as you pointed out.
> >
> > > Moreover, although Shale is based on JSF, it will hopefully be the next
> > > major revision of Struts. Struts has its own very strong brand, and it
> > > seems strange to pull Shale away from that.
> >
> > That is a big question mark but I happen to agree with you (and Craig)
> > on the desirability of that outcome. Moving Shale to a new project
> > does pretty much give up on that idea so I can see that as a drawback.
> >
> > sean
> >
>
Re: Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
Posted by Martin Marinschek <ma...@gmail.com>.
I am replying to several postings on the mailing list in the last time
at once, so sorry if I puzzle someone.
With all this discussion on toplevel or sublevel or whatever level
projects we should still try to get our infrastructure up-to-date
first (I agree with Matthias and his former postings on this topic).
In the last one and a half years, we have had (4) different homepages,
we should finally try to get the dust cloud to settle down.
For the meantime, I believe that all is quite good as it is right now,
even with the components being part of MyFaces.
The thing is that it is much easier to work on the components if they
are at least part of the common source base of the framework, and this
might be a reason why the components of MyFaces are indeed thriving as
much as they do.
As soon as we get to be a large bureaucratic body, we should stop,
rethink our ways and move the components out to a subproject.
regards,
Martin
On Wed, 16 Mar 2005 13:16:53 -0500, Sean Schofield
<se...@gmail.com> wrote:
> On Wed, 16 Mar 2005 12:46:58 -0500, Kito D. Mann <km...@virtua.com> wrote:
> > Personally, I'm not convinced that Shale really should be part of the
> > MyFaces project. If you look at JSF as a foundation for UI frameworks (and
> > more sophisticated web frameworks in general), then hopefully we'll see it
> > pop up in lots of different places (in my perfect world, even Tapestry
> > would use JSF components). Placing all projects that use JSF under one
> > umbrella may break over time as JSF grows. (For example, all Java projects
> > are no longer part of Jakarta.)
>
> Good point. We definitely don't want to rush into something like
> this. There are potential drawbacks as you pointed out.
>
> > Moreover, although Shale is based on JSF, it will hopefully be the next
> > major revision of Struts. Struts has its own very strong brand, and it
> > seems strange to pull Shale away from that.
>
> That is a big question mark but I happen to agree with you (and Craig)
> on the desirability of that outcome. Moving Shale to a new project
> does pretty much give up on that idea so I can see that as a drawback.
>
> sean
>
Re: Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
Posted by Sean Schofield <se...@gmail.com>.
On Wed, 16 Mar 2005 12:46:58 -0500, Kito D. Mann <km...@virtua.com> wrote:
> Personally, I'm not convinced that Shale really should be part of the
> MyFaces project. If you look at JSF as a foundation for UI frameworks (and
> more sophisticated web frameworks in general), then hopefully we'll see it
> pop up in lots of different places (in my perfect world, even Tapestry
> would use JSF components). Placing all projects that use JSF under one
> umbrella may break over time as JSF grows. (For example, all Java projects
> are no longer part of Jakarta.)
Good point. We definitely don't want to rush into something like
this. There are potential drawbacks as you pointed out.
> Moreover, although Shale is based on JSF, it will hopefully be the next
> major revision of Struts. Struts has its own very strong brand, and it
> seems strange to pull Shale away from that.
That is a big question mark but I happen to agree with you (and Craig)
on the desirability of that outcome. Moving Shale to a new project
does pretty much give up on that idea so I can see that as a drawback.
sean
Re: Shale and MyFaces (was Re: How to execute bean method
before JSF page is loaded?)
Posted by "Kito D. Mann" <km...@virtua.com>.
Personally, I'm not convinced that Shale really should be part of the
MyFaces project. If you look at JSF as a foundation for UI frameworks (and
more sophisticated web frameworks in general), then hopefully we'll see it
pop up in lots of different places (in my perfect world, even Tapestry
would use JSF components). Placing all projects that use JSF under one
umbrella may break over time as JSF grows. (For example, all Java projects
are no longer part of Jakarta.)
Moreover, although Shale is based on JSF, it will hopefully be the next
major revision of Struts. Struts has its own very strong brand, and it
seems strange to pull Shale away from that.
That's my $0.02.
Kito D. Mann
Author, JavaServer Faces in Action
http://www.JSFCentral.com - JSF FAQ, news, and info
Are you using JSF in a project? Send an e-mail to trenches@jsfcentral.com
and you could win a free copy of JavaServer Faces in Action!
At 02:29 AM 3/16/2005, you wrote:
>>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.
>
>Nice to hear that some of you like the *idea*. It was just only a idea
>for now and yes there must be provided more to be concret on something
>like that. Since there seams to be interesst it is worth to go that road.
>
>>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.
>
>
>yes that's the best as far as I see. And perhaps a fourth subproject
>for sample apps; all JSF users could benefit from a wide range of sample
>apps
>
>>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.
>
>
>yes token could also be inside of "JSF Components" (or how you could call
>such a subproject)
>
>>I suggest we keep working together closely and keep the discussions
>>going and see where that takes us.
>
>Yes, that is right! It is should be the best for the users of the JSF spec.
>
>The benefit from a *big* Apache Faces project is
>a) users *can* (not must) use a impl. that is shipped under a liberal
>licence (Apache2.0)
>b)Having lot's of cool components for a usage with *any* JSF impl.
>c)Having a framework ontop of JSF to leverage the development of JSF web
>app (also not bound to a specific JSF impl)
>
>-Matthias
>
>
>>sean
>>
>>On Tue, 15 Mar 2005 18:58:56 -0800 (PST), Ray Clark
>><rc...@yahoo.com> 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 <sa...@earthlink.net> 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
>
>"Existence doesn't necessarily mean living..."
Re: Shale and MyFaces (was Re: How to execute bean method before
JSF page is loaded?)
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
> 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.
Nice to hear that some of you like the *idea*. It was just only a idea
for now and yes there must be provided more to be concret on something
like that. Since there seams to be interesst it is worth to go that road.
> 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.
yes that's the best as far as I see. And perhaps a fourth subproject
for sample apps; all JSF users could benefit from a wide range of sample
apps
> 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.
yes token could also be inside of "JSF Components" (or how you could
call such a subproject)
> I suggest we keep working together closely and keep the discussions
> going and see where that takes us.
Yes, that is right! It is should be the best for the users of the JSF spec.
The benefit from a *big* Apache Faces project is
a) users *can* (not must) use a impl. that is shipped under a liberal
licence (Apache2.0)
b)Having lot's of cool components for a usage with *any* JSF impl.
c)Having a framework ontop of JSF to leverage the development of JSF web
app (also not bound to a specific JSF impl)
-Matthias
> sean
>
>
> On Tue, 15 Mar 2005 18:58:56 -0800 (PST), Ray Clark
> <rc...@yahoo.com> 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 <sa...@earthlink.net> 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
>>
>
>
Re: Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
Posted by Sean Schofield <se...@gmail.com>.
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
<rc...@yahoo.com> 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 <sa...@earthlink.net> 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
>
Re: Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
Posted by Ray Clark <rc...@yahoo.com>.
+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 <sa...@earthlink.net> 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
Re: Shale and MyFaces (was Re: How to execute bean method before JSF page is loaded?)
Posted by David Geary <sa...@earthlink.net>.
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
>
Re: Shale and MyFaces (was Re: How to execute bean method before
JSF page is loaded?)
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
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