(not commenting below, just up top on this)
In reference to your first comment:
> I think that what appears to be a model emphasis for the
> solution in your [rick's] approach is bound to fail. Further, making > the
> solution view based frees the model to be built for performance, which
> is why I use the solution I sent to you with respect to images, i.e.
> the image tag for submits.
Maybe you are misunderstanding what I'm doing. My approach has nothing to do with the model at all. All I have is a very simple MappingDispatchAction with typical dispatch methods.
All my links, forms, or image 'onClicks' simply equate to a standard mapping (ie /updateFooBar.do... /viewFooBars.do, etc). So a developer can ALWAYS easily tell what is being called (of course to see the actual method being called he/she will need to look in the struts-config but it's consistent across all types of front end calls.
I saw two things in the initial e-mail that had me concerned. One was where the tag had this code:
if(buttonValue.endsWith(".x")) {
command = buttonValue.substring(0,buttonValue.indexOf('.'));
}
}
return command;The second was all the code you added inside of your ActionForm subclass... even to the extent that it needs to contain an inner class. I just find this to be way overcomplicated for something that I think should be pretty simple.
In reference to my first concern... How would you have two different commands executed for a button with the same name? In my case here at work, we had to develop this one app where we needed to use an "Ok" button. If I was on an edit page I needed to still have an "Ok" button and when on an insert page I still had to use the same "Ok" button. Looks like in your above, this would end up calling on the one type of method. (It also looked like you would run into the same problem with the CrackWillowButton class).
I guess what I am missing is what your approach gains me verses using just a 'tiny' amount of javascript. (I'm not one to believe that a web application in today's world should be required to work without ANY javascript).
I'll sum up my approach with examples and would love to hear the problems with it. Keep in mind the advantage (I think) to this is that you simple code your standard MappingDispatchAction and that you can 'easily' see what is being called. In ALL the example below you easily see the action being called (no need to figure what underlying implementation is taking care of figuring out what dispatch method to call, you easily can just look at your mapping and find out.)
Enjoying this discussion. Hopefully below it makes it more clear what I'm doing:
UserAction of type MappingDispatchAction with some typical dispatch methods ie updateUser, insertUser, deleteUser, getUser, getUsers
(mappings in struts-config could look identical to the above which of course map to "UserAction")
Different ways you could get access to the methods:
1) From a link. (I like JSTL even though a bit more verbose than html:link):
<c:url var="url" value="/getUsers.do"/><a href="${url}">[ Get Users ]</a>
2) From a typical form with one submit button
<html:form action="/updateUser"> <html:submit><fmt:message key="button.update"/></html:submit>
3) For images or buttons
<c:url var="url" scope="page" value="/getUser.do">
<c:param name="id" value="${user.id}"/>
</c:url>
//on button or img onClick, or I usually make this a js function:
window.location='${url}'
4) When you need different submit buttons for one form
//create a javascript function. I keep this in my header.jsp //Thanks Bill (I think it was Bill S. who posted this:)
function swapAction( formName, action) {
formAction = document.getElementById( formName ).action;
newAction = '<html:rewrite page="/'+action+'.do"/>';
document.getElementById( formName ).action = newAction;
}//then on different submit buttons <html:submit onclick="swapAction( 'userForm', 'updateUser')"> <fmt:message key="button.update"/> </html:submit>
Michael McGrady wrote the following on 9/13/2004 11:09 AM:
SEE WITHIN:
Michael McGrady
Rick Reumann wrote:
I hope you have a bit of time to discuss this in detail, Rick, because the amount of activity in this area is huge. I think this is one of those areas, along with looking for persistence not identical to the normal scopes, where there is continued dissatisfaction.
First I'd like to point out that I like to keep an application as consistent as possible. That means that I like my links, my form submits, my buttons to all act similarly - this makes it very easy for a new developer to the project to figure out what is going on.
I do too. My generic solution is based on what appears on the "coded" page. I wanted to decouple that from everything else. I, therefore, use a variation of the FACADE PATTERN with these, emphasizing a generic solution from the VIEW perspective rather than from the MODEL perspective. I think that what appears to be a model emphasis for the solution in your approach is bound to fail. Further, making the solution view based frees the model to be built for performance, which is why I use the solution I sent to you with respect to images, i.e. the image tag for submits.
There simply is not a model based generic solution, in my opinion, which sometimes if right and sometimes is wrong. (I also include <input type='file'>, by the way, in addition to your list.) I think you have to use something like the Facade Pattern because the actual logic underlying these view related behaviors is so different. If you try to disseminate a generic solution in the model, you are bound to run into the types of problems you have discussed. So, essentially, I have developed a taglib that looks like this:
GENERIC PAGE BASED SOLUTION
<crackwillow:image button='Crack_Willow_Chat.gif' mapBean='hkc' bgClrCode='banRtBgClr' txtClrCode='banRtTxtClr' font='Edwardian Script ITC' italic='false' bold='true' size='30' property='chatSend'/>
The key here is the "image". If you wanted to browse with an input type of file, this would be "file". This produces a GIF button saying "Crack Willow Chat" in Edwardian Script ITC embolded with a size of 30 and a coded identification of the command as "chatSend" and whatever colors happen to be represented in this space by the values of bgClrCode (background color) and txtClrCode (text color). If you want a jpeg, put in ".jpg", etc. If you don't want a button, just drop ".gif" entirely.
The behavior of the button is changed by changing "image", e.g. "submit", "link", "file". The view value of the button itself is changed by changing the value of "button". This is fully localized. If you don't want a And the property you want to send is changed with a change in "property". The colors are dynamic here with bgClrCode and txtClrCode. If you wanted to hard code them, you would with bgClr and txtClr. The value of property can be dynamic or not. This depends on the model coders. The map bean, which is instrumented, allows me to connect the dynamic colors with other colors on a page, which are held in the same bean. Any other model solution for that problem can easily be plugged into this solution.
Here is the rub or the main point. The solution I sent to you is decoupled from this page code, emphasizing the use of the Facade Pattern. Accordingly, I send parts of my solution out each time a question comes up in the area, but never the whole solution, which is too involved for simple posts. (Images, for example, are created dynamically and cached.)
This solution presently lets me just put in my buttons and have no concern at all for what happens in the background. Some parts of the solution, e.g. for <input type='file'>, will generate JavaScript and others won't. I use a mock image over the "live" image of the file browse button in order to get dynamic, image buttons for the browse button that are consistent with the security protocols for <input type='file'>. Further, the background code for this is decoupled from the model because the model simply has to deal with results rather than with mining the results. I place the class* */ImageTagUtil /cited in my last to you between the form and the Action. Thus, Actions don't care if it is an image, a submit, or whatever.
You get the idea. What do you think?
Michael McGrady
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Rick
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
