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 <[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
