I like your idea about being able to switch though (I always like more flexibility in anything)... I'm not sure I'm convinced it isn't better to just make the include required from the get-go, but a switch is certainly not a bad option. Not a big deal to implement, I just wonder if the benefit isn't a little dubious (i.e., there is probably more to be said for not putting the code inline, so why not make it only work that way?)
Worth some others' input in any case I think.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Andres Paz Sampedro wrote:
The difference between inline and an external js file is only performance. To reduce the size of the HTML,and in general as a good practice, the best is to include the links as part of the <header>.
I would suggest the following: add a setting in the ajax config file to decide whether or not to include the inline javascript. By default, the value would indicate to include the inline code. As an optimization (newbies never need to worry about these), users can turn the inline javascript off and then include a link to the corresponding js.
So, originally they would only need to worry about the plugin and the config-xml, and things would work; when they understand and decide they want to optimize it, they will be able to do so.
My $0.02,
-a.
On Apr 6, 2005 3:52 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
One quick comment...
You'll notice that a rather large chunk of code is inserted inline for the event handlers... this is, I would think, not the final answer.
My first thought was "is it possible to insert into the <head> of a document from within a tag class?" I assumed not. My other thought was "should I just supply a .js file that a developer has to include if they want to use the Ajax-aware tags?" I didn't do that initially because I wanted to make it as easy as possible on a developer, but probably that is in fact the best answer.
So, 3 steps would be involved in using these tags:
(1) Include the plugin in struts-config (2) Write the struts-html-ajax config file (3) (probably) Include the .js file on any page you want to use the Ajax-aware tags
Like I said though, various approaches, and I'm more concerned with the underlying concept and what people think of it... If there is support, then everyone can fire away with how it really should be done (although aside from the above, I'm frankly liking this).
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
On Wed, April 6, 2005 3:37 pm, Frank W. Zammetti said:
Afternoon all,
Please reference the code at:
http://www.omnytex.com/ajaxtags.zip
I wanted to put something out there in front of you all and get some feedback on it before I go that extra mile and finish it out.
This came out of some ideas I tossed at Ted a few days ago. The basic idea is to take the existing Struts HTML taglib and make the tags Ajax-aware.
In a nuthsell, take a simple button tag...
<html:button property="button1" value="Click to do Ajax!" />
...now, add a new attribute to it, ajaxRef:
<html:button property="button1" value="Click to do Ajax!" ajaxRef="button1" />
When the tag is rendered, each possible type of event handler looks something like this:
if (getOnclick() != null) { handlers.append(" onclick=\""); handlers.append(getOnclick()); handlers.append("\""); } else { prepareAjax("onclick", handlers); }
prepareAjax() does a lookup to a new XML configuration file (well, in-memory objects representing the XML of course!) like so:
<AjaxConfig> <ajaxElement> <id>button1</id> <event> <type>onClick</type> <submitType>queryString</submitType> <submitItems>buttonValue=button1,textValue=text1</submitItems> <submitTarget>http://www.omnytex.com</submitTarget> <returnAction>stdInnerHTML</returnAction> <returnTargets>resultLayer</returnTargets> </event> </ajaxElement> </AjaxConfig>
If an <ajaxElement> with an <id> matching the ajaxRef attribute is found, and if an <event> with a <type> matching the type being added to the tag, then the prepareAjax() method does it's thing (note that developer-defined event handler functions will take precedent, so no existing code would be broken by this). And what is "it's thing"?
Basically it will add an inline event handler to the tag, just like always, that is capable of making an Ajax request (using the XMLHttpRequest component). A quick description of the XML elements pertaining to <event> should bring this in to focus:
type .. is of course the type of event handler. It can be any of the types that the BaseHandlerTag handles.
submitType .. is the type of submission that will be made. Two types are (will be) supported: queryString and XML.
submitItems .. is a comma-separated list of form elements and the names they should be given. For instance, in the example above we would get a query string in the form ?buttonValue=<1>&textValue=<2> where <1> is the value of the button on the page and <2> is the value of the textbox on the page.
submitTarget .. is the URL the request is submitted to. This can be a relative path or a full URL (although full URLs will of course incur the cross-site scripting restrictions)
returnAction .. is what will happen when the request returns. There will be a number of built-in actions, all prefixed with "std' (let's get all the disease jokes out of the way now!). You can also name a page-level Javascript function here to do other things.
returnTargets .. is a comma-separated list of elements on the page that will be affected by the action. This will generally be required for the standard actions, and is up to the developer if they want it if writing their own function.
The code you hopefully downloaded is a sample webapp, very simple. Click the button to retrieve the Struts web site and dump it in a span. Note that if you are in an environment that requires a proxy for network access, you will need to set the httpProxy and httpPort elements in web.xml appropriately. It is by default set up assuming no proxy is required.
The example has a number of quick-and-dirty type hacks just to demonstrate... for one, the XML config file is NOT read in, instead the objects are just populated manually in AjaxInit (which is a Struts plug-in and is required to make the tags Ajax-aware). Second, the query string is currently not actually built, it's just hard-coded. Third, only the queryString submitType is recognized. Fourth, only the stdInnerHTML returnAction is recognized (as the name implies, this just sets the innerHTML of any elements named in returnTargets). And lastly, there is very little commenting or proper error handling in spots.
Like I said, a very simple example, but I think it gets the point across.
Also included is the change to BaseTagHandler, the only altered class from the taglib (no Struts core changes, as one would expect). As I mentioned, there is a plug-in required for this, and there are a total of six new classes, all dealing with storing the configuration information.
So, the question is, does anyone see this as something interesting? Is anyone interested in seeing this actually finished up? If so I can do that, probably by the weekend if things go well, and I suppose open a ticket for it at that point.
Questions? Comments? Whatever? Thanks all!
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
