Date: 2004-09-24T04:03:41
Editor: NiallPemberton <[EMAIL PROTECTED]>
Wiki: Apache Struts Wiki
Page: StrutsCatalogFiveMultipleButtonSolutions
URL: http://wiki.apache.org/struts/StrutsCatalogFiveMultipleButtonSolutions
no comment
Change Log:
------------------------------------------------------------------------------
@@ -1,7 +1,7 @@
##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.
+The desire of people to add to this wiki is extremely gratifying. 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 links to other 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 ==
{{{
@@ -46,10 +46,8 @@
9 Links
10 Comments (Peanut Gallery)
11 Author
-12 Readers Favorites
-12.1 Niall Pemberton's Links
-12.1.1 Link A
-12.1.3 Link B
+12 Other Solutions
+12.1 Links to Other Solutions
12.2 Let's Hear from You
}}}
@@ -495,7 +493,7 @@
So, while button solutions are poor in general (too heavy, too slow, too
over-engineered) this is better than the existing solutions.
-This solution is superior to the Button solution which follows and is recommended,
apparently, by Niall, because only one button object has to be created. If you use
buttons for navigation extensively within large forms, this because crucial.
+This solution is superior to the Button solution which follows and is recommended,
because only one button object has to be created. If you use buttons for navigation
extensively within large forms, this because crucial.
=== SOLUTION FOUR: ButtonForm Code ===
{{{
@@ -637,18 +635,20 @@
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 ==
+== SOLUTION SIX AND BEYOND: Links to Other Solutions ==
-=== Niall Pemberton's Links ===
+=== Links to Other Solutions ===
-==== 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''
+Open Source Struts Extension
[http://kenfitzpatrick.dnsalias.org:8080/imageButtonBeanManager Image Button Bean
Manager]
-==== Link B ====
+=== Let's Hear From You Too ===
-Open Source Struts Extension
[http://kenfitzpatrick.dnsalias.org:8080/imageButtonBeanManager Image Button Bean
Manager]
+==== Use an ImageButtonBean to represent an image button ====
+
+''** 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''
+
+==== Image Button Bean Manager ====
''**This solution is, I would suggest, over-engineered. However, there is one thing
about this solution I really, really, really like. That thing is that it creates an
extension to struts rather than trying to be part of struts itself. This is the way
to go, in my opinion. I admire this restraint and good sense. And, who knows, maybe
I am wrong about this solution. I don't think so, but the nice things about
extensions is that it leaves everyone a choice rather than having to either do triage
to the struts application or having to accept solutions you don't like.
Unfortunately, this solution not only embraces the difficulties inherent in
ImageButtonBean but also combines that with DispatchAction and its progeny, which have
the same problem in a different way. -- Michael !McGrady''
-=== Let's Hear From You Too ===
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
