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]
