You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2004/12/29 20:44:47 UTC
Shale for 2.x? (was Re: RoadMap)
Objectively, I think that Shale would be a better fit for Apache MyFaces.
Back in the day, it might have been better if we had placed most of our taglibs with Jakarta Taglibs, rather than keep them all here. I think this is the same sort of thing.
Since I'm not doing the work, I can't make the decision, but I think it would be nice if a serious proposal were made to Apache MyFaces before launching Shale from here.
Shale has been mentioned on the MyFaces lists a couple of times, but no one has asked the question "Do we want to host Shale here at Apache MyFaces?".
Apache MyFaces already has generic JSF components, and Shale fits in that venue. They also have a very strong JSF community that can appreciate, support, and enhance Shale.
Eventually, if everyone migrates to Shale, and the Struts community withers away, then so be it.
Let Darwin decide.
-Ted.
On Wed, 29 Dec 2004 10:50:42 -0800, Craig McClanahan wrote:
>�On Wed, 29 Dec 2004 10:21:24 -0500, Ted Husted <hu...@apache.org>
>�wrote:
>
>>�Is there anything someone would like put differently?
>>
>
>�I'm somewhat curious when the Struts committers might be willing to
>�make a conscious choice for a Struts 2.x architecture.
>
>�While I'm personally going to continue to support the 1.3.x changes
>�for evolution of existing apps, and use of the Struts-Faces
>�integration library with it, I believe that Struts will become
>�gradually less relevant for new application development unless it
>�adopts JSF strongly; and it would be a shame to have to *compete*
>�with Struts instead of *being* Struts.
>
>>�-Ted.
>>
>�Craig
>
>�--------------------------------------------------------------------
>�- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>�additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Shale for 2.x? (was Re: RoadMap)
Posted by Dakota Jack <da...@gmail.com>.
How can Struts which is inherenlty incompatible with JSF be a "better
fit" than MyFaces which is a JSF implementation? I would prefer
Darwin rather than Machievelli resolve the Struts v. JSF choice and
think that Ted as usual is right on the mark.
Jack
On Wed, 29 Dec 2004 12:56:35 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Wed, 29 Dec 2004 14:44:47 -0500, Ted Husted <hu...@apache.org> wrote:
>
> > Objectively, I think that Shale would be a better fit for Apache MyFaces.
>
> If the scope of the MyFaces proposal were expanded to "building a JSF
> implementation and value added 'stuff' around it" instead of "building
> a JSF implementation, and oh by the way here's some components too",
> this might indeed be a possible future. I'm also looking at some
> other alternatives if the Struts folks decide not to go this way.
>
> > Back in the day, it might have been better if we had placed most of our taglibs with Jakarta Taglibs, rather than keep them all here. I think this is the same sort of thing.
>
> The problem with this theory relates to a similar issue that would be
> raised if Shale were a MyFaces subproject. It's the fact that the
> Struts tag libraries have dependencies on the Struts core, which in
> some cases (like manufacturing a form bean on demand, doing
> transaction tokens, and interacting with validation rules) are fairly
> deep. It would not have been particularly useful to create an
> arbitrary binding API between the two, just so the tags could
> theoretically be used on their own, without Struts.
>
> The situation with Shale inside of MyFaces would be muddled by a
> potential misunderstanding ... it would be silly to build such a thing
> that was dependent on MyFaces internals, when you would really want
> such an architecture to work on any JSF implementation (the same way
> that Struts works on top of any servlet/JSP container). It would be
> tiresome to keep having to deal with an incorrect perception, based on
> the fact that it would be a subproject.
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
------------------------------
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
-----------------------------------------------
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Shale for 2.x? (was Re: RoadMap)
Posted by Ted Husted <hu...@apache.org>.
On Wed, 29 Dec 2004 16:28:32 -0800, Martin Cooper wrote:
>>�>�Back in the day, it might have been better if we had placed
>>�most of our taglibs with Jakarta Taglibs, rather than keep them
>>�all here. I think this is the same sort of thing.
>>
>>�The problem with this theory relates to a similar issue that
>>�would be �raised if Shale were a MyFaces subproject. �It's the
>>�fact that the �Struts tag libraries have dependencies on the
>>�Struts core, which in �some cases (like manufacturing a form bean
>>�on demand, doing �transaction tokens, and interacting with
>>�validation rules) are fairly �deep. �It would not have been
>>�particularly useful to create an �arbitrary binding API between
>>�the two, just so the tags could �theoretically be used on their
>>�own, without Struts.
>>
>
>�This is all water under the bridge, of course, but the goal
>�wouldn't necessarily have been to make these tags usable without
>�Struts. Rather, they would be located in a (sub)project that cares
>�primarily about tag libraries. There are several taglibs in JT that
>�rely on additional packages to be useful (e.g. BSF, JMS, JNDI,
>�Mailer). The Struts tags would fit fine along with those.
>
>�On the other hand, I suppose we could still move them over there.
>�The JT lists sometimes get questions on the Struts taglibs already.
>�-)
Yes, I still think it would be great if we maintained the html/el-html taglibs here, and the others lived at Jakarta Taglibs. But, there would have to be people in the Jakarta Taglibs community willing to take responsibility for the care and feeding of the libs. Just like there are people in Jakarta Commons willing to take responsibility for BeanUtils, Digester, et al.
I apply patches to the tags here, when I can, as a courtesy to others, but it would better if they were maintained by people who actually use them.
I think one of the very first things we started to say about 2.x is that we were going avoid past mistakes and do all the "could-a-would-a-should-a" things. So, just like it would be better if the independent Struts tags were maintained by Taglib people, I'm suggesting that Shale would be best maintained by JSF people. Right now, we seem desperately short of JSF people. So why not just move he mountain?
Personally, I think it would be great if JSF did take off, and a strong open source community grew up around the technology. Right now, our strongest JSF community is living at Apache MyFaces. It's better to play to our strengths.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Shale for 2.x? (was Re: RoadMap)
Posted by Martin Cooper <mf...@gmail.com>.
On Wed, 29 Dec 2004 12:56:35 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Wed, 29 Dec 2004 14:44:47 -0500, Ted Husted <hu...@apache.org> wrote:
>
> > Objectively, I think that Shale would be a better fit for Apache MyFaces.
>
> If the scope of the MyFaces proposal were expanded to "building a JSF
> implementation and value added 'stuff' around it" instead of "building
> a JSF implementation, and oh by the way here's some components too",
> this might indeed be a possible future. I'm also looking at some
> other alternatives if the Struts folks decide not to go this way.
>
> > Back in the day, it might have been better if we had placed most of our taglibs with Jakarta Taglibs, rather than keep them all here. I think this is the same sort of thing.
>
> The problem with this theory relates to a similar issue that would be
> raised if Shale were a MyFaces subproject. It's the fact that the
> Struts tag libraries have dependencies on the Struts core, which in
> some cases (like manufacturing a form bean on demand, doing
> transaction tokens, and interacting with validation rules) are fairly
> deep. It would not have been particularly useful to create an
> arbitrary binding API between the two, just so the tags could
> theoretically be used on their own, without Struts.
This is all water under the bridge, of course, but the goal wouldn't
necessarily have been to make these tags usable without Struts.
Rather, they would be located in a (sub)project that cares primarily
about tag libraries. There are several taglibs in JT that rely on
additional packages to be useful (e.g. BSF, JMS, JNDI, Mailer). The
Struts tags would fit fine along with those.
On the other hand, I suppose we could still move them over there. The
JT lists sometimes get questions on the Struts taglibs already. ;-)
--
Martin Cooper
> The situation with Shale inside of MyFaces would be muddled by a
> potential misunderstanding ... it would be silly to build such a thing
> that was dependent on MyFaces internals, when you would really want
> such an architecture to work on any JSF implementation (the same way
> that Struts works on top of any servlet/JSP container). It would be
> tiresome to keep having to deal with an incorrect perception, based on
> the fact that it would be a subproject.
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Shale for 2.x? (was Re: RoadMap)
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 29 Dec 2004 14:44:47 -0500, Ted Husted <hu...@apache.org> wrote:
> Objectively, I think that Shale would be a better fit for Apache MyFaces.
If the scope of the MyFaces proposal were expanded to "building a JSF
implementation and value added 'stuff' around it" instead of "building
a JSF implementation, and oh by the way here's some components too",
this might indeed be a possible future. I'm also looking at some
other alternatives if the Struts folks decide not to go this way.
> Back in the day, it might have been better if we had placed most of our taglibs with Jakarta Taglibs, rather than keep them all here. I think this is the same sort of thing.
The problem with this theory relates to a similar issue that would be
raised if Shale were a MyFaces subproject. It's the fact that the
Struts tag libraries have dependencies on the Struts core, which in
some cases (like manufacturing a form bean on demand, doing
transaction tokens, and interacting with validation rules) are fairly
deep. It would not have been particularly useful to create an
arbitrary binding API between the two, just so the tags could
theoretically be used on their own, without Struts.
The situation with Shale inside of MyFaces would be muddled by a
potential misunderstanding ... it would be silly to build such a thing
that was dependent on MyFaces internals, when you would really want
such an architecture to work on any JSF implementation (the same way
that Struts works on top of any servlet/JSP container). It would be
tiresome to keep having to deal with an incorrect perception, based on
the fact that it would be a subproject.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Shale for 2.x? (was Re: RoadMap)
Posted by BaTien Duong <ba...@dbgroups.com>.
Matthias Wessendorf wrote:
>>-----Original Message-----
>>From: Ted Husted [mailto:husted@apache.org]
>>Sent: Thursday, December 30, 2004 4:20 PM
>>To: MyFaces Development
>>Subject: RE: Shale for 2.x? (was Re: RoadMap)
>>
>>
>>On Thu, 30 Dec 2004 09:44:16 +0100, Matthias Wessendorf wrote:
>>
>>
>>> I also amazed about all the shouts "JSF is dead"... JSF is a
>>> standard, that is an important point! Not only for support via
>>> tool/server manufacturers
>>>
>>>
>>Just to be clear, that's not something any of the Struts
>>committers are shouting. :)
>>
>>
>
>ok... I haven't mentioned that right. sorry for that...
>
>
>
>>What the Struts committers seem to be saying is that we would
>>like to use JSF in our own applications someday, but, alas,
>>not today.
>>I don't believe any of the committers want to block Shale.
>>
>>
>
>fine!
>
>
>
>>The rest of us just don't have the bandwidth to help build it
>>right now.
>>
>>But, perhaps, there are MyFaces committers who do.
>>
>>
>
>Well, I will give it a try. Feedback will come. Since
>I am interessted in using Shale and MyFaces. Craig's
>proposal sounds *very* interessting.
>
>Matthias
>
>
Matthias, i second this one.
BaTien
DBGROUPS
>
>
>>-Ted.
>>
>>
>>
>>
>
>
>.
>
>
>
RE: Shale for 2.x? (was Re: RoadMap)
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Thursday, December 30, 2004 4:20 PM
> To: MyFaces Development
> Subject: RE: Shale for 2.x? (was Re: RoadMap)
>
>
> On Thu, 30 Dec 2004 09:44:16 +0100, Matthias Wessendorf wrote:
> > I also amazed about all the shouts "JSF is dead"... JSF is a
> > standard, that is an important point! Not only for support via
> > tool/server manufacturers
>
> Just to be clear, that's not something any of the Struts
> committers are shouting. :)
ok... I haven't mentioned that right. sorry for that...
> What the Struts committers seem to be saying is that we would
> like to use JSF in our own applications someday, but, alas,
> not today.
> I don't believe any of the committers want to block Shale.
fine!
> The rest of us just don't have the bandwidth to help build it
> right now.
>
> But, perhaps, there are MyFaces committers who do.
Well, I will give it a try. Feedback will come. Since
I am interessted in using Shale and MyFaces. Craig's
proposal sounds *very* interessting.
Matthias
> -Ted.
>
>
RE: Shale for 2.x? (was Re: RoadMap)
Posted by Ted Husted <hu...@apache.org>.
On Thu, 30 Dec 2004 09:44:16 +0100, Matthias Wessendorf wrote:
>�I also amazed about all the shouts "JSF is dead"... JSF is a
>�standard, that is an important point! Not only for support via
>�tool/server manufacturers
Just to be clear, that's not something any of the Struts committers are shouting. :)
What the Struts committers seem to be saying is that we would like to use JSF in our own applications someday, but, alas, not today.
I don't believe any of the committers want to block Shale. The rest of us just don't have the bandwidth to help build it right now.
But, perhaps, there are MyFaces committers who do.
-Ted.
RE: Shale for 2.x? (was Re: RoadMap)
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
> Shale very deliberately presumes the presence of JSF as a
> foundation technology. That means that, among other things,
> Shale does not need to reinvent a bunch of technology that
> JSF already provides (in particular, managed beans, page
> navigation, the request processing lifecycle for form
> submits, and value/method binding expressions).
> Ironically, Shale itself doesn't care a lot about which
> actual JSF components you are using :-). It wants JSF for
> its framework capabilities. In turn, this lets the
> development of Shale focus on the areas that JSF does not, or
> does not yet, cover.
Another interessting thing would looking at Spring Framework
and its IoC (aka Dependency Injection)
> So far, however, the Struts developers have been unwilling to
> make the leap to "assume JSF as a base technology, then build
> on top" -- the very assumption that is the foundation to the
> whole idea.
I also amazed about all the shouts "JSF is dead"...
JSF is a standard, that is an important point!
Not only for support via tool/server manufacturers
Struts(or Shale) is a product. that is also important
since products fit (often better) into users demand...
standard vs. product? No, products using standards to
enlarge them. And not providing *yet another dataTable*-component
for JSF. That is the way I understood the Shale
proposal. And so I am waiting for your new input
(mentioned in dev@s.a.o :-)) to give it a try.
Matthias
> Craig McClanahan
>
> > On Thu, 30 Dec 2004 01:46:57 +0100, carsten@wildehor.de
> > <ca...@wildehor.de> wrote:
> > >
> > > What is the main pruposal of MyFaces? I see
> > > a: the need of an open source implementation of JSF and
> > > b: like the idea to implement 'extras' to give the open source
> > > implamantation a real meaning to use it *g*
> > >
> > > In my opinion shale and similar projects are trying to fill a gap
> > > for existing applications or programmers which have not the
> > > possibility to change to jsf completly. I developed a application
> > > for a company with realy many cooperations so struts ore
> jsf was no
> > > alternative for us because of branding problems and similars. I
> > > would realy like to see the focus of the MyFaces on the JSF
> > > implementation with performance and stability with the
> plus of realy
> > > needed or 'neat' components to higher the aceptance. Trying to
> > > assimilate the one or other project should be the third
> or further
> > > focus to get some attention for developers which have not
> the chance
> > > to decide which technology to use but giving them a plus for the
> > > decicionmaker. My opinion is definetly egoistic but i think it is
> > > the only chance to deliver extraordinary good code. (even better
> > > than sun's (sooorry lars *g* )).
> > >
> > > It that sense and do not flame me please
> > >
> > > Carsten Fregin
> > >
> > > P.S.
> > > This is my 11 beer with my investor so please are
> mercyfull with my
> > > bad english and typos *g*
> > >
> >
> >
> > --
> > -Heath Borders-Wing
> > hborders@mail.win.org
> >
>
Re: Shale for 2.x? (was Re: RoadMap)
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
So far as I am concerned, the basic ideas in Struts are superior.
Struts is poor architected in many ways and needs to be improved.
Introducing basic interfaces and decoupling so far as is practicable are
just two necessities. However, the ideal, in my opinion, would be to
improve Struts and to provide "connected" technologies like a
sophisticated view, etc. JSF can go where it wants in my view and I
wish people who like it the best. I just cannot endorse the basic
concepts myself and believe they can never become popular. I really
don't think JSF is for the better.
Sean Schofield wrote:
>>Shale very deliberately presumes the presence of JSF as a foundation
>>technology. That means that, among other things, Shale does not need
>>to reinvent a bunch of technology that JSF already provides (in
>>particular, managed beans, page navigation, the request processing
>>lifecycle for form submits, and value/method binding expressions).
>>Ironically, Shale itself doesn't care a lot about which actual JSF
>>components you are using :-). It wants JSF for its framework
>>capabilities. In turn, this lets the development of Shale focus on
>>the areas that JSF does not, or does not yet, cover.
>>
>>
>
>Good point. Perhaps some of the confusion is over the lack of
>understanding of what JSF does. I did not really understand the Shale
>proposal until I did a lot of reading on JSF.
>
>
>
>>So far, however, the Struts developers have been unwilling to make the
>>leap to "assume JSF as a base technology, then build on top" -- the
>>very assumption that is the foundation to the whole idea.
>>
>>
>
>IMO this calls for abandoning the notion of Struts as we know it.
>Developers like myself have come to love Struts for how it helped
>simplify and standardize web applications. We've grown attached to
>it, so there is reluctance to abandon this approach in favor of a new
>one.
>
>You've mentioned in previous posts about how JSF has the advantage of
>being designed from scratch with all of the knowledge gained from the
>work on Struts (and other frameworks.) I agree that at some point we
>will have to say good bye to our beloved Struts. Also, there will be
>a lengthy transition where development on Struts continues and even
>longer transition where people will continue to use it. Many "late
>adopters" are just now getting around to learning Struts. We're
>talking years until they get to JSF.
>
>I would propose we consider halting major development efforts on
>Struts after the 1.3 release. The 1.3 release will use commons-chain
>for request processing which will give even more flexability to Struts
>users. After that release though, it would seem that Struts would be
>all grown up and ready to leave the nest. Yes we could always add
>something, but why not be bold and try something new (as Craig is
>suggesting)?
>
>One suggestion would be to not really consider Shale as Struts 2.0.
>>>From what I understand, it really has very little to do with Struts as
>we know it. Ultimately we should consider releasing it as its own
>project with a new name (Shale or whatever.)
>
>Just some thoughts.
>
>
>
>>Craig McClanahan
>>
>>
>
>sean
>
>
>
>
>
Re: Shale for 2.x? (was Re: RoadMap)
Posted by Sean Schofield <se...@gmail.com>.
> Shale very deliberately presumes the presence of JSF as a foundation
> technology. That means that, among other things, Shale does not need
> to reinvent a bunch of technology that JSF already provides (in
> particular, managed beans, page navigation, the request processing
> lifecycle for form submits, and value/method binding expressions).
> Ironically, Shale itself doesn't care a lot about which actual JSF
> components you are using :-). It wants JSF for its framework
> capabilities. In turn, this lets the development of Shale focus on
> the areas that JSF does not, or does not yet, cover.
Good point. Perhaps some of the confusion is over the lack of
understanding of what JSF does. I did not really understand the Shale
proposal until I did a lot of reading on JSF.
> So far, however, the Struts developers have been unwilling to make the
> leap to "assume JSF as a base technology, then build on top" -- the
> very assumption that is the foundation to the whole idea.
IMO this calls for abandoning the notion of Struts as we know it.
Developers like myself have come to love Struts for how it helped
simplify and standardize web applications. We've grown attached to
it, so there is reluctance to abandon this approach in favor of a new
one.
You've mentioned in previous posts about how JSF has the advantage of
being designed from scratch with all of the knowledge gained from the
work on Struts (and other frameworks.) I agree that at some point we
will have to say good bye to our beloved Struts. Also, there will be
a lengthy transition where development on Struts continues and even
longer transition where people will continue to use it. Many "late
adopters" are just now getting around to learning Struts. We're
talking years until they get to JSF.
I would propose we consider halting major development efforts on
Struts after the 1.3 release. The 1.3 release will use commons-chain
for request processing which will give even more flexability to Struts
users. After that release though, it would seem that Struts would be
all grown up and ready to leave the nest. Yes we could always add
something, but why not be bold and try something new (as Craig is
suggesting)?
One suggestion would be to not really consider Shale as Struts 2.0.
>From what I understand, it really has very little to do with Struts as
we know it. Ultimately we should consider releasing it as its own
project with a new name (Shale or whatever.)
Just some thoughts.
> Craig McClanahan
sean
Re: Shale for 2.x? (was Re: RoadMap)
Posted by Heath Borders <he...@gmail.com>.
So, if Shale is just going to assume a JSF (MyFaces) basis, what
development responsibilities for Shale would MyFaces have?
On Thu, 30 Dec 2004 00:22:49 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Wed, 29 Dec 2004 20:13:01 -0600, Heath Borders
> <he...@gmail.com> wrote:
> > I just read the Shale proposal, and I don't see why we can't have both
> > sides work together on this.
> >
> > Assuming that the View tier of Shale is pluggable, I don't see why
> > MyFaces couldn't have the responsibility of developing a plugin for
> > the view.
>
> It depends on what you mean by the "view tier".
>
> Shale very deliberately presumes the presence of JSF as a foundation
> technology. That means that, among other things, Shale does not need
> to reinvent a bunch of technology that JSF already provides (in
> particular, managed beans, page navigation, the request processing
> lifecycle for form submits, and value/method binding expressions).
> Ironically, Shale itself doesn't care a lot about which actual JSF
> components you are using :-). It wants JSF for its framework
> capabilities. In turn, this lets the development of Shale focus on
> the areas that JSF does not, or does not yet, cover.
>
> You still get a form of view tier pluggability for Shale, but it is by
> virtue of the fact that JSF lets you plug in alternate ViewHandlers --
> any ViewHandler that MyFaces might wish to provide will work with
> Shale (as long as it conforms to the JSF spec requirements). But that
> is just one example of what Shale gains by assuming JSF in the first
> place, instead of trying to pretend to plug into any possible UI
> component framework. In that scenario, Shale would have to create
> redundant support for things JSF already does. There are more
> interesting problems to focus on than reinventing those particular
> wheels.
>
> So far, however, the Struts developers have been unwilling to make the
> leap to "assume JSF as a base technology, then build on top" -- the
> very assumption that is the foundation to the whole idea.
>
> Craig McClanahan
>
> > On Thu, 30 Dec 2004 01:46:57 +0100, carsten@wildehor.de
> > <ca...@wildehor.de> wrote:
> > >
> > > What is the main pruposal of MyFaces? I see
> > > a: the need of an open source implementation of JSF and
> > > b: like the idea to implement 'extras' to give the open source
> > > implamantation a real meaning to use it *g*
> > >
> > > In my opinion shale and similar projects are trying to fill a gap for
> > > existing applications or programmers which have not the possibility to
> > > change to jsf completly. I developed a application for a company with realy
> > > many cooperations so struts ore jsf was no alternative for us because of
> > > branding problems and similars. I would realy like to see the focus of the
> > > MyFaces on the JSF implementation with performance and stability with the
> > > plus of realy needed or 'neat' components to higher the aceptance. Trying to
> > > assimilate the one or other project should be the third or further focus to
> > > get some attention for developers which have not the chance to decide which
> > > technology to use but giving them a plus for the decicionmaker. My opinion
> > > is definetly egoistic but i think it is the only chance to deliver
> > > extraordinary good code. (even better than sun's (sooorry lars *g* )).
> > >
> > > It that sense and do not flame me please
> > >
> > > Carsten Fregin
> > >
> > > P.S.
> > > This is my 11 beer with my investor so please are mercyfull with my bad
> > > english and typos *g*
> > >
> >
> >
> > --
> > -Heath Borders-Wing
> > hborders@mail.win.org
> >
>
--
-Heath Borders-Wing
hborders@mail.win.org
Re: Shale for 2.x? (was Re: RoadMap)
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 29 Dec 2004 20:13:01 -0600, Heath Borders
<he...@gmail.com> wrote:
> I just read the Shale proposal, and I don't see why we can't have both
> sides work together on this.
>
> Assuming that the View tier of Shale is pluggable, I don't see why
> MyFaces couldn't have the responsibility of developing a plugin for
> the view.
It depends on what you mean by the "view tier".
Shale very deliberately presumes the presence of JSF as a foundation
technology. That means that, among other things, Shale does not need
to reinvent a bunch of technology that JSF already provides (in
particular, managed beans, page navigation, the request processing
lifecycle for form submits, and value/method binding expressions).
Ironically, Shale itself doesn't care a lot about which actual JSF
components you are using :-). It wants JSF for its framework
capabilities. In turn, this lets the development of Shale focus on
the areas that JSF does not, or does not yet, cover.
You still get a form of view tier pluggability for Shale, but it is by
virtue of the fact that JSF lets you plug in alternate ViewHandlers --
any ViewHandler that MyFaces might wish to provide will work with
Shale (as long as it conforms to the JSF spec requirements). But that
is just one example of what Shale gains by assuming JSF in the first
place, instead of trying to pretend to plug into any possible UI
component framework. In that scenario, Shale would have to create
redundant support for things JSF already does. There are more
interesting problems to focus on than reinventing those particular
wheels.
So far, however, the Struts developers have been unwilling to make the
leap to "assume JSF as a base technology, then build on top" -- the
very assumption that is the foundation to the whole idea.
Craig McClanahan
> On Thu, 30 Dec 2004 01:46:57 +0100, carsten@wildehor.de
> <ca...@wildehor.de> wrote:
> >
> > What is the main pruposal of MyFaces? I see
> > a: the need of an open source implementation of JSF and
> > b: like the idea to implement 'extras' to give the open source
> > implamantation a real meaning to use it *g*
> >
> > In my opinion shale and similar projects are trying to fill a gap for
> > existing applications or programmers which have not the possibility to
> > change to jsf completly. I developed a application for a company with realy
> > many cooperations so struts ore jsf was no alternative for us because of
> > branding problems and similars. I would realy like to see the focus of the
> > MyFaces on the JSF implementation with performance and stability with the
> > plus of realy needed or 'neat' components to higher the aceptance. Trying to
> > assimilate the one or other project should be the third or further focus to
> > get some attention for developers which have not the chance to decide which
> > technology to use but giving them a plus for the decicionmaker. My opinion
> > is definetly egoistic but i think it is the only chance to deliver
> > extraordinary good code. (even better than sun's (sooorry lars *g* )).
> >
> > It that sense and do not flame me please
> >
> > Carsten Fregin
> >
> > P.S.
> > This is my 11 beer with my investor so please are mercyfull with my bad
> > english and typos *g*
> >
>
>
> --
> -Heath Borders-Wing
> hborders@mail.win.org
>
Re: Shale for 2.x? (was Re: RoadMap)
Posted by Heath Borders <he...@gmail.com>.
I just read the Shale proposal, and I don't see why we can't have both
sides work together on this.
Assuming that the View tier of Shale is pluggable, I don't see why
MyFaces couldn't have the responsibility of developing a plugin for
the view.
On Thu, 30 Dec 2004 01:46:57 +0100, carsten@wildehor.de
<ca...@wildehor.de> wrote:
>
> What is the main pruposal of MyFaces? I see
> a: the need of an open source implementation of JSF and
> b: like the idea to implement 'extras' to give the open source
> implamantation a real meaning to use it *g*
>
> In my opinion shale and similar projects are trying to fill a gap for
> existing applications or programmers which have not the possibility to
> change to jsf completly. I developed a application for a company with realy
> many cooperations so struts ore jsf was no alternative for us because of
> branding problems and similars. I would realy like to see the focus of the
> MyFaces on the JSF implementation with performance and stability with the
> plus of realy needed or 'neat' components to higher the aceptance. Trying to
> assimilate the one or other project should be the third or further focus to
> get some attention for developers which have not the chance to decide which
> technology to use but giving them a plus for the decicionmaker. My opinion
> is definetly egoistic but i think it is the only chance to deliver
> extraordinary good code. (even better than sun's (sooorry lars *g* )).
>
> It that sense and do not flame me please
>
> Carsten Fregin
>
> P.S.
> This is my 11 beer with my investor so please are mercyfull with my bad
> english and typos *g*
>
--
-Heath Borders-Wing
hborders@mail.win.org
RE: Shale for 2.x? (was Re: RoadMap)
Posted by ca...@wildehor.de.
What is the main pruposal of MyFaces? I see
a: the need of an open source implementation of JSF and
b: like the idea to implement 'extras' to give the open source
implamantation a real meaning to use it *g*
In my opinion shale and similar projects are trying to fill a gap for
existing applications or programmers which have not the possibility to
change to jsf completly. I developed a application for a company with
realy many cooperations so struts ore jsf was no alternative for us
because of branding problems and similars. I would realy like to see the
focus of the MyFaces on the JSF implementation with performance and
stability with the plus of realy needed or 'neat' components to higher the
aceptance. Trying to assimilate the one or other project should be the
third or further focus to get some attention for developers which have not
the chance to decide which technology to use but giving them a plus for
the decicionmaker. My opinion is definetly egoistic but i think it is the
only chance to deliver extraordinary good code. (even better than sun's
(sooorry lars *g* )).
It that sense and do not flame me please
Carsten Fregin
P.S.
This is my 11 beer with my investor so please are mercyfull with my bad
english and typos *g*
RE: Shale for 2.x? (was Re: RoadMap)
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
Hi Ted and others,
> Objectively, I think that Shale would be a better fit for
> Apache MyFaces.
Uh, interessting point. I read the Shale proposal and
found it nice. I haven't tried it for now.
> Back in the day, it might have been better if we had placed
> most of our taglibs with Jakarta Taglibs, rather than keep
> them all here. I think this is the same sort of thing.
I guess that was before my time here ... :-)
> Since I'm not doing the work, I can't make the decision, but
> I think it would be nice if a serious proposal were made to
> Apache MyFaces before launching Shale from here.
>
> Shale has been mentioned on the MyFaces lists a couple of
> times, but no one has asked the question "Do we want to host
> Shale here at Apache MyFaces?".
Well, I allways thought it is a Struts thing. One alternative solution
to the Jericho/Chain issue... Or even including more standards,
since Filters where mentioned in Shale...
> Apache MyFaces already has generic JSF components, and Shale
> fits in that venue. They also have a very strong JSF
> community that can appreciate, support, and enhance Shale.
We have some extra components in MyFaces. Custom validators
based on Commons Validator. Now I am about to include a
RenderKit for WML. Also support for Tiles see:
http://www.apache.org/~matzew/myfaces-tiles-example.war
Perhaps we could bring the MyFaces' TilesViewHandler to
David's comming Tiles project.
BTW. I would like to see this project inside of Apache ...
But I am now becomming OT...
I guess the Struts developers should decide what
they wanted to do with Shale (and Tiles).
Just my thought.
Regards,
Matthias
> Eventually, if everyone migrates to Shale, and the Struts
> community withers away, then so be it.
>
> Let Darwin decide.
>
> -Ted.
>
> On Wed, 29 Dec 2004 10:50:42 -0800, Craig McClanahan wrote:
> > On Wed, 29 Dec 2004 10:21:24 -0500, Ted Husted <hu...@apache.org>
> > wrote:
> >
> >> Is there anything someone would like put differently?
> >>
> >
> > I'm somewhat curious when the Struts committers might be willing to
> > make a conscious choice for a Struts 2.x architecture.
> >
> > While I'm personally going to continue to support the 1.3.x changes
> > for evolution of existing apps, and use of the Struts-Faces
> > integration library with it, I believe that Struts will become
> > gradually less relevant for new application development unless it
> > adopts JSF strongly; and it would be a shame to have to *compete*
> > with Struts instead of *being* Struts.
> >
> >> -Ted.
> >>
> > Craig
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> > additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
RE: Shale for 2.x? (was Re: RoadMap)
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
Hi Ted and others,
> Objectively, I think that Shale would be a better fit for
> Apache MyFaces.
Uh, interessting point. I read the Shale proposal and
found it nice. I haven't tried it for now.
> Back in the day, it might have been better if we had placed
> most of our taglibs with Jakarta Taglibs, rather than keep
> them all here. I think this is the same sort of thing.
I guess that was before my time here ... :-)
> Since I'm not doing the work, I can't make the decision, but
> I think it would be nice if a serious proposal were made to
> Apache MyFaces before launching Shale from here.
>
> Shale has been mentioned on the MyFaces lists a couple of
> times, but no one has asked the question "Do we want to host
> Shale here at Apache MyFaces?".
Well, I allways thought it is a Struts thing. One alternative solution
to the Jericho/Chain issue... Or even including more standards,
since Filters where mentioned in Shale...
> Apache MyFaces already has generic JSF components, and Shale
> fits in that venue. They also have a very strong JSF
> community that can appreciate, support, and enhance Shale.
We have some extra components in MyFaces. Custom validators
based on Commons Validator. Now I am about to include a
RenderKit for WML. Also support for Tiles see:
http://www.apache.org/~matzew/myfaces-tiles-example.war
Perhaps we could bring the MyFaces' TilesViewHandler to
David's comming Tiles project.
BTW. I would like to see this project inside of Apache ...
But I am now becomming OT...
I guess the Struts developers should decide what
they wanted to do with Shale (and Tiles).
Just my thought.
Regards,
Matthias
> Eventually, if everyone migrates to Shale, and the Struts
> community withers away, then so be it.
>
> Let Darwin decide.
>
> -Ted.
>
> On Wed, 29 Dec 2004 10:50:42 -0800, Craig McClanahan wrote:
> > On Wed, 29 Dec 2004 10:21:24 -0500, Ted Husted <hu...@apache.org>
> > wrote:
> >
> >> Is there anything someone would like put differently?
> >>
> >
> > I'm somewhat curious when the Struts committers might be willing to
> > make a conscious choice for a Struts 2.x architecture.
> >
> > While I'm personally going to continue to support the 1.3.x changes
> > for evolution of existing apps, and use of the Struts-Faces
> > integration library with it, I believe that Struts will become
> > gradually less relevant for new application development unless it
> > adopts JSF strongly; and it would be a shame to have to *compete*
> > with Struts instead of *being* Struts.
> >
> >> -Ted.
> >>
> > Craig
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> > additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org