The problem is one of access and planning. The solution is a hack. Not a bad hack and one which some people are satisfied with apparently. However, I hate a hack. And, it really does not work.
There are applications in the framework now. This is a hit or miss thing based on personalities and predelictions rather than on a coherent plan. DownloadAction, UploadAction, the whole panoply of Struts upload and its insinuation into the RequestProcessor code in inappropriate ways, LookupDispatchAction, etc., are all examples of code that has a place but not the place they have. Then there are things like Frank's proposal. I would love to have a place in Struts where Struts based applications could be exposed, debated, improved, etc. Let me ask this question, what is wrong with having Struts, rather than Struts SF, be the place for Struts applications and having Struts SF be the place for developing Struts related applications? There is, I would suggest, no coherent plan at the moment. You are, I think, really missing a lot of submissions that would be great, if only you had a way to do it that made sense. I have lots of code I have just given up trying to provide because there is no way to do so intelligently and without argument and rancor. My discussions on an upload application were significant for me in this regard. Essentially, I had to bastardize my appllication to fit the existing Struts upload in order to present it to Struts. I decided that crippling the code to accommodate an inferior but traditional product just was not woth it. Struts SF cannot solve that problem. I don't want to overstate the problem. I suspect a lot of people like myself are constantly rewriting the underpinings of Struts to do their own thing. I just took out everything associated with the upload so that it did not get in the way. I gave up discussing this because committers don't continue any discussions but merely repeat the old saws. I have read the one you offer about ten times, Don. Please don't take that personal. It is not meant to be and I understand the legitimacy of your thoughts. I expect the next usual suspects, a discussion of keeping things consistent with existing code, etc. will be next. I am not an idiot and realize all these rather obvious options and problems. That does not change the fact that there is presently not an intelligent way to add FINISHED applications to Struts. I think that making plugin applications available would be more important to Struts USERS than anything else you might do. I wonder how many thousands of times the same basic applications are coded out there with varying degrees of sophistication and success. Anyway, you get the idea. I jsut thought I would note that the issues arise again. They do this frequently. On Apr 6, 2005 11:01 PM, Don Brown <[EMAIL PROTECTED]> wrote: > I haven't really been following closely, but what is wrong with using > struts.sf.net for distributing struts-related extensions? I've been > using that site for years with good results. Some ideas became struts > subprojects and others didn't go anywhere. We've been very accepting of > new projects over there and I believe Martin or Ted have already > suggested it. struts.sf.net gets tons of hits and is a very good way to > get your project out there and known. > > Don > > Dakota Jack wrote: > > The below is a continuing problem. At this stage, Struts is pretty > > mature and if you are not a committer able to make decisions, there > > really is not too much you can do of interest with Struts other than > > applications, although I will probably write my own branch this summer > > for my own use with IoC. However, again, unless you are a committer > > as in MappingDispatchAction, LookupDispatchAction, UploadAction, and > > other like Strust application code not really part of the framework, > > you face this problem Frank is facing because there is no effective > > way to make these potential plugins available to the public. It would > > be wonderful if there were a way to provide choices without having the > > pecking order more important than the diversity of projects. I hope > > to Hell that no one takes this as being a personal matter. Sometimes > > you have to discuss principles and leave the personal trash at home. > > A general scheme for application plugins would be really nice. There > > should be a way for Frank's work to become available for people that > > would like to use it. I don't think a rehash of the Wiki and like > > recommendations really would be helpful on this, so please don't go > > there unless you feel you must. > > > > > > <SNIP> > > On Apr 6, 2005 9:40 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > > >>Martin Cooper wrote: > >> > It's just a subset of > >> > >>>the possible schemes that people use for partial page rendering. By > >>>adopting something like this as a Struts subproject, it gives the > >>>appearance that Struts is endorsing this one particular approach to > >>>the more general problem. That will carry a lot of weight in the > >>>Struts community, and since I don't believe that this is the "one true > >>>way" (LOTR again ;), that is not something I want to see. > >> > >>That's a valid point. No doubt there are 100 ways to skin this > >>particular cat, and I wouldn't even claim to be proposing the best of > >>the bunch. > > > > </SNIP. > > --------------------------------------------------------------------- > 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]
