On Tue, February 20, 2007 5:20 pm, Michael Jouravlev wrote: > Oops, did not mean it to sound like that, I am sorry. I forgot that > you've proposed the same thing for s1.
That's alright because I forgot too :) > On the other hand, you think that adding new functionality > to v. 1.4 instead of v. 2.0 may break compatibility or add unnecessary > strain on developers' brains or incur excessive overhead and you are > worried. Well, it will incur additional overhead. Struts was > originally designed in 2001, and since then computers have become at > least three times faster. I haven't timed the modified action, so I > cannot tell you how slower it will be. Let me make clear, I only mentioned overhead from the point of view of considering all the angles... I don't for a second think what your proposing will add any overhead that anyone will consider significant. But it *is* a reasonable thing to consider, along with other things, that's all I'm saying. As a side note, I'm not a fan of the "but machines are so much faster today" argument... there's no excuse IMO for sloppy, inefficient coding just because the hardware can make up for it (and I'm in no way implying your code is sloppy or inefficient, I'm just making a generalization here). > By the way I already have made another change to future 1.4 codebase, > now it is possible to configure when reset and populate are performed. > This change adds about the same amount of overhead as adding check for > action type (dispatching or not). Want me to take it out? Again, I didn't mean to say I had any great concern about overhead... and in fact I'm in favor of that particular modification so no, I wouldn't want you to pull it out... trolling through the archives you'll find I made that suggestion 2+ years ago as well :) (I think it's on the Wiki as a matter of fact). > You are correct that from purely technical perspective there is no > reason of adding dispatching into Action. But from the mindset > perspective I think there is. People will be able to learn right off > the bat that they can either use execute, or use event handlers. Many > do not bother reading about some obscure enhanced classes once they > got their first app running. Well, maybe one reason is upgrading from > prior versions and adding event handlers into existing classes instead > of rewriting class hierarchy and inheriting from another uberaction. Here's the problem I see here... by saying they'll "learn right off the bat" about something, no matter what it is, your making a decision for them that they should be thinking that way. I'm not in favor of that, *especially* when we're talking about an established, well-understood framework (I might feel differently if Struts was something brand-spankind new). Now, if there was another type of Action, and they later discovered your way of thinking and liked it (and by all means, promote the concept!), then the framework has the ability to support them. A framework should be like an onion: the outer layer(s) should be quick and simple to grasp, but the "advanced" options and capabilities should be revealed as you peel away the layers, there for you when you need/want them. Thrust too much to the surface and you just make it harder to ingest :) (how's that for a stretched analogy?!?) > I cannot make a better argument now, so in technical terms I guess you > are right. But having it all together in one class simply makes the > framework more cohesive to my mind. Well, as you've said, your a committer, you can make that judgement and act upon it. I'm not, so all I can do is voice my concerns. > I just want to clean s1 up a bit. > People say that s1 is way too complex for what it does, and I want to > reduce this complexity for new users of s1 if there will be ones. I just don't see how what your proposing does that. I think it adds power, which is great, but I can't see how it makes anything simpler, most especially for new Struts developers. > I will think on what you said. Maybe I will change my mind indeed. Fair enough, that's all I can ask. At the end of the day, it's your (and the other committers') decision. I just wanted to put my thoughts out there for your consideration. Mission accomplished :) > Thanks. > > Michael. No, thank you Michael, your efforts are recognized and appreciated, at least by me! :) Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! > On 2/20/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> I'm not sure what exactly this has to do with anything Michael. I can >> only assume your referring to me having made that suggestion in the >> past, >> and yeah, you'd probably be right to make the comparison, but here's the >> very important difference: I'm not a committer. I can't go off and do >> what I want with the code that everyone else is (generally speaking) >> going >> to use. You can. Therefore, it's not at all unreasonable for me to ask >> the questions I've asked in my estimation. >> >> On Tue, February 20, 2007 4:54 pm, Michael Jouravlev wrote: >> > Oh, and by the way while we are on the s2 topic: combining action + >> > form in one class which reinstantiates every request is a pretty >> > stupid thing if you ask me and is much farther from original Struts >> > session-scoped-by-default ActionForm than my subtle :) changes to >> > Action. >> >> > ---------- Forwarded message ---------- >> > From: Michael Jouravlev <[EMAIL PROTECTED]> >> > Date: Feb 20, 2007 1:42 PM >> > Subject: Action, dispatch, etc. >> > To: "Frank W. Zammetti" <[EMAIL PROTECTED]> >> > >> > >> > Hi Frank, I've taken this discussion offline if you don't mind, but if >> > you like we can bring ig back to the list. We had this argument >> > before, my reasons are the same. >> > >> > With current shift from s1 to s2 Paul and me are free (well, not >> > completely, but we have more leeway) to implement features we like, >> > features we always wanted but could not add to the core because of >> > resistance of several core committers. >> > >> > Whether s1 will stay viable after 1.4 release or not I want to make >> > changes I always wanted, and now I can do this being a committer :-) >> > >> > My changes do not break backward compatibility so I don't see why you >> > or anyone else should be worried. If 1.4 won't be used in the field >> > then why would one care about its features? >> > >> > On 2/20/07, Frank W. Zammetti (JIRA) <[EMAIL PROTECTED]> wrote: >> >> >> >> [ >> >> https://issues.apache.org/struts/browse/STR-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40222 >> >> ] >> >> >> >> Frank W. Zammetti commented on STR-2940: >> >> ---------------------------------------- >> >> >> >> I'm not arguing what your trying to do... I'm simply asking two >> >> intermingled questions here: >> >> >> >> Why does what your trying to do have to involve modifying Action? >> Why >> >> isn't simply creating a new kind of Action sufficient? >> >> >> >> I imagine that when DispatchAction was first introduced, a similar >> >> question was asked... why not just add dispatching functionality to >> >> Action and be done with it? Well, somewhere along the line, someone >> >> decided a second kind of Action was the better answer. I'm asking >> the >> >> same question here, not debating whether what your proposing is a >> good >> >> idea or not. It seems to me, if it's a new descendant of Action, >> then >> >> that question is moot anyway. >> >> >> >> If your only goal is to push a new mindset on people, which frankly >> >> seems to be the case based on what you said in the previous comment, >> I >> >> would contend that's not the right reason to do this, considering the >> >> tremendous number of existing Struts apps that have to be maintained. >> >> >> >> A related piont, although one I hesitate to make frankly... One could >> >> certainly make the argument that S1 is quickly becoming legacy given >> the >> >> advent of S2, and in that frame of mind, I don't think major >> >> architectural changes (which this is, whether developers are forced >> to >> >> deal with it or not) should be undertaken lightly. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
