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]
