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 16:21:24 UTC
RoadMap [was Re: ViewUtils ... ]
On Wed, 22 Dec 2004 17:21:46 -0600, Joe Germuska wrote:
>�I haven't felt like there's a clear consensus on how to move such a
>�thing forward, and I guess I'm still in "ask permission" mode
>�instead of "ask forgiveness" mode. � I'm not really even sure how
>�to move it forward in small measured steps to get people looking at
>�something concrete for reactions.
On the Milestones page [http://struts.apache.org/milestones.html], there are actually two "API Beans". Once for the server-side and one for the view-side:
* ActionContext - A Commons Chain Context that implements the Action class logical API (same signatures).
* ViewContext - A Commons Chain Context that implements the combined VelocityStruts logical API (same signatures).
Perhaps it would help if we could come to a consensus on the Roadmap, or used the Roadmap to forge a consensus. (I have no illusions about getting this page right the first time.)
Does anyone disagree with the Roadmap [http://struts.apache.org/roadmap.html] or Milestones [http://struts.apache.org/milestones.html] ?
Is there anything someone would like put differently?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Martin Cooper <mf...@gmail.com>.
On Wed, 29 Dec 2004 13:59:17 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Wed, 29 Dec 2004 16:50:51 -0500, Sean Schofield
> <se...@gmail.com> wrote:
>
> [snip]
> > Probably a little bit off topic, but I wanted to respond to your
> > theory. If your theory is correct, then yes, JSF is a dead-end. I
> > don't agree with that theory, but I'm not sure that JSF will be the
> > next step either. That will depend on how fast developers evaluate
> > and then adopt the technology. And that will depend on how fast JSF
> > evolves to address various issues (see an earlier post of mine about
> > current JSF limitations.)
>
> Assuming that JSF and "highly dynamic" apps (i.. where a high degree
> of interactivity happens on the client side via DHTML and JavaScript)
> are mutually exclusive is too simplistic. The standard components in
> 1.0/1.1 don't help you do this sort of thing, but there are already
> JSF component libraries available that do. Such libraries use the JSF
> components to persist the page author's design decisions (i.e. set the
> correct attributes on the correct tags or whatever), rather than do
> the actual rendering -- so they still fit nicely into development
> tools that know how to manipulate components.
Toolkits like FacesClient Components and ADF Faces are a step in the
right direction, but they do not address most of the things I
mentioned. At least as far as I'm aware, neither can handle drag and
drop in the browser, real time updates, or wizard pages in the client.
They do handle some of the simple cases for dynamic apps, but they
don't tackle the hard problems. When you get to more complex
components, and more complex interactions, I don't see how this is
going to be handled in a way that makes it make sense to use JSF.
(Also, I don't know about ADF Faces, but FacesClient Components
appears to commit the cardinal sin of believing it owns the JavaScript
global namespace, which is pretty much guaranteed to cause problems
when any other JavaScript is used in the app.)
--
Martin Cooper
> >
> > sean
> >
>
> 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: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 29 Dec 2004 16:50:51 -0500, Sean Schofield
<se...@gmail.com> wrote:
[snip]
> Probably a little bit off topic, but I wanted to respond to your
> theory. If your theory is correct, then yes, JSF is a dead-end. I
> don't agree with that theory, but I'm not sure that JSF will be the
> next step either. That will depend on how fast developers evaluate
> and then adopt the technology. And that will depend on how fast JSF
> evolves to address various issues (see an earlier post of mine about
> current JSF limitations.)
Assuming that JSF and "highly dynamic" apps (i.. where a high degree
of interactivity happens on the client side via DHTML and JavaScript)
are mutually exclusive is too simplistic. The standard components in
1.0/1.1 don't help you do this sort of thing, but there are already
JSF component libraries available that do. Such libraries use the JSF
components to persist the page author's design decisions (i.e. set the
correct attributes on the correct tags or whatever), rather than do
the actual rendering -- so they still fit nicely into development
tools that know how to manipulate components.
>
> sean
>
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: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Dakota Jack <da...@gmail.com>.
Sometimes Martin just hits the nail on the head. The House of Lords
once debated putting up neon "FOG" signs in London for those that
could not see the obvious. We have Martin to help us. My hats are
off to this bit of very important bit of common sense.
Jack
On Wed, 29 Dec 2004 14:39:27 -0800, Martin Cooper <mf...@gmail.com> wrote:
>
> The key to highly dynamic apps is JavaScript, not Java. The browser is
> actually a very powerful beast, it's just that it's a royal pain to
> tame it. ;-)
>
> --
> Martin Cooper
--
------------------------------
"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: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Martin Cooper <mf...@gmail.com>.
On Wed, 29 Dec 2004 16:50:51 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > I would classify Gmail as "moderately dynamic", but it's heading in
> > the right direction. I'm talking about things like handling wizard
> > page changes entirely on the client, up until Apply or OK is clicked;
> > drag and drop in the browser; master/detail handling within the
> > browser; real-time updates (i.e. not polling). Stuff like that. One of
> > the characteristics is minimising, if not eliminating, the number of
> > full-page refreshes, which makes page-oriented technologies like JSF a
> > whole lot less relevant.
> >
>
> GMail is pretty much a standard web application (even if its a
> relatively simple one from an interface standpoint.) Do you really
> think these kinds of web applications are likely to be obsolete
> anytime soon?
No, I don't. People will still develop web apps using today's
technology for a long time, but I don't think that's a reason not to
innovate and work with newer, more dynamic technologies.
> I'd admit it would be nice, but my feeling is that we are going to be
> stuck with full page refreshes (or IFrame refreshes) for a long time.
> This is the fundamental nature of web pages and the HTTP protocol.
> Yes it sucks but I don't see anything on the horizon that is likely to
> change this.
There is nothing in the nature of HTTP that has anything to do with
pages; it's simply a request / response protocol. Using HTTP doesn't
tie you to full page refreshes at all, and it's quite feasible to make
HTTP requests "behind the scenes", receive back HTML, XML, JavaScript,
or whatever, and optionally pre-process it in the browser before
updating some part of the page. This is all here today, and I'm using
it today, in production.
> I've written a lot of cool WebStart applications using JMS on the back
> end. They work great but we had the luxury of installing WebStart on
> the all of the customer's computers. I think of the browser as a
> crappier version of WebStart. Its just a vehicle for running your
> application. The key is that its a world-wide standard. Changing
> this will take time. If and when this changes, its likely to be
> influenced heavily by Microsoft. I wouldn't count on it supporting
> Java ;-)
The key to highly dynamic apps is JavaScript, not Java. The browser is
actually a very powerful beast, it's just that it's a royal pain to
tame it. ;-)
--
Martin Cooper
> Probably a little bit off topic, but I wanted to respond to your
> theory. If your theory is correct, then yes, JSF is a dead-end. I
> don't agree with that theory, but I'm not sure that JSF will be the
> next step either. That will depend on how fast developers evaluate
> and then adopt the technology. And that will depend on how fast JSF
> evolves to address various issues (see an earlier post of mine about
> current JSF limitations.)
>
> > Martin Cooper
>
> sean
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Vic <vi...@friendvu.com>.
Sean Schofield wrote:
>I think of the browser as a
>crappier version of WebStart.
>
;-)
"Walk towards the light"
I try to make my apps look like they are browser based..... so people I
show it to say: Nice DHTML. :-). Yah.
This is not the old Swing, Swing Extensions in JDNC are VERY good ...
and they are OPEN SOURCE!
JRE 1.5 Web Start is better than 1.42... so I see no road blocks yet.
(W/Flex/Lazlo, I found major performance issues in UI). Installation is
painless even for a father in law.
(Someplace I heard that 70% of Java developers know Struts. I think the
number of closet Swing people is higher - they will all come out.
ECMA-script has no chance, Swing is MVC for DataGrids)
.V
--
RiA-SoA w/JDNC <http://www.SandraSF.com> forums
- help develop a community
My blog <http://www.sandrasf.com/adminBlog>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Sean Schofield <se...@gmail.com>.
> I would classify Gmail as "moderately dynamic", but it's heading in
> the right direction. I'm talking about things like handling wizard
> page changes entirely on the client, up until Apply or OK is clicked;
> drag and drop in the browser; master/detail handling within the
> browser; real-time updates (i.e. not polling). Stuff like that. One of
> the characteristics is minimising, if not eliminating, the number of
> full-page refreshes, which makes page-oriented technologies like JSF a
> whole lot less relevant.
>
GMail is pretty much a standard web application (even if its a
relatively simple one from an interface standpoint.) Do you really
think these kinds of web applications are likely to be obsolete
anytime soon?
I'd admit it would be nice, but my feeling is that we are going to be
stuck with full page refreshes (or IFrame refreshes) for a long time.
This is the fundamental nature of web pages and the HTTP protocol.
Yes it sucks but I don't see anything on the horizon that is likely to
change this.
I've written a lot of cool WebStart applications using JMS on the back
end. They work great but we had the luxury of installing WebStart on
the all of the customer's computers. I think of the browser as a
crappier version of WebStart. Its just a vehicle for running your
application. The key is that its a world-wide standard. Changing
this will take time. If and when this changes, its likely to be
influenced heavily by Microsoft. I wouldn't count on it supporting
Java ;-)
Probably a little bit off topic, but I wanted to respond to your
theory. If your theory is correct, then yes, JSF is a dead-end. I
don't agree with that theory, but I'm not sure that JSF will be the
next step either. That will depend on how fast developers evaluate
and then adopt the technology. And that will depend on how fast JSF
evolves to address various issues (see an earlier post of mine about
current JSF limitations.)
> Martin Cooper
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Martin Cooper <mf...@gmail.com>.
On Wed, 29 Dec 2004 14:36:19 -0600, Michael Rasmussen
<ra...@gmail.com> wrote:
> > other page oriented technologies as the past. The future, as I see it,
> > is in highly dynamic apps
>
> What exactly do you mean by "highly dynamic"? Are you referring to
> applications like gmail? Do you mean XAML type applications? (God
> willing they won't actually be XAML ;-) ) Or are you referring to
> something all together different?
I would classify Gmail as "moderately dynamic", but it's heading in
the right direction. I'm talking about things like handling wizard
page changes entirely on the client, up until Apply or OK is clicked;
drag and drop in the browser; master/detail handling within the
browser; real-time updates (i.e. not polling). Stuff like that. One of
the characteristics is minimising, if not eliminating, the number of
full-page refreshes, which makes page-oriented technologies like JSF a
whole lot less relevant.
--
Martin Cooper
> Michael
>
> ---------------------------------------------------------------------
> 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: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Michael Rasmussen <ra...@gmail.com>.
> other page oriented technologies as the past. The future, as I see it,
> is in highly dynamic apps
What exactly do you mean by "highly dynamic"? Are you referring to
applications like gmail? Do you mean XAML type applications? (God
willing they won't actually be XAML ;-) ) Or are you referring to
something all together different?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ]
Posted by Ted Husted <hu...@apache.org>.
On Wed, 29 Dec 2004 12:29:58 -0800, Martin Cooper wrote:
>�There are a few points that I don't necessarily agree with, but
>�they're all phrased as "Consider X". I can't argue with considering
>�them, although I might argue against actually doing them. ;-)
Me too. But things get mentioned, so, like a good scribe, I set them down for consideration. :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ]
Posted by Martin Cooper <mf...@gmail.com>.
On Wed, 29 Dec 2004 10:21:24 -0500, Ted Husted <hu...@apache.org> wrote:
> On Wed, 22 Dec 2004 17:21:46 -0600, Joe Germuska wrote:
> > I haven't felt like there's a clear consensus on how to move such a
> > thing forward, and I guess I'm still in "ask permission" mode
> > instead of "ask forgiveness" mode. I'm not really even sure how
> > to move it forward in small measured steps to get people looking at
> > something concrete for reactions.
>
> On the Milestones page [http://struts.apache.org/milestones.html], there are actually two "API Beans". Once for the server-side and one for the view-side:
>
> * ActionContext - A Commons Chain Context that implements the Action class logical API (same signatures).
>
> * ViewContext - A Commons Chain Context that implements the combined VelocityStruts logical API (same signatures).
>
> Perhaps it would help if we could come to a consensus on the Roadmap, or used the Roadmap to forge a consensus. (I have no illusions about getting this page right the first time.)
>
> Does anyone disagree with the Roadmap [http://struts.apache.org/roadmap.html] or Milestones [http://struts.apache.org/milestones.html] ?
>
In general, I'm OK with what's listed there. I would point out,
though, that we seem to be discussing "Consider a 'smart' action
type", listed under 1.5, at the moment, potentially as part of 1.3.
(I'm not suggesting that we necessarily defer it, just pointing out
the discrepancy.)
There are a few points that I don't necessarily agree with, but
they're all phrased as "Consider X". I can't argue with considering
them, although I might argue against actually doing them. ;-)
One particular area on which I am not in sync with some others is the
whole JSF thing. I have no problem with Struts providing support for
JSF, but I am not in favour of "adopt[ing] JSF strongly", as Craig put
it. Craig and I see the future differently. He, I believe, sees JSF as
the future (which is not entirely surprising ;), whereas I see JSF and
other page oriented technologies as the past. The future, as I see it,
is in highly dynamic apps.
So what I'd like to see in a Struts 2.0 is strong support for highly
dynamic apps.This might include handling requests submitted as XML,
support for "serialising" to JavaScript or XML, etc.
--
Martin Cooper
> Is there anything someone would like put differently?
>
> -Ted.
>
> ---------------------------------------------------------------------
> 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: RoadMap [was Re: ViewUtils ... ]
Posted by Dakota Jack <da...@gmail.com>.
Why is JSF looking for help? Because it is superior or because it is
failing? Why there is any *shame* in choices is really beyond me. I
would like someone explain to me what JSF is doing involved with
Struts other than raiding the name and goodwill. Struts and JSF are
inherently incompatible. Why not merge JSF and NET?
Jack
On Wed, 29 Dec 2004 10:50:42 -0800, Craig McClanahan <cr...@gmail.com> 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
>
>
--
------------------------------
"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: RoadMap [was Re: ViewUtils ... ]
Posted by Martin Cooper <mf...@gmail.com>.
On Wed, 29 Dec 2004 14:53:52 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > 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.
> >
>
> I guess this would depend on one's view of JSF and where it's headed.
> I'm interested in trying to use JSF in the next release of my project
> at work, but I have some serious concerns about the current spec
> (1.1).
>
> One concern is with the limitation surrounding dynamic includes. This
> is a huge deal for us as we use Tiles all over the place to help with
> our layouts. Tiles is great and I'd hate to give it up just so JSF is
> happy. I'm not thrilled about the work-around either (using
> f:verbatim tags everywhere).
>
> The other problem I discovered recently is with the "id" attribute
> being determined by JSF (in the standard components.) We have tons of
> javascipt that use the getElementById() method which won't work
> without changes. Again there is a workaround
> (http://www.jsftutorials.com/proxyTag.html) but this seems like a lot
> of extra code that shouldn't be necessary.
>
> My understanding is that the first issue may be addressed in the 1.2
> spec (although its still missing from the latest draft.) I didn't see
> anything on the second issue but I might have missed it.
>
> I understand why these two problems are going to be hard to solve . I
> want to emphasize that I think JSF looks very promising and I
> appreciate all of the hard work that went into it. But I think that
> issues like these need to be addressed before programmers like myself
> can fully embrace JSF. Maybe these concerns only affect me, but
> judging from the postings I have been reading, it seems I am not
> alone.
No, you're definitely not alone. We also have scads of JavaScript code
that uses getElementById(), and I wouldn't _want_ to change it, since
that is the right way to grab elements you want to manipulate. (In
fact, we just got done fixing some of our code to use this, instead of
using the name, so that it works correctly on both IE and Mozilla /
Firefox.)
> I would agree that Struts without JSF could become less relevant, but
> only once JSF becomes widely adopted. Right now I don't know any
> developers who are using JSF in their applications. I'm sure there
> are some people who are using JSF but I doubt it even approaches the
> level of developers using Struts. Of course, the same could be said
> about Struts a few years ago.
There are certainly developers using JSF. Recently, though, I went
looking to see how widely adopted it really is, and my impression was
that it's not in nearly as widespread use as I had expected. Of
course, I could have been looking in the wrong places, and thus have
the wrong impression.
> I think a key to Struts rapid acceptance was its rapid evolution. The
> open source nature of Struts made it easier for people who had issues
> with it, to make improvements. With JSF, all we can do is submit
> something to the expert group and sit back and wait. IMO this will
> slow the adoption of JSF. I understand why JSF is within the JCP, but
> I think this is one of the negative results of that decision.
This is an interesting point. The key is that we (Struts) need to take
maximum advantage of this, and forge ahead while JSF sits in the JCP.
;-)
> I guess this means that IMO, I think Struts 1.3 would be relevant for
> quite a while yet. I'd hate to see all of (or the bulk of) the
> development effort shift to Struts 2.0 at this point because of what I
> foresee as a very slow evolution and adoption of JSF. On the other
> hand, I could see why Craig wants to keep pusing with the Shale stuff
> because that will take time to develop and evolve itself. I guess I
> just see the JSF evolution itself as being the critical part missing
> from an all-out effort on Struts 2.0/Shale.
I don't think you're going to see everyone abandon 1.x any time soon.
Speaking for myself, I recently elected to go with Struts 1.3 for a
new project in my day job, after looking at a variety of other
options, including JSF. Together with a client side framework, this is
working out well for us (even if 1.3 technically doesn't exist yet ;).
I'm unlikely to be interested in a JSF based solution until the new
Dojo client side framework is complete and someone has figured out how
to build a JSF component library around that. I'm not holding my
breath. ;-)
--
Martin Cooper
> Just my 2 cents. Thanks again for the hard work on JSF. I'm
> continuing to experiment with it and can't wait to use it. Eventually
> I will have to dig into your Shale stuff as well.
>
> > Craig
>
> sean
>
> ---------------------------------------------------------------------
> 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: RoadMap [was Re: ViewUtils ... ]
Posted by Sean Schofield <se...@gmail.com>.
> 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.
>
I guess this would depend on one's view of JSF and where it's headed.
I'm interested in trying to use JSF in the next release of my project
at work, but I have some serious concerns about the current spec
(1.1).
One concern is with the limitation surrounding dynamic includes. This
is a huge deal for us as we use Tiles all over the place to help with
our layouts. Tiles is great and I'd hate to give it up just so JSF is
happy. I'm not thrilled about the work-around either (using
f:verbatim tags everywhere).
The other problem I discovered recently is with the "id" attribute
being determined by JSF (in the standard components.) We have tons of
javascipt that use the getElementById() method which won't work
without changes. Again there is a workaround
(http://www.jsftutorials.com/proxyTag.html) but this seems like a lot
of extra code that shouldn't be necessary.
My understanding is that the first issue may be addressed in the 1.2
spec (although its still missing from the latest draft.) I didn't see
anything on the second issue but I might have missed it.
I understand why these two problems are going to be hard to solve . I
want to emphasize that I think JSF looks very promising and I
appreciate all of the hard work that went into it. But I think that
issues like these need to be addressed before programmers like myself
can fully embrace JSF. Maybe these concerns only affect me, but
judging from the postings I have been reading, it seems I am not
alone.
I would agree that Struts without JSF could become less relevant, but
only once JSF becomes widely adopted. Right now I don't know any
developers who are using JSF in their applications. I'm sure there
are some people who are using JSF but I doubt it even approaches the
level of developers using Struts. Of course, the same could be said
about Struts a few years ago.
I think a key to Struts rapid acceptance was its rapid evolution. The
open source nature of Struts made it easier for people who had issues
with it, to make improvements. With JSF, all we can do is submit
something to the expert group and sit back and wait. IMO this will
slow the adoption of JSF. I understand why JSF is within the JCP, but
I think this is one of the negative results of that decision.
I guess this means that IMO, I think Struts 1.3 would be relevant for
quite a while yet. I'd hate to see all of (or the bulk of) the
development effort shift to Struts 2.0 at this point because of what I
foresee as a very slow evolution and adoption of JSF. On the other
hand, I could see why Craig wants to keep pusing with the Shale stuff
because that will take time to develop and evolve itself. I guess I
just see the JSF evolution itself as being the critical part missing
from an all-out effort on Struts 2.0/Shale.
Just my 2 cents. Thanks again for the hard work on JSF. I'm
continuing to experiment with it and can't wait to use it. Eventually
I will have to dig into your Shale stuff as well.
> Craig
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ]
Posted by Craig McClanahan <cr...@gmail.com>.
Funny how, every time I raise this issue, I only seem to get responses
from NON committers :-).
On Wed, 29 Dec 2004 13:08:32 -0600, Vic <vi...@friendvu.com> wrote:
> Craig McClanahan wrote:
>
> > I believe that Struts will become
> >gradually less relevant for new application development unless it
> >adopts JSF strongly;
> >
>
> :-). I don't think so.
>
We'll see :-).
> > and it would be a shame to have to *compete* with
> >Struts instead of *being* Struts.
> >
> >
> >
>
> Why not have JSF compete with HTML tag libs? Like Velcotiy does, etc. No
> need to have a view Religion locked in MVC implementation - the C part.
Because tags is only a small portion of what JSF does. Indeed, it
does pretty much everything that Struts 1.x does, either by itself or
in conjunction with appropriate libraries (i.e. Tiles, validator
framework).
> If so, then lets all agree on one true DAO 1st, that is more mature
> EJB? iBatis? Which JDO? Hibreante? Spring JDBC? Roll your own JDBC?
> ... which is the official one?
> Best thing about Java is choice. I think Caraig said way back "over my
> dead body will there be a lock on a one DAO", or words to that effect.
>
When Struts first came out in 2000, a large percentage of early
adopters commented that "oh, I was just about to build my own
framework -- now I don't have to."
We now have that opportunity in 2005 -- to stop spending time on a
problem that has been solved (not just by JSF, but by five or six
other viable frameworks) -- and solved in ways that are more elegant
than our original design. Of course, that is what one hopes to see;
that the state of the art advances over time.
> I will agree that "the view has been done in '04". If anyone has doubt
> as to what view will win out in '05, take a look at my sample at
> http://www.boardVU.com (in IE only for now - click on IE link. Also
> SandraSF.com has javadocs. It's a chain based dispatcher that I will
> port to Struts chain after chain becomes a bit more stable.). I see the
> light, it's a diferent light. By next X-mass, JDNC will be a very
> polular view tech in production, ahead of JSF and Tapestry.
> If I was to limit myself to DHTML tech only... then clearly PHP is best,
> look at all the PHP apps. Java is most competetive w/ JDNC. That is my
> religion, the one true one, so all pray to my god! ;-)
>
> No mater how much skill and effort is put in JSF, it will not get
> production market share, it will only move people to .NET ASP, thats
> all. I do not think people should be disallowed to do JSF as view in
> Struts, choice is good. If JSF makes improves... GREAT!!!!!!!
>
> I hope Struts contines to be View agnostic and that it even have some
> SoA dispatch support in version 2 and 3.
Why bother with Struts for SoA dispatch? You can solve that problem
easily with ChainServlet (part of Commons Chain) and/or things like
XML-RPC.
>
> .V
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ]
Posted by Vic <vi...@friendvu.com>.
Craig McClanahan wrote:
> I believe that Struts will become
>gradually less relevant for new application development unless it
>adopts JSF strongly;
>
:-). I don't think so.
> and it would be a shame to have to *compete* with
>Struts instead of *being* Struts.
>
>
>
Why not have JSF compete with HTML tag libs? Like Velcotiy does, etc. No
need to have a view Religion locked in MVC implementation - the C part.
If so, then lets all agree on one true DAO 1st, that is more mature
EJB? iBatis? Which JDO? Hibreante? Spring JDBC? Roll your own JDBC?
... which is the official one?
Best thing about Java is choice. I think Caraig said way back "over my
dead body will there be a lock on a one DAO", or words to that effect.
I will agree that "the view has been done in '04". If anyone has doubt
as to what view will win out in '05, take a look at my sample at
http://www.boardVU.com (in IE only for now - click on IE link. Also
SandraSF.com has javadocs. It's a chain based dispatcher that I will
port to Struts chain after chain becomes a bit more stable.). I see the
light, it's a diferent light. By next X-mass, JDNC will be a very
polular view tech in production, ahead of JSF and Tapestry.
If I was to limit myself to DHTML tech only... then clearly PHP is best,
look at all the PHP apps. Java is most competetive w/ JDNC. That is my
religion, the one true one, so all pray to my god! ;-)
No mater how much skill and effort is put in JSF, it will not get
production market share, it will only move people to .NET ASP, thats
all. I do not think people should be disallowed to do JSF as view in
Struts, choice is good. If JSF makes improves... GREAT!!!!!!!
I hope Struts contines to be View agnostic and that it even have some
SoA dispatch support in version 2 and 3.
.V
>Craig
>
>
--
RiA-SoA w/JDNC <http://www.SandraSF.com> forums
- help develop a community
My blog <http://www.sandrasf.com/adminBlog>
---------------------------------------------------------------------
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
Shale for 2.x? (was Re: RoadMap)
Posted by Ted Husted <hu...@apache.org>.
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: RoadMap [was Re: ViewUtils ... ]
Posted by Craig McClanahan <cr...@gmail.com>.
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