I think the other benefit, although a more subjective one, is that a big long string of Javascript inline in a tag is kind of ugly. I've certainly done it many times, as I'm sure others have, so it isn't the end of the world, it's just aesthetically not very pleasing to me.

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]



Reply via email to