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: interceptor-ref name=jsfApplicationSetup param name=actionListener/param param name=defaultRenderKitId/param param name=localeConfig/param param name=messageBundle/param param name=navigationHandler/param param name=propertyResolver/param param name=stateManager/param param name=variableResolver/param param name=viewHandlerorg.apache.shale.tiles.TilesViewHandler/param /interceptor-ref 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: 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
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: interceptor-ref name=jsfApplicationSetup param name=actionListener/param param name=defaultRenderKitId/param param name=localeConfig/param param name=messageBundle/param param name=navigationHandler/param param name=propertyResolver/param param name=stateManager/param param name=variableResolver/param param name=viewHandlerorg.apache.shale.tiles.TilesViewHandler/param /interceptor-ref 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: [jira] Created: (WW-1388) Shopping Cart Example throws HTTP 500
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
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: [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
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
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, 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
] - 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
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: 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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
] 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)
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=34915messageID=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)
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)
? 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)
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)
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: 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: [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: action name=employee class=org.apache.struts.action2.showcase.jsf.EmployeeAction interceptor-ref name=basicStack/ interceptor-ref name=jsfStack/ result name=success type=jsf / result name=index type=redirect-actionindex/result /action 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
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: action name=employee class=org.apache.struts.action2.showcase.jsf.EmployeeAction interceptor-ref name=basicStack/ interceptor-ref name=jsfStack/ result name=success type=jsf / result name=index type=redirect-actionindex/result /action 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
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: action name=employee class=org.apache.struts.action2.showcase.jsf.EmployeeAction interceptor-ref name=basicStack/ interceptor-ref name=jsfStack/ result name=success type=jsf / result name=index type=redirect-actionindex/result /action 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
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: action name=employee class=org.apache.struts.action2.showcase.jsf.EmployeeAction interceptor-ref name=basicStack/ interceptor-ref name=jsfStack/ result name=success type=jsf / result name=index type=redirect-actionindex/result /action 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
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 - 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~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 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
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: action name=employee class=org.apache.struts.action2.showcase.jsf.EmployeeAction interceptor-ref name=basicStack/ interceptor-ref name=jsfStack/ result name=success type=jsf / result name=index type=redirect-actionindex/result /action 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
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: [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...
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...
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: 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. snip 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. /snip -- 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
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: 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. snip 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. /snip -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~
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=28320messageID=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: 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=2r=1s=greg.reddinq=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~ -- 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: 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: Proposal for change
, 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
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 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=2r=1s=greg.reddinq=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: 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: 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
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: 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: [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: Fwd: Action/Shale/JSF Overlap? (Was -- RESTful JSF)
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. snip 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 /snip -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~
Re: Reasons for 1.3 release
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
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
less than size of filter,
// the gravel will pass to the next level. if(gravel.getSize
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
Responses are following snippets of your remarks, Frank. snip Anyone can quote chapter and verse from the GoF book. Can you instead explain *why* what's in Struts isn't CoR? /snip 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. snip And, perhaps more importantly, explain why, even if it isn't an exact match for the pattern, it matters one bit? /snip 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. snip 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. /snip 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. snip 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. /snip 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
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
snip 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. /snip 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
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
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: [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: [ANNOUNCEMENT] Apache Struts offers Shale for JSF
to accept that they should reject her claims. The same attack could function as an Appeal to Emotion and a Personal Attackhttp://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 Popularityhttp://www.nizkor.org/features/fallacies/appeal-to-popularity.htmlfallacy. 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 Popularityhttp://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 Popularityhttp://www.nizkor.org/features/fallacies/appeal-to-popularity.htmlthe 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-userm=110651419515521w=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
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-userm=110651419515521w=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
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] wrote: By the way, the original decision to incorporate Shale as a subproject occurred nearly 11 months ago: http://marc.theaimsgroup.com/?l=struts-userm=110651419515521w=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
Re: [ANNOUNCEMENT] Apache Struts offers Shale for JSF
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-userm=110651419515521w=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
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: [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 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: 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
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: 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: 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, developers from four popular web frameworks - Struts, Spring, WebWork, and Beehive, have gotten together to discuss the possibility of consolidating their efforts into a new project, termed Clarity. Clarity would be an action-based MVC framework that combines the commonality of the four aforementioned frameworks into one that can be built upon by all. These discussions have just began, and while no one has officially signed on, I thought I should bring it before the Struts community for feedback. There is still much to work out, but I want to keep the community involved from the beginning. I personally am excited about this project and think it will be beneficial to users and developers alike. The Struts Classic code base is showing its age, but speaking as a developer who maintains old Struts apps, few people have the time and budget to rewrite them from scratch with a more disparate framework like Shale or Wicket. I think
Re: Web Framework Consolidation
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: [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: 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: [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]
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: JSF vs. Struts
No On 8/15/05, Rich Feit [EMAIL PROTECTED] wrote: Hmm... I'm just about to post a reply to that entry. Basically, I feel that although JSF itself can be great view-tier technology, it isn't really a full replacement for Struts. JSF+Shale *is* a replacement for Struts, but I think that's a point which is often lost. An interesting thing about Struts Ti is that it would treat JSF as a first-class view tier without depending on it for anything else. That may or may not turn out to be important, but it does keep JSF as a peer to other view technologies, rather than at the core. I don't think JSF and Struts are incompatible, as long as JSF is being used as a (powerful) view. Intra-page event handling works fine with something like Struts. When the other more general-framework-type functionality is used, there's a conflict. 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? Rich Matthias Wessendorf wrote: FYI http://jroller.com/page/dgeary -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Thursday, August 11, 2005 8:44 AM To: Struts Developers List Subject: Re: JSF vs. Struts I personally think all this exploration is a Very Good Thing(tm). There are a vast number of different ideas out there as to how a modern application framework should be built. Mistakes have been made over the years, lessons have been learned, but we don't all agree on what the mistakes were or what the lessons are! If that sounds bad to anyone, it isn't. It's quite the opposite and is the only way healthy debate and ultimately progress is made. At some point we're going to have to all weed out the options that don't quite measure up, and that will happen via simple market forces (the market in this case being mostly developer mind share), but I don't think that time is now, so the more experimentation, the better. I for one am not willing to declare one thing better than another... I regret having done that in the past prematurely, and certainly not in a manner I'm especially proud of. So, I'm certainly not going to make the same mistake twice. I'm still not sold on JSF, that much has not changed. I do however think there is some decent ideas underpinning it, which is also the case for many of the other frameworks and approaches out there, so declaring JSF or anything else for that matter a failure now is probably not fair either. I do think Jack's point about JSF being around for a while and not really setting the world on fire is fair, although that doesn't mean it has failed, just that it's going a little slower than hoped. My take on JSF is simply this: we'll see. I'm not sold yet, but I'm not willing to say I never will be. As for Shale, I'm not sure I understand why Rod or anyone says that Struts and JSF are not compatible... if the thinking is that the result will be quite a bit different from Struts as we know it today, then I suppose he might be right. That to me doesn't make them incompatible though. From what I have seen of JSF, and what I know of Struts, I can conceive of ways they could be fit together. I haven't had a chance to get into Shale yet, but I have no doubt many of those ideas, and many more I haven't thought of, are present. Why they are incompatible I just don't get, and I don't care who is making the claim, no matter how well-respected they are, I need to see some real, concrete examples before I'm convinced. Struts Ti looks pretty interesting... many of the ideas that were described here a few days ago were quite good in my mind. Should it be the future of Struts? I don't know yet, and I'm not even sure those developing it would be willing to say that at this juncture. It's another possible path, another exploration of possibilities, and that's good. One thing is for sure: most of us look back on the way we developed applications just five years ago and wonder why we ever did things that way. I have absolutely no doubt we'll be doing the same thing in another five years. I too would like to see less hype sometimes, but promoting ones' ideas is human nature. If you think you have a compelling answer, or even the One True Answer, you tell people about it and try and convince them. That's hype. It may not always be helpful, but it's perfectly natural :) Frank Dakota Jack wrote: I have to agree personally with Rod Johnson J2EE without EJBs, Spring framework architect, etc., when he says that Shale is merely a stopgap and that Struts as we know it is simply incompatible with JSF. That seems fairly obvious and I find it hard to believe that anyone familiar with the issues would think any differently. I personally would not hire anyone would thought
Re: 1.3.0 Release - Next Steps
Your assertion in bugzilla that Ted invented stripping .x in 2002 is incorrect. If you think he invented that in 2002 you need to document it. The use of getX() and getY() is another matter entirely. On 8/1/05, Michael Jouravlev [EMAIL PROTECTED] wrote: On 8/1/05, Hubert Rabago [EMAIL PROTECTED] wrote: The fewer than expected time I got to work on this was spent on the list of bugs. I got about a quarter from the list, including two duplicates and a worksforme. The rest are items I just didn't get time to work on, or in an area I'm not that familiar with, or items that other people already had a headstart with so perhaps they might like a chance to resolve it. There's a few there I think should be marked as enhancements (one of which I just marked as such), and even then perhaps be closed after updating documentation to tell users to watch out for those cases (like 35389 and 35477). I hate to poke the wound, but will something be done with http://issues.apache.org/bugzilla/show_bug.cgi?id=30292 (the infamous DispatchAction)? Or it is going to just marinate there? 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~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.0 Release - Next Steps
Here is Ted's 2002 offering: you will see that this has nothing to do with stripping .x. I think, further, that what Ted is talking about originated with Hubert Rabago, although I am not suggesting that Ted is suggesting otherwise. Anyway, this is all irrelevnat. On 7/31/05, Michael Jouravlev [EMAIL PROTECTED] wrote: On 7/30/05, Ted Husted [EMAIL PROTECTED] wrote: But, first things first, we should resolve the problem reports and roll 1.3.0. Does this mean, that even if I present MailReader rewritten with Dialogs, it won't be accepted for 1.3 ? Will it be considered for a future version? Or will the answer be more definite after I show how to make MailReader with dialogs? Do you have any timeframe in mind for 1.3? 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~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.0 Release - Next Steps
Ooops! Forgot the stuff. Here you go.
An endless source of aggravation is the HTML input image element. The
specification says that browsers should treat this control like an
image map. Unlike other buttons, it does not submit a string
representing the button's label, it submits the X and Y coordinates.
If you look at the HTTP post for an image button, you'll see it looks
something like this
myImageButton.x=200
myImageButton.y=300
For most other controls, a Struts developer can create a simple String
property to represent the element. This clearly won't work with an
image button, because it submits two dotted properties instead of a
simple name=value entry like other elements.
Happily, Struts allows an ActionForm to contain, or nest, other
JavaBeans, and will automatically populate the beans using the same
syntax as the image element. (What a co-inky-dink!)
To represent an image input element in your ActionForm, say what you
mean, and use an ImageButtonBean to capture the X and Y parameters.
public final class ImageButtonBean extends Object {
private String x = null;
private String y = null;
public String getX() {
return (this.x);
}
public void setX(String x) {
this.x = x;
}
public String getY() {
return (this.y);
}
public void setY(String y) {
this.y = y;
}
public boolean isSelected() {
return ((x!=null) || (y!=null));
}
} // End ImageButtonBean
Note that we've included a helper method on this bean, isSelected().
This just returns true if either the x or y property is not null. If
both are still null, then isSelected() returns false.
Here's how you could declare two ImageButtonBeans on an ActionForm.
// ..
private ImageButtonBean logonButton = new ImageButtonBean();
public void setLogonButton(ImageButtonBean button) {
this.logonButton = button;
}
public ImageButtonBean getLogonButton() {
return this.logonButton;
}
private ImageButtonBean cancelButton = new ImageButtonBean();
public void setCancelButton(ImageButtonBean button) {
this.cancelButton = button;
}
public ImageButtonBean getCancelButton() {
return this.cancelButton;
}
// ...
The next question will be OK, which button did they push?, so let's
define another helper method on the ActionForm to tell us.
public String getSelected() {
if (getLogonButton().isSelected()) {
return Constants.LOGON;
}
if (getCancelButton().isSelected()) {
return Constants.CANCEL;
}
return null; // nobody home
}
In an Action, determining which button is pressed is then a simple
matter of asking the form what was selected.
String selected = ((myForm) form).getSelected();
if (Constants.CANCEL.equals(selected)) ...
Of course selected doesn't need to be a String; it could be an int, a
custom type to represent your API functions, or even the name of
another method for use with a DispatchAction.
Using API helper methods on ActionForms, as we did with
getSelected(), is a very useful technique. We'll use it again in Tip
#2, when we discuss the standard Dispatch Actions.
HTH, Ted.
On 8/17/05, Dakota Jack [EMAIL PROTECTED] wrote:
Here is Ted's 2002 offering: you will see that this has nothing to do
with stripping .x. I think, further, that what Ted is talking about
originated with Hubert Rabago, although I am not suggesting that Ted
is suggesting otherwise. Anyway, this is all irrelevnat.
On 7/31/05, Michael Jouravlev [EMAIL PROTECTED] wrote:
On 7/30/05, Ted Husted [EMAIL PROTECTED] wrote:
But, first things first, we should resolve the problem reports and roll
1.3.0.
Does this mean, that even if I present MailReader rewritten with
Dialogs, it won't be accepted for 1.3 ? Will it be considered for a
future version?
Or will the answer be more definite after I show how to make
MailReader with dialogs?
Do you have any timeframe in mind for 1.3?
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~
--
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
I think that most everyone would agree that exploration is a very good thing. At least I have not run into the people who take the opposite stand. Unfortunately, I think there is a definite disconnect between market forces and what is the best product. This is particularly true with the computer industry, in my experience. Market forces include hype, and if you want the industry to do well, you are certainly obligated to meet hype with hype. The next email in this thread references an individual's thoughts on JSF versus other options. This reference leaves out stuff that is more than relevant. That is how it works. JSF is struggling, so they are playing hardball at the top. I think that is okay. I can play in that ballpark. I wish so many people were not toadies though and would participate instead of choosing a leader for themselves. However, exploration is great. Wonnderful, wonnderful! I don't think that there is that much to computer programming. It really is not rocket science. And, I don't think the advances have been that great in the last five years, except in the market place. I have used at least five different frameworks equal to or better than Struts and certainly better than JSF before five years ago. I think we do not see often how much there is out there in companies that do not use open source. On 8/10/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: I personally think all this exploration is a Very Good Thing(tm). There are a vast number of different ideas out there as to how a modern application framework should be built. Mistakes have been made over the years, lessons have been learned, but we don't all agree on what the mistakes were or what the lessons are! If that sounds bad to anyone, it isn't. It's quite the opposite and is the only way healthy debate and ultimately progress is made. At some point we're going to have to all weed out the options that don't quite measure up, and that will happen via simple market forces (the market in this case being mostly developer mind share), but I don't think that time is now, so the more experimentation, the better. I for one am not willing to declare one thing better than another... I regret having done that in the past prematurely, and certainly not in a manner I'm especially proud of. So, I'm certainly not going to make the same mistake twice. I'm still not sold on JSF, that much has not changed. I do however think there is some decent ideas underpinning it, which is also the case for many of the other frameworks and approaches out there, so declaring JSF or anything else for that matter a failure now is probably not fair either. I do think Jack's point about JSF being around for a while and not really setting the world on fire is fair, although that doesn't mean it has failed, just that it's going a little slower than hoped. My take on JSF is simply this: we'll see. I'm not sold yet, but I'm not willing to say I never will be. As for Shale, I'm not sure I understand why Rod or anyone says that Struts and JSF are not compatible... if the thinking is that the result will be quite a bit different from Struts as we know it today, then I suppose he might be right. That to me doesn't make them incompatible though. From what I have seen of JSF, and what I know of Struts, I can conceive of ways they could be fit together. I haven't had a chance to get into Shale yet, but I have no doubt many of those ideas, and many more I haven't thought of, are present. Why they are incompatible I just don't get, and I don't care who is making the claim, no matter how well-respected they are, I need to see some real, concrete examples before I'm convinced. Struts Ti looks pretty interesting... many of the ideas that were described here a few days ago were quite good in my mind. Should it be the future of Struts? I don't know yet, and I'm not even sure those developing it would be willing to say that at this juncture. It's another possible path, another exploration of possibilities, and that's good. One thing is for sure: most of us look back on the way we developed applications just five years ago and wonder why we ever did things that way. I have absolutely no doubt we'll be doing the same thing in another five years. I too would like to see less hype sometimes, but promoting ones' ideas is human nature. If you think you have a compelling answer, or even the One True Answer, you tell people about it and try and convince them. That's hype. It may not always be helpful, but it's perfectly natural :) Frank Dakota Jack wrote: I have to agree personally with Rod Johnson J2EE without EJBs, Spring framework architect, etc., when he says that Shale is merely a stopgap and that Struts as we know it is simply incompatible with JSF. That seems fairly obvious and I find it hard to believe that anyone familiar with the issues would think any differently. I
Re: [Proposal] Struts Ti
This all sounds good, Don, and I have been an admirer of your horse sense for some time. I especially like the emphasis on KISS. I have a few comments infra. On 8/2/05, Don Brown [EMAIL PROTECTED] wrote: I'd been waiting to announce/propose this until I could write up a decent proposal and have the code in a better state, but with all the talk about Struts 2.0, good now is better than better tomorrow I suppose. The following is a proposal for Struts Ti, a possible successor to Struts classic: I like the name Struts-Titanium too. That has the right feel for what would be a good framework's attributes: light and strong. Struts Ti is a simplified Model 2 framework for developing webapps which allows the developer better access to the underlying servlet/portlet environment. .. The key word for Struts Ti is simplicity. Ideally, Struts Ti should approach Ruby on Rails levels of easy of use, yet scale up to large applications providing a smooth transition to JSF/Shale if desired. GREAT! * POJO-based action that combines an Action and ActionForm in a similar manner to JSF backing beans and WebWork 2 Commands Allowing multiple ActionForms per Action would be a blessing, This would allow you, where you have the following flow ActionA -- FormA -- ActionB -- FormB -- ActionC and allow ActionB to share FormA with ActionA and FormB with ActionC. * Spring-based dependency injection in core to allow for pluggability GREAT! * Built on the backbone of commons-chain How are you going to allow IoC dependency injection and build on the backbone of commons-chain? Those seem to be inherently incompatible. Isn't the chain necessary only where you use a Template-Method Pattern rather than a Strategy Pattern, as the recommended relationship between the view and the controller by GoF, and accordingly have IoC problems? At this point, the project site, code, and more detailed design discussions are on my personal server: https://www.twdata.org/projects/struts-ti This looks promising. I will be following with a lot of interest. Good show! -- 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: [Struts Wiki] Update of ShaleReleasePlans by CraigMcClanahan
How can Shale cut a Struts release? Isn't this just more legerdemain by those trying to prop up JSF's utter failure to grab an audience by stealing the Struts name? On 7/29/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 CraigMcClanahan: http://wiki.apache.org/struts/ShaleReleasePlans New page: The purpose of this page is to set up '''checklists''' for Shale releases. Add a new page for each release in the section below using the the version number for the release in the page name. Starting from series 1.2.x, Struts adopted the Tomcat style of release. The quality of each new version is decided by voting. If there are any issues then they are not fixed in that version, but instead a new version is created. See the ''Release Grade'' section in the [http://struts.apache.org/bylaws.html bylaws] and the [http://struts.apache.org/releases.html Release Guidelines] for more details. '''NOTE''' For info on cutting a release see the Struts [http://struts.apache.org/releases.html#Releases Release Guidelines] = 1. Shale Release Plans = * ShaleRelease100m1 - ''Shale Version 1.0.0 Milestone 1'' * ShaleRelease100m2 - ''Shale Version 1.0.0 Milestone 2'' - 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: How about including Struts controls/dialogs library into core Struts?
This is all very strange. Very strange. Except for the stuff that is from www.michaelmcgrady.com, I cannot see any value. What is the value of this? In English, please. Plain English? On 6/27/05, Michael Jouravlev [EMAIL PROTECTED] wrote: Yep, it is me again. Third email in two hours. I finished about 80% of code and about 40% of docs (tutorials + javadocs) for Struts Dialogs project. It is not finalized yet, but is taking shape. Thus, I want to test waters to include dialog functionality into Struts core, preferably into 1.3. First, live demos. * the main demo page: http://www.superinterface.com/strutsdialog which contains some noteworthy samples, like: * Login web control, which has two states: not logged in and logged in and two corresponding pages: http://www.superinterface.com/strutsdialog/dialogloginactioncontrol.do * Master JSP page containing child web control: http://www.superinterface.com/strutsdialog/embeddedmasterpage-tomcat.do The login/userinfo cell in the top-left is the same web control as in prior example, it differs only in page design and in View location. Note, that you submit login info into a separate action, not into one which is displayed in the address bar. * Wizard: http://www.superinterface.com/strutsdialog/wizardaction.do You probably saw it before, but now it is nicely integrated into Struts Dialogs. I would like you guys to check out the live examples and to consider the feasibility of including this stuff (possibly, with changes and updates) into Struts core. The reason is that Struts is a controller framework. Check the packages: actions, taglibs, tiles and validator. The latter two pachages are not used by every Struts user. Taglibs? Aren't they obsolete, now when JSTL is available? So, average Struts developer is left with actions and config. All other frameworks, even Spring, which is not very strong in UI, have UI layer. Many of them have business/persistence integration layer and other good stuff. I think that adding some UI classes into Struts would be a good thing. Classes that I developed, pick up where DispatchAction left, and move on almost to JSF-like integration with business objects and with server-side viewstate, but without JSF tags. Currently the following actions are available: * SelectAction - improved DispatchAction, works with pushbuttons and image buttons. * DialogAction - implements two-phase input processing aka Post-redirect-Get. Manages error messages, allows to reload pages without implicit resubmit. * CRUDAction - all CRUD operations in one action and one interface. * WizardAction - allows to create robust web wizards Also, as you might see from master/child example, it is very easy to create a componentized page with child controls, and you don't even need Porlet API for it! Granted, this component application would not have extensive API, but is it really needed? In most cases all one needs is to drop control onto page and to have it rendered when page is rendered. Data exchange is possible through session object. Project homepage (not classes are described yet): http://struts.sourceforge.net/strutsdialogs/index.html I want to initiate some traction, while I am finishing with documentation and with final touches on the code. Hoping for positive replies ;-) 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~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3 ETA
I don't know about anyone else's household or how they want to live. I do know that this thread is very rude where I come from. I have to admit that I am guilty of jumping too easily into these things but I am just used to people being more kind to one another where I live. Would it hurt? What good is there in these sorts of mean exchanges? -- 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]
