Hi, Joe, I think you sort of "punched the pouch" here. Let me explain.
All your questions were answered in my posts, which you must have not read. Maybe you just read the first post and did not check out the later ones? I have suggested an answer to cluster related behavior, if you read what I said and the code I provided. What I objected to has nothing to do with what you said. In fact, that is exactly what the code provided does. I could not agree with you more, so it is sort of humous reading your post. What I objected to was the LOOKUP mechanism in LookupDispatchAction and the reason that is seen as horribly inefficient, hard to maintain, and generally belonging to the stone ages in this area, is explained in detail at the citation/URL mentioned. So, we are in agreement given what you said. If you use LookupDispatchAction and you look at the StateBaseAction which was provided in this thread (which retains the clustering and the reflection in LookupDispatchAction) you might want to dump LookupDispatchAction. I have no idea why someone would want to retain LookupDispatchAction at this point in Java history. Jack (see below) <snip> On Fri, 14 Jan 2005 12:09:37 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > I'm not sure what the perceived inefficiencies are. </snip> I guess you did not look over the URL I sent. CHECK OUT: http://www.michaelmcgrady.com/button/jsp/button_talk.jsp <snip> > We use a > variation of this extensively at my day job, </snip> Yes. So do I and I have offered such a "variation" (without the tortuous lookup logic) in this thread. Did you miss that? <snip> >and I find the dispatch > model a very nice way to organize code. </snip> Yes. So do I and I used that in the code provided, sans the lookup monster code. <snip> >We prefer to cluster related > behavior (although at a level higher than per-page) rather than have > an explosion of classes to understand. </snip> Yes. So do I. I have no idea who's posts you were reading, but I cannot see how you thought otherwise reading mine. <snip> > So, for us, from a code-grokking perspective, it gains efficiency. > > Joe </snip> I gather than by "grok" you mean the traditional "to drink" or (metaphorically) "to profoundly appreciate or understand" in Martian in "Grokking the GIMP" by Carey Bunks? I agree when you talk about "dispatch actons" but disagree completely when you talk about "lookup dispatch actions". That is what I said before your post, and I stick to that. I suspect you got in a hurry and assumed that a non-committer was not worth reading carefully. That is reasonable! I suggest you read or reread more thoroughly. You might like the code. I am actually fairly sure you will. -- ------------------------------ "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ ----------------------------------------------- "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
