Not mine, Michael. I am just saying that it is really incredible that you came up with the exact same code to solve a problem and then that solved the problem for you and you did not even know the problem existed. I do find that very hard to swallow. Why shouldn't I? Random solutions to a problem that bears directly on what you are doing without you even knowing about the problem, i.e. name.x and name.y, is pretty weird, no? Very weird.
On 6/9/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > On 6/9/05, Dakota Jack <[EMAIL PROTECTED]> wrote: > > I still am absolutely amazed that you "came up with these tricks" > > without even knowing that the difficulty was that you could not > > directly reference a name in name value pair because <image> includes > > an .x and a .y with the name. The code you duplicate exactly has been > > based on solving that problem for ages and you do the same thing > > without even knowing the basis for the solution. That is very odd > > indeed. I would be inclined to think that you duplicated the code > > without knowing why it was used that way and came up with the > > description you did because that is the description on > > www.michaelmcgrady.com and has been referenced to death by the struts > > list. > > Are you accusing me in stealing your idea, or your code, or taking > credit for what you did? I already told you, that I did not see your > code before I wrote mine. If you want to believe in opposite, this is > your right to do so. Funny that you chose SelectAction for your > accusations, for it being just a dispatch helper. > > The real deal is DialogAction, which packs several nice ideas into one > compact class. Again, I do not say that I invented something that > never existed. But I came up with these ideas myself. Careful search > on the internet revealed several blogs which discuss similar > approaches. This does not diminish what I did, and does not make a > thief out of me. I wrote the class and want it to be accepted in core > Struts. Plain and simple. > > I already told you, that I do not use images, hence I do not know > what's the deal with ".x" and ".y". I wanted to use a plain pushbutton > with arbitrary caption on it, that is all. DispatchAction is so basic > that only a lazy dog have not tried to improve it. > > I finally looked at your DispatchAction class. Obviously, it looks > similar, because the goal is similar. You do not use mapping from > request parameter to method, but I do. I think that indirect method > access gives more flexibility. You use dotted notation, I do not > anymore, because couple of times Struts threw an exception trying to > populate non-existent nested property. > > > But, as you say, you came up with these "tricks" and only later > > discovered both the code that duplicates yours and the reason for the > > code. As I said, Michael, amazing! Amazing! You cannot pass on a > > license to something you did not create or which is in the public > > domain. > > I believe you misread what I wrote. By tricks I meant features of > DialogAction class, like (1) I/O separation in two phases using > POST/redirect/GET pattern, (2) using the same URL for redirected GET > to keep browser history from growing, (3) using non-cachable response > headers to avoid stale pages and to prevent resubmits, (4) creating > stateful object (a "web control") and rendering a page which > corresponds to its current state (think portlets for poor), (5) > storing messages in session for access after redirect. I don't think > that your DispatchAction has any of that. You do not even use > redirection in your mapping, and clicking Refresh button on your > sample web page invokes the infamous "Do you want to resubmit > POSTDATA?" dialog. This freaking dialog was the trigger, when I > started to think about I/O separation. > > I have my own solution for (5), but in DialogAction I use method > which comes in Struts, because it is easier. Still, I will probably > use my own solution, because current Struts implementation removes > messages from session after they were accessed, that does not really > work for me. > > Why don't you submit your updated DispatchAction to Bugzilla? If it is > adopted in Struts standard library, I might rewrite my DialogAction > based on your code, there is no reason to multiply entities beyond > necessity. But mind you, that current Struts policy is to remove > @author tags from core classes. > > 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]
