Re: Struts2 JSF Integration Proposal
Does anyone notice what is happening here? On 8/8/06, Don Brown <[EMAIL PROTECTED]> wrote: Sounds reasonable. Open up a JIRA ticket and attach the patch, and I'll apply it. Don Chris Waring wrote: > > Don Brown-2 wrote: >>> 3) Should we add the capability to configure the JSF application, phase >>> listeners, etc. from within the Struts config? How far do we go with >>> this? >>> I'm not sure that we would want to allow navigation, validation, and the >>> like to be configured using the Struts config? >>> >> I'd say no for now, but if we move to a more extensible XSD-based XML >> format later on, it might be interesting to combine them. >> > > What about just adding a couple of paramaters to the FacesSetupInterceptor > for the heavily used things like VariableResolver, MessageBundle, > ViewHandler and maybe ActionListener (although I don't think many people > change this one)? > > The config might look something like this: > > > > > > > > > >name="viewHandler">org.apache.shale.tiles.TilesViewHandler > > > The FacesSetupInterceptor Code could then check the parameter variables to > see that they are not null, create the requested class and set the class on > the JSF application object using the appropriate setter. > > --Chris > > --------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Struts2 JSF Integration Proposal
i've never seen you sign your emails as "Rod" before Don. Just curious. What's with that? Something similar happened with me sometime ago and they have been accusing me of being several people ever since. LOL Are you really Rod Steiger? On 8/4/06, Don Brown <[EMAIL PROTECTED]> wrote: Hmm...I agree with your premise that there are two types of JSF integration use cases: 1. The JSf app that wants some action-driven pages 2. The Struts 2 app that wants to use JSF components However, I don't see why both aren't serviced by the existing code today. To meet use case #1, you could define a wildcard that basically hands most requests off to JSF automatically then configure the exceptions. For use case #2, the Showcase example demonstrates how it is possible. What specific functionality do you see missing? Rod :) Chris Waring wrote: > I've been working with the Struts2 JSF Integration and I wanted to run a few > ideas past the development community. > > First, I would like to give a high level description of the functionality > that I see as being desirable as well as why I believe it to be so. > > Second, I would like to give a description of some of the design ideas to > see if their are better alternatives available to meet the described > functionality. > > THE MARKET PITCH: > I see Struts2 JSF integration as a good lure to get JSF developers > interested in checking out Struts2. With that said I think that the end > implementation should be able to support both an integrated lifecycle where > Struts2 takes over the duties of executing Actions, performing validation, > handling result navigation, and all the other things that Struts2 does well, > as well as a wrapped lifecycle where Struts2 supports pre and post > processing of the default JSF Lifecycle. In this second case JSF would > handle everything in it's standard way but integrated with in the Struts2 > Lifecycle stack to support things like error handling, etc. that JSF seems > to lack. > > > > Why support two different JSF lifecycle implementations? > > My thought here is that if we can add value to a project that already has > invested development into JSF, while keeping the "barrier to entry" to > integrate with Struts2 to a minimum, we ought to be able to attract a number > of JSF projects that are already in progress to try us out. On the other > side, if you are evaluating frameworks for a new project, it might be > attractive to be able to use Struts2 but still be able to use JSF > components. In this situation it would be nice to be able to use a single > configuration file and not have to learn the faces-config.xml. > > > > How would the integrated lifecycle work? > > JSF 1.1 supports six phases but it does so by using only 2 Lifecycle events. > It has an execute() and a render(). I see Struts2 integrating right between > those two lifecycle methods. The Struts 2 lifecycle stack could be > something like: > > FacesSetupInterceptor - Accepts parms for configuring JSF application, > lifecycle, etc. > > FacesExecuteLifecyleInterceptor - Would create the JSF lifecycle and > perform and call the execute() portion of the JSF lifecycle. > > (Normal Action call would occur) > > FacesResult - Would use the Struts2 result uri to construct a new jsf > UIViewRoot. Calls the render portion of the JSF lifecycle. > > > > How would the wrapped lifecycle work? > > The wrapped lifecycle would rely on a properly configured faces-config.xml > and would not allow the normal action processing to occur. The lifecycle > stack could be as simple as a single jsf interceptor. > > FacesFullLifecycleInterceptor - Creates the JSF lifecycle. Calls both > execute() and render() methods on the lifecycle. Returns null to prevent > further processing. > > > > If people think that this would be beneficial, I am willing to do most of > the coding, testing and documentation for it. > > I already have a good start on the code for the integrated lifecycle part, > thanks in part to Rod Browns efforts. Let me know if I should continue to > work on this. > > Thank You, > --Chris Waring > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Struts2 JSF Integration Proposal
All of these discussions go back to all the troubles brought to Struts by somewhat inane and uninformed attempts to integrate two competing ways to code web apps with JSF advocates. JSF and Struts are not compatible. They are wholly different philosophies and JSF has nothing to offer Struts without chaning the whole nature of the web framework. JSF was built to compete with .NET and is built for web tools. Struts is built for developers who know how to code a bit and are not that interested in tool support other than an IDE. As Waring says, he does not know Struts that well. JSF ideas should go over to JSF sites. Are we going to have to see this all happen again. Are there never any lessons learned around here? On 8/7/06, Chris Waring <[EMAIL PROTECTED]> wrote: Don Brown-2 wrote: > >> 3) Should we add the capability to configure the JSF application, phase >> listeners, etc. from within the Struts config? How far do we go with >> this? >> I'm not sure that we would want to allow navigation, validation, and the >> like to be configured using the Struts config? >> > I'd say no for now, but if we move to a more extensible XSD-based XML > format later on, it might be interesting to combine them. > What about just adding a couple of paramaters to the FacesSetupInterceptor for the heavily used things like VariableResolver, MessageBundle, ViewHandler and maybe ActionListener (although I don't think many people change this one)? The config might look something like this: org.apache.shale.tiles.TilesViewHandler The FacesSetupInterceptor Code could then check the parameter variables to see that they are not null, create the requested class and set the class on the JSF application object using the appropriate setter. --Chris -- View this message in context: http://www.nabble.com/Struts2-JSF-Integration-Proposal-tf2051594.html#a5687736 Sent from the Struts - Dev forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [jira] Created: (WW-1388) Shopping Cart Example throws HTTP 500
ntact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Re: [PROPOSAL] Rename Struts Action as Struts
I think everyone knows by now that this brevity is bad programming? On 6/30/06, Ted Husted <[EMAIL PROTECTED]> wrote: On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: > Ted Husted wrote: > > Though, there's no reason why we couldn't use > > > >> repos/asf/struts/struts1 > >> repos/asf/struts/struts2 > > > > Or > > > >> repos/asf/struts/framework > >> repos/asf/struts/framework2 > > I like struts1/struts2. Or, in the interest of brevity, even repos/asf/struts/s1 repos/asf/struts/s2 -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
Give it up! Lord! What nonsense. Do you hate versioning, Paul? On 6/28/06, Paul Benedict <[EMAIL PROTECTED]> wrote: I am guessing the winner is going to be struts1/struts2 So if struts1 is: org.apache.struts If struts2: org.apache.struts2 ? Niall Pemberton <[EMAIL PROTECTED]> wrote: On 6/29/06, Don Brown wrote: > > I like struts1/struts2. +1 Niall > Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [PROPOSAL] Rename Struts Action as Struts
s/asf/struts/framework, keep >> >> the >> >> > other >> >> > top level directories the same >> >> > 3. The org.apache.struts.action2 package becomes >> org.apache.struts2 >> >> > 4. action.* and struts-action.* configuration files become >> struts.* >> >> > 5. The SAF acronym in the documentation would return to Struts >> >> > >> >> > Given all the product naming changes in the last few years (much of >> >> which >> >> > was my >> >> > fault, I admit), I'd like to have these changes decided on soon, so >> >> we can >> >> > move >> >> > on to getting Struts 2.0 out the door. >> >> > >> >> > Don >> >> > >> >> > >> - >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >> >> > >> >> >> >> >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [PROPOSAL] Rename Struts Action as Struts
Heh, yah, almost like real versioning, eh? On 6/28/06, Paul Benedict <[EMAIL PROTECTED]> wrote: My two cents: I am okay with 1.x and 2.x numbering. It doesn't bother me. I look at them in terms of generations; different people who can live together in one family (webapp). Michael Jouravlev <[EMAIL PROTECTED]> wrote: In this case we are returning to a half-year old situation, that is, Struts 2 is a new crown holder of a single unified project. Consider the announcements like this: "Struts team is proud to announce immediate availability of Struts 2.0 as a next version of popular Struts framework. New features include ... " and then: "Struts team releases Struts 1.4, the next version of popular Struts framework. New features include ... " Things have not got simpler after divorce :) I suppose that having Struts 2 as the next version works for you. But I afraid that it does not work well for those who think about releasing new versions of 1.x codebase. So, maybe Win9x vs. WinNT is not that bad idea after all? And look at them now, united. Now not only former NT users wait for Vista, but former 9x users too :-)) On 6/28/06, Don Brown wrote: > I think it is as simple as Struts 1.3, Struts 1.4, Struts 2.0, Struts 2.1, > etc... The whole point of this proposal is to unify Struts as a single project, > getting away from this concept of separately versioned "subprojects". There > will be Struts 1.x releases, and there will be Struts 2.x releases, and perhaps > some day, Struts 3.x releases. > > Don > > Michael Jouravlev wrote: > > You mean, Struts 2.0 version 2.0, then Struts 2.0 version 2.1, Struts > > 2.0 version 2.2, ..., Struts 2.0 version 3.0, ..., Struts 2.0 version > > 4.0 > > > > :-) > > > > 2.0 is a version number, while we are choosing project names (Are we?) > > Do we treat Struts2 as the next version, or do we treat Struts and > > Struts2 as separate subprojects like Win9x/Me vs. WinNT/2K/XP ? > > (Obviously I prefer the latter) > > How version numbers correspond to project names? > > Can Struts 2 subproject have version number higher than 2.x? (I think yes) > > Can Struts [implied: 1] have version numbers higher than 1.x? > > (theoretically yes, but that would be bizzare) > > > > On 6/28/06, Bob Lee wrote: > >> +1 for Struts 2.0 > >> > >> Bob > >> > >> On 6/28/06, Don Brown wrote: > >> > > >> > With the departure of Struts Shale, I think it is time we return to the > >> > idea of > >> > Struts as a single, unified framework. While I had hoped we could > >> do this > >> > by > >> > including Shale, everyone involved felt Shale deserved its own > >> project and > >> > so > >> > I'm adjusting my original Struts 2.0 proposal to simply rename Struts > >> > Action as > >> > Struts. > >> > > >> > The ramifications of such a renaming up for discussion: > >> > 1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0becomes > >> > Struts 2.0 > >> > 2. We rename the > >> https://svn.apache.org/repos/asf/struts/actionsubversion > >> > directory as https://svn.apache.org/repos/asf/struts/framework, keep > >> the > >> > other > >> > top level directories the same > >> > 3. The org.apache.struts.action2 package becomes org.apache.struts2 > >> > 4. action.* and struts-action.* configuration files become struts.* > >> > 5. The SAF acronym in the documentation would return to Struts > >> > > >> > Given all the product naming changes in the last few years (much of > >> which > >> > was my > >> > fault, I admit), I'd like to have these changes decided on soon, so > >> we can > >> > move > >> > on to getting Struts 2.0 out the door. > >> > > >> > Don > >> > > >> > - > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Yahoo! Music Unlimited - Access over 1 million songs.Try it free. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [PROPOSAL] Rename Struts Action as Struts
Things will never be simple with MJ on the team. This is typical. Learn to live with it. On 6/28/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: In this case we are returning to a half-year old situation, that is, Struts 2 is a new crown holder of a single unified project. Consider the announcements like this: "Struts team is proud to announce immediate availability of Struts 2.0 as a next version of popular Struts framework. New features include ... " and then: "Struts team releases Struts 1.4, the next version of popular Struts framework. New features include ... " Things have not got simpler after divorce :) I suppose that having Struts 2 as the next version works for you. But I afraid that it does not work well for those who think about releasing new versions of 1.x codebase. So, maybe Win9x vs. WinNT is not that bad idea after all? And look at them now, united. Now not only former NT users wait for Vista, but former 9x users too :-)) On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: > I think it is as simple as Struts 1.3, Struts 1.4, Struts 2.0, Struts 2.1, > etc... The whole point of this proposal is to unify Struts as a single project, > getting away from this concept of separately versioned "subprojects". There > will be Struts 1.x releases, and there will be Struts 2.x releases, and perhaps > some day, Struts 3.x releases. > > Don > > Michael Jouravlev wrote: > > You mean, Struts 2.0 version 2.0, then Struts 2.0 version 2.1, Struts > > 2.0 version 2.2, ..., Struts 2.0 version 3.0, ..., Struts 2.0 version > > 4.0 > > > > :-) > > > > 2.0 is a version number, while we are choosing project names (Are we?) > > Do we treat Struts2 as the next version, or do we treat Struts and > > Struts2 as separate subprojects like Win9x/Me vs. WinNT/2K/XP ? > > (Obviously I prefer the latter) > > How version numbers correspond to project names? > > Can Struts 2 subproject have version number higher than 2.x? (I think yes) > > Can Struts [implied: 1] have version numbers higher than 1.x? > > (theoretically yes, but that would be bizzare) > > > > On 6/28/06, Bob Lee <[EMAIL PROTECTED]> wrote: > >> +1 for Struts 2.0 > >> > >> Bob > >> > >> On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: > >> > > >> > With the departure of Struts Shale, I think it is time we return to the > >> > idea of > >> > Struts as a single, unified framework. While I had hoped we could > >> do this > >> > by > >> > including Shale, everyone involved felt Shale deserved its own > >> project and > >> > so > >> > I'm adjusting my original Struts 2.0 proposal to simply rename Struts > >> > Action as > >> > Struts. > >> > > >> > The ramifications of such a renaming up for discussion: > >> > 1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0becomes > >> > Struts 2.0 > >> > 2. We rename the > >> https://svn.apache.org/repos/asf/struts/actionsubversion > >> > directory as https://svn.apache.org/repos/asf/struts/framework, keep > >> the > >> > other > >> > top level directories the same > >> > 3. The org.apache.struts.action2 package becomes org.apache.struts2 > >> > 4. action.* and struts-action.* configuration files become struts.* > >> > 5. The SAF acronym in the documentation would return to Struts > >> > > >> > Given all the product naming changes in the last few years (much of > >> which > >> > was my > >> > fault, I admit), I'd like to have these changes decided on soon, so > >> we can > >> > move > >> > on to getting Struts 2.0 out the door. > >> > > >> > Don > >> > > >> > - > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [PROPOSAL] Rename Struts Action as Struts
Heh, what about Struts? That might work? And, then, like the rest of the world, you could have versions like 1.* and 2.*, and 3.*. Oh, that was the proposal which the newly knighted can't seem to stomach. Too rational. On 6/28/06, Paul Benedict <[EMAIL PROTECTED]> wrote: I am very much against naming 1.x "Classic" . I think it's a horrible name. I think of classical music, classic cars, and anything that smells of belonging in a museum (stationary, old, idle, doesn't move, better looked at than used). Why do we need it? I am totally fond of action and action2. Why does having the departure of Shale instigate nomenclature madness? :-) Struts Action Framework is actually a very professional title and I prefer we keep it as is. Ted Husted <[EMAIL PROTECTED]> wrote: On 6/28/06, Michael Jouravlev wrote: > Also, hoping not to hijaack this thread I would suggest coming up with > codenames for 1.x and 2.x codebases. If we were to do that, the obvious choices would be Classic for 1.x and Action for 2.x. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [PROPOSAL] Rename Struts Action as Struts
Heh, you voted him in. He is all yours. On 6/28/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: You mean, Struts 2.0 version 2.0, then Struts 2.0 version 2.1, Struts 2.0 version 2.2, ..., Struts 2.0 version 3.0, ..., Struts 2.0 version 4.0 :-) 2.0 is a version number, while we are choosing project names (Are we?) Do we treat Struts2 as the next version, or do we treat Struts and Struts2 as separate subprojects like Win9x/Me vs. WinNT/2K/XP ? (Obviously I prefer the latter) How version numbers correspond to project names? Can Struts 2 subproject have version number higher than 2.x? (I think yes) Can Struts [implied: 1] have version numbers higher than 1.x? (theoretically yes, but that would be bizzare) On 6/28/06, Bob Lee <[EMAIL PROTECTED]> wrote: > +1 for Struts 2.0 > > Bob > > On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > > With the departure of Struts Shale, I think it is time we return to the > > idea of > > Struts as a single, unified framework. While I had hoped we could do this > > by > > including Shale, everyone involved felt Shale deserved its own project and > > so > > I'm adjusting my original Struts 2.0 proposal to simply rename Struts > > Action as > > Struts. > > > > The ramifications of such a renaming up for discussion: > > 1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0becomes > > Struts 2.0 > > 2. We rename the https://svn.apache.org/repos/asf/struts/actionsubversion > > directory as https://svn.apache.org/repos/asf/struts/framework, keep the > > other > > top level directories the same > > 3. The org.apache.struts.action2 package becomes org.apache.struts2 > > 4. action.* and struts-action.* configuration files become struts.* > > 5. The SAF acronym in the documentation would return to Struts > > > > Given all the product naming changes in the last few years (much of which > > was my > > fault, I admit), I'd like to have these changes decided on soon, so we can > > move > > on to getting Struts 2.0 out the door. > > > > Don > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [PROPOSAL] Rename Struts Action as Struts
God yes, Don. Please don't let them go nuts again. Here you are in the reach of sanity. Stay the course! On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: I'm against "official" code names. We have had enough confusion in Struts with different names meaning different things, and we shouldn't pile on more names. If folks want to off-hand use code names, that's fine, but to have them used in code or documentation is too far. Version 1 and 2 are simple enough. Don Ted Husted wrote: > On 6/28/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: >> Also, hoping not to hijaack this thread I would suggest coming up with >> codenames for 1.x and 2.x codebases. > > If we were to do that, the obvious choices would be Classic for 1.x > and Action for 2.x. > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
JSF is not a major shift. It is just a way to let tools do the coding for people who have difficulty with code. It is also not ahead of its time, unless it has been ahead of its time for a record length of time. It is just not a very good idea. It is VB for Java web frameworks. Only VB oriented people will like it. It is not positioned well for a market. It sure as h-e-l-l is not the next generation anything. On 6/23/06, Sean Schofield <[EMAIL PROTECTED]> wrote: I agree that its time for Shale to find a new home. I actually think that living here in the Struts project is holding Shale back more then its helping at this point. I also feel that Shale is still a little ahead of its time. JSF is still gaining acceptance and Shale builds on JSF. Imagine if Struts had come out shortly after JSP and Servlets. JSF is a major shift in the way we've been doing things. It will take a while for everyone to understand JSF enough before they are ready for Shale. Maybe JSF won't ever become widely accepted but if you have looked at job postings lately you will see that its gaining ground. Struts Action and Shale are competing frameworks. There are two camps. At last year's Apache Con BOF I was shouted down for expressing this obvious fact but now I think its become obvious to almost everyone. I don't know anyone who spends a lot of time in *both* of these camps so why keep trying to force them to live together? I'm in favor of an amicable divorce as Craig has hinted at. We can continue to work together but lets create a formal split so we stop confusing the users and ourselves. Sean On 6/22/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > On 6/22/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > > What about a "generic" Faces project, like portals or ws ? > > Apache Faces. > > > > To me Shale fits fine into that. > > > > There - in an apache faces land - is enough space for: > > Myfaces > > Tomahawk > > Tobago > > Shale > > Sandbox (well, our sandbox) > > and soon Trinidad (aka ADF Faces donation) > > > > WDYT ? > > As far as I can tell, you've just proposed adding Shale and renaming > the MyFaces project to just 'Faces'. :) > > Everything you listed (except Shale) is already at MyFaces, or coming > soon. And I agree, Shale is a better fit with that list. > > -- > Wendy > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
I am just trying to figure out how all the movement the last few years fits into this supposed picture of reality. How does Shale fit into this? How does WebWorks fit into this? This is mere words without any inkling of the reality of what happens on Struts. On 6/22/06, Ted Husted <[EMAIL PROTECTED]> wrote: On 6/22/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > In the meantime I want to make sure that SAF1 will not be simply > removed from source repository just because SAF2 is the official > future. The future belongs to the volunteers willing to do the work. So long as we have volunteers to work on the SAF1 codebase, then the work will continue. Trying to kill a codebase is a marketplace ploy. As an ASF project, our mandate is *not* "conquer the marketplace". Our mandate is to create an environment where a community of volunteers can collaborate on open source software. If the product finds marketplace acceptance, that's icing. But, it is *not* the point of the exercise. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
t; How would this benefit Struts Action? By splitting of the tags, we can focus on > the core project and get it out the door quicker. By publicizing our JSF and > Shale integration, we would open our framework up to a broader audience. > > How would this benefit Struts Shale? Shale would also be opened up to a broader, > Action-based audience and wouldn't be seen as a competitor to Struts Action. It > wouldn't lose its autonomy or pure JSF support. It would gain developer support > as more Action-based apps would start to use JSF and need Shale. > > How would this benefit Struts Tags? The tags could evolve quicker with faster > releases due to less code. They would be free to add new marginal features > without worrying about bloating Struts. This project would be analogous to > MyFaces Tomahawk as a library of components. > > How would this benefit the Struts community? Finally, Struts returns to its > roots as a single framework. While pieces of it may be usable outside the > Action-based controller like Shale, it becomes the single place you go to solve > your application development needs. The documentation would be unified and the > supporting committer community in step. If you wanted the whole framework, you > download Struts. If you just want one of the libraries, they are available ala > carte as well. > > This proposed change is primarily one of message and vision, and should have > minimal impact on current development activity. With the next generation of > books and conferences in the works, I think it is important to develop a clear > message to the Struts community and minimize any confusion. > > The bottom line is we want Struts to be the place to go to make web development > easier, faster, with less hassles. I think this proposal provides the vision to > make that happen. > > Don > > [1] http://www.oreillynet.com/onjava/blog/2006/06/isnt_rails_supposed_to_change.html > > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
s. These tags would most likely remain tied > to Struts Action 2, but not necessarily. > > How would this benefit Struts Action? By splitting of the tags, we can focus on > the core project and get it out the door quicker. By publicizing our JSF and > Shale integration, we would open our framework up to a broader audience. > > How would this benefit Struts Shale? Shale would also be opened up to a broader, > Action-based audience and wouldn't be seen as a competitor to Struts Action. It > wouldn't lose its autonomy or pure JSF support. It would gain developer support > as more Action-based apps would start to use JSF and need Shale. > > How would this benefit Struts Tags? The tags could evolve quicker with faster > releases due to less code. They would be free to add new marginal features > without worrying about bloating Struts. This project would be analogous to > MyFaces Tomahawk as a library of components. > > How would this benefit the Struts community? Finally, Struts returns to its > roots as a single framework. While pieces of it may be usable outside the > Action-based controller like Shale, it becomes the single place you go to solve > your application development needs. The documentation would be unified and the > supporting committer community in step. If you wanted the whole framework, you > download Struts. If you just want one of the libraries, they are available ala > carte as well. > > This proposed change is primarily one of message and vision, and should have > minimal impact on current development activity. With the next generation of > books and conferences in the works, I think it is important to develop a clear > message to the Struts community and minimize any confusion. > > The bottom line is we want Struts to be the place to go to make web development > easier, faster, with less hassles. I think this proposal provides the vision to > make that happen. > > Don > > [1] http://www.oreillynet.com/onjava/blog/2006/06/isnt_rails_supposed_to_change.html > > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
What is the problem? Who caused it? Bingo! Eureka? On 6/21/06, Don Brown <[EMAIL PROTECTED]> wrote: Paul Benedict wrote: > I don't see the point in bundling Shale into a "Struts 2.0" distribution. No > offense to anyone who develops Shale, but when we have packages called > "action2", it makes it pretty clear Shale is not Struts 2.0 -- only the action > framework. Separate frameworks, imo, get different names and distributions. I am > not offended Shale is within the Struts community, but I do not see it as the > torch bearer to the name Struts -- I do see that with the AF, which historically > holds the name. Again, Struts Action and Struts Shale would both retain their separate projects, codebases, and release cycles. Struts 2.0 is about building something on top of our Struts efforts to create a unified front to users. Users don't care about all the little projects, subprojects, and libraries we have; I think they just want something to help them build webapps - they want Struts 2.0. And as a committer, PMC member and Struts user, I want it too. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
It would be impossible to pull off. Since Struts and JSF are inherently incompatible, there would be a my way or I will run away from home from Craig and an unwillingness of the Struts community to quit a true controller based framework. There is no way to make this marriage work. On 6/21/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote: My quick thoughts: I think realistically either of the following two outcomes are positive developments for everyone: 1) We move in the direction of "Struts 2.0", which houses all SAF2 and Shale and get back for it being OK for folks to say, "I use Struts". We've all said we want to work together closer, but it's just talk until we take action to do so. This strategy, as proposed by Don in this thread, would be the first step in taking action. 2) Shale becomes a TLP. We continue to share code and ideas where it makes sense, but that is entirely optional. This is effectively what we have now, except that it would be formalized. I would prefer option #1, but I know it could be hard to pull off. Either way, both are good routes to go down and would be healthy for the community. Patrick - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=34915&messageID=68478#68478 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
The success of Spring is not that "people like modularity". On 6/21/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Ted Husted wrote: > So, in addition to including the Action 1.3 JARs in the SAF 2.0 > release, essentially, you are suggesting that we also include the > Shale 1.x JARs in the same distribution, so that anyone obtaining SAF2 > can use Action 1, Action 2, and/or Shale 1? Even though Don hasn't answered yet, I have to say I agree with Joe, and I hope that wasn't the idea... if we have learned anything from the success of Spring, it should be that people like modularity. Making sure that Action 1.3, SAF2 and Shale 1.x can be used together as desired is one thing, bundling them all together is another. I don't think that will make things easier or less confusing, on the contrary, I can't imagine it would do anything but make people scratch their heads even more. > -Ted. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
ere is a common narrative we can weave to create a unified Struts project. Don > > Don > > > Craig > --------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
t I'm saying is you could view this "overlap" in a negative > or positive light. I think the Struts project should put forth a > "preferred" approach, used in our quickstarts and tutorials. However, > that doesn't mean that we should force developers into our way of > thinking. Having options isn't necessarily bad. > > At this point, I really don't see a valid either/or framework approach > debate: > > - If your application needs to be built by tool-dependent programmers, > pure JSF is definitely the way to go. > > - If you prefer the pure JSF approach for other reasons, use a pure > JSF framework, but perhaps use Action 2 to organize and deliver JSON/XML > services. > > - If your application has a lot of Struts developers or stateless > pages that need pure speed, but in sections you want to use fancy JSF > components, use Action 2 as the controller and sprinkle in JSF where > needed. > > - If you like Action-based approaches and don't need/like JSF > components, just use Action 2. > > I hope we can agree that each of the above situations and solutions is > valid, and make that our common ground. You may prefer the first > couple, others the latter two. As a Struts project, we need to be of > one mind in at least some things, and it is my hope Action 2's recent > JSF integration attempts can help get us there. I put this proposal out > to help bring us together, not precipitate a "divorce" :) Doesn't it really come down to which front controller you choose as the primary foundation of your architecture? Nearly every existing framework that has added JSF integration has kept their original basic architecture, and thought of JSF primarily as a library of UI widgets. Shale (and Seam) take a different viewpoint -- utilize the front controller built in to JSF instead, and decorate around the edges to add features and ease of use. If you take that approach, you discover a very capable framework, usable for server generated markup or AJAX callbacks or any other sort of HTTP request, with basic IoC-ish bean instantiation and dependency injection built in, along with an expression language that can be used to bind components to model data, but can also be used programmatically by an application framework itself. Personally, I want to get out of the front controller business :-), and leave that problem to the MyFaces and RI teams to compete on quality and features. I'd rather add value by leveraging concepts that a JSF-oriented developer already has to know about, rather than adding abstraction layers so I can be agnostic about the front controller that is under the covers. Don Craig -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
Thanks, Ted. Well said! On 6/21/06, Ted Husted <[EMAIL PROTECTED]> wrote: On 6/21/06, Don Brown <[EMAIL PROTECTED]> wrote: > I put this proposal out to help bring us together, > not precipitate a "divorce" :) We're not "divorcing" Tiles. Neither did we "divorce" any of the components that now live in the commons. We believed each of these codebase could attract a larger community on their own. We didn't abandon these components, we still use them. And, no matter where it lives, now it looks like we can still use Shale and other JSF components with SAF2. We can give away the cake and eat it too. As a PMC member, I'm concerned that, after all this time, Shale has still not had a GA release. We are all busy professionals, and we need a large community to push a release out the door. Shale has attracted a hard-working community, but it still has not attracted a large community. The question should be what is best for the Shale community? Where will the people working on Shale going to be the most productive? Where will they get the most help from other developers and users? At one time, the answer was here at Struts. But, 18 months later, maybe the answer has changed. Maybe the best thing for Shale would be to become a TLP, or a MyFaces subproject. I don't know myself. It's up to them that are doing the work. If the people working on Shale still think that this is the still the best location, then they have my support. But, I do think it is healthy to ask the question. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
This is so odd. You begin by recognizing the problem and trying to hide it. Now you deny the problem and want to continue it in spades. Everyone who knows anything about frameworks sees that these two frameworks are inherently incompatible. They have been from the start. That is the problem. Had Craig not had a career dependent presently on the success of JSF and also the pull at Struts, this mess would never have happened. On 6/21/06, Don Brown <[EMAIL PROTECTED]> wrote: Tim O'Brien wrote: > There is obviously a good deal > of exchange, but the frameworks "compete" (not my words). While this may be true politically, from a code perspective, I completely disagree. Just about every feature of Shale, AFAIK can easily be used with Action 2: Spring integration, clay, message bundles, basically anything that doesn't use an alternative NavigationHandler or Lifecycle. I think Shale is a great project and plan to use it where I can in Action 2 JSF examples as it really makes JSF easier. I think JSF is a very legitimate view option for Action 2 and Shale fills in JSF's gaps quite nicely. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
The obvious truth is so easy to state. Thanks, Tim. On 6/21/06, Tim O'Brien <[EMAIL PROTECTED]> wrote: ...we're dealing with the ramifications of dismantling Jakarta from years ago.I actually think that this situation would have never arose if Struts and Shale were two sibling subprojects in a larger Jakarta project. But, the Board spoke years ago, and umbrella projects were broken up because of oversight concens. This highly dormant non-member votes TLP for Shale. This isn't meant as a slight towards Craig, rather I think that separating Shale into separate entity will help clarify the message of both Shale and SAF2. Otherwise every Shale page on the site is like an if/else clause "Use SAF2 if you like actions, but use shale if you...". I take a look at the db.apache.orgTLP, and I don't wish that fate upon Shale. Shale should be a TLP, the Shale site should be self-hosting. Struts is a TLP, the Struts site should be self-hosting. There is obviously a good deal of exchange, but the frameworks "compete" (not my words). On 6/21/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > On 6/21/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > If that means a (hopefully amicable) divorce, then so be it. > > If that's what the people working on Shale want, I doubt that the PMC > would oppose a change of venue. > > If that is the case, then the next question would be whether Shale > would be a better fit as a top-level ASF project, a subproject of > MyFaces, or somewhere else entirely? > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
d >> include current and future AJAX tags. These tags would most likely >> remain >> tied >> to Struts Action 2, but not necessarily. >> >> How would this benefit Struts Action? By splitting of the tags, we can >> focus on >> the core project and get it out the door quicker. By publicizing our JSF >> and >> Shale integration, we would open our framework up to a broader audience. >> >> How would this benefit Struts Shale? Shale would also be opened up to a >> broader, >> Action-based audience and wouldn't be seen as a competitor to Struts >> Action. It >> wouldn't lose its autonomy or pure JSF support. It would gain developer >> support >> as more Action-based apps would start to use JSF and need Shale. >> >> How would this benefit Struts Tags? The tags could evolve quicker with >> faster >> releases due to less code. They would be free to add new marginal >> features >> without worrying about bloating Struts. This project would be analogous >> to >> MyFaces Tomahawk as a library of components. >> >> How would this benefit the Struts community? Finally, Struts returns to >> its >> roots as a single framework. While pieces of it may be usable outside >> the >> Action-based controller like Shale, it becomes the single place you go to >> solve >> your application development needs. The documentation would be unified >> and the >> supporting committer community in step. If you wanted the whole >> framework, you >> download Struts. If you just want one of the libraries, they are >> available ala >> carte as well. >> >> This proposed change is primarily one of message and vision, and should >> have >> minimal impact on current development activity. With the next generation >> of >> books and conferences in the works, I think it is important to develop a >> clear >> message to the Struts community and minimize any confusion. >> >> The bottom line is we want Struts to be the place to go to make web >> development >> easier, faster, with less hassles. I think this proposal provides the >> vision to >> make that happen. >> >> Don >> >> [1] >> http://www.oreillynet.com/onjava/blog/2006/06/isnt_rails_supposed_to_change.html >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
Finally! On 6/21/06, Ted Husted <[EMAIL PROTECTED]> wrote: On 6/21/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > If that means a (hopefully amicable) divorce, then so be it. If that's what the people working on Shale want, I doubt that the PMC would oppose a change of venue. If that is the case, then the next question would be whether Shale would be a better fit as a top-level ASF project, a subproject of MyFaces, or somewhere else entirely? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
to adopt an > action-based > approach for an application, yet use JSF components and abilities where > needed. > We have always said the desired end state would be to return Struts into > a > unified framework, and I think we should jump on this chance now. > > I propose Struts return to its roots as a unified framework through > building on > three libraries to make JSF and pure Servlet/JSP development > easier. Namely, > I propose the Struts project to be the following subprojects, each with > their > own release cycle: > > - Framework: Struts 2 > - Libraries: Struts Action, Shale and Struts Tags > > Struts would be the single framework the world would see. It would > contain > support for Action-based, JSF-based, and hybrid applications. Its > documentation > would promote the Struts Action controller as the preferred entry point, > even if > only to be used for AJAX services. Its JSF library, Struts Shale, > however, > could be used with a regular FacesServlet. JSF components and Struts Tags > would > be equals when describing how to tackle the View of an application. > > Struts Action would be the core library driving Struts 2, replace Struts > 1.x. > This library would be everything now known as Struts Action 2, but without > the > UI components. We would aim for a solid Action-based library independent > of the > view, much like Action 1.x. When we talked about what an Action JSR would > look > like, this would be it. > > Struts Shale would be repositioned as a library, which I think is a better > fit. > A framework to me is a comprehensive, one-stop-shop solution to create > an > application. A library is a collection of independent features that can > be used > in piecemeal. Therefore, I think a library is a better definition for > Shale's > collection of JSF extensions. While Struts Action would definitely > support > Shale, it would continue to be able to be used with pure JSF applications. > > Struts Tags would be the WebWork UI components, a library of re-usable, > stateless tags that can be used in Velocity, Freemarker, or JSP. They > would > include current and future AJAX tags. These tags would most likely remain > tied > to Struts Action 2, but not necessarily. > > How would this benefit Struts Action? By splitting of the tags, we can > focus on > the core project and get it out the door quicker. By publicizing our JSF > and > Shale integration, we would open our framework up to a broader audience. > > How would this benefit Struts Shale? Shale would also be opened up to a > broader, > Action-based audience and wouldn't be seen as a competitor to Struts > Action. It > wouldn't lose its autonomy or pure JSF support. It would gain developer > support > as more Action-based apps would start to use JSF and need Shale. > > How would this benefit Struts Tags? The tags could evolve quicker with > faster > releases due to less code. They would be free to add new marginal > features > without worrying about bloating Struts. This project would be analogous > to > MyFaces Tomahawk as a library of components. > > How would this benefit the Struts community? Finally, Struts returns to > its > roots as a single framework. While pieces of it may be usable outside the > Action-based controller like Shale, it becomes the single place you go to > solve > your application development needs. The documentation would be unified > and the > supporting committer community in step. If you wanted the whole > framework, you > download Struts. If you just want one of the libraries, they are > available ala > carte as well. > > This proposed change is primarily one of message and vision, and should > have > minimal impact on current development activity. With the next generation > of > books and conferences in the works, I think it is important to develop a > clear > message to the Struts community and minimize any confusion. > > The bottom line is we want Struts to be the place to go to make web > development > easier, faster, with less hassles. I think this proposal provides the > vision to > make that happen. > > Don > > [1] http://www.oreillynet.com/onjava/blog/2006/06/isnt_rails_supposed_to_change.html > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
Struts is not advocating a preference? The Orwellian Speak continues. Struts is Action. Struts is NOT JSF. Struts does not have a preference because Struts IS one of the alternatives and one of the alternatives is NOT Struts. I get a kick out of Don calling people willing to state that the king has no clothes are radical. The people who are not radical are the people willing to tell the half truths to keep Craig, and other JSF career dependent people, happy. On 6/21/06, Ian Roughley <[EMAIL PROTECTED]> wrote: If the goal is to separate the life cycles or to share code, then I am all for it. But I don't think the end users perception is going to be any different by this proposed change. The question is still going to be "are we going to use a JSF or action framework?" Struts is not advocating a preference (and I don't think it should) and I believe this is the confusion for most people when making a choice. /Ian Don Brown wrote: > Ted Husted wrote: >> As for making the UI tags an independant extension, a al Tiles, that >> sounds good too. (Even better if we include the "value added" Ajax >> support.) But I don't know if we want to hold back the SAF 2.0.0 to >> make it happen. But, for phase 2, sure! > Actually, I'm thinking splitting off the tags would help us get SAF > 2.0.0 out the door sooner. A lot of our remaining tickets are for > AJAX tags, which would be in this new project. As for the Tiles > comparison, that is exactly what I was going for. > > And to be clear, the tags, at least for the near term, would stay > dependent on Struts Action 2. The reason to split them off would be > to give them their own release cycle and make Struts Action 2 releases > more focused and quicker. The tags have their own group of interested > committers, so I don't see a repeat of our last spinoff attempt. :) > > Don > >> >> -Ted. >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > ----- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
That's right. The problem is the presence of any and all JSF hacks. On 6/21/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: Hi everybody! I've read this thread a couple of times, because I was having a somehow weird sentiment while doing it. Now, I think I have figured it out :-). So, please bear with me for the short following paragraphs (I am not a good writer yet): 1. even if I don't know too many details about Struts history, I somehow agree with Don's opinion that changing it to be an umbrella project may become confusing for the existing users, for new users and for users that might consider migrating to newer approaches. But... 2. this single package, solve-all idea, is something that RoR prooved to be the wrong approach. I am playing now with RoR and I frankly don't see anything in RoR over WebWork (really). But, what I am seeing behind RoR is a very simple idea: drop it in and it will help you build very quickly an web app (or at least some of them). And the single-package-solves-all is exactly the opposite. People will not be able to just drop in a couple of jars (for people knowing RoR, read it a couple of gems) with their dependency managed directly and start working on your app in a couple of seconds. It will be something like: drop this in and now let's start and think: what other piece do I need? Is it actions? Is it JSF? Is it X or Y? What dependencies should I use for X over Y? And so, we are once again gonna fail the simplicity that RoR proposed to web development (and IMO this is the sole real contribution). Convention over configuration cannot work with a big-solve-all package/framework. And this will leave the Java web apps world for another period as a "zombie in the dark". WebWork has tried to adapt to this new approach proposed by RoR. And it was nice to see it. We may have a few more ideas to make it even simpler in the near future. But this will not work with the big-solve-all approach. Indeed, this may look at the first glance as another, but opposite radical view. It is only my opinion, as a guy being involved in the Java world for 10 years and seeing everywhere people thriving to take a decission. IMO another big-all-solve-all approach will not be able to solve this problem, nor to simplify it in the future. BR, ./alex -- .w( the_mindstorm )p. On 6/21/06, Don Brown <[EMAIL PROTECTED]> wrote: > Ted Husted wrote: > > As for making the UI tags an independant extension, a al Tiles, that > > sounds good too. (Even better if we include the "value added" Ajax > > support.) But I don't know if we want to hold back the SAF 2.0.0 to > > make it happen. But, for phase 2, sure! > Actually, I'm thinking splitting off the tags would help us get SAF > 2.0.0 out the door sooner. A lot of our remaining tickets are for AJAX > tags, which would be in this new project. As for the Tiles comparison, > that is exactly what I was going for. > > And to be clear, the tags, at least for the near term, would stay > dependent on Struts Action 2. The reason to split them off would be to > give them their own release cycle and make Struts Action 2 releases more > focused and quicker. The tags have their own group of interested > committers, so I don't see a repeat of our last spinoff attempt. :) > > Don > > > > > -Ted. > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ----- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
Why in the world cannot you people see that JSF just does not fit? Is it impossible to accept the truth? Would Craig be too angry? On 6/20/06, Ted Husted <[EMAIL PROTECTED]> wrote: Yes, it would be helpful to find a good way to make JSF easier to use in a conventional Action-based application, much the same way we are trying to make Ajax easier to use in SAF2. Our first attempt (as a project) at JSF/Action integration was the Struts JSF taglib. The promise here was to migrate a Struts JSP to JSF, one page a time. It sounded good, but unfortunately, it didn't' work out as well in practice. Our second attempt is Shale. Since we couldn't find a way to integrate JSF into an Action-based framework, we erased the whiteboard and started over. While this approach seems to be working well for people ready for a clean break, it is not creating a migration path for Action-centric developers. Our third attempt at integration is the recent work that tacks JSF components onto SAF2. If this third attempt pans out in practice, and works with extensions like Clay, then, sure, we might be able to position Shale as the JSF extension to SAF2. Much like we're talking about creating an Ajax extension based on DWR or Dojo. As for making the UI tags an independant extension, a al Tiles, that sounds good too. (Even better if we include the "value added" Ajax support.) But I don't know if we want to hold back the SAF 2.0.0 to make it happen. But, for phase 2, sure! -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
I laughed when you were made a committer, Michael. That convinced me that the end was inevitable. However, this I don't find at all funny. I really would like to see Struts succeed. On 6/20/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: On 6/20/06, Don Brown <[EMAIL PROTECTED]> wrote: > As Shale and Action zero in on their first GA release, I don't think it is too > late to ask the question, "Does Struts really need two frameworks?" I bet DJ and JR are laughing their asses off. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
These are not "camps" of a framework but competing frameworks. That is the bottom line. Struts is dying and you guys, Gary, are killing it. Why not man up and get your own space and try to survive on your own? On 6/21/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: >From: "Ted Husted" <[EMAIL PROTECTED]> > > On 6/21/06, Don Brown wrote: > > Again, Struts Action and Struts Shale would both retain their separate > projects, > > codebases, and release cycles. Struts 2.0 is about building something on top > of > > our Struts efforts to create a unified front to users. Users don't care about > > all the little projects, subprojects, and libraries we have; I think they just > > want something to help them build webapps - they want Struts 2.0. And as a > > committer, PMC member and Struts user, I want it too. > > Wearing my PMC hat, I'd be surprised if that approach would well serve > the Shale community. You can dress it up anyway you want, but in the > end, this approach will have the effect of demoting Shale to an > appendage of SAF, rather than a framework in its own right. > > We like to chatter about what's best for Struts, or what Struts is, > but I think the key question is what's Shale, and what's best for > Shale? I remain concerned that, after two years on a greenfield, there > has not been a GA release of Shale. I have to wonder if keeping Shale > here is stunting the community's growth. > > We've heard from Craig, but in order to make any kind of decision, I'd > have to know how the other people working on Shale feel. > I think we could use some more Shale recruiters but I don't necessarily think that is because of lacking community support. I can think of several people that I feel have been worthy contributors but we have been very conservative. The SAF camp has recently been very active in recruiting anyone showing interest. I don't have a strong opinion either way. I remember someone saying that they have precious little time and I sympathize. Making this happen is really a team effort and you have to pick your battles. Even though I have not made the time to evaluate the latest in the action camp, I truly enjoy the exchange of ideas. If we continue to share a single community, I don't think that it is wise to force both camps into a single shoe box. On occasion we might want to get funky mixing styles but most like to play it safe, after all, it's about the right context. Gary > -Ted. > > --------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Does Struts really need two frameworks? (long)
e framework. While pieces of it may be usable outside the Action-based controller like Shale, it becomes the single place you go to solve your application development needs. The documentation would be unified and the supporting committer community in step. If you wanted the whole framework, you download Struts. If you just want one of the libraries, they are available ala carte as well. This proposed change is primarily one of message and vision, and should have minimal impact on current development activity. With the next generation of books and conferences in the works, I think it is important to develop a clear message to the Struts community and minimize any confusion. The bottom line is we want Struts to be the place to go to make web development easier, faster, with less hassles. I think this proposal provides the vision to make that happen. Don [1] http://www.oreillynet.com/onjava/blog/2006/06/isnt_rails_supposed_to_change.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: SAF2 JSF Support (was Re: Does Struts ...)
Comparing JSF to JSP, FTL, PDF, XLST is comparing apples and oranges. That is like comparing Struts to PDF. Ridiculous! On 6/21/06, Ted Husted <[EMAIL PROTECTED]> wrote: On 6/21/06, Juan Ara <[EMAIL PROTECTED]> wrote: > The point is, provide an easy way to do things with JSF in a plugable > fashion: use it or not, use it our way or not, but if you use it our > way, well... there must be any benefit! Yes, it's always been a technical problem. We accepted Shale as a Struts subproject to give Struts developers a JSF alternative. Now that we have a JSF option for SAF2, with a simple Showcase example, the next step would be to try a coherent application using SAF2 as the controller, and then mixing JSF and maybe AJAX in the view. Such an example would help clarify that notion that SAF2 can be omnibus controller. Just as we can plug PHP and JSP into Apache HTTPD, we should be able to plug JSP, FTL, JSF, PDF, XLST, and whatever else (Tapestry?) into SAF2. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SAF2 JSF Support (was Re: Does Struts ...)
Shale has come close to ruining Struts, might as well use it to finish the job. On 6/21/06, Juan Ara <[EMAIL PROTECTED]> wrote: > The reason there are both Action and Shale frameworks is because we > didn't know how to support JSF in Action. We're finally starting to > make some headway on that score. Now what do we need to do to finish > the job? > > If the job is finished, then is someone up to "showing us the code" by > driving the Shale MailReader from SAF2? > > -Ted. > I think this is a great point. Easy/centraliced way of doing things was the key to original Struts success. I think Action2 must keep that point, and JSF (nor shale nor seam nor no-framework yet) provides a way of doing things. IMHO, the original perform() method and ActionForm was the key of Struts success. Easy and centralized, a single way of doing webapps with Struts. If I do Struts, and I you do Struts, we *surely* talk the same dialect. If I do JSF and you do JSF, I'm 95% sure we won't talk *exactly* the same dialect. I can implement my managed beans in lot's of different ways. I can have events, or actions, centralized or uncentralized actions... a lot of differences between two programmers. The point is, provide an easy way to do things with JSF in a plugable fashion: use it or not, use it our way or not, but if you use it our way, well... there must be any benefit! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [action2] Combining JSF and SAF2
Of course this is what Craig wanted the whole time. Lord! And, it is what the rest of the world has been trying to avoid. Now, it comes again in the back door. Don't any committers know where the front door is? On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: In the Action 2 approach, you should be able to use any feature of Shale, or any other JSF extension, that doesn't involve a custom NavigationHandler, since that is overridden to defer to Action 2-style navigation, or a custom Lifecycle. By leaving JSF alone otherwise, you should be able to use fancy Ajax components or any other more intrusive extension that relies heavily on PhaseListeners or custom ViewHandlers. For me, Action 2 really makes JSF more palatable by remove two parts of JSF I found unnecessarily complex and tedious - navigation and required managed beans. You can still use navigation JSF components, but instead of all that navigation rule XML, you use Action 2's Results, which are simpler and more extensible. You can also still have managed beans, but since the Action is treated as one from an EL perspective, they are no longer required. Therefore, your JSF-enabled app doesn't need faces-config.xml at all. The downside is the Action 2-style navigation might not be as toolable and you lose some advantage of the tool support overall. However, from this old Struts user's perspective, I think this makes JSF much more attractive and easier to assimilate. Isn't that what you wanted, Craig, the whole time? ;) Don Craig McClanahan wrote: > On 5/21/06, Kito D. Mann <[EMAIL PROTECTED]> wrote: >> >> Congrats, Don! I'm very encouraged, and I'm anxious to check it out. >> This >> will allow SAF2 developers to work with JSF components (and the >> market is >> growing nicely). >> >> I wonder how well Shale will run in this context... > > > Don and I had a chance to chat about this idea last week at JavaOne > (glad to > see the phase listener strategy worked out so well :-). You'll want > to look > at SAF2+JSF for cases where you've got a primarily action controller > driven > application architecture, but where you want to use some really cool JSF > components here and there on your pages -- without *having* to convert > the > entire page to use components. You'll be able to do that, without > throwing > away all the rest of your architecture (but you won't be leveraging > anything > in JSF other than the components). > > If you're building an app around the JSF controller (perhaps because you > like the JSF approach to navigation, or its lifecycle), on the other > hand, > you'd be better off starting with JSF+Shale. Just to make things a > bit more > interesting, several of the Struts committers got together and talked > about > how we can share common stuff between the two frameworks ... and some > ideas > that are already on the Shale roadmap[1][2] involve support for XWork > interceptors in addition to (and probably ultimately preferred to) using > Commons Chain to decorate the overall request lifecycle. This will > likely > end up being fairly similar to what Don did in terms of being able to > customize each phase individually. I'll have more detailed comments when > I've had a chance to dig in a little deeper. > > Craig > > [1] http://issues.apache.org/struts/browse/SHALE-108 > [2] http://issues.apache.org/struts/browse/SHALE-136 > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [action2] Combining JSF and SAF2
Since Kito is committed and has been to JSF Central, why pretend that he needs to know about this. These are like those paid 1 hour commercials we have to put up with on Sunday mornings that attempt to distort the truth. Give us a break. On 5/21/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: On 5/21/06, Kito D. Mann <[EMAIL PROTECTED]> wrote: > > Congrats, Don! I'm very encouraged, and I'm anxious to check it out. This > will allow SAF2 developers to work with JSF components (and the market is > growing nicely). > > I wonder how well Shale will run in this context... Don and I had a chance to chat about this idea last week at JavaOne (glad to see the phase listener strategy worked out so well :-). You'll want to look at SAF2+JSF for cases where you've got a primarily action controller driven application architecture, but where you want to use some really cool JSF components here and there on your pages -- without *having* to convert the entire page to use components. You'll be able to do that, without throwing away all the rest of your architecture (but you won't be leveraging anything in JSF other than the components). If you're building an app around the JSF controller (perhaps because you like the JSF approach to navigation, or its lifecycle), on the other hand, you'd be better off starting with JSF+Shale. Just to make things a bit more interesting, several of the Struts committers got together and talked about how we can share common stuff between the two frameworks ... and some ideas that are already on the Shale roadmap[1][2] involve support for XWork interceptors in addition to (and probably ultimately preferred to) using Commons Chain to decorate the overall request lifecycle. This will likely end up being fairly similar to what Don did in terms of being able to customize each phase individually. I'll have more detailed comments when I've had a chance to dig in a little deeper. Craig [1] http://issues.apache.org/struts/browse/SHALE-108 [2] http://issues.apache.org/struts/browse/SHALE-136 -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [action2] Combining JSF and SAF2
Are there any figures on this market junk? Or is this more Bush-Speak, lies to get someone thinking your way? On 5/21/06, Kito D. Mann <[EMAIL PROTECTED]> wrote: Congrats, Don! I'm very encouraged, and I'm anxious to check it out. This will allow SAF2 developers to work with JSF components (and the market is growing nicely). I wonder how well Shale will run in this context... ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com - JSF/J2EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info > -Original Message- > From: Don Brown [mailto:[EMAIL PROTECTED] > Sent: Sunday, May 21, 2006 3:55 AM > To: Struts Developers List > Subject: [action2] Combining JSF and SAF2 > > After talking with several on this list about the possibility > of combining the best of JSF and Action 2 in a unified > framework from a user perspective, I have completed a first > cut at JSF support in Action > 2 with this loftly goal. > > From a user perspective, you still have one configuration > file, struts-action.xml, which maps urls to actions and > actions to results. > However, you can optionally include the JSF interceptor stack > and use the JSF result, allowing you to use JSF components in > the view. You still define alternative results the same way, > still have an action class per url, and can still use the > normal GET-style navigation. > > From a framework perspective, I split the lifecycle class > into indivudal Action 2 interceptors, one per phase. The > final render phase I turned into a Result. Upon > initialization, I replace the navigation handler with one > that simply records outcomes as if they were result codes > from an Action. Also, the setup inserts a variable resolver > that exposes the action instance to the EL bindings. > Therefore, the flow > goes: determine action/namespace -> run normal interceptors > -> run JSF phases -> invoke JSF action (optional) -> invoke > SAF2 action -> invoke render phase. The purpose of the > Action then becomes as a general setup for the page, much > like the Shale pre-render hook. > > I chose this approach because I find the Action 2 controller > stronger (JSF was always meant as a view tech, as I > understand it), so think it better suited for navigation, > state-less actions, and centralizing page setup code. JSF is > better for complex single pages or page groups where > different stateful components might be needing to submit the > page without affecting others. > > To demonstrate this integration, I added a JSF tab to the > showcase. As a sneak peek, here is the action mapping for a > JSF page that edits an > employee: > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction"> > > > > index > > > Notice the default page is the JSF page, but other navigation > is handled by traditional Action 2 results. Incidently, this > means only POSTs for real form submits and bookmarkable GETS > everywhere else. > > I'm sure there is a lot of refinement to do, but I'm hoping > this general approach will solve the very popular need to > combine the two frameworks in a seamless way for the user. > I'm particularly interested in feedback from the JSF folks, > as I'm pretty new to the framework. > > Don > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [action2] Combining JSF and SAF2
Sounds like Ted. Let me say that anyone that says web services is a half-baked CICS is really not worth listening to. That is ridiculous. I am really amazed at the nutty things said on this list. If you think that web services is coincident with SOA that is equal madness. Do you guys think these things through or just mix the newest words around the best you can figure it out? SOA is an architecture. You really have to know what you are doing to use CICS right in SOA, which is done with all the major players in this arena, even with web services. So far as I can see, you don't understand much you are talking about. I'm not at all against JSF or other solutions of any kind. What I hate is people who in order to market themselves lie and manipulate people who trust them. That is the only thing I have against JSF, the attempt to market it buy taking space where it does not belong. Anyone who brings JSF to Struts cannot be working on too much voltage. On 5/21/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: >From: "Dakota Jack" <[EMAIL PROTECTED]> > > Of course you aren't, Gary, because my panties are not in a bunch. > You are the one with his panties in a bunch because you are here for > JSF and JSF alone anyway and you don't like me having pointed out that > your contributions did not merit your status. You can side with > Kamini if you like, but she is the one of the real trolls on this > list. You just don't like what I say. If you have trouble with me > because of what I say, then you have black and white thinking. If you > like what people like Kamini say, then you are just beyond interest. > No, I don't care about that. I think that Clay is a pretty fun trick and might make folks think about alternatives to using the JSP JSF technology. It's not the best or only solution either. Facelets is another very interesting solution. In many aspects superior to Clay. I had a chance to talk with Howard Lewis Ship last week about new features in Tapestry. I also talked with Jacob Hookem about Facelets. I was honored that they would take the time to share their ideas with me. But, really, there might be something to be learned with Don's proposal. It's really easy to get caught up in the merits of technology but the question is, will people be able to better automate there business? At JavaOne 2006, Sun announces VB that will run under the java VM. Now, that's not my cup-of-tea but I bet that it will be a big hit in the business world. So, is finding ways to use Struts action and Struts Shale really that big of a deal? I also had a chance to attend Scott Ambler's session on Agile Modeling last week. He had a funny comment about how he had seen a lot of reinvention of the wheel in regards to web services. He said something like, it was a half bake retooling of CICS. I've often thought of SOA that way too and kind of thought that at some level the whole JavaSpaces and BEPL was similar to JCL. There was also a session on AJAX/SOA and Web 2.0 that they discussed the re branding of these technologies. I guess that my point is that we will always be looking for better ways to solve our problems in a smaller window of time using spins on the same technology and at the same time, trying to leverage existing investments. This is in a market that doesn't always value the people that have the knowledge of their business or the people that automate the business using technologies. So, what have you done for me lately? Well, not only the Struts and other apache communities but Commercial vendors contribute their time and ideas and are trying to make their products better by using open source as the vehicle. I attended a session on "project tango". Oh my, first class interoperability between java and .Net. This is "Human sacrifice, dogs and cats, living together... mass hysteria!". Yet, it's hard for you to understand why two java web frameworks would want to achieve interoperability. "Which pill would you take, the red or the blue?". "I don't know if we each have a destiny, or if we're all just floatin' around accidental-like on a breeze. I think maybe it's both." But, "That's all I have to say about that." Gary > On 5/21/06, Gary VanMatre wrote: > > >From: "Dakota Jack" > > > > > > You are right, for once. I only speak for myself. Those who are > > > unwilling to listen to others are condemned by their own choice to a > > > life of ignorance. > > > > > > > Sheese, sorry this got your panties in a bunch. > > > > > > > On 5/21/06, Kimani Darisha wrote: > > > > To anyone following these thread, please ignore this fool. He does > > > > not speak for anyone, and is only here to
Re: [action2] Combining JSF and SAF2
Of course you aren't, Gary, because my panties are not in a bunch. You are the one with his panties in a bunch because you are here for JSF and JSF alone anyway and you don't like me having pointed out that your contributions did not merit your status. You can side with Kamini if you like, but she is the one of the real trolls on this list. You just don't like what I say. If you have trouble with me because of what I say, then you have black and white thinking. If you like what people like Kamini say, then you are just beyond interest. On 5/21/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: >From: "Dakota Jack" <[EMAIL PROTECTED]> > > You are right, for once. I only speak for myself. Those who are > unwilling to listen to others are condemned by their own choice to a > life of ignorance. > Sheese, sorry this got your panties in a bunch. > On 5/21/06, Kimani Darisha wrote: > > To anyone following these thread, please ignore this fool. He does > > not speak for anyone, and is only here to confuse people. > > > > K. > > > > On 5/21/06, Dakota Jack wrote: > > > I have seen no "very popular need". This is like Bush-Speak. Baloney > > > parading as truth. > > > > > > On 5/21/06, Don Brown wrote: > > > > > > > > After talking with several on this list about the possibility of > > > > combining the best of JSF and Action 2 in a unified framework from a > > > > user perspective, I have completed a first cut at JSF support in Action > > > > 2 with this loftly goal. > > > > > > > > From a user perspective, you still have one configuration file, > > > > struts-action.xml, which maps urls to actions and actions to results. > > > > However, you can optionally include the JSF interceptor stack and use > > > > the JSF result, allowing you to use JSF components in the view. You > > > > still define alternative results the same way, still have an action > > > > class per url, and can still use the normal GET-style navigation. > > > > > > > > From a framework perspective, I split the lifecycle class into > > > > indivudal Action 2 interceptors, one per phase. The final render phase > > > > I turned into a Result. Upon initialization, I replace the navigation > > > > handler with one that simply records outcomes as if they were result > > > > codes from an Action. Also, the setup inserts a variable resolver that > > > > exposes the action instance to the EL bindings. Therefore, the flow > > > > goes: determine action/namespace -> run normal interceptors -> run JSF > > > > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke > > > > render phase. The purpose of the Action then becomes as a general setup > > > > for the page, much like the Shale pre-render hook. > > > > > > > > I chose this approach because I find the Action 2 controller stronger > > > > (JSF was always meant as a view tech, as I understand it), so think it > > > > better suited for navigation, state-less actions, and centralizing page > > > > setup code. JSF is better for complex single pages or page groups where > > > > different stateful components might be needing to submit the page > > > > without affecting others. > > > > > > > > To demonstrate this integration, I added a JSF tab to the showcase. As > > > > a sneak peek, here is the action mapping for a JSF page that edits an > > > > employee: > > > > > > > > > > > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction"> > > > > > > > > > > > > > > > > index > > > > > > > > > > > > Notice the default page is the JSF page, but other navigation is handled > > > > by traditional Action 2 results. Incidently, this means only POSTs for > > > > real form submits and bookmarkable GETS everywhere else. > > > > > > > > I'm sure there is a lot of refinement to do, but I'm hoping this general > > > > approach will solve the very popular need to combine the two frameworks > > > > in a seamless way for the user. I'm particularly interested in feedback > > > > from the JSF folks, as I'm pretty new to the framework. > > > > > > > > Don > > > > > > > > ------
Re: [action2] Combining JSF and SAF2
You are right, for once. I only speak for myself. Those who are unwilling to listen to others are condemned by their own choice to a life of ignorance. On 5/21/06, Kimani Darisha <[EMAIL PROTECTED]> wrote: To anyone following these thread, please ignore this fool. He does not speak for anyone, and is only here to confuse people. K. On 5/21/06, Dakota Jack <[EMAIL PROTECTED]> wrote: > I have seen no "very popular need". This is like Bush-Speak. Baloney > parading as truth. > > On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > > After talking with several on this list about the possibility of > > combining the best of JSF and Action 2 in a unified framework from a > > user perspective, I have completed a first cut at JSF support in Action > > 2 with this loftly goal. > > > > From a user perspective, you still have one configuration file, > > struts-action.xml, which maps urls to actions and actions to results. > > However, you can optionally include the JSF interceptor stack and use > > the JSF result, allowing you to use JSF components in the view. You > > still define alternative results the same way, still have an action > > class per url, and can still use the normal GET-style navigation. > > > > From a framework perspective, I split the lifecycle class into > > indivudal Action 2 interceptors, one per phase. The final render phase > > I turned into a Result. Upon initialization, I replace the navigation > > handler with one that simply records outcomes as if they were result > > codes from an Action. Also, the setup inserts a variable resolver that > > exposes the action instance to the EL bindings. Therefore, the flow > > goes: determine action/namespace -> run normal interceptors -> run JSF > > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke > > render phase. The purpose of the Action then becomes as a general setup > > for the page, much like the Shale pre-render hook. > > > > I chose this approach because I find the Action 2 controller stronger > > (JSF was always meant as a view tech, as I understand it), so think it > > better suited for navigation, state-less actions, and centralizing page > > setup code. JSF is better for complex single pages or page groups where > > different stateful components might be needing to submit the page > > without affecting others. > > > > To demonstrate this integration, I added a JSF tab to the showcase. As > > a sneak peek, here is the action mapping for a JSF page that edits an > > employee: > > > > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction"> > > > > > > > > index > > > > > > Notice the default page is the JSF page, but other navigation is handled > > by traditional Action 2 results. Incidently, this means only POSTs for > > real form submits and bookmarkable GETS everywhere else. > > > > I'm sure there is a lot of refinement to do, but I'm hoping this general > > approach will solve the very popular need to combine the two frameworks > > in a seamless way for the user. I'm particularly interested in feedback > > from the JSF folks, as I'm pretty new to the framework. > > > > Don > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > "You can lead a horse to water but you cannot make it float on its back." > ~Dakota Jack~ > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
This post shows who the limited person is. It is you, Ma'am. On 5/21/06, Kimani Darisha <[EMAIL PROTECTED]> wrote: Oh wonderful, more comments from the list idiot. K. On 5/21/06, Dakota Jack <[EMAIL PROTECTED]> wrote: > Who wants these frameworks combined? This is what has been killing Struts. > This is anything but a lofty goal. It is architectural suicide. There is > Shale, which could not really do this. Why is that not enough or in fact > way too much? This is ridiculous. I hope people on this list see this > effort for what it is. > > On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: > > > > After talking with several on this list about the possibility of > > combining the best of JSF and Action 2 in a unified framework from a > > user perspective, I have completed a first cut at JSF support in Action > > 2 with this loftly goal. > > > > From a user perspective, you still have one configuration file, > > struts-action.xml, which maps urls to actions and actions to results. > > However, you can optionally include the JSF interceptor stack and use > > the JSF result, allowing you to use JSF components in the view. You > > still define alternative results the same way, still have an action > > class per url, and can still use the normal GET-style navigation. > > > > From a framework perspective, I split the lifecycle class into > > indivudal Action 2 interceptors, one per phase. The final render phase > > I turned into a Result. Upon initialization, I replace the navigation > > handler with one that simply records outcomes as if they were result > > codes from an Action. Also, the setup inserts a variable resolver that > > exposes the action instance to the EL bindings. Therefore, the flow > > goes: determine action/namespace -> run normal interceptors -> run JSF > > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke > > render phase. The purpose of the Action then becomes as a general setup > > for the page, much like the Shale pre-render hook. > > > > I chose this approach because I find the Action 2 controller stronger > > (JSF was always meant as a view tech, as I understand it), so think it > > better suited for navigation, state-less actions, and centralizing page > > setup code. JSF is better for complex single pages or page groups where > > different stateful components might be needing to submit the page > > without affecting others. > > > > To demonstrate this integration, I added a JSF tab to the showcase. As > > a sneak peek, here is the action mapping for a JSF page that edits an > > employee: > > > > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction"> > > > > > > > > index > > > > > > Notice the default page is the JSF page, but other navigation is handled > > by traditional Action 2 results. Incidently, this means only POSTs for > > real form submits and bookmarkable GETS everywhere else. > > > > I'm sure there is a lot of refinement to do, but I'm hoping this general > > approach will solve the very popular need to combine the two frameworks > > in a seamless way for the user. I'm particularly interested in feedback > > from the JSF folks, as I'm pretty new to the framework. > > > > Don > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > "You can lead a horse to water but you cannot make it float on its back." > ~Dakota Jack~ > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
I have seen no "very popular need". This is like Bush-Speak. Baloney parading as truth. On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: After talking with several on this list about the possibility of combining the best of JSF and Action 2 in a unified framework from a user perspective, I have completed a first cut at JSF support in Action 2 with this loftly goal. From a user perspective, you still have one configuration file, struts-action.xml, which maps urls to actions and actions to results. However, you can optionally include the JSF interceptor stack and use the JSF result, allowing you to use JSF components in the view. You still define alternative results the same way, still have an action class per url, and can still use the normal GET-style navigation. From a framework perspective, I split the lifecycle class into indivudal Action 2 interceptors, one per phase. The final render phase I turned into a Result. Upon initialization, I replace the navigation handler with one that simply records outcomes as if they were result codes from an Action. Also, the setup inserts a variable resolver that exposes the action instance to the EL bindings. Therefore, the flow goes: determine action/namespace -> run normal interceptors -> run JSF phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke render phase. The purpose of the Action then becomes as a general setup for the page, much like the Shale pre-render hook. I chose this approach because I find the Action 2 controller stronger (JSF was always meant as a view tech, as I understand it), so think it better suited for navigation, state-less actions, and centralizing page setup code. JSF is better for complex single pages or page groups where different stateful components might be needing to submit the page without affecting others. To demonstrate this integration, I added a JSF tab to the showcase. As a sneak peek, here is the action mapping for a JSF page that edits an employee: index Notice the default page is the JSF page, but other navigation is handled by traditional Action 2 results. Incidently, this means only POSTs for real form submits and bookmarkable GETS everywhere else. I'm sure there is a lot of refinement to do, but I'm hoping this general approach will solve the very popular need to combine the two frameworks in a seamless way for the user. I'm particularly interested in feedback from the JSF folks, as I'm pretty new to the framework. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [action2] Combining JSF and SAF2
Who wants these frameworks combined? This is what has been killing Struts. This is anything but a lofty goal. It is architectural suicide. There is Shale, which could not really do this. Why is that not enough or in fact way too much? This is ridiculous. I hope people on this list see this effort for what it is. On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote: After talking with several on this list about the possibility of combining the best of JSF and Action 2 in a unified framework from a user perspective, I have completed a first cut at JSF support in Action 2 with this loftly goal. From a user perspective, you still have one configuration file, struts-action.xml, which maps urls to actions and actions to results. However, you can optionally include the JSF interceptor stack and use the JSF result, allowing you to use JSF components in the view. You still define alternative results the same way, still have an action class per url, and can still use the normal GET-style navigation. From a framework perspective, I split the lifecycle class into indivudal Action 2 interceptors, one per phase. The final render phase I turned into a Result. Upon initialization, I replace the navigation handler with one that simply records outcomes as if they were result codes from an Action. Also, the setup inserts a variable resolver that exposes the action instance to the EL bindings. Therefore, the flow goes: determine action/namespace -> run normal interceptors -> run JSF phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke render phase. The purpose of the Action then becomes as a general setup for the page, much like the Shale pre-render hook. I chose this approach because I find the Action 2 controller stronger (JSF was always meant as a view tech, as I understand it), so think it better suited for navigation, state-less actions, and centralizing page setup code. JSF is better for complex single pages or page groups where different stateful components might be needing to submit the page without affecting others. To demonstrate this integration, I added a JSF tab to the showcase. As a sneak peek, here is the action mapping for a JSF page that edits an employee: index Notice the default page is the JSF page, but other navigation is handled by traditional Action 2 results. Incidently, this means only POSTs for real form submits and bookmarkable GETS everywhere else. I'm sure there is a lot of refinement to do, but I'm hoping this general approach will solve the very popular need to combine the two frameworks in a seamless way for the user. I'm particularly interested in feedback from the JSF folks, as I'm pretty new to the framework. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [action][Proposal] Architecture plan for Struts Action 2.0
I am a bit surprised that this was not all pretty well worked out in detail before the merger. Why not first take the time to see what will need to be done and what the result will look like before deciding to do it? That should not be a daunting task. A list of what the result will take and what the result will look like would be worth having before taking a vote on this. To just a make a decision and to start coding blindly before knowing what the parameters of the situation are would be just to return to past "throw it against the wall and see what sticks" sort of decision making. The continuing introduction of "Ti" into these conversations is confusing to me. I am not sure what Ted means by that. I know Ted and I know it is an agenda for sure, but I don't know what that agenda is. I also don't see the arguments (reasons) for evolution now revolution later decisions. Are there any that have been gathered, arranged, collated, etc? This all seems a bit out of control and not well-planned. These sorts of discussion, by the way, have nothing to do with "architecture". On 5/7/06, Ted Husted <[EMAIL PROTECTED]> wrote: On 5/6/06, Bob Lee <[EMAIL PROTECTED]> wrote: > The new API should be simpler, cleaner, better separated from the > implementation, more intuitive, and better organized. If you > understand WW2, you'll have no problem understanding the new API. If > you haven't learned WW2 yet, it will be easier to learn the new API > than WW2. All of which seems to imply that the "new API" might be the equivalent of WW 3. We've always planned to consider signficant API changes for "SAF 2.0 Next" as Ti Phase 2, but we need to set modest, achievable expectations for SAF 2.0 (aka WW 2.3). The first phase is an evolutionary transition. The second phase is meant to be revolutionary. Of course, without code on the table, it's too soon to say yes, no, or maybe. No matter what anyone plans to do, the implementation has to pass muster. The most anyone here can say is "Looks cool, show us the code" or "Here's the code, how do you like it?". -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Dear trolls...
This is silly, whomever you are. On 5/3/06, netsql <[EMAIL PROTECTED]> wrote: "and that is why you will kill me last"? :-0 .V Dakota Jack wrote: > > At least you are civil. That part is good. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dear trolls...
Thanks for this advice. No one has ever mentioned this before. I remamber someone else talking about code like itches and scratches. I think that has been repeated so many times the itch must be confused with a tickle. If you like this idea, go at it. Obviously suggesting what someone else should like to do is really stupid. I think other people can find their own course. Now if you had something to actually say about an issue someone cared about, that would help. At least you are civil. That part is good. On 5/2/06, netsql <[EMAIL PROTECTED]> wrote: If there is an itch for anyone, they can easily go to sf.net, pick a license they like, and implement an enlightened design. I believe that even if they want to check out any source of Struts module, and refactor it under ASF license, that is legal too. It it's not an itch, then it must not be important to anyone. hth, .V Dakota Jack wrote: > What is amazing to me is that the people who are called "trolls" are > only those in some way contrary to the status quo. Others in favor of > the status quo who do nothing but use invective and display 10 year > old conduct are never mentioned. > They are used by the powers that be to attack without any > point dissidents. This is really an open source Gulag Apache. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dear trolls...
What is amazing to me is that the people who are called "trolls" are only those in some way contrary to the status quo. Others in favor of the status quo who do nothing but use invective and display 10 year old conduct are never mentioned. The worst they get is a little slap from Ted saying "Don't do that in my name", for which he deserves some respect. The truth, however, is that they are the only real trolls on this list. They are used by the powers that be to attack without any point dissidents. This is really an open source Gulag Apache. On 5/1/06, Paul Speed <[EMAIL PROTECTED]> wrote: Jonathan Revusky wrote: > Paul Speed wrote: >> >> Of course, there is a difference between polite discourse and >> trolling. I think we all know who the real trolls are and I think the >> term has been leveled a little heavy-handed lately. I think the >> bottom line is that if someone doesn't use the product, doesn't like >> the product, doesn't like any of the people who work on the product, >> frequently finds themselves always disagreeing with everyone else on >> the list then maybe it is time for them to find another place to argue. > > Well, I think the above begs the question. In terms of certain comments > I have made, and questions I have posed, look, we all know that *only* > an outsider to this project would ever say those things. This is > particularly true in situations where the insiders are largely chosen on > the basis of them being people who won't rock the boat. > > So, I mean to say, that if an insider won't say certain things (because > they just won't) and an outsider is not supposed to say certain things > (because it's somehow improper) you're basically saying that *nobody* > should say certain things. > > IOW, nobody should make certain pointed comments or ask certain hard > questions. > > BUT... if the questions and comments are legitimate, it seems that they > should not be off-limits, they should be asked. By somebody > > Now, OTOH, if your position is that certain comments or questions are > illegitimate, you should be able to explain why. But that should be > independent of who is making the comment or asking the question... > My position is that there is a difference between discussing a topic and being blatently insulting. Certain people tend to use a sort of style that implies that to disagree with them automatically means that you are stupid... and follow it up with some sort of twisted proof by induction that you are stupid because you don't agree with them. For example, I could have answered that way (politely) or the following way which is how one frequent poster who keeps threatening to leave tends to approach a discussion. Example of bad manners version of response, do not adopt this style: ;) "Obviously I didn't mean what you say. Anyone with a half a brain can see that there is a difference between polite discourse and trolling." Note: no real argument content added. Blatently "superior" attitude. Implied assumption that simply stating that a different point of view is stupid means that it requires no additional discussion. Read useless responses like that about 50 times and it really starts to grate. -Paul ----- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dear trolls...
LIke Pogo, Warner, you are the troll. On 4/27/06, Daniel Warner <[EMAIL PROTECTED]> wrote: > > I am sorry to have bothered you, Patrick. I am well aware of who they > are and how they work. I knew what would happen when I responded; > ignorance is not my problem. I just couldn't resist. Bad > self-control day. This happens when things get slow around my office. > I was just having a little fun and hoping the productive people on > the list would skip the posts and ignore them. I probably should have > prefixed them with [friday] or something. I really did not mean to > entice one of you to respond! I will let the cute little trolls > starve from here on out. > > Daniel Warner, > generic lurker and ex-troll feeder > > On 4/27/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote: > > Dear trolls, > > Please go. Or at least try to form your rambling in to some sort of > actionable suggestion. But don't just bitch for the sake of knowing that > people are reading, because... > > > > Dear everyone else, > > Please stop reading or replying to the trolls. Seriously. You guys are > just as bad for feeding the trolls. Ignoring them is the fastest way to make > them go away. I have not and will not entertain them with any sort of > response. I suggest you do the same. > > - > > Posted via Jive Forums > > > http://forums.opensymphony.com/thread.jspa?threadID=28320&messageID=55091#55091 > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Tea Time with the Trolls (Was: Re: Proposal for change)
I really have to disagree with this Jonathan. I don't think Warner has the mettle to be sarcastic. Maybe sardonic at best; not sarcastic. On 4/27/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote: > > Daniel Warner wrote: > > I know you're being sarcastic, but in your attempts at sarcasm, you > actually have a point. All the rhetoric about the "Apache Way" is not > useful or productive. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Proposal for change
Jonathan has the patience of a saint in answering people like you. I don't. I am not 10 years old and have no interest in this sort of discussion. Grow up! On 4/27/06, Daniel Warner <[EMAIL PROTECTED]> wrote: > > Please forgive me for feeding the trolls and wasting bandwidth. I > know, it makes me no better than they are and this apology is > meaningless since I am going to keep doing it for a little while. > but they are just such cute little trolls with those adorable > nicknames and tiny perspectives! Seriously, how can you expect anyone > to resist those?! :) > > Besides, it is a slow morning for me, and I do not feel like just > lurking as usual. :) I will understand if you all think less of me > for this utterly juvenile email. I think less of me too. Today is > not a good self-control day. :( > > On 4/27/06, Dakota Jack <[EMAIL PROTECTED]> wrote: > > People do not do "work" around here because it is not rewarded. > > The people who are rewarded are political. Then they do the work and > the > > work looks like coding by politicians. > > Congratulations, that is the stupidest thing I have heard all week! > You should be rewarded for being so political! Or did you not know > that playing the opposition means you are a politician too? > > > I can remember going into the > > file upload section and seeing one of the worst messes I have ever > > seen in an open source project. There are hanging references and > > other monstrosities that I had only seen community college class > > assignments prior to looking at Struts code. I could not even discuss > > the code much less have any hope of helping, because the committers > > use this for their work and are not amenable to good code but rather > > to code that advances their careers. > > Then why are you here? Why do you care if not because you love the > politics? Admit it, you are just jealous that you are not on the > Struts PMC. Come on, a little self-awareness will not hurt. I > promise. > > > If you think that Jonathan or I have nothing to contribute, you are > > sadly mistaken. > > Awesome! I love being called "sadly mistaken". That is so witty and > eloquent! Now if only i could be called that by a truly famous troll > like Mr. Revusky (there's a little ego stroke for you, JR), my life > would be complete. > > But anyway, it is nice of you to "read my mind" and all, but all I was > trying to communicate was that Jonathan and myself had not done any of > the work around here. I did not say anything about you or anyone's > ability to contribute. (Though I think it is cute that you wanted to > be in on the action. :) > > > We are quite aware of the nature of this beast. You > > really need to pay attention to what is going on. There is nothing > > like a meritocracy around here. > > (In unworthy imitation of the inimitable Bill Cosby) ..right. > > > How do you think that Struts 1.x > > managed to become a plate of spaghetti after such a fine start? > > Well, I do not think that. I know that seems odd to you, but I > actually lurk on this list because I think Struts 1.x was a decently > constructed ham and cheese sandwich. I am also excited to see it > turning into a delicious BLT with the introduction of WebWork as SAF > 2. > > > Mertiocracy does not mean just work, by the way. It means work with > > merit. This not sold as a "docracy" or "actcracy". > > This is the second stupidest thing I have heard all week. Thank you > for sharing! > > > Get a clue. > > A clue? Like the board game? I love board games! Would you like to > play a game of "Sorry"? CandyLand is fun too. > > Daniel Warner, > lead time waster and troll feeder > (for today only, I promise I will go back to lurking tomorrow!) > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Proposal for change
People do not do "work" around here because it is not rewarded. The people who are rewarded are political. Then they do the work and the work looks like coding by politicians. I can remember going into the file upload section and seeing one of the worst messes I have ever seen in an open source project. There are hanging references and other monstrosities that I had only seen community college class assignments prior to looking at Struts code. I could not even discuss the code much less have any hope of helping, because the committers use this for their work and are not amenable to good code but rather to code that advances their careers. If you think that Jonathan or I have nothing to contribute, you are sadly mistaken. We are quite aware of the nature of this beast. You really need to pay attention to what is going on. There is nothing like a meritocracy around here. How do you think that Struts 1.x managed to become a plate of spaghetti after such a fine start? Mertiocracy does not mean just work, by the way. It means work with merit. This not sold as a "docracy" or "actcracy". Get a clue. On 4/27/06, Daniel Warner <[EMAIL PROTECTED]> wrote: > > The only principle I see is the principle of incumbency or tenure. > > That's a problem with your vision. There are plenty of reasons: > > 1) it's more about doing the work than doing the work "better". > 2) SAF 2/WebWork is still in incubation. It's not even actually part > of Struts yet. > 3) The Struts PMC currently oversees Shale, Tiles, and SAF 1. WebWork > is not the only project here. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for change
What is stupid or assinine is to suggest that the problem is that I cannot count. That is typical of you snipers. You do everything to avoid the real issues. Look at the entries for Reddin and look at the entries for other people. In my opinion you have to be addled not to see that he is brought on for Shale and not for Struts. On 4/25/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > > On 4/25/06, Dakota Jack <[EMAIL PROTECTED]> wrote: > > > > This is the kind of stupid, assinine comment > > > What is stupid or assinine about pointing out that your count is > incorrect? > It *is* incorrect. You counted 4 posts to the dev list. To quote you > directly: > > "I count four (4) posts to the dev list in Greg Reddin's history" > > I provided a URL which demonstrates that that statement is incorrect. > > -- > Martin Cooper > > > that is really what trolling is > > all about. There are clearly more than I found by doing a general search > > for > > Redding. Try doing one for Frank and see what happens, Martin. I > really > > could vomit when I hear that feminine English "pity". > > > > On 4/25/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > > > > > > On 4/25/06, Dakota Jack <[EMAIL PROTECTED]> wrote: > > > > > > > > Here is a case in point: I count four (4) posts to the dev list in > > Greg > > > > Reddin's history. > > > > > > > > > Pity you can't count. > > > > > > http://marc.theaimsgroup.com/?w=2&r=1&s=greg.reddin&q=a > > > > > > -- > > > Martin Cooper > > > > > > > > > He is a committer. On the user list there is also > > > > virtually nothing. What stands out is that he was interested in a > > > couple > > > > of > > > > posts in Shale. What is the possible reason he is a committer and > > Frank > > > > is > > > > not? Is this the Way Different Struts-Apache Way. This is > crazy! Do > > > > people actually believe Ted and Craig? > > > > > > > > On 4/25/06, Greg Reddin <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > On Apr 25, 2006, at 9:55 AM, Frank W. Zammetti wrote: > > > > > > > > > > > That depends entirely on your meaning of the word "closed". You > > > > > > make the > > > > > > argument that the number of new committers means it isn't > closed, > > > > > > and I > > > > > > agree with you to a degree. But that's not the only meaning of > > > > > > "closed"... the invitations to those people came *soley* from > the > > > PMC > > > > > > AFAIK... the community had no say in it. That's the thing my > > > proposal > > > > > > seeks to address, that the initiation of someone being invited > > > doesn't > > > > > > necessarily have to come from those already there (although they > > > would > > > > > > still have the final say-so). > > > > > > > > > > I have some serious concerns about this. Let me just use myself > as > > > > > an example. I've been a committer for about 6 months or so. I > have > > > > > absolutely no idea what sort of discussion took place before I > > > > > received that invitation. If there was someone among the PMC who > > was > > > > > vehemently opposed to my nomination I'm glad they had a > confidential > > > > > forum in which to discuss their concerns. Now that I am a > committer > > > > > I can have an unbiased conversation with anybody else in the group > > > > > without any preconceived notion of what that individual's opinion > of > > > > > me might be. Truly, I don't have confidence that either user@ or > > > > > dev@ is a place where concerns can be expressed openly without > fear > > > > > of unprofessional response. It's just too easy for this kind of > > > > > discussion to turn into personal attacks in a forum such as user@ > or > > > > > even [EMAIL PROTECTED] > > > > > > > > > > When Struts was a Jakarta subproject I remember committer votes > > > > > taking place on [EMAIL PROTECTED] I always felt just a little uneasy > > > > > about > i
Re: Agitator Licenses for Struts Committers
Do you ever discuss the issues Mitchell? Struts is in large part a quagmire due to an attempt to give the branding to JSF for Craig via Shale. No one not in the long term know or even in the long term know can now see what the future is. No code On 4/25/06, James Mitchell <[EMAIL PROTECTED]> wrote: > > Yep, I agree. You wouldn't believe the commission percentage that > Craig gets whenever he sells a free copy of Java Studio Creator. I'm > impressed that you noticed that toowow. > > -- > James Mitchell > > > > > On Apr 25, 2006, at 7:50 AM, Dakota Jack wrote: > > > There is a big difference between having an open source project > > that is used > > for business and using your position on the list to promote your > > business > > ideas on the list. How about we begin selling our sites on this > > list? If > > you cannot see the difference in this, then you just are not being > > honest or > > you are not to bright. I think Ted sees exactly the point. > > Reducing this > > to the TV idiocy is just as bad as the usual claim that Struts is just > > another Apache list, which it is not. > > > > On 4/25/06, Ted Husted <[EMAIL PROTECTED]> wrote: > >> > >> On 4/25/06, James Mitchell <[EMAIL PROTECTED]> wrote: > >>> Ok, let's review shall we. > >>> > >>>>> ... for our committers to use on open source projects... > >>>>> > >>> > >>> What part of that says anything about personal gain? > >> > >> I seem to remember the term "personal gain" from the TV series > >> "Charmed', but I for one am not a witch :) > >> > >> The Apache License is designed to be business friendly. We expect and > >> encourage commercial uses of our products. As a result, it's not > >> uncommon for vendors of retail products to want to give back to open > >> source projects. > >> > >> Another good example is JetBrains, which provides complementantry > >> IDEA > >> licenses to many open source projects, including the ASF. > >> > >> Of course, these licenses usually come with the stipulation that the > >> license is only to be used when working on open source projects. The > >> licenses are not for our personal use, but to help us with the > >> volunteer work we do for the foundation. > >> > >> -Ted. > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > "You can lead a horse to water but you cannot make it float on its > > back." > > ~Dakota Jack~ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Agitator Licenses for Struts Committers
This is crap. Read the record. Do you guys even care if you make sense? On 4/25/06, James Mitchell <[EMAIL PROTECTED]> wrote: > > You're welcome to advertise any product you like. Please prefix it > with [Announce] or [Ann], but that's not required. Do you have a > product you'd like to sell? > > -- > James Mitchell > > > > > On Apr 25, 2006, at 7:51 AM, Dakota Jack wrote: > > > We can advertise our wares here? I did not know that. I thought > > this list > > was about Struts and not about Ted's business. But, excuse me. I > > should > > have known that Craig was not the exception in using the list that > > way. > > > > On 4/25/06, James Mitchell <[EMAIL PROTECTED]> wrote: > >> > >> Ok, let's review shall we. > >> > >>>> ... for our committers to use on open source projects... > >>>> > >> > >> What part of that says anything about personal gain? > >> > >> > >> -- > >> James Mitchell > >> > >> > >> > >> > >> On Apr 25, 2006, at 12:50 AM, Dakota Jack wrote: > >> > >>> Isn't this using the committer status for personal gain? > >>> > >>> On 4/23/06, Ted Husted <[EMAIL PROTECTED]> wrote: > >>>> > >>>> Agitar Software (http://www.agitar.com/) has donated several > >>>> licenses > >>>> for its Agitator product to Apache Struts for our committers to > >>>> use > >>>> on open source projects. The Agitator includes "experts" that > >>>> help it > >>>> work better with frameworks like Struts Action. Right now, the > >>>> Agitator "Struts Expert" supports Action 1.2. Experts for other > >>>> releases of Apache Struts frameworks are expected. I'm working with > >>>> Agitar to make the Expert API available to us, so that we can > >>>> create > >>>> and maintain our own experts. > >>>> > >>>> A whitepaper that describes using the Agitator to test the > >>>> MailReader > >>>> is available here: > >>>> > >>>> * http://www.StrutsUniversity.org/Agitator > >>>> > >>>> And I'll be giving the whitepaper as a "webinar" on Wednesday. > >>>> > >>>> * http://www.planetstruts.org/roller/page/news? > >>>> entry=what_to_do_if_your > >>>> > >>>> Apache Struts committers can find the list of product keys in > >>>> the ASF > >>>> repository. > >>>> > >>>> * > >>>> https://svn.apache.org/repos/private/committers/pmc/struts/ > >>>> agitator-keys.txt > >>>> > >>>> Access to this file is resticted to Struts committers. > >>>> > >>>> -Ted. > >>>> > >>>> --- > >>>> -- > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>> > >>> > >>> -- > >>> "You can lead a horse to water but you cannot make it float on its > >>> back." > >>> ~Dakota Jack~ > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > "You can lead a horse to water but you cannot make it float on its > > back." > > ~Dakota Jack~ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Proposal for change
Also, by the way, it is mostly about getting tiles to shale, etc, and clearly is not based on Struts. On 4/25/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > > On 4/25/06, Dakota Jack <[EMAIL PROTECTED]> wrote: > > > > Here is a case in point: I count four (4) posts to the dev list in Greg > > Reddin's history. > > > Pity you can't count. > > http://marc.theaimsgroup.com/?w=2&r=1&s=greg.reddin&q=a > > -- > Martin Cooper > > > He is a committer. On the user list there is also > > virtually nothing. What stands out is that he was interested in a > couple > > of > > posts in Shale. What is the possible reason he is a committer and Frank > > is > > not? Is this the Way Different Struts-Apache Way. This is crazy! Do > > people actually believe Ted and Craig? > > > > On 4/25/06, Greg Reddin <[EMAIL PROTECTED]> wrote: > > > > > > > > > On Apr 25, 2006, at 9:55 AM, Frank W. Zammetti wrote: > > > > > > > That depends entirely on your meaning of the word "closed". You > > > > make the > > > > argument that the number of new committers means it isn't closed, > > > > and I > > > > agree with you to a degree. But that's not the only meaning of > > > > "closed"... the invitations to those people came *soley* from the > PMC > > > > AFAIK... the community had no say in it. That's the thing my > proposal > > > > seeks to address, that the initiation of someone being invited > doesn't > > > > necessarily have to come from those already there (although they > would > > > > still have the final say-so). > > > > > > I have some serious concerns about this. Let me just use myself as > > > an example. I've been a committer for about 6 months or so. I have > > > absolutely no idea what sort of discussion took place before I > > > received that invitation. If there was someone among the PMC who was > > > vehemently opposed to my nomination I'm glad they had a confidential > > > forum in which to discuss their concerns. Now that I am a committer > > > I can have an unbiased conversation with anybody else in the group > > > without any preconceived notion of what that individual's opinion of > > > me might be. Truly, I don't have confidence that either user@ or > > > dev@ is a place where concerns can be expressed openly without fear > > > of unprofessional response. It's just too easy for this kind of > > > discussion to turn into personal attacks in a forum such as user@ or > > > even [EMAIL PROTECTED] > > > > > > When Struts was a Jakarta subproject I remember committer votes > > > taking place on [EMAIL PROTECTED] I always felt just a little uneasy > > > about it. > > > 99 times out of 100 it was a unanimous +1 with no discussion. But I > > > seem to recall at least one case when concerns were expressed (sorry, > > > I don't remember the specifics, please correct me if I'm wrong). I > > > feel really bad that this person's personal merit would have to be > > > discussed in a public forum. I understand some others' concerns > > > about the community appearing to be closed, but I think there should > > > be a barrier to entry. Maybe it's too high, but it seems to me that > > > it should exist. After all it's basically a lifetime appointment and > > > revocations are very rare if one has ever happened at all. > > > > > > Greg > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > "You can lead a horse to water but you cannot make it float on its > back." > > ~Dakota Jack~ > > > > > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Proposal for change
This is the kind of stupid, assinine comment that is really what trolling is all about. There are clearly more than I found by doing a general search for Redding. Try doing one for Frank and see what happens, Martin. I really could vomit when I hear that feminine English "pity". On 4/25/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > > On 4/25/06, Dakota Jack <[EMAIL PROTECTED]> wrote: > > > > Here is a case in point: I count four (4) posts to the dev list in Greg > > Reddin's history. > > > Pity you can't count. > > http://marc.theaimsgroup.com/?w=2&r=1&s=greg.reddin&q=a > > -- > Martin Cooper > > > He is a committer. On the user list there is also > > virtually nothing. What stands out is that he was interested in a > couple > > of > > posts in Shale. What is the possible reason he is a committer and Frank > > is > > not? Is this the Way Different Struts-Apache Way. This is crazy! Do > > people actually believe Ted and Craig? > > > > On 4/25/06, Greg Reddin <[EMAIL PROTECTED]> wrote: > > > > > > > > > On Apr 25, 2006, at 9:55 AM, Frank W. Zammetti wrote: > > > > > > > That depends entirely on your meaning of the word "closed". You > > > > make the > > > > argument that the number of new committers means it isn't closed, > > > > and I > > > > agree with you to a degree. But that's not the only meaning of > > > > "closed"... the invitations to those people came *soley* from the > PMC > > > > AFAIK... the community had no say in it. That's the thing my > proposal > > > > seeks to address, that the initiation of someone being invited > doesn't > > > > necessarily have to come from those already there (although they > would > > > > still have the final say-so). > > > > > > I have some serious concerns about this. Let me just use myself as > > > an example. I've been a committer for about 6 months or so. I have > > > absolutely no idea what sort of discussion took place before I > > > received that invitation. If there was someone among the PMC who was > > > vehemently opposed to my nomination I'm glad they had a confidential > > > forum in which to discuss their concerns. Now that I am a committer > > > I can have an unbiased conversation with anybody else in the group > > > without any preconceived notion of what that individual's opinion of > > > me might be. Truly, I don't have confidence that either user@ or > > > dev@ is a place where concerns can be expressed openly without fear > > > of unprofessional response. It's just too easy for this kind of > > > discussion to turn into personal attacks in a forum such as user@ or > > > even [EMAIL PROTECTED] > > > > > > When Struts was a Jakarta subproject I remember committer votes > > > taking place on [EMAIL PROTECTED] I always felt just a little uneasy > > > about it. > > > 99 times out of 100 it was a unanimous +1 with no discussion. But I > > > seem to recall at least one case when concerns were expressed (sorry, > > > I don't remember the specifics, please correct me if I'm wrong). I > > > feel really bad that this person's personal merit would have to be > > > discussed in a public forum. I understand some others' concerns > > > about the community appearing to be closed, but I think there should > > > be a barrier to entry. Maybe it's too high, but it seems to me that > > > it should exist. After all it's basically a lifetime appointment and > > > revocations are very rare if one has ever happened at all. > > > > > > Greg > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > "You can lead a horse to water but you cannot make it float on its > back." > > ~Dakota Jack~ > > > > > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Proposal for change
If you thought waiting like you were asked would help at all, Patrick, you are probably about to learn your first lesson in Struts-Shale-JSF-Craig-Apache Way. On 4/25/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > On 4/25/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote: > > > > Any chance that as you discuss this there would be a move to make dev@ > not > > receive all commit@ messages? Some of us (me) prefer to use RSS and > forcing > > the emails seems a bit heavy handed. > > > I've historically been a holdout on this issue (based on the philosophy > that > anyone who is interested in the development of a project should be > watching > the commit messages too, and having separate lists for commit messages > makes > it too easy to ignore those), but I'd be ok with separate lists if the > majority of the commiters want it that way. > > Craig > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Proposal for change
> This is where I'm not sure I agree... why can you only have a stake in > the > > code, or in the community even, if you are a committer? And certainly > the > > "community" is often touted as the most important part of any ASF > > project... it's just that "community" in that context means the > committers > > only, which is where I disagree with the Apache Way I guess. > > > No, that's not correct. The community is, as you put it earlier, "anyone > who > has an active interest in how the project develops". So you actually agree > with the Apache Way. ;-) > > -- > Martin Cooper > > > Simply putting code out there and sharing your work is great, but going > > back to a point I made some weeks ago, I beleive there is a > responsibility > > that comes along with it when you do that. Whether they should or not, > > people become dependent on the project... not in a cocaine kind of way > of > > course, but they are "counting on you" basically. That to me implies > > taking into consideration their needs and wants. Not above your own of > > course, but to some degree. > > > > > Bottom line: if a person isn't contributing to code and documentation > in > > > a way that the other committers are comfortable with then that person > > > shouldn't be a committer on the project. There is no other reason for > > > being a committer. > > > > This I absolutely agree with, and it was the reason my proposal didn't > try > > to change that. I would NEVER propose that the PMC not have the final > say > > in who is invited. It just to me seems right for that to be the case. > > But, I still see nothing wrong with being able to say "hey, PMC, we > think > > this guy or gal would be a good addition, please consider him". > > > > > My personal (and probably unneeded) opinion on the original subject: > > > > > > From my perspective, nominations don't matter so much... as I recall > > > someone could nominate themselves. If that person hasn't been > > > contributing code then there is no reason to think they will become a > > > committer. > > > > That is correct. I frankly was not aware that someone could do that, > Ted > > pointed it out to me. As I replied previously, that indeed covers the > > first principle of my proposal. I always prefer things like that be > more > > concrete, i.e., rules layed out in document form, but even failing that > I > > think the principle is followed, so I'm happy. > > > > > It would be nice if the process were a little more transparent as it > > > would be interesting to know who was proposed, accepted, rejected, > etc. > > > even if we didn't know why. (Though, even counter to that it was nice > > > to know that someone who contributed to another apache project and > > > stomped all over my contributed implementation because they didn't > > > bother to patch to head was at least a controversial nomination. But > > > that's sort of personal and isolated reason for wanting to see the > dirty > > > laundry.) > > > > I still have the concerns about people being embarassed by > this. However, > > I think the idea of a nominee accepting the nomination first is a fair > > idea. Putting aside the original proposal, how would that simple > change, > > along with opening the vote process discussion for all to see, sit with > > everyone? > > > > > I guess I have trouble seeing how things could be improved much by > your > > > proposal... especially since I understood there to be nothing wrong > with > > > nominations coming from anywhere. It was just explained to be easier > > > with a committer's support. I don't follow this list too closely, so > > > maybe I missed someone who has been contributing lots of stuff and > still > > > was overlooked. > > > > Agreed, once Ted explained that point to me, the proposal isn't quite as > > strong as I thought at first. I still think there is the issue of > > transparency that could do with further discussion, but it seems the > > nomination part of it is, more or less, already present. Codifying it > > would be nice, but I can live with it not being written anywhere. > > > > Thanks for commenting, you are always welcome as far as I'm concerned :) > > > > > -Paul > > > > Frank > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Proposal for change
Here is a case in point: I count four (4) posts to the dev list in Greg Reddin's history. He is a committer. On the user list there is also virtually nothing. What stands out is that he was interested in a couple of posts in Shale. What is the possible reason he is a committer and Frank is not? Is this the Way Different Struts-Apache Way. This is crazy! Do people actually believe Ted and Craig? On 4/25/06, Greg Reddin <[EMAIL PROTECTED]> wrote: > > > On Apr 25, 2006, at 9:55 AM, Frank W. Zammetti wrote: > > > That depends entirely on your meaning of the word "closed". You > > make the > > argument that the number of new committers means it isn't closed, > > and I > > agree with you to a degree. But that's not the only meaning of > > "closed"... the invitations to those people came *soley* from the PMC > > AFAIK... the community had no say in it. That's the thing my proposal > > seeks to address, that the initiation of someone being invited doesn't > > necessarily have to come from those already there (although they would > > still have the final say-so). > > I have some serious concerns about this. Let me just use myself as > an example. I've been a committer for about 6 months or so. I have > absolutely no idea what sort of discussion took place before I > received that invitation. If there was someone among the PMC who was > vehemently opposed to my nomination I'm glad they had a confidential > forum in which to discuss their concerns. Now that I am a committer > I can have an unbiased conversation with anybody else in the group > without any preconceived notion of what that individual's opinion of > me might be. Truly, I don't have confidence that either user@ or > dev@ is a place where concerns can be expressed openly without fear > of unprofessional response. It's just too easy for this kind of > discussion to turn into personal attacks in a forum such as user@ or > even [EMAIL PROTECTED] > > When Struts was a Jakarta subproject I remember committer votes > taking place on [EMAIL PROTECTED] I always felt just a little uneasy about > it. > 99 times out of 100 it was a unanimous +1 with no discussion. But I > seem to recall at least one case when concerns were expressed (sorry, > I don't remember the specifics, please correct me if I'm wrong). I > feel really bad that this person's personal merit would have to be > discussed in a public forum. I understand some others' concerns > about the community appearing to be closed, but I think there should > be a barrier to entry. Maybe it's too high, but it seems to me that > it should exist. After all it's basically a lifetime appointment and > revocations are very rare if one has ever happened at all. > > Greg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Agitator Licenses for Struts Committers
We can advertise our wares here? I did not know that. I thought this list was about Struts and not about Ted's business. But, excuse me. I should have known that Craig was not the exception in using the list that way. On 4/25/06, James Mitchell <[EMAIL PROTECTED]> wrote: > > Ok, let's review shall we. > > >> ... for our committers to use on open source projects... > >> > > What part of that says anything about personal gain? > > > -- > James Mitchell > > > > > On Apr 25, 2006, at 12:50 AM, Dakota Jack wrote: > > > Isn't this using the committer status for personal gain? > > > > On 4/23/06, Ted Husted <[EMAIL PROTECTED]> wrote: > >> > >> Agitar Software (http://www.agitar.com/) has donated several > >> licenses > >> for its Agitator product to Apache Struts for our committers to use > >> on open source projects. The Agitator includes "experts" that help it > >> work better with frameworks like Struts Action. Right now, the > >> Agitator "Struts Expert" supports Action 1.2. Experts for other > >> releases of Apache Struts frameworks are expected. I'm working with > >> Agitar to make the Expert API available to us, so that we can create > >> and maintain our own experts. > >> > >> A whitepaper that describes using the Agitator to test the MailReader > >> is available here: > >> > >> * http://www.StrutsUniversity.org/Agitator > >> > >> And I'll be giving the whitepaper as a "webinar" on Wednesday. > >> > >> * http://www.planetstruts.org/roller/page/news? > >> entry=what_to_do_if_your > >> > >> Apache Struts committers can find the list of product keys in the ASF > >> repository. > >> > >> * > >> https://svn.apache.org/repos/private/committers/pmc/struts/ > >> agitator-keys.txt > >> > >> Access to this file is resticted to Struts committers. > >> > >> -Ted. > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > "You can lead a horse to water but you cannot make it float on its > > back." > > ~Dakota Jack~ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Agitator Licenses for Struts Committers
There is a big difference between having an open source project that is used for business and using your position on the list to promote your business ideas on the list. How about we begin selling our sites on this list? If you cannot see the difference in this, then you just are not being honest or you are not to bright. I think Ted sees exactly the point. Reducing this to the TV idiocy is just as bad as the usual claim that Struts is just another Apache list, which it is not. On 4/25/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > On 4/25/06, James Mitchell <[EMAIL PROTECTED]> wrote: > > Ok, let's review shall we. > > > > >> ... for our committers to use on open source projects... > > >> > > > > What part of that says anything about personal gain? > > I seem to remember the term "personal gain" from the TV series > "Charmed', but I for one am not a witch :) > > The Apache License is designed to be business friendly. We expect and > encourage commercial uses of our products. As a result, it's not > uncommon for vendors of retail products to want to give back to open > source projects. > > Another good example is JetBrains, which provides complementantry IDEA > licenses to many open source projects, including the ASF. > > Of course, these licenses usually come with the stipulation that the > license is only to be used when working on open source projects. The > licenses are not for our personal use, but to help us with the > volunteer work we do for the foundation. > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Agitator Licenses for Struts Committers
Isn't this using the committer status for personal gain? On 4/23/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > Agitar Software (http://www.agitar.com/) has donated several licenses > for its Agitator product to Apache Struts for our committers to use > on open source projects. The Agitator includes "experts" that help it > work better with frameworks like Struts Action. Right now, the > Agitator "Struts Expert" supports Action 1.2. Experts for other > releases of Apache Struts frameworks are expected. I'm working with > Agitar to make the Expert API available to us, so that we can create > and maintain our own experts. > > A whitepaper that describes using the Agitator to test the MailReader > is available here: > > * http://www.StrutsUniversity.org/Agitator > > And I'll be giving the whitepaper as a "webinar" on Wednesday. > > * http://www.planetstruts.org/roller/page/news?entry=what_to_do_if_your > > Apache Struts committers can find the list of product keys in the ASF > repository. > > * > https://svn.apache.org/repos/private/committers/pmc/struts/agitator-keys.txt > > Access to this file is resticted to Struts committers. > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [action1] cleaning up the build
Interesting that you would put [action1] in when discussing struts but not [faces] when discussing faces. This is a real upside down deal, isn't it? On 4/5/06, James Mitchell <[EMAIL PROTECTED]> wrote: > > > I'd like to address some the current [action 1] build issues. Now > that we've simplified the directory structure (thanks Don!), I'd like > to spend some time on our build process. > > > Please comment on the following, if I don't hear back soon I'll go > ahead and take care of these... > > 1. sample apps > > action/apps/blank > - I think we should remove the dependency on tiles, blank should > not be an empty showcase for how to work with tiles. > > 2. Dependency declarations are inconsistent. For example, some Maven > 1 targets end with... > > ... > ... > struts-tiles-1.3.1-SNAPSHOT.jar (try downloading from http:// > struts.apache.org/) > struts-core-1.3.2-SNAPSHOT.jar (try downloading from http:// > struts.apache.org/) > struts-extras-1.3.2-SNAPSHOT.jar (try downloading from http:// > struts.apache.org/download.cgi) > struts-taglib-1.3.2-SNAPSHOT.jar (try downloading from http:// > struts.apache.org/download.cgi) > ... > ... > > So, is it 1.3.1 or 1.3.2? Is it download.cgi or the root of the > project site? > > > > And a few more questions: > Q. We have a Maven 1 and Maven 2 build available, is this really > necessary? Why not just go with Maven 2? > > Q. I know there was apprehension about moving to Maven 2 a while back > because of the lack of plugins compared to maven 1. Is this still > the case? > > Q. How many other committers are committed to learning and perfecting > our Maven 1 and/or 2 builds? > > Q. What is the difference between these? > sandbox/tiles/tiles-documentation > sandbox/tiles-documentation > > > > I have more, but I'll fire this off for now... > > > -- > James Mitchell > > > > > > --------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Struts Faces - what to do?
Isn't the rule that this should have [faces] or something like that in the subject matter? On 4/13/06, James Mitchell <[EMAIL PROTECTED]> wrote: > > Perhaps Craig can shed some light on this, but are we going to > continue to support the struts-faces project? If so, can someone > please fix the faces example (1 and 2) apps? > > -- > James Mitchell > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
thod. This corresponds to when an action framework > invokes the "execute" or whatever method on the selected action. > This takes care of per-action pipeline customizations. > > * Supporting the use of an XWork interceptor stack in the application > controler filter part of Shale (as an alternative to the current > mechanism, > which lets you customize a Commons Chain command chain). This > takes care of global pipeline customization. > > The first scenario seems pretty straightforward. I don't know XWork well > enough to know whether the second strategy can actually be implemented the > way I think it should (it would be necessary to split the "before" and > "after" parts of the interceptor chain), but that'll become obvious when > it > gets attempted :-). > > The gain for the end user is to be able to reuse (or migrate) existing > interceptors without having to rewrite everything. > > This is a good discussion, and I hope it can continue and be a benefit to > > both communities. > > > > Don > > > Craig > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Why would we want the Action/Shale frameworks closer. I thought you guys were into diversity, not just trying to sell JSF? Lord, if you bring Shale to WebWorks, then you will truly have destroyed any hope of Struts survival in any form, even WebWorks. On 4/9/06, Sean Schofield <[EMAIL PROTECTED]> wrote: > > [Moving this aspect of the discussion from myfaces to struts list ...] > > On 4/7/06, Jacob Hookom <[EMAIL PROTECTED]> wrote: > > Covered here a bit: > > > > > http://weblogs.java.net/blog/jhook/archive/2006/03/the_new_servlet_1.html > > @Jacob: > > Great blog entry! > > @ Struts Dev: > > I recommend you check this out. Jacob outlines how its possible to > create a simple action oriented framework on top of the JSF API > without fussing with components.You really get a sense for how > powerful (and pluggable) the API really is. > > Maybe this a possible Action/Shale/MyFaces cooperation opportunity? > Maybe the Webwork stuff could take advantage of the EL and > NavigationHandler? Its not 100% JSF but it would bring the > Action/Shale frameworks a little closer together. > > Back at ApacheCon USA we talked about trying to work more closely > between the two frameworks. To me, this idea has some interesting > possibilities. I know there was some interest in the Shale dialog > stuff but why not get the impressive navigation and EL capabilities of > JSF for free? > > Sean > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [OT] What can I do?
What is the basis for saying "[b]oth ASF and Apache Struts are standard-bearers"? What does this mean and what is the import, for both ASF and Apache Struts, separately? This is not a challenge or anything like that but a sincere request for clarification. What is a "standard-bearer". Are you saying that both ASF and Struts are somehow beholden to Sun to do this? Why is Struts seen as the standard-bearer for JSF. If a "standard-bearer" was needed for JSF, why wasn't a separate one created? Sun itself seems to be supporting the GlassFish project on this one, so why does Struts also get the job? You can imagine all the questions about this simple paragraph. The assumptions behind this little bit of what you had to say are huge. Can you not flesh them out so that someone not into the politics can see what is really going on? I cannot tell what this means. On GlassFish: https://glassfish.dev.java.net/public/faq/GF_FAQ_2.html#community, https://glassfish.dev.java.net/ -- , https://javaserverfaces.dev.java.net/servlets/NewsItemView?newsItemID=3340 , http://wiki.java.net/bin/view/Projects/GlassFishModuleOwners?rev=1.19 , and at http://java.sun.com/javaee/javaserverfaces/ . "*Current Status <http://java.sun.com/javaee/javaserverfaces/download.html> * The latest build of JavaServer Faces technology 1.2 is integrated into the GlassFish project. Click the Current Status link to read more about what's happening now with JavaServer Faces Technology and to download specifications and reference implementations." Anyway, before anyone could make an intelligent proffer of anything they would have to know what is the basis for your statements about ASF, Struts and JSF, as well as a bit of clarification as to what you mean. On 3/20/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > * Both the ASF and Apache Struts are standard-bearers, and, like it or > not, JSF is a designated Java standard. Given volunteers, we believe > that it is appropriate that Apache Struts provide JSF developers with > a MVC framework to fill in the gaps left by JSR 127, just like Struts > Action fills in the gaps left by the servlet platform -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Reasons for 1.3 release
Following is a sample implementation of a real CoR pattern. Notice how
different it looks? Notice how data driven it is?
On 2/18/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>
> Dakota Jack wrote:
> > The flexibility is clear. But, from what I can see the pattern is not
> CoR.
>
> Ok, I'll bite... can you explain that?
*JAVA DESIGN PATTERNS*
*Behavioral Patterns - Chain of Responsibility Pattern*
The chain of responsibility pattern is based on the same principle as
written above. It decouples the sender of the request to the receiver. The
only link between sender and the receiver is the request which is sent.
Based on the request data sent, the receiver is picked. This is called
"data-driven". In most of the behavioral patterns, the data-driven concepts
are used to have a loose coupling.
The responsibility of handling the request data is given to any of the
members of the "chain". If the first link of the chain cannot handle the
responsibility, it passes the request data to the next level in the chain,
i.e. to the next link. For readers, familiar with concepts of Java, this is
similar to what happens in an Exception Hierarchy. Suppose the code written
throws an ArrayIndexOutOfBoundsException. Now, this exception is because of
some bug in coding and so, it gets caught at the correct level. Suppose, we
have an application specific exception in the catch block. This will not be
caught by that. It will find for an Exception class and will be caught by
that as both the application specific exceptions and the
ArrayIndexOutOfBoundsException are sub-classes of the class Exception.
Once get caught by the exception, which is the base class, it will then not
look for any other exception. This is precisely the reason why, we get an
"Exception is unreachable" message when we try to add a catch block with the
exception below the parent exception catch block.
So, in short, the request rises in hierarchy till some object takes
responsibility to handle this request.
It's the same mechanism used for multi-level filtration. Suppose, we have a
multi level filter and gravel of different sizes and shapes. We need to
filter this gravel of different sizes to approx size categories. We will put
the gravel on the multi-level filtration unit, with the filter of maximum
size at the top and then the sizes descending. The gravel with the maximum
sizes will stay on the first one and rest will pass, again this cycle will
repeat until, the finest of the gravel is filtered and is collected in the
sill below the filters. Each of the filters will have the sizes of gravel
which cannot pass through it. And hence, we will have approx similar sizes
of gravels grouped.
Let's apply the same example in the form of code.
First, let's talk about the request data. In this case, it is the gravel. We
call it Matter. It has size and quantity. Now, the size determines whether
it matches the size of filter or not and the quantity tells how much matter
is below the size.
*Matter.java*
package bahavioral.chainofresponsibility;
public class Matter {// size of matter
private int size;
// quantity
private int quantity;
/**
* returns the size
*/
public int getSize() {
return size;
}
/**
* sets the size
*/
public void setSize(int size) {
this.size = size;
}
/**
* returns the quantity
*/
public int getQuantity() {
return quantity;
}
/**
* sets the quantity
*/
public void setQuantity(int quantity) {
this.quantity = quantity;
}
}// End of class
The next thing is now the base class. This base class in our case is Sill.
Nothing escapes the Sill. All the matter is collected in the sill.
Everything which cannot be filtered gets collected in the Sill. Like all the
requests which cannot be handled at a lower level rise to higher level and
are handled at the highest level.
*Sill.java*
package bahavioral.chainofresponsibility;
/**
* Sill.java
*
* This is the base class, you can say, which collects everything
* and nothing passes this. Whatever matter is remaining, and is
* still not filtered, is collected here.
*/
public class Sill {
/**
* Method collect.
* Everything is collected here.
*/
public void collect(Matter gravel) {
} }// End of class
And of course, the next class will be the chain. In the example, I have just
created one single class called Filter1. This class extends from the Sill.
And the chain grows on. Every class like Filter2, Filter3 etc extends from
Filter1, Filter2 and so on.
* Filter1.java* package bahavioral.chainofresponsibility;
/**
* This is a filter. This filters out the gravel and
* passes the rest to the next level.
*/
public class Filter1 extends Sill {
private int size;
public Filter1(int size) {
this.size = size;
}
/**
* over-ridden method from base class
*/
public void collect(Matter gravel) { // for the entire quantity of
matter
for(int i = 0; i < gravel.getQuantity(); i++) {// if gravel size is
Re: Reasons for 1.3 release
mapping)) {
return;
}
// Process any ActionForm bean related to this request
ActionForm form = processActionForm(request, response, mapping);
processPopulate(request, response, form, mapping);
if (!processValidate(request, response, form, mapping)) {
return;
}
// Process a forward or include specified by this mapping
if (!processForward(request, response, mapping)) {
return;
}
if (!processInclude(request, response, mapping)) {
return;
}
// Create or acquire the Action instance to process this request
Action action = processActionCreate(request, response, mapping);
if (action == null) {
return;
}
// Call the Action instance itself
ActionForward forward =
processActionPerform(request, response,
action, form, mapping);
// Process the returned ActionForward instance
processActionForward(request, response, forward);
}
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: Reasons for 1.3 release
On 2/19/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > > > > If I understand correctly, in CoR pattern a client calls the chain > > head and "the request propagates along the chain until a > > ConcreteHandler object takes responsibility for handling it." (GoF) > > > That's the most important sentence in the GoF description ... and the one > that motivated the API design for a Comman in Commons Chain. > > Craig is sure right that this is the most important sentence. It is the one that keeps each link in the chain ignorant of the rest. Now, go look at ChainBase in commons and you will see that this is NOT the API design in commons chain. The Command, hopefully, but NOT, would be part of a command pattern. ChainBase, NOT Command, hopefully, but NOT, would be part of a chain pattern. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Reasons for 1.3 release
Here is the ChainBase execute method, gentlemen. If you think that is CoR,
then I have nothing further to say. This is the real "pattern". It is not
even OOP. It merely uses a class as a repository to do C coding.
// Documented in Chain interface
public boolean execute(Context context) throws Exception {
// Verify our parameters
if (context == null) {
throw new IllegalArgumentException();
}
// Freeze the configuration of the command list
frozen = true;
// Execute the commands in this list until one returns true
// or throws an exception
boolean saveResult = false;
Exception saveException = null;
int i = 0;
int n = commands.length;;
for (i = 0; i < n; i++) {
try {
saveResult = commands[i].execute(context);
if (saveResult) {
break;
}
} catch (Exception e) {
saveException = e;
break;
}
}
// Call postprocess methods on Filters in reverse order
if (i >= n) { // Fell off the end of the chain
i--;
}
boolean handled = false;
boolean result = false;
for (int j = i; j >= 0; j--) {
if (commands[j] instanceof Filter) {
try {
result =
((Filter) commands[j]).postprocess(context,
saveException);
if (result) {
handled = true;
}
} catch (Exception e) {
; // Silently ignore
}
}
}
// Return the exception or result state from the last execute()
if ((saveException != null) && !handled) {
throw saveException;
} else {
return (saveResult);
}
}
On 2/19/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>
> Does "MyCommand" represent a chain in MyCatalog? If so, while I
> wouldn't presume to speak for Craig, it sure seems like it :) I've
> personally used the "fire a chain from an Action" in the past, but I can
> certainly see where this would be very nice.
>
> Frank
>
> Martin Cooper wrote:
> > On 2/19/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> >
> >
> > The next step would be to provide customizable chains per Action
> (becoming
> >> even more like how you configure actions in WebWork) -- but you can
> even
> >> do
> >> that today by using an Action that itself executed a chain.
> >
> >
> > Craig, isn't that what we already have with:
> >
> >
> > > catalog="MyCatalog"
> > command="MyCommand"/>
> >
> > or am I misunderstanding?
> >
> > --
> > Martin Cooper
> >
> >
> > Michael.
> >>
> >> Craig
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: Reasons for 1.3 release
Why don't you guys just look at the code? It is fairly simple and straightforward. On 2/19/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > On 2/19/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Anyone can quote chapter and verse from the GoF book. Can you instead > > explain *why* what's in Struts isn't CoR? And, perhaps more > > importantly, explain why, even if it isn't an exact match for the > > pattern, it matters one bit? > > By the way, is Struts CoR actually a CoR? This is not a trick > question, I am just asking. > > If I understand correctly, in CoR pattern a client calls the chain > head and "the request propagates along the chain until a > ConcreteHandler object takes responsibility for handling it." (GoF) > > In Struts Classic prior to 1.3 a client calls a concrete action (which > is why I consider Struts Classic to *not* be an implementation of > Front Controller pattern). It is possible to stick additional > processing before the action class is called. Though it is not as easy > as in WebWork, it is possible. So, Struts Classic implements > Interceptor pattern, not Chain of Responsibility. > > So, how the whole thing works in 1.3? A client still calls a > particular mapping like in older Struts versions, right? Does this > mapping define a head of chain (CoR) or an end of chain > (interceptors)? If it defines the head of chain, is it still possible > to sneak interceptors into an arbitrary chain? > > Michael. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Reasons for 1.3 release
Responses are following of your remarks, Frank. Anyone can quote chapter and verse from the GoF book. Can you instead explain *why* what's in Struts isn't CoR? I assumed you had looked at the code, and in case you had not, encouraged you to do so and even indicated where the problem was by telling you there were "Iterations". And, perhaps more importantly, explain why, even if it isn't an exact match for the pattern, it matters one bit? If you think that there are "exact" and "inexact" "matches" for patterns, as if this were something like a pattern for making a dress, then I don't have much to say. Patterns don't work like that in software development. Would you deny that that the flexibility of the chain approach, regardless of it's "correctness" as far as pattern implementation goes, doesn't make Struts better? THAT is what I care about, and likely most other developers would care about. I in fact said it was flexible. So are POJOs. If you don't care if it is CoR or not and want to call it "CoR" whether it is or not, go ahead. I cannot say I would trust a developer much who used basic pattern names wrong. But, if you are comfortable not understanding what you say or what you are talking about, you and your "other developer[]" friends can have at it. I work and live in development communities and we damn sure do care about being precise and knowing what we talk about. I'm not writing my thesis on why or why not Struts implements this pattern or that pattern as advertised, I'm interested in whether it makes my life better, and I for one am convinced the chain approach does. If you disagree, that's fine, I would like to hear why, but with specifics, not by quoting a theoretical abstraction. If you have decided that the GoF book is a "theoretical abstraction", then you and I probably have very little to discuss. If you don't care if it is CoR or not, I have no idea why you responded to the note that it is not, which it is not. If you think understanding and employing design patterns in a wise way is an academic "thesis" matter, then you are running in a very different development crowd than I am. If you said anything like that where I work, they would be shocked. We don't write theses around here. We write code. Good code and we know what patterns we are using. Actually, the reason Struts has to be tossed is just because it is a mess in regard to the flexibility and the use of deep level design patterns. Maybe it is easy to use, but so are lots of bad ideas. Had Struts used a Strategy pattern instead of whatever that is that they have now, it might have had a chance to use AOP, and other cook features that this code won't help. It is easy to code, that is true. It is flexible as hell in the sense that anyone with any sense can code it and it is easy to change in the concrete classes. There are much deeper problems which it not only does not address but exascerbates. Why don't you look at the code and see where there is iteration? I don't think I should have to go to the code and show you. If you insist you don't want to even look at the code and still defend it, then that's your perogative. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack
Re: Reasons for 1.3 release
Have you looked at the actual code? And have you looked at what a CoR pattern is? The actual code is not a CoR pattern. I am not interested in "hooking" anyone, by the way, and so you don't need to "bite". I guess saying you'll "bite" is like saying I am "fishing" for bullshit. That is not true. Anyway, the actual design goes as follows. Please notice that none of the iterations in Struts CoR are present, for good reason. Chain of Responsibility Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. There is a potentially variable number of "handler" objects and a stream of requests that must be handled. Need to efficiently process the requests without hard-wiring handler relationships and precedence, or request-to-handler mappings. The pattern chains the receiving objects together, and then passes any request messages from object to object until it reaches an object capable of handling the message. The number and type of handler objects isn't known a priori, they can be configured dynamically. The chaining mechanism uses recursive composition to allow an unlimited number of handlers to be linked. Chain of Responsibility simplifies object interconnections. Instead of senders and receivers maintaining references to all candidate receivers, each sender keeps a single reference to the head of the chain, and each receiver keeps a single reference to its immediate successor in the chain. Make sure there exists a "safety net" to "catch" any requests which go unhandled. Do not use Chain of Responsibility when each request is only handled by one handler, or, when the client object knows which service object should handle the request. [ http://www.cs.huji.ac.il/labs/parallel/Docs/C++/DesignPatterns/chain.html.] The Chain of Responsibility pattern avoids coupling the sender of a request to the receiver by giving more than one object a chance to handle the request. Mechanical coin sorting banks use the Chain of Responsibility. Rather than having a separate slot for each coin denomination coupled with a receptacle for the denomination, a single slot is used. When the coin is dropped, the coin is routed to the appropriate receptacle by the mechanical mechanisms within the bank. [Michael Duell, "Non-software examples of software design patterns", Object Magazine, Jul 97, p54] Chain of Responsibility, Command, Mediator, and Observer, address how you can decouple senders and receivers, but with different trade-offs. Chain of Responsibility passes a sender request along a chain of potential receivers. Chain of Responsibility can use Command to represent requests as objects. [GOF, p349] Chain of Responsibility is often applied in conjunction with Composite. There, a component's parent can act as its successor. [GOF, p232] ----- On 2/18/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Dakota Jack wrote: > > The flexibility is clear. But, from what I can see the pattern is not > CoR. > > Ok, I'll bite... can you explain that? > > Frank > > > On 2/16/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > >> Craig McClanahan wrote: > >>> This pattern, of course, can be used today in a Struts 1.x action ... > or > >> in > >>> the "action" equivalent of any other framework too (JSF, WebWork, > >>> whatever). And, it's not even web specific ... you can design your > >> whole > >>> business logic layer out of chains. > >> Having done this recently in a behavioral analysis application that was > >> not web-based, I know exactly what your saying. I can't tell you how > >> thrilled the business was in a meeting a few weeks ago when they said > >> "well, what happens when we want to add a rule between C and D in this > >> processing flow" and I was able to do it in about 1 minute right before > >> their eyes. They flipped! CoR makes that flexibility very easy to do. > >> > >>> Craig > >> Frank > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > "You can lead a horse to water but you cannot make it float on its > back." > > ~Dakota Jack~ > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Reasons for 1.3 release
The flexibility is clear. But, from what I can see the pattern is not CoR. On 2/16/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Craig McClanahan wrote: > > This pattern, of course, can be used today in a Struts 1.x action ... or > in > > the "action" equivalent of any other framework too (JSF, WebWork, > > whatever). And, it's not even web specific ... you can design your > whole > > business logic layer out of chains. > > Having done this recently in a behavioral analysis application that was > not web-based, I know exactly what your saying. I can't tell you how > thrilled the business was in a meeting a few weeks ago when they said > "well, what happens when we want to add a rule between C and D in this > processing flow" and I was able to do it in about 1 minute right before > their eyes. They flipped! CoR makes that flexibility very easy to do. > > > Craig > > Frank > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
I think the fact that some committers are building code for their personal use and have already personally "committed" it is not a good reason to roll out a bad idea. On 2/15/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > > On 2/15/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > > > On 2/14/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > > > Is it the intention of the Struts commiters to > > > make a Command something like a new Action that should be used > instead? > > > Or are you expecting commands to be created solely for the request > > processor chain? > > > > Some people have suggested that Command replace Action, and we are > > encouraging people to explore that avenue to see how well it works. > > Personally, I favor using Commands the way WebWork/Action2 uses > > Interceptors and leaving Action as a "place to stand" on the web > > layer. > > > > Our intent has been to make a numbered build available so that we can > > get more input from other Struts developers. > > > > > If it is the second, then I stand by my suggestion that ActionContext > > should be renamed > > > to reserve the name (ProcessorActionContext?) for the day when you > want > > actions to > > > receive an ActionContext like WebWork. > > > > :) There are any number of naming quirks in Struts Action 1.x, and I > > don't know if one more is going to make a difference. :) > > > > The 1.3.x series has been cooking for about 18 months now (since the > > summer of 2004), and some people are already using it in production. I > > think if we do not get something rolled this week, a few us might > > burst into flames. That doesn't mean 1.3.0 will go GA, and it doesn't > > mean that we can't make significant API changes before 1.3.x goes GA. > > But, it does mean more people will look at what we've done so far. > > > > If we did decide to rename a member for future use, we could copy it > > and deprecate the old one for a milestone, and then remove the old > > one. But, since the ActionContext has been in the nightly build for > > many, many months, we should not just change it willy-nilly. > > > I just checked SVN, and ActionContext has been in there for just over a > year. Some people have been developing with it in nightly builds since > then. > I, for one, am certainly not in favour of changing such a key class on the > eve of rolling the first "real" 1.3.x build, not least because I don't > want > to have to go change my code! ;-) > > Once we > > get a numbered build out there, I'm sure that there will be many more > > comments like this. If there is interest, we can regroup and make any > > desirable changes in 1.3.1 and 1.3.2 and so forth. In the past, we > > have deprecated and removed and released new members during a beta > > cycle, and I expect we wil do so again. > > > > The other important thing is that once we roll the seven 1.3.0 builds, > > we can make internal changes to Action without re-releasing the other > > six, if the external API doesn't change. > > > > I would tend to agree that we need two flavors of Context available > > during the request/response cycle. One for the Actions and Commands to > > use internally, and another for server pages (including Velocity > > templates) to read externally. Perhaps we could just adopt the > > Velocity Tools for that, and expect that tags to get everything they > > need from a "tool" passed through the request. > > > > * http://jakarta.apache.org/velocity/tools/ > > > > But, before getting into anything like that, we should roll the 1.3.0 > > builds, so that we can start making lighter releases. > > > +1 > > -- > Martin Cooper > > > I didn't have any discretionary time last night, but, hopefully, I can > > wrap up the review of the Release Notes tonight. We can then tag the > > repository for STRUTS_1_3_0 as well as for each of the subprojects > > (STRUTS_ACTION_1_3_0 ... STRUTS_TILES_1_3_0), and take it from there. > > > > -- HTH, Ted. > > ** http://www.husted.com/ted/blog/ > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
For my part, I don't think haste because things are late is a good idea. Do it right and have a good product. On 2/15/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > On 2/14/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > > Is it the intention of the Struts commiters to > > make a Command something like a new Action that should be used instead? > > Or are you expecting commands to be created solely for the request > processor chain? > > Some people have suggested that Command replace Action, and we are > encouraging people to explore that avenue to see how well it works. > Personally, I favor using Commands the way WebWork/Action2 uses > Interceptors and leaving Action as a "place to stand" on the web > layer. > > Our intent has been to make a numbered build available so that we can > get more input from other Struts developers. > > > If it is the second, then I stand by my suggestion that ActionContext > should be renamed > > to reserve the name (ProcessorActionContext?) for the day when you want > actions to > > receive an ActionContext like WebWork. > > :) There are any number of naming quirks in Struts Action 1.x, and I > don't know if one more is going to make a difference. :) > > The 1.3.x series has been cooking for about 18 months now (since the > summer of 2004), and some people are already using it in production. I > think if we do not get something rolled this week, a few us might > burst into flames. That doesn't mean 1.3.0 will go GA, and it doesn't > mean that we can't make significant API changes before 1.3.x goes GA. > But, it does mean more people will look at what we've done so far. > > If we did decide to rename a member for future use, we could copy it > and deprecate the old one for a milestone, and then remove the old > one. But, since the ActionContext has been in the nightly build for > many, many months, we should not just change it willy-nilly. Once we > get a numbered build out there, I'm sure that there will be many more > comments like this. If there is interest, we can regroup and make any > desirable changes in 1.3.1 and 1.3.2 and so forth. In the past, we > have deprecated and removed and released new members during a beta > cycle, and I expect we wil do so again. > > The other important thing is that once we roll the seven 1.3.0 builds, > we can make internal changes to Action without re-releasing the other > six, if the external API doesn't change. > > I would tend to agree that we need two flavors of Context available > during the request/response cycle. One for the Actions and Commands to > use internally, and another for server pages (including Velocity > templates) to read externally. Perhaps we could just adopt the > Velocity Tools for that, and expect that tags to get everything they > need from a "tool" passed through the request. > > * http://jakarta.apache.org/velocity/tools/ > > But, before getting into anything like that, we should roll the 1.3.0 > builds, so that we can start making lighter releases. > > I didn't have any discretionary time last night, but, hopefully, I can > wrap up the review of the Release Notes tonight. We can then tag the > repository for STRUTS_1_3_0 as well as for each of the subprojects > (STRUTS_ACTION_1_3_0 ... STRUTS_TILES_1_3_0), and take it from there. > > -- HTH, Ted. > ** http://www.husted.com/ted/blog/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [ANNOUNCEMENT] Apache Struts offers "Shale" for JSF
emotions is an important skill. Without an appeal to peoples' emotions, it is often difficult to get them to take action or to perform at their best. For example, no good coach presents her team with syllogisms before the big game. Instead she inspires them with emotional terms and attempts to "fire" them up. There is nothing inherently wrong with this. However, it is not any acceptable form of argumentation. As long as one is able to clearly distinguish between what inspires emotions and what justifies a claim, one is unlikely to fall prey to this fallacy. As a final point, in many cases it will be difficult to distinguish an Appeal to Emotion from some other fallacies and in many cases multiple fallacies may be committed. For example, many Ad Hominem<http://www.nizkor.org/features/fallacies/ad-hominem.html>s will be very similar to Appeals to Emotion and, in some cases, both fallacies will be committed. As an example, a leader might attempt to invoke hatred of a person to inspire his followers to accept that they should reject her claims. The same attack could function as an Appeal to Emotion and a Personal Attack<http://www.nizkor.org/features/fallacies/personal-attack.html>. In the first case, the attack would be aimed at making the followers feel very favorable about rejecting her claims. In the second case, the attack would be aimed at making the followers reject the person's claims because of some perceived (or imagined) defect in her character. This fallacy is related to the Appeal to Popularity<http://www.nizkor.org/features/fallacies/appeal-to-popularity.html>fallacy. Despite the differences between these two fallacies, they are both united by the fact that they involve appeals to emotions. In both cases the fallacies aim at getting people to accept claims based on how they or others feel about the claims and not based on evidence for the claims. Another way to look at these two fallacies is as follows Appeal to Popularity<http://www.nizkor.org/features/fallacies/appeal-to-popularity.html> 1. Most people approve of X. 2. So, I should approve of X, too. 3. Since I approve of X, X must be true. Appeal to Emotion 1. I approve of X. 2. Therefore, X is true. On this view, in an Appeal to Popularity<http://www.nizkor.org/features/fallacies/appeal-to-popularity.html>the claim is accepted because most people approve of the claim. In the case of an Appeal to Emotion the claim is accepted because the individual approves of the claim because of the emotion of approval he feels in regards to the claim. Examples of Appeal to Emotion 1. The new PowerTangerine computer gives you the power you need. If you buy one, people will envy your power. They will look up to you and wish they were just like you. You will know the true joy of power. TangerinePower. 2. The new UltraSkinny diet will make you feel great. No longer be troubled by your weight. Enjoy the admiring stares of the opposite sex. Revel in your new freedom from fat. You will know true happiness if you try our diet! 3. Bill goes to hear a politician speak. The politician tells the crowd about the evils of the government and the need to throw out the peoople who are currently in office. After hearing the speach, Bill is full of hatred for the current politicians. Because of this, he feels good about getting rid of the old politicians and accepts that it is the right thing to do because of how he feels. On 12/16/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > FYI Dakota Jack is a troll. Please don't encourage him, even if you > agree with his position. > > sean > > On 12/16/05, Patrick Lightbody <[EMAIL PROTECTED]> wrote: > > This sounds familiar :) > > > > I definitely would recommend changing the slides and title of the > > presentation. Just yesterday I ran in to this: > > > > > http://javasymposium.techtarget.com/html/det_descriptions.htm#McClanahanShale > > > > Changing the title to something like "Shale: the Struts Component > > Framework" would certainly clear this up. We need to be firm and clear > > on the idea that Struts has many sub-projects, and two major > > frameworks: an Action framework and a Component framework. > > > > Patrick > > > > On 12/16/05, Dakota Jack <[EMAIL PROTECTED]> wrote: > > > With some people like Craig McClanahan delivering talks at significant > > > conferences entitled with contrary ideas like "Is Shale the next > Struts", > > > you might excuse people for thinking that this "subproject" ruse is > > > baloney. I didn't fall off the turnip truck yesterday and I have read > all > > > about the Trojan Horse. > > > > > > On 12/15/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > By the way, the original decision to incorporate Shale as a > subproject > > > > occurred nearly 11 months ago: > > > > > > > > http://marc.theaimsgroup.com/?l=struts-user&m=110651419515521&w=2 > > > > > > > > -- Paul > > > > > > > > > > > > Craig > > > > > > > > > > > > > > > > > -- > > > "You can lead a horse to water but you cannot make it float on its > back." > > > ~Dakota Jack~ > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [ANNOUNCEMENT] Apache Struts offers "Shale" for JSF
o on board > > to continue the grow the spirit of cooperation, not only between > > Struts Action and WebWork, but between Struts Action and Struts Shale. > > > > Patrick > > > > On 12/16/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > >> I think it is fair to say that many of us have made similar comments > >> over > >> the past few months, and have every time been basically told that it is > >> our problem we are not "getting it". Usually we've been told nicely, > >> but > >> not always. That isn't the point though, The point is that this is > not > >> a > >> new complaint by any stretch, and it has previously been dismissed on > >> many > >> occasions by more than one person. > >> > >> -- > >> Frank W. Zammetti > >> Founder and Chief Software Architect > >> Omnytex Technologies > >> http://www.omnytex.com > >> AIM: fzammetti > >> Yahoo: fzammetti > >> MSN: [EMAIL PROTECTED] > >> > >> On Fri, December 16, 2005 10:37 am, Patrick Lightbody said: > >> > This sounds familiar :) > >> > > >> > I definitely would recommend changing the slides and title of the > >> > presentation. Just yesterday I ran in to this: > >> > > >> > > http://javasymposium.techtarget.com/html/det_descriptions.htm#McClanahanShale > >> > > >> > Changing the title to something like "Shale: the Struts Component > >> > Framework" would certainly clear this up. We need to be firm and > clear > >> > on the idea that Struts has many sub-projects, and two major > >> > frameworks: an Action framework and a Component framework. > >> > > >> > Patrick > >> > > >> > On 12/16/05, Dakota Jack <[EMAIL PROTECTED]> wrote: > >> >> With some people like Craig McClanahan delivering talks at > >> significant > >> >> conferences entitled with contrary ideas like "Is Shale the next > >> >> Struts", > >> >> you might excuse people for thinking that this "subproject" ruse is > >> >> baloney. I didn't fall off the turnip truck yesterday and I have > >> read > >> >> all > >> >> about the Trojan Horse. > >> >> > >> >> On 12/15/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > >> >> > > >> >> > > >> >> > By the way, the original decision to incorporate Shale as a > >> subproject > >> >> > occurred nearly 11 months ago: > >> >> > > >> >> > > http://marc.theaimsgroup.com/?l=struts-user&m=110651419515521&w=2 > >> >> > > >> >> > -- Paul > >> >> > > >> >> > > >> >> > Craig > >> >> > > >> >> > > >> >> > >> >> > >> >> -- > >> >> "You can lead a horse to water but you cannot make it float on its > >> >> back." > >> >> ~Dakota Jack~ > >> >> > >> >> > >> > > >> > - > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [ANNOUNCEMENT] Apache Struts offers "Shale" for JSF
I have no reservations about your sincerity, Patrick, and I am glad to find you at Struts. Welcome! However, I would be careful if I were you about being sanguine about your new companions. I hope things turn out as you have indicated. On 12/16/05, Patrick Lightbody <[EMAIL PROTECTED]> wrote: > > I think I can offer a somewhat unique perspective. As an "outsider" to > Struts and someone who has spent 3 years living in the "WebWork > world", I only recently many of the Struts developers and community > this week at ApacheCon. Having been in a room talking about this very > issue with Ted, Don, Craig, Martin, Neil, Clinton, and others, I can > say without a doubt that everyone is on board with this vision of > Struts as a community and two parallel frameworks. > > More so, we are all in agreement that we will collaborate wherever > possible, including: > > - common set of Java 5 annotations > - similar style configuration tricks (auto-reloading, consistent use > of DTD or XML schema, etc) > - validation engine > - internationalization > - possibly some tags even > > I'd also like to add that whatever the history has been, today I see > Struts as a unique offering. In the web development space (regardless > of language), there are two schools of thoughts: > > - action frameworks: bind requests to methods in beans > - event/component frameworks: don't worry about URLs as much and bind to > events > > I think it is fair to say that marketplace of developers has not yet > decided that one of these is a clear "winner". Struts, as a community, > is uniquely positioned to offer both options and is best prepared for > the day when that winner is declared. We all agreed that when that day > comes, by working together in other areas (validation, i18n, config, > annotations, etc) not only will the code be easy to merge, but the > community will be too. No other web development community offers this. > > As someone who has said some pretty disparaging remarks about Struts > technolog and community in the part (I'll do the google search for > you: > http://blogs.opensymphony.com/plightbo/2003/10/webwork_docaday_struts_really.html) > , > I can comfortably say I made a big mistake in choosing to create a > divide but that I've learned from that mistake and that is why I am > here today. > > And I believe that everyone in the Struts community is also on board > to continue the grow the spirit of cooperation, not only between > Struts Action and WebWork, but between Struts Action and Struts Shale. > > Patrick > > On 12/16/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > I think it is fair to say that many of us have made similar comments > over > > the past few months, and have every time been basically told that it is > > our problem we are not "getting it". Usually we've been told nicely, > but > > not always. That isn't the point though, The point is that this is not > a > > new complaint by any stretch, and it has previously been dismissed on > many > > occasions by more than one person. > > > > -- > > Frank W. Zammetti > > Founder and Chief Software Architect > > Omnytex Technologies > > http://www.omnytex.com > > AIM: fzammetti > > Yahoo: fzammetti > > MSN: [EMAIL PROTECTED] > > > > On Fri, December 16, 2005 10:37 am, Patrick Lightbody said: > > > This sounds familiar :) > > > > > > I definitely would recommend changing the slides and title of the > > > presentation. Just yesterday I ran in to this: > > > > > > > http://javasymposium.techtarget.com/html/det_descriptions.htm#McClanahanShale > > > > > > Changing the title to something like "Shale: the Struts Component > > > Framework" would certainly clear this up. We need to be firm and clear > > > on the idea that Struts has many sub-projects, and two major > > > frameworks: an Action framework and a Component framework. > > > > > > Patrick > > > > > > On 12/16/05, Dakota Jack <[EMAIL PROTECTED]> wrote: > > >> With some people like Craig McClanahan delivering talks at > significant > > >> conferences entitled with contrary ideas like "Is Shale the next > > >> Struts", > > >> you might excuse people for thinking that this "subproject" ruse is > > >> baloney. I didn't fall off the turnip truck yesterday and I have > read > > >> all > > >> about the Trojan Horse. > > >> > > >> On 12/15/05, Craig McClanahan <[EMAIL PROTECTED
Re: [ANNOUNCEMENT] Apache Struts offers "Shale" for JSF
With some people like Craig McClanahan delivering talks at significant conferences entitled with contrary ideas like "Is Shale the next Struts", you might excuse people for thinking that this "subproject" ruse is baloney. I didn't fall off the turnip truck yesterday and I have read all about the Trojan Horse. On 12/15/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > By the way, the original decision to incorporate Shale as a subproject > occurred nearly 11 months ago: > > http://marc.theaimsgroup.com/?l=struts-user&m=110651419515521&w=2 > > -- Paul > > > Craig > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [ANNOUNCEMENT] Apache Struts offers "Shale" for JSF
This reads like Shale is not only a proposal but part of Struts. Is that true? If that is true, can someone explain how that happened? What the process was? On 12/14/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > > 14 Dec 2005 - To give JavaServer Faces developers a head start on building > scalable web applications for the enterprise, Apache Struts now offers the > Shale Framework. Like the original "Struts Action Framework", Shale > provides > developers with a front controller, and several other components, to > provide > the "invisible underpinnings that hold an application together". > > "When JavaServer Faces arrived," explains the Struts website, "our > development community chose to 'make new friends but keep the old'. Some > of > us want (or need) to stick with the original request-based framework. > Others > are ready to switch to an component-based framework that builds on > JavaServer Faces. We offer both frameworks because we have volunteers to > create and maintain both frameworks." > > Shale is based on the recently standardized JavaServer Faces APIs, and > focuses on adding value, rather than redundantly implementing features > that > JSF already provides. Shale will run on any compliant JSF implementation, > including the one being developed by the Apache MyFaces project. It also > includes many features that Struts users appreciate, such as supporting > client side validation and the Tiles framework. > > Struts Shale was discussed by Craig McClanahan in a talk at ApacheCon on > Tuesday, December 13, 2005, entitled "Shale: The Next Struts??". Slides > from > the talk are available online [ > http://people.apache.org/~craigmcc/apachecon-2005-shale.pdf]. > > For more about Shale, visit the Struts Shale website [ > http://struts.apache.org/struts-shale/]. > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Clarification on Shale Framewok
I would suggest that you read the notes that Rod Johnson, the creator of Spring, on Shale for starters. Shale should be called "Huckster". On 11/29/05, Kade Jeevan Kumar <[EMAIL PROTECTED]> wrote: > Hi! > > I worked on Struts 1.1 and also on 1.2. I came across Shale framework > which is look like the JSF. > > Correct me if am wrong and also kindly help me out to know more abt Shale > framework. > > I have few questions . > > 1) How it is related to Struts framework > 2) How it works > 3) Is part of Struts or differ > 4) How it will be useful/ advantage to existing Struts framework > 5) What kind of programming language requried for Shale framework > 6) What i can do with Shale framework. > 7) Is Shale framework going to compete with other frameworks like JSF, > which is component oriented architecture > > > may be my question are repeated but help me out in clearing this confusion > > -Thanks > Jeevan > > > - > Yahoo! Music Unlimited - Access over 1 million songs. Try it free. > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: site/build/DRAFTS.txt
What is with the silence on this WebWorks? That is very interesting. On 11/26/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > Believe it or not, the ASF actually has a Public Relations Committee, > that likes to do things like collect together a stack of press > releases to send out during ApacheCon, which starts in two weeks. > There are some draft announcements in a new file named "DRAFTS.txt" in > the Site Build folder, including the Action name change, Shale, and > Tiles. > > We haven't done this before, but I guess we'd do something like: let > these ruminate for a day or three, send them along to the PRC, and > then update the Announcements section of the site during ApacheCon. > > These releases typically contain quotes, and so if any of the > committers want to comment and quote yourself, feel free :) > > Of course, once we get some feedback on the WebWork proposal, we might > want to add a draft announcement about that too. > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [Struts Wiki] Update of "StrutsTags" by FrankZammetti
Good show, Frank! Do you ever sleep? On 11/24/05, Apache Wiki <[EMAIL PROTECTED]> wrote: > > Dear Wiki user, > > You have subscribed to a wiki page or wiki category on "Struts Wiki" for > change notification. > > The following page has been changed by FrankZammetti: > http://wiki.apache.org/struts/StrutsTags > > > -- > > == Ajax Tags == > > + AjaxTags is an enhanced version of the standard Struts HTML taglibs that > provides an easy way to add AJAX functionality to an existing struts app > through a completely declarative approach (read: it's all an XML config > file). This enhanced taglib provides 100% compatibility with the normal > HTML taglib and in fact requires NO changes to existing pages UNTIL you want > to add AJAX functions. > + > + The original AjaxTags project, which is still available on the Struts > Apps SourceForge page at http://struts.sourceforge.net is **DEPRECATED** > in favor of the AjaxTags subcomponent of the Java Web Parts (JWP) project at > http://javawebparts.sourceforge.net. AjaxTags in JWP is a much more > powerful and flexible version of the original concept and IS NOT > STRUTS-SPECIFIC like the original was. While the original version is still > available, it is no longer being developed and will likely NOT work with > future Struts versions. > + > + It is HIGHLY recommended that the AjaxTags in JWP be used if this is > something you are interested in as you will definitely find it more > feature-rich and just as easy to use, and it IS being supported and further > developed (I will still support the original version as much as I can, but > at a lower priority than the version in JWP). > + > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [PROPOSAL] Merger with WebWork
Capital! On 11/25/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > Presented by: Don Brown, Ted Husted, Jason Carreira, and Patrick Lightbody > > Between the Clarity hubbub [1] and the Java Web Alignment brouhaha > [2], it came up that WebWork would like to merge with another > framework. Ted and Don followed up with the two core WebWork > developers, Patrick Lightbody and Jason Carreira. As it turns out, > they are very interested in merging WebWork with Struts. An archive of > our discussions is available as a Quick Topic thread [3]. > > As some of you know, the underlying idea behind Ti was to use WebWork > as the core of Struts Action Framework 2.x. Conceptually, WebWork and > Struts 1.x are very similar. We've often said, without embarrassment, > that WebWork does many things better than Struts 1.x. Meanwhile, > WebWork has the ability to provide a layer of almost full > backwards-compatibility for Struts 1.x, and we have already > demonstrated we can integrate Beehive's (very cool) Page Flow with > WebWork. > > PROPOSAL: Bring WebWork into Struts through Struts Ti > > We would to amend the Struts Ti sandbox proposal to provide for > merging WebWork 2.2 into our codebase. The WebWork merger would be Ti > phase 1. Much of the work now proposed for Ti would become phase 2. > > * Ti phase 1 = WebWork 2.2 + Struts 1.x compatibility library and > migration tools > * Ti phase 2 = phase 1 + Commons Chain integration + Beehive's Page > Flow + simplified annotations + quick development mode > > When the Ti phase 1 has coalesced and is providing a high degree of > Struts 1.x compatibility, our intention would be to propose Ti as a > Struts Action Framework 2.x candidate. Until that time, we would > continue to consider Ti a "next generation" proposal and, pending a > decison by the PMC, avoid attaching the 2.x label to Ti. > > When BeeHive Page Flow matures, it may be proposed to be merged with > Struts Ti as phase 2. That work could also be positioned as a new > subproject depending on where the PMC feels it would be better suited. > As we work on Struts Ti, we would also expect that work would continue > on Struts Action 1.x, perhaps including feature changes that would > bring the codebases even closer together. > > To get started, we could bring the WebWork codebase into the > Foundation through the Incubator. As part of the proposal to the > Incubator, we could elect Patrick and Jason as committers, so that > they could help us get Ti ready for an acceptance vote. > > There is also a Confluence space [4] setup to manage documents > relating to the proposal. > > -- Don Brown, Ted Husted, Jason Carreira, and Patrick Lightbody. > > [1] Clarity - > http://opensource2.atlassian.com/confluence/oss/display/WAG/Clarity > > [2] Java Web Alignment Group - > http://opensource2.atlassian.com/confluence/oss/display/WAG/Home > > [3] Quick Topic Thread - > http://www.quicktopic.com/33/H/KBfrHFUehSj/p16.1#QTmsg4 > > [4] Confluence space - > http://opensource.atlassian.com/confluence/oss/x/kQY > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Struts 1.3 Naming
The answer, in a more serious vein, Laurie, is that it doesn't make sense for Struts to use the same name for itself and other tag-a-long wannabees. Dump them into research and development and leave them to fend for themselves on their own merits, which are suspect. Then, there will be no problem. I think it is hilarious that this community has gotten itself so beholden to non-Struts interests that it has trouble using its own name. What a situation. On 11/3/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > The Struts project used to have a single deliverable/artifact, which was > Struts, the product. Using the same name for both made sense then. Now > that the Struts project has multiple deliverables/artifacts, they > obviously need different names. It just happens that many of the > deliverables are subcomponents of the original product, and that one is > an assembly of deliverables roughly equivalent to the original product. > > So, the question is, does it make sense to overload the name 'Struts' to > mean both > > - Struts: the project (w/ various deliverables) > - Struts: the product (a deliverable of the project, > comprised of other deliverables but *not* all of them) > > Especially since then Shale, Ti, etc. are at the same conceptual level > as (and not a part of) Struts (the product), even though they are a part > of Struts (the project)... > > I do think there needs to be a name, distinct from the project name, to > describe the (currently primary) deliverable. If you're still not > convinced, try removing '(the project)' and '(the product)' from this > email and see if it still makes any sense ;-) > > L. > > Frank W. Zammetti wrote: > > One option I've said a couple of times that isn't on that list and seems > > like it isn't getting due consideration: "STRUTS"! > > > > I really don't understand why there would be any desire or need to > > change from the name in use now. As Laurie quite coherently stated > > earlier today, there is already an understanding in the community that > > Struts is a project, but also is a product. IMO, that should continue > > to be true. > > > > We should see: > > > > Struts 1.3.0 > > > > ...which consists of: > > > > Core x.x.x > > Tiles x.x.x > > Validator x.x.x > > ...and so on... > > > > I think it's fair to say that the version number of Core would always > > match the version number of Struts. But the other subproject numbers > > can go off and do whatever they want. > > > > But when someone comes to get Struts, *TODAY*, they are looking for that > > one download that contains everything they need. I don't see why this > > should change after breaking out the subprojects. > > > > How should the Struts version number increment? I'm not as sure about > > that, but that is to me a separate question anyway. Call it Struts and > > be done with it. That neatly avoids all the confusion IMO. > > > > Frank > > > > Wendy Smoak wrote: > > > >> On 11/3/05, Don Brown <[EMAIL PROTECTED]> wrote: > >> > >> > >>> BTW, was "Struts > >>> Distribution" voted down already, because I thought that was the most > >>> intuitive > >>> name for what we are trying to do. > >> > >> > >> > >> IIRC it was Martin's suggestion, I think it got lost in the Great > >> Version Debate. :) > >> > >> So far we have > >> - Struts Classic > >> - Struts Core Library > >> - Struts Distribution > >> > >> Any other options, and which do you prefer? > >> > >> -- > >> Wendy > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > >> > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Struts 1.3 Naming
Bingo! The palace revolt continues! On 11/3/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > The Struts project used to have a single deliverable/artifact, which was > Struts, the product. Using the same name for both made sense then. Now > that the Struts project has multiple deliverables/artifacts, they > obviously need different names. It just happens that many of the > deliverables are subcomponents of the original product, and that one is > an assembly of deliverables roughly equivalent to the original product. > > So, the question is, does it make sense to overload the name 'Struts' to > mean both > > - Struts: the project (w/ various deliverables) > - Struts: the product (a deliverable of the project, > comprised of other deliverables but *not* all of them) > > Especially since then Shale, Ti, etc. are at the same conceptual level > as (and not a part of) Struts (the product), even though they are a part > of Struts (the project)... > > I do think there needs to be a name, distinct from the project name, to > describe the (currently primary) deliverable. If you're still not > convinced, try removing '(the project)' and '(the product)' from this > email and see if it still makes any sense ;-) > > L. > > Frank W. Zammetti wrote: > > One option I've said a couple of times that isn't on that list and seems > > like it isn't getting due consideration: "STRUTS"! > > > > I really don't understand why there would be any desire or need to > > change from the name in use now. As Laurie quite coherently stated > > earlier today, there is already an understanding in the community that > > Struts is a project, but also is a product. IMO, that should continue > > to be true. > > > > We should see: > > > > Struts 1.3.0 > > > > ...which consists of: > > > > Core x.x.x > > Tiles x.x.x > > Validator x.x.x > > ...and so on... > > > > I think it's fair to say that the version number of Core would always > > match the version number of Struts. But the other subproject numbers > > can go off and do whatever they want. > > > > But when someone comes to get Struts, *TODAY*, they are looking for that > > one download that contains everything they need. I don't see why this > > should change after breaking out the subprojects. > > > > How should the Struts version number increment? I'm not as sure about > > that, but that is to me a separate question anyway. Call it Struts and > > be done with it. That neatly avoids all the confusion IMO. > > > > Frank > > > > Wendy Smoak wrote: > > > >> On 11/3/05, Don Brown <[EMAIL PROTECTED]> wrote: > >> > >> > >>> BTW, was "Struts > >>> Distribution" voted down already, because I thought that was the most > >>> intuitive > >>> name for what we are trying to do. > >> > >> > >> > >> IIRC it was Martin's suggestion, I think it got lost in the Great > >> Version Debate. :) > >> > >> So far we have > >> - Struts Classic > >> - Struts Core Library > >> - Struts Distribution > >> > >> Any other options, and which do you prefer? > >> > >> -- > >> Wendy > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > >> > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Struts 1.3 Naming
What a concept. But, Frank, this leaves no room for things like Struts JSF, etc. If Struts is just Struts, what will the people who want it to be non-Struts do? On 11/3/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > One option I've said a couple of times that isn't on that list and seems > like it isn't getting due consideration: "STRUTS"! > > I really don't understand why there would be any desire or need to > change from the name in use now. As Laurie quite coherently stated > earlier today, there is already an understanding in the community that > Struts is a project, but also is a product. IMO, that should continue > to be true. > > We should see: > > Struts 1.3.0 > > ...which consists of: > > Core x.x.x > Tiles x.x.x > Validator x.x.x > ...and so on... > > I think it's fair to say that the version number of Core would always > match the version number of Struts. But the other subproject numbers > can go off and do whatever they want. > > But when someone comes to get Struts, *TODAY*, they are looking for that > one download that contains everything they need. I don't see why this > should change after breaking out the subprojects. > > How should the Struts version number increment? I'm not as sure about > that, but that is to me a separate question anyway. Call it Struts and > be done with it. That neatly avoids all the confusion IMO. > > Frank > > Wendy Smoak wrote: > > On 11/3/05, Don Brown <[EMAIL PROTECTED]> wrote: > > > > > >>BTW, was "Struts > >>Distribution" voted down already, because I thought that was the most > intuitive > >>name for what we are trying to do. > > > > > > IIRC it was Martin's suggestion, I think it got lost in the Great > > Version Debate. :) > > > > So far we have > > - Struts Classic > > - Struts Core Library > > - Struts Distribution > > > > Any other options, and which do you prefer? > > > > -- > > Wendy > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > AIM: fzammetti > Yahoo: fzammetti > MSN: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: Web Framework Consolidation
I guess if you don't mind having a pile of controllers in an MVC environment and don't having leaky abstractions abounding in your code, this would work. Myself, I like to KISS and do not like leaky abstractions. On 10/19/05, Rich Feit <[EMAIL PROTECTED]> wrote: > JSF (or any framework that supports serverside component/event-based > pages and which is pluggable enough) is not incompatible with an > action-based controller like Struts. To use them together, you let your > JSF pages handle intra-page interactions (possibly spanning multiple > requests) and then raise actions on the controller to navigate to other > pages (and to run app-level code that your pages shouldn't know about). > It fits nicely, and in a lot of ways it's like using JSP as your view > tier... only with much more capable pages. > > Rich > > Dakota Jack wrote: > > >Bolting JSF onto Struts makes no sense. They are simply incompatible. > > If you want to do something with the merits of both, you still have > >to choose which way you want to go. You cannot go both ways, unless > >you are doing it just to fish people in. > > > >On 10/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > > > > >>Just a few opinions from the peanut gallery... > >> > >>The era of the "classic" webapp is dead. Any new framework that doesn't > >>make it easy (well, EASIER anyway) to develop robust RIAs is dead on > >>arrival as far as I am concerned. > >> > >>Further, I do not believe that the action-centric and component-centric > >>models need be exclusive of each other and in fact I believe that is the > >>natural evolution of things. I don't think this necessarily implies an > >>approach like bolting JSF onto Struts for example, but then again maybe > >>that is the most natural path. The real point though is the merging of > >>the two approaches into *something*, whatever that something winds up being. > >> > >>So, if Clarity is going to take into consideration the building of RIAs > >>at its core, than I for one will be interested in how it evolves. IF > >>that isn't a central theme though, then it's DOA from my perspective. > >> > >>All of the frameworks involved do many things right, so it would seem > >>logical to me that as long as you choose the things that work to merge, > >>the end result should be pretty good. I would start by getting input > >>from the community on what aspects of the contributing frameworks they > >>feel truly work and are must-haves for a next-generation framework. > >>Heck, the results of such a question could wind up being your goal > >>statement entirely :) > >> > >>I would also make the point that Struts is the market leader for good > >>reason and so I would hope it isn't the fourth banana in the group. > >>Some people seem to believe that Struts is obsolete, or is rapidly > >>becoming so, is showing it's age, etc. I believe this is only the case, > >>if in fact it is, because it has been allowed to stagnate a bit in terms > >>of truly evolving. It has been on autopilot for way too long and other > >>frameworks have had a chance to pass it by. Be that as it may, the > >>point is that I believe for a new framework to be successful it should > >>take more cues from Struts on what TO do rather than what NOT to do. > >>Anything less is, IMO, foolishly ignoring the reputation and community > >>and success that Struts has enjoyed. > >> > >>Those are my initial thoughts. In any case, I offer my sincerest Good > >>Luck in the endeavor, I'll be interested to see how it goes. > >> > >>-- > >>Frank W. Zammetti > >>Founder and Chief Software Architect > >>Omnytex Technologies > >>http://www.omnytex.com > >>AIM: fzammetti > >>Yahoo: fzammetti > >>MSN: [EMAIL PROTECTED] > >> > >>Don Brown wrote: > >> > >> > >>>Consolidation is a relatively unknown concept in the crowded web > >>>framework space. While most frameworks are open source allowing > >>>cross-pollination, collaboration is still rare resulting in duplicated > >>>efforts and confusion for the end user. Struts Ti, a next-gen project > >>>in the Struts sandbox, tried to buck the trend by building on WebWork > >>>rather than wasting its time writing yet another Model2 framework. > >>> > >>>Taking this level of cooperation to the next level
Re: Web Framework Consolidation
r of WebWork and XWork, with both a > > >>>Struts and simplified "flavor" to it. > > >>> - Rich represents the Beehive team and also works on the Struts Ti > > >>>project. Rich will represent most of the Beehive input. > > >>> - Finally, I hope to, more than anything, act as a facilitator for > > >>>this whole project. Obviously I have a WebWork-slanted perspective, > > >>>but I believe that facilitating this process is more important than > > >>>any set of features or implementations choices. > > >>> > > >>>As I mentioned to you guys individually, I think the best way to move > > >>>forward is to take the following steps. I've taken a stab at the > > >>>first item as well. > > >>> > > >>> > > >> > > >>0) Agree on the software license. Without the right license > > >>(ASF), > > >>I'm guessing many of us wouldn't be able to participate. > > >> > > >>Also, a basic question. Is this an open source project? > > >> > > >> > > >> > > >>>1) Establish the rules: a small, agreed upon list of rules that we > > >>>promise to adhere to while working on this project. These will be > > >>>especially important in the early phases. > > >>> > > >>>1) Complete a statement: we need to come up with a single paragraph > > >>>that sums up this effort. It should include the desire to work > > >>>together, the desire for clarity in the java web space, and the > > >>>desire to move beyond "petty" differences about implementation > > >>>choices. In short, this mission statement, when releases as a press > > >>>release to the entire community, should be powerful enough to get > > >>>everyone excited about it and know for sure that _this_ is the effort > > >>>that will bring web development productivity back to the Java camp. > > >>> > > >>> > > >> > > >>Totally. The only thing I'd add here (maybe obvious) is that this > > >>should go beyond the desire to work together and bring clarity to the > > >>space -- some high-level characterization of what the framework itself > > >>is about. > > >> > > >> > > >> > > >>>2) Announce the project: we need to gather excitement around this as > > >>>soon as possible. Doing so will not only get us early feedback from > > >>>the community, it will most likely stave off a few more web > > >>>frameworks from being created (I found two more just today - eek!). > > >>> > > >>>3) Set up a neutral place to host the project, including SVN, wiki, > > >>>bug tracker, etc. This place must be detached from Jakarta/Struts, > > >>>Spring, and OpenSymphony and must stay that way until we all feel > > >>>comfortable working together. That will likely happen about half way > > >>>through step 4... > > >>> > > >>> > > >> > > >>It would be as open as the wikis, mailing lists, repositories, etc. of > > >>the rest of the projects, right? > > >> > > >> [additional item -- maybe falls under #4] Agree on general features > > >>and characteristics of the framework. Some examples (note: I'm not > > >>assuming everyone would agree to these particular ones :) ): > > >>- support entities that are flow controllers as first class > > >>citizens > > >>- support the association of per-user state with a flow controller > > >>- allow Java 5 annotations as a way to configure controllers > > >>- provide a fast no-redeploy iterative dev experience > > >> > > >> [additional item -- maybe falls under #4] Mock up some files/ > > >>artifacts > > >>as the user would see/write them. Like what Don did early on in Ti > > >>(http://wiki.apache.org/struts/StrutsTi/ControllerMock ). > > >> > > >> > > >> > > >> > > >>>4) Now for the hard part: map out a technical implementation. > > >>> > > >>>5) Release and re-establish Java as the place to build web > > >>>applications. I hope for this to happen within 8-12 months time, > > >>>starting today. > > >>> > > >>>So here are my ideal set of rules. Please adjust as you see fit: > > >>> > > >>> - Above all else, we recognize that consolidation is the overriding > > >>>goal. > > >>> - We recognize that we'll all have to compromise on items we are > > >>>passionate about, but that the overall project success is more > > >>>important. > > >>> - This project aims to unify WebWork, Struts, Spring MVC, Beehive, > > >>>and Spring WebFlow in to a single project that establishes clear > > >>>leadership in the web development space. > > >>> - All project leaders understand that once this project is > > >>>releases, > > >>>future work their own projects should cease (other than supporting > > >>>it, minor releases, migration path to Clarity, etc). > > >>> - Technical disputes should be coordinated by those _least_ > > >>>familiar > > >>>with the topic, and therefore least biased. > > >>> - When criticizing or proposing alternatives or otherwise "stopping > > >>>forward progress" - we promise to ask ourselves if this issue we're > > >>>about to raise is really "worth it". > > >>> - We recognize that not everyone works the way we do and we > > >>>understand that we may have to work hard to find common ground. > > >>> > > >>> > > >> > > >> The rules... I agree, for us to succeed, we need these. We'll all > > >>have to take as a prime goal compromise/progress over dogma. My main > > >>comment is about consolidation and ceasing development on the ancestor > > >>projects. Beehive has components that I assume are far outside the > > >>mission of Clarity (e.g., JSR 181 Web Services Metadata > > >>implementation). Just want to make sure we're not trumpeting the > > >>death > > >>of entire frameworks that don't overlap. Relatedly, I feel that the > > >>cease-development clause should go something like this: > > >>"... will cease developing features that overlap with features > > >>in Clarity." > > >>It's clearly not in the interest of any project to keep plugging > > >>along with a redundant framework (c'mon, how can you compete with > > >>Clarity? :) ), but I imagine that many features will fall outside the > > >>scope of what's done here. > > >> > > >>A final question: would people agree that we should start core/focused > > >>(e.g., controller tier, view agnostic, not trying to define an entire > > >>stack)? Seems like this is something that would help us move forward > > >>more quickly, and would prevent us from trying to make too many leaf > > >>nodes part of the trunk. > > >> > > >> > > >> > > >>>So what's next? Let's nail down the rules and then move on to a > > >>>mission statement that we can announce. Remember: once we announce > > >>>this, there's no going back, so let's spend some time on the rules > > >>>and the mission statement. For now, please email back and forth any > > >>>edits/additions to the rules. > > >>> > > >>>This is really exciting! Sorry for the long email and the (likely > > >>>very) bureaucratic approach I'm taking with this -- I hope it adds > > >>>some value. > > >>> > > >>>Patrick > > >>> > > >>> > > >> > > >>Exciting stuff! > > >> > > >>Rich > > >> > > > > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] RE: [ANNOUNCEMENT] New Struts Committer: Gary vanMatre
Well, you aren't doing a great job, David, because what you have never noticed happened again this last week. Why don't you try doing a search for SHALE and JSF for the last week? I really don't think this is a big deal, but wonder why someone would bother saying what was going on here without making at least a cursory check. Anyway, your suggestion is clearly mistaken. On 8/25/05, David Durham <[EMAIL PROTECTED]> wrote: > Dakota Jack wrote: > > First, comparing Struts and JSF is like comparing C++ and Visual > > Basic. Struts is REQUEST-DRIVEN MVC and JSF (Shale) is PAGE CENTRIC > > RAD (rapid development with tools as in VB). Anyone that cannot see > > they don't go together, frankly, is not that insightful, in my > > opinion. The present idea that they go together is one of the more > > interesting marketing ploys in my recent experience. I have to admit > > that Craig is not only a superb coder but also a clever politician. I > > would have bet big money that no one could convince the Struts > > community to share a bedroom with JSF. I would have lost. I still am > > amazed. > > > > Second, Rod Johnson only has three books out that I know of. There is > > a whole section on web frameworks in Ch. 13 of Expert One-on-One J2EE > > Development without EJB. That is where I "read it". You can read the > > same thing from numerous other folks in the Struts lists as well. Of > > course, if you don't want to see it, you won't. > > > > Third, I am amazed that people who consider themselves to be expert in > > this area, and who should be expert in this area given their status, > > people such as yourself, Matthias, even argue this point. A modicum > > of understanding of the two frameworks shows that they are like night > > and day. Indeed, Craig is constantly trumpeting that JSF is a "new > > deal" which should tell you that it is not what he now decries as the > > "old deal", Struts. He says it is a huge architectural shift. He is > > right. You CANNOT combine the two. You CAN mix them into what is > > essentially a mush, a hodge-podge. But, you cannot combine them. You > > have to have a switch that chooses one over the other in the mix. > > That is what Rod Johnson says and that is what I agree with. > > > > Fourth, I am about to leave the debate arena on this one, however. > > This is all too nutty for me to stick with any longer. I don't mind a > > good spirited debate on architecture, but I am not intersted in a > > political community with its head in the sand. When a VB expert is > > voted into the C++ expert community, that is enough for me. And, when > > a JSF expert is voted into the Struts community, that is enough for > > me. I have to admit that I am completely enamored anyway with the > > Spring IoC and AOP approach and believe that a one can build something > > akin to the Struts package there. I will, of course, remain > > interested in Struts even though the interest will be more one of > > morbid fascination with the process that is happening here. > > > > Cheers! > > Thanks, I'm following this list off and on, but fairly regularly, I > don't recall anyone else saying "hey, this shouldn't be in struts". I > have no doubt that others feel the way you do, just interested in some > names that's all. I don't think this is a decision that's made based on > technical merits as you suggest it should. From what I can tell, this > is a community effort as much as it is a technical effort. > > > - Dave > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale Volunteers (was Re: [OT] RE: [ANNOUNCEMENT])
This is one point of view, Ted, and one that needs to be considered of course. I think it is not accurate myself. Another point of view is that Struts needs to come up to snuff in the arena and is being left behind. Having half the community spend time on a completely incompatible framework like JSF will ensure that it won't recover. That is nother point of view. Having half of the other half chase the patch of a chain-based architecture launched off a template-method design won't help either. That also is another point of view. I suspect the result will be that Craig will get what he was aiming for, the Struts name for JSF. If so, my hats are off to him for a remarkable campaign. While, I am always willing to fight the good fight, I have to admit that this one looks lost and that, since I am not a JSF guy, my choices have been effectively narrowed to a non-Struts future in my coding. This does not mean, of course, that there is not a long period of weaning off Struts. Business moves slower than developing ideas. I am presently switching over to Spring, and will try to develop a Struts-like architecture there. (I know there is a Struts plugin, but I would like an up-to-date IoC, AOP, framework under a real Struts.) I probably will be better off there anyway, since I am philosophically much closer to what is going on there. As Ted keeps noting, this community is tied a great deal to the projects they are working on and really has no time to sit back and think things through before coding. Code is what is master here, not thought. That is understandable. I am sure, as people are always saying around here that there is a niche for JSF. People who need tools will love it. Heck, there was a niche for Windows, wasn't there? Maybe JSF will finally succeed. Maybe not. But, it sure doesn't do what I want done. This sort of solution works against what I think is the future, which is a smaller group of highly educated, well-trained and efficient coders as opposed to a large group of tool jockeys that really don't know what they are working with when coding. Good luck to you all. While my feet are going elsewhere, I certainly will remain interested in the progress of this community. Cheers, and I hope to have been of some assistance in clarifying something for someone. Sorry that so many got their knickers in a twist. On 8/24/05, Ted Husted <[EMAIL PROTECTED]> wrote: > Since the ANNOUNCEMENT thread is veering off-topic > On 8/24/05, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > ah... > > > > were did you read it ?!? > > > > > Rod Johnson and many others. But, that should be a start to > > > think about, Dave. > > From the ASF's point of view, the only thing that matters is whether > there are volunteers who are ready, willing, and able to create and > maintain the software in the Apache Way. We're not a steering commitee > trying to decide what's best for everyone. We're a bunch of engineers > who want to share the software we're using with who other engineers > who might want to use it. > > Since there are volunteers ready, willing, and able to create and > maintain Shale in the Apache Way, the only question that remains is > where to find more volunteers. The people actually working on Shale > now seem to think that the Apache Struts project is a good place to > find more volunteers. Since Shale is to JSF what Struts Classic is to > JSP, the Struts PMC agreed the idea had merit, and we made Shale a > subproject. Meanwhile, other volunteers continue to work on Struts > Classic, unabated. > > Of course, at some point in time, the people actually working on Shale > may decide that they could find more volunteers as a top-level > project, or as subproject of another Apache TLP (like, say, Apache > MyFaces), or somewhere else in cyberspace. The Shale volunteers might > then choose to continue work in some other repository. Or they might > decide to continue working here. But, the only people entitled to make > that decision are the ones creating and maintaining the Shale > codebase. The most the rest of can do is wish them godspeed. > > We're seeing a similar thing happening with Tiles today. Right now, > volunteers are extracting Tiles into a separate subproject. Once that > is done, the volunteers might decide to continue work under the Struts > repository, or somewhere else. But, whatever they decide, the decision > will be driven by the simple question: Where will we find other > volunteers to help? > > -Ted > > --------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] RE: [ANNOUNCEMENT] New Struts Committer: Gary vanMatre
First, comparing Struts and JSF is like comparing C++ and Visual Basic. Struts is REQUEST-DRIVEN MVC and JSF (Shale) is PAGE CENTRIC RAD (rapid development with tools as in VB). Anyone that cannot see they don't go together, frankly, is not that insightful, in my opinion. The present idea that they go together is one of the more interesting marketing ploys in my recent experience. I have to admit that Craig is not only a superb coder but also a clever politician. I would have bet big money that no one could convince the Struts community to share a bedroom with JSF. I would have lost. I still am amazed. Second, Rod Johnson only has three books out that I know of. There is a whole section on web frameworks in Ch. 13 of Expert One-on-One J2EE Development without EJB. That is where I "read it". You can read the same thing from numerous other folks in the Struts lists as well. Of course, if you don't want to see it, you won't. Third, I am amazed that people who consider themselves to be expert in this area, and who should be expert in this area given their status, people such as yourself, Matthias, even argue this point. A modicum of understanding of the two frameworks shows that they are like night and day. Indeed, Craig is constantly trumpeting that JSF is a "new deal" which should tell you that it is not what he now decries as the "old deal", Struts. He says it is a huge architectural shift. He is right. You CANNOT combine the two. You CAN mix them into what is essentially a mush, a hodge-podge. But, you cannot combine them. You have to have a switch that chooses one over the other in the mix. That is what Rod Johnson says and that is what I agree with. Fourth, I am about to leave the debate arena on this one, however. This is all too nutty for me to stick with any longer. I don't mind a good spirited debate on architecture, but I am not intersted in a political community with its head in the sand. When a VB expert is voted into the C++ expert community, that is enough for me. And, when a JSF expert is voted into the Struts community, that is enough for me. I have to admit that I am completely enamored anyway with the Spring IoC and AOP approach and believe that a one can build something akin to the Struts package there. I will, of course, remain interested in Struts even though the interest will be more one of morbid fascination with the process that is happening here. Cheers! On 8/24/05, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > ah... > > were did you read it ?!? > > > Rod Johnson and many others. But, that should be a start to > > think about, Dave. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] New Struts Committer: Gary vanMatre
Rod Johnson and many others. But, that should be a start to think about, Dave. On 8/23/05, David Durham <[EMAIL PROTECTED]> wrote: > Dakota Jack wrote: > > That would be, James, not Dakota but the list. This is the most > > unusual committer nomination I have ever seen. James, will it ever be > > possible to get you to respond to these inquiries, if you must > > respond, in an adult way? I appreciate Joe's perspective, although I > > think Shale is part of Struts only because it merges with Craig's > > career and Craig understandably has a bit of pull around here. > > Besides you, who is saying that it should not be part of the Struts? > > > - Dave > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] New Struts Committer: Gary vanMatre
That would be, James, not Dakota but the list. This is the most unusual committer nomination I have ever seen. James, will it ever be possible to get you to respond to these inquiries, if you must respond, in an adult way? I appreciate Joe's perspective, although I think Shale is part of Struts only because it merges with Craig's career and Craig understandably has a bit of pull around here. On 8/22/05, James Mitchell <[EMAIL PROTECTED]> wrote: > Did someone forget to run this by Dakota first? > > Oh wait, no one cares what Dakota thinksnever mind. > > -- > James Mitchell > Software Engineer / Open Source Evangelist > Consulting / Mentoring / Freelance > EdgeTech, Inc. > http://www.edgetechservices.net/ > 678.910.8017 > AIM: jmitchtx > Yahoo: jmitchtx > MSN: [EMAIL PROTECTED] > Skype: jmitchtx > > > > On Aug 22, 2005, at 1:50 PM, Dakota Jack wrote: > > > Just wondering if this was not a palace revolt to get JSF into the > > back door. Wondering how a person who works on something that is not > > even part of struts and not struts, here, becomes a struts committer. > > Interesting! I am not questioning his ability. Don't know anything > > about him, which seems odd. > > > > On 8/22/05, David Geary <[EMAIL PROTECTED]> wrote: > > > >> Congratulations Gary! Welcome aboard. > >> > >> Gary has done a great deal of work on Clay, which has turned into > >> one of the most popular features of Shale. > >> > >> > >> david > >> > >> Le 05-08-21 à 18:53, Craig McClanahan a écrit : > >> > >> > >>> Please join me in welcoming Gary vanMatre as a new Struts committer. > >>> Gary has been quite busy proposing code for the "Clay" plug-in on > >>> Shale, and has also been supportive on the dev and user mailing > >>> lists > >>> (for both Struts and MyFaces) ... we look forward to his energy > >>> being > >>> available to the entire Struts project as well. > >>> > >>> Welcome, Gary! (And now you can process some of your own > >>> outstanding > >>> code diffs :-). > >>> > >>> PMC vote: 4 +1 > >>> > >>> Craig > >>> > >>> ---- > >>> - > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > > -- > > "You can lead a horse to water but you cannot make it float on its > > back." > > ~Dakota Jack~ > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] New Struts Committer: Gary vanMatre
Just wondering if this was not a palace revolt to get JSF into the back door. Wondering how a person who works on something that is not even part of struts and not struts, here, becomes a struts committer. Interesting! I am not questioning his ability. Don't know anything about him, which seems odd. On 8/22/05, David Geary <[EMAIL PROTECTED]> wrote: > Congratulations Gary! Welcome aboard. > > Gary has done a great deal of work on Clay, which has turned into > one of the most popular features of Shale. > > > david > > Le 05-08-21 à 18:53, Craig McClanahan a écrit : > > > Please join me in welcoming Gary vanMatre as a new Struts committer. > > Gary has been quite busy proposing code for the "Clay" plug-in on > > Shale, and has also been supportive on the dev and user mailing lists > > (for both Struts and MyFaces) ... we look forward to his energy being > > available to the entire Struts project as well. > > > > Welcome, Gary! (And now you can process some of your own outstanding > > code diffs :-). > > > > PMC vote: 4 +1 > > > > Craig > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSF vs. Struts
There is nothing new about JSF. In net terms it is old news On 8/21/05, Ted Husted <[EMAIL PROTECTED]> wrote: > On 8/15/05, Rich Feit <[EMAIL PROTECTED]> wrote: > > In general, I agree with the sentiment that there's a lot of hype in > > this arena, and not all of it is easily backed up. But the Struts > > community has always been a bit hype-adverse, no? > > Once upon a time, people were saying the same sort of things about > custom tags that people now say about JSF. It's too new, it's too fat, > scriplets are faster. We already know how to use scriptlets, why fuss > with tags? > > And, all of those statements were true. In the beginning, custom tags > were slower than scriplets. Five years ago, custom tag compilers were > naive and generated sad, bloated code. But, many of us saw the > potential in custom tags, and we bit the bullet and took the hit. > Sure, the code was sad, but in the greater scheme of things, the tags > are lost in the rounding, and such things are easily fixed by > improving the compiler. The long-term architectural gains custom tags > provided, many of us believed, were worth the short-term code bloat. > Compilers did improve, and all the work we did with custom tag > suddenly became more valuable. > > Custom tags were a pardigm shift for many teams then, and components > are a paradigm shift for many teams today. From experience, many of us > know that custom tags provide many benefits in terms of fast > deployment and easy maintenance. And, from experience, many of us > already know that components provide benefits in terms of fast > deployment. > > Over time, will components also provide the benefits of easy > maintenance? Hmmm, probably. Check back in 2010, and then we'll know > for sure :) > > In the meantime, those of us interested in Struts Classic will > continue to work on Struts Classic, and those of us interested in > Struts Shale can spend our volunteer hours there. > > Like two flowers planted in the same bed, Classic and Shale can be > healthier together than apart. Synergistically, roots can intertwine > and reinforce each other, making two together stronger than either > apart. > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] New Struts Committer: Gary vanMatre
Has this committer to struts ever done anything with struts other than clay and the JSF stuff? On 8/21/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > Please join me in welcoming Gary vanMatre as a new Struts committer. > Gary has been quite busy proposing code for the "Clay" plug-in on > Shale, and has also been supportive on the dev and user mailing lists > (for both Struts and MyFaces) ... we look forward to his energy being > available to the entire Struts project as well. > > Welcome, Gary! (And now you can process some of your own outstanding > code diffs :-). > > PMC vote: 4 +1 > > Craig > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
