Frank, Ok here are my "interpretations" of his comments about that. And mind you this is a very high level kind of thing I haven't thought through any kind of real architecture here.
1) We (or you and whoever, or just you) create a framework that abstracts view type things. 2) Create extensions of the struts tags (much like the el tags did) that extend struts to use that framework either using Ajax extensions in this iteration or... as a pluggable view technology and in... 3) create the pluggable Ajax portion. Now this begs some questions... 1) how is it easy to use. For instance I assume if we use a pluggable view technology that there has to be a configuration for that technology (in addition to any configuration that technology needs - i.e. your ajax xml config) and that makes things inherently more complicated. 2) what is the "intermediate" view technology framework. that is , what is needed in it. And of course the real question becomes - is the struts dev list the right place to hold this conversation now? And if it is not where or how do we hold it? :) Al -----Original Message----- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Thursday, April 07, 2005 1:07 PM To: Struts Developers List Cc: Struts Developers List Subject: RE: RFC: Struts HTML Ajax-Aware Tags Well then perhaps we can shift this discussion to what Martin had in mind... I wasn't sure where he was going frankly. It sounded to me like he was almost saying we should be looking at providing a whole new GUI framework for developing client-side webapp components, independant of what is going on back at the server (mostly). Of course, something like that pretty quickly starts to sound like XUL or even JSF or 100 other things out there. And if you go down that route, what do you lose in the process? The Struts tags are a known quantity, and they are aware of Struts to an extent... will people be willing to give that up to use a whole new set of GUI components? That was, I felt, the beauty of Ajax-enabling the existing tags... it's something know, something real (mostly), now (well, soon!), that expands the toolbox of existing Struts developers, rather than four months of discussions, another four months of proof-of-concepts, and a year before anything is produced that is useable. I am open to the possibilities though, so by all means let's have a discussion and see where everyone thinks we are and where we should be going. I'm all for going a different route if it can be shown to be better and not just pie-in-the-sky. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Thu, April 7, 2005 1:58 pm, Fogleson, Allen said: > Yes, I think that is the bottom line, but I believe your post did > provide some good things. > > 1) there is some interest from other developers in assisting with such a > project. > > 2) Although the initial proposal was for a specific technology I believe > Martin brought up some good points about there being a "core" framework > for other view technologies to use, and the first concrete > implementation of that framework can be Ajax. > > Now on to the sf thing. I really need to write off I have some stuff > that I thought about starting a sf project for.. basically extensions of > MessageResources. (much like Jame's stuff) I really should just write to > one of the admins at struts.sf.net so I can become a member of that > project. > > Al > > > -----Original Message----- > From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 07, 2005 12:45 PM > To: [EMAIL PROTECTED] > Cc: Struts Developers List > Subject: Re: RFC: Struts HTML Ajax-Aware Tags > > Well, the bottom-line here is that I am in fact a developer member of > struts.sf.net, although I have yet to contribute anything to it. If I > want to persue this, that is one of the avenues available to me > (although > I don't know the procedure yet). I don't know at this point if I'm > going > to do that, go somewhere else, or simply say to hell with it. I was > hoping for a different answer, but I didn't get it, but that's OK, that > was the whole point of bringing it up. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > On Thu, April 7, 2005 1:28 pm, Ted Husted said: >> On Apr 7, 2005 1:12 PM, Fogleson, Allen <[EMAIL PROTECTED]> >> wrote: >>> Jack, >>> >>> Actually my comments were in no way an answer to his proposal. I > believe >>> that under the rules of Apache we have already gotten our answer to >>> whether it will be included as a subproject of struts. To be included >>> there must be no vetoing vote by a member of the PMC. (pardon me > Martin >>> if I misquote you or I misinterpreted your intent) Martin Cooper is a >>> member of the PMC and basically gave a -1 vote on including it as a >>> subproject. >> >> Just as point of order, vetos only apply to product changes. Adopting >> a subproject is a 3/4 majority vote. >> >> http://struts.apache.org/bylaws.html >> >> And, there is not enough here to even think about voting on subproject >> status. We don't vote on good intentions. A product would have to be >> very nearly complete, and have already attracted a following, before >> we'd want to consider a subproject vote. >> >> This is an informal discussion. Frank just wanted to run it up the > flag >> pole. >> >> -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] > > --------------------------------------------------------------------- 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]
