Date: 2004-09-23T19:55:50
   Editor: MichaelMcGrady <[EMAIL PROTECTED]>
   Wiki: Apache Struts Wiki
   Page: StrutsCatalogFiveMultipleButtonSolutions
   URL: http://wiki.apache.org/struts/StrutsCatalogFiveMultipleButtonSolutions

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -1,6 +1,8 @@
 ##language:en
 This presentation is somewhat detailed, so we begin with a Table of Contents for your 
ease in navigating the presentation.  Enjoy!  There is a comment section at the very 
end.
 
+The desire of people to add to this wiki is extremely gratifying.  Thank you, 
'''Niall Pemberton''', who has indicated an unusual and ongoing interest in this area. 
 In order to better accommodate this need and to maintain some "order" and "look" to 
this presentation, I have added a section at the end for readers' favorite solutions.  
Please do feel free to add your own ideas there.  Please follow the "look and feel" 
and format of the wiki.  
+
 == Table of Contents ==
 {{{
 1     Table of Contents
@@ -41,6 +43,7 @@
 9     Links
 10    Comments (Peanut Gallery)
 11    Author
+12    Readers Favorites
 
 }}}
 == Universal Button Solutions ==
@@ -597,12 +600,6 @@
 StrutsCatalogMappedBeans
 
 ["StrutsCatalogHidingImagesAndOtherResourcesUnderWEBINF"]
-
-From Ted Husted's Tips: [http://www.husted.com/struts/tips/001.html Use an 
ImageButtonBean to represent an image button]
-
-Open Source Struts Extension 
[http://kenfitzpatrick.dnsalias.org:8080/imageButtonBeanManager Image Button Bean 
Manager]
-
-''** Note on link to "Ted Husted's use of an ImageButtonBean": This is an old heavy 
solution which was proposed here originally as an option to Ted's solution using 
JavaScript.  The guts of this solution came from '''Antonio Lagnada''' 
(http://j2ee-01.lagnada.com/struts/html-buttons.htm) and was credited at 
http://wiki.apache.org/struts/StrutsCatalogMultipleImageButtonsWithNoJavaScript?action=recall&date=1083359181
 .  When Ted changed from his JavaScript based solution, cited on the same wiki, I 
don't know.  I believe, however, that Antonio is the originator of this pattern. This 
is, at any rate, in my opinion, a very outmoded solution.  This solution uses the 
update.x nature of the name in the request parameters name/value pair to get a 
[SomeObject].getName().getX() rather than finding a "field" (name or request 
parameter) with suffix of .x.  The solutions are equivalent except that this one 
creates an object for each command you need.  This solution requires that you create a 
button for each command and that proliferates the button objects.  The solution on 
this page, inspired as an improvement to the code the author of this link calls "Ted 
Husted's use of an ImageButtonBean", uses only one button in its best form and less in 
the second best form.  The button solutions themselves, including especially the one 
called ImageButtonBean are inferior.  My testing, at any rate, indicates that this 
solution is super slow relatively speaking.  You can, you might note, use 
"update.firstChoice", "update.secondChoice", etc. and do fancier things with this 
pattern.  I first awoke from my dogmatic slumber on these buttons when '''Larry 
Young''' noted that there was no need to go with all these button objects.  He has his 
own better solution too.  If you look at the actual use of this pattern, it is not 
particularly inviting.  Larry was right and I hope the work I have done on his 
prompting is worth someone's time.''
 == Comments ==
 
 CommentPageForCritiques
@@ -619,3 +616,19 @@
 
 
 If your comments are extensive, you might want to provide a link instead of adding to 
this already incredibly verbose presentation.
+
+== SOLUTION SIX AND BEYOND: Readers Favorites ==
+
+=== Niall Pemberton's Links ===
+
+==== Link A ====
+From Ted Husted's Tips: [http://www.husted.com/struts/tips/001.html Use an 
ImageButtonBean to represent an image button]
+
+''** Note on link to "Ted Husted's use of an ImageButtonBean" (Niall has since 
changed the title of his presentation): This is an old heavy solution which was 
proposed here originally as an option to Ted's solution using JavaScript.  The guts of 
this solution came from '''Antonio Lagnada''' 
(http://j2ee-01.lagnada.com/struts/html-buttons.htm) and was credited at 
http://wiki.apache.org/struts/StrutsCatalogMultipleImageButtonsWithNoJavaScript?action=recall&date=1083359181
 .  When Ted changed from his JavaScript based solution, cited on the same wiki, I 
don't know.  I believe, however, that Antonio is the originator of this pattern. This 
is, at any rate, in my opinion, a very outmoded solution.  This solution uses the 
update.x nature of the name in the request parameters name/value pair to get a 
[SomeObject].getName().getX() rather than finding a "field" (name or request 
parameter) with suffix of .x.  The solutions are equivalent except that this one 
creates an object for each command you need.  This solution requires that you create a 
button for each command and that proliferates the button objects.  The solution on 
this page, inspired as an improvement to the code the author of this link calls "Ted 
Husted's use of an ImageButtonBean", uses only one button in its best form and less in 
the second best form.  The button solutions themselves, including especially the one 
called ImageButtonBean are inferior.  My testing, at any rate, indicates that this 
solution is super slow relatively speaking.  You can, you might note, use 
"update.firstChoice", "update.secondChoice", etc. and do fancier things with this 
pattern.  I first awoke from my dogmatic slumber on these buttons when '''Larry 
Young''' noted that there was no need to go with all these button objects.  He has his 
own better solution too.  If you look at the actual use of this pattern, it is not 
particularly inviting.  Larry was right and I hope the work I have done on his 
prompting is worth someone's time. -- Michael McGrady''
+
+==== Link B ====
+
+Open Source Struts Extension 
[http://kenfitzpatrick.dnsalias.org:8080/imageButtonBeanManager Image Button Bean 
Manager]
+
+''**This solution is, I would suggest, over-engineered.  I will add comments in the 
future to this. -- Michael McGrady''
+=== Let's Hear From You Too ===

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to