Personally I don't see where putting the code inline or forcing the use of a .js file through a switch really brings value. If the switch bought some value, say advanced features or something then it might make sense. Power users could turn on the switch and access these wonderful extra features that are not used normally, but the PU might want to use.
Personally I would say force the use of the file from the get go. Al -----Original Message----- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 06, 2005 4:07 PM To: Struts Developers List Subject: Re: RFC: Struts HTML Ajax-Aware Tags 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
