You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Frank W. Zammetti" <fz...@omnytex.com> on 2005/04/06 21:37:40 UTC
RFC: Struts HTML Ajax-Aware Tags
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by Dakota Jack <da...@gmail.com>.
<SNIP>
On Apr 7, 2005 3:06 AM, Ted Husted <te...@gmail.com> wrote:
> If at some time, we were to add a Struts Ajax subproject, based on a
> mature codebase with a strong following within the Struts community, I
> doubt it would carry any more weight than our adding Struts Shale :)
</SNIP>
Actually, isn't adding Struts Shale more like adding Struts .NET or
Struts Tapestry? Franks proposal makes sense. Adding JSF to Struts
is the weirdest thing I couild imagine.
LOL ///;-) In fact, I am with David Geary in thinking that Tapestry
is superior to JSF, and he ought to know. ///;-)
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by Ted Husted <te...@gmail.com>.
On Apr 7, 2005 12:13 AM, Martin Cooper <mf...@gmail.com> wrote:
> I'm not sure what you're proposing here. If you're looking for
> feedback on something that might become a Struts extension, for
> example as part of the Struts SourceForge project, then I would say
> knock yourself out. ;-) However, if you're proposing this as a future
> Struts subproject here at the ASF, then I would be against it, for the
> following reasons:
>
> 1) Ajax is just the latest buzzword for something people have been
> doing with browser based applications for years. It's just a subset of
> the possible schemes that people use for partial page rendering. By
> adopting something like this as a Struts subproject, it gives the
> appearance that Struts is endorsing this one particular approach to
> the more general problem. That will carry a lot of weight in the
> Struts community, and since I don't believe that this is the "one true
> way" (LOTR again ;), that is not something I want to see.
If at some time, we were to add a Struts Ajax subproject, based on a
mature codebase with a strong following within the Struts community, I
doubt it would carry any more weight than our adding Struts Shale :)
> 2) Many people are already using existing libraries to build Ajax-like
> applications. I don't believe that Struts should be providing yet
> another client-side implementation. If we really want to have an
> Ajax-like taglib as part of Struts, then it should be capable of using
> whatever client-side library the developer wants, whether that's Dojo,
> nWidgets, Burst, f(m) or Zammetti Special. ;-)
That's probably a good idea, if the community finds that this is
something people need.
I think the path Frank is suggesting does have a distinct Struts feel
to it. If he did flesh this out, and it did become popular within the
Struts community, then we could consider it on the merits of what our
community needs, expects, and, most importantly, will support with
posts and patches.
> 3) This seems to me to be a particularly restrictive implementation of
> the Ajax concept. While it might be possible to expand this to cover
> all of the possibilities, I suspect that the end result would be
> horribly complicated, making it much simpler to go back to just using
> the existing onXXX attributes and defining the rest in JavaScript.
I hear that, brother. I said the same thing about modules :)
But, on the other hand, if someone is willing to dot the i's and cross
the t's, such things can be made to work, especially when there are
enough eyeballs in play :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by Ted Husted <te...@gmail.com>.
On Apr 7, 2005 2:01 AM, Don Brown <mr...@twdata.org> wrote:
> I haven't really been following closely, but what is wrong with using
> struts.sf.net for distributing struts-related extensions? I've been
> using that site for years with good results. Some ideas became struts
> subprojects and others didn't go anywhere. We've been very accepting of
> new projects over there and I believe Martin or Ted have already
> suggested it. struts.sf.net gets tons of hits and is a very good way to
> get your project out there and known.
+1
At SourceForge we have the freedom to add as committers whatever
volunteers are interested in this or that.
Last I knew, the bar was working code and a SourceForge account :)
The SourceForge site can be whatever the Struts community wants it to
be. People just have to step-up, do the work, and make a difference.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
LazyDynaBean [was Re: RFC: Struts HTML Ajax-Aware Tags]
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
----- Original Message -----
From: "Ted Husted" <te...@gmail.com>
Sent: Thursday, April 07, 2005 3:30 PM
> Is it hard to get new code into the Struts project? Yes, it is. But
> peole do it. Craig did it. Don did it. I'm hoping Niall will do it
> soon with LazyDynaBeans, and that Hubert will do the same.
LazyDynaBean, LazyDynaMap and LazyDynaClass were added to BeanUtils (July
2004) and released in version 1.7.0 - http://tinyurl.com/47scs
I added LazyValidatorForm to Struts (November 2004) and that got into
Version 1.2.6 - http://tinyurl.com/6nug4
Originally I also had a LazyValidatorActionForm flavour as well, but I
wasn't sure that people would want loads of lazy forms clogging up struts. I
also have a NestedLazyBean flavour ( http://tinyurl.com/53osj ) which I
quite like that I could put into struts. I'm easy going whether these go in
or not as I'm happy using them either way.
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by Ted Husted <te...@gmail.com>.
On Apr 7, 2005 9:31 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> I think the problem I see with that is that if you are making changes to
> existing code in the Struts distribution it means that people have to make
> a conscious choice to go down a potentially incompatible path.
>
> I think struts.sf.net works fine for things that truly are extensions,
> i.e., things that don't require an updated struts.jar for instance...
> But, anything that would require that, like these Ajax-aware tags requires
> one existing class be altered, makes it more difficult...
>
> If I were to finish this up and post it on struts.sf.net (or the Wiki,
> same argument) and then people decide to use it, they won't be able to
> move to 1.3... well, *theoretically* they couldn't, in this case they
> actually probably could, but for something like my setupItems a while back
> for instance, they couldn't. They would be relying on ME to upgrade it
> for each new Struts version (or prior versions maybe even) or they would
> have to do it themselves.
>
> But, if it was accepted into the Struts project proper, then it would be
> dealt with as part of the project, and while I myself still might be
> responsible for making sure it works with the next version, I am then
> doing so in the context of the larger project.
Before any of us add something to the main project, *all* of us have
to feel like it is going to be maintained. If necessary, each of us
has to be willing to take on the maintenance of any part of the
project ourselves.
That doesn't mean we have to write the patches, but it does mean we
have to be willing to consider patches the community supplies. Which
implies there has to be a community ready, willing, and able to supply
patches for us to consider.
Before we can commit to new code, we want to see the code in action.
We want to know how the community feels about it. We want to know how
easy it will be to maintain and patch. And we have to feel like the
original coder is going to stick by the product, at least for awhile.
When the code is created by someone who is already a committer, we can
put it in our own sandbox. Struts-Chain started this way, as did
Struts-Shale and Struts-Faces. Other gizmos, like the Nesting Taglibs,
Struts EL, the Validator, Tiles, and others, all had their own sites
and followers *before* we ever added them to the main project.
Once we do add code to the main project, we take it very seriously. We
maintain it over time, and if we decide to remove it, we do so by
deprecating and replacing over a series of releases. This is what we
have always done, and this is what the community expects us to do.
Is it hard to get new code into the Struts project? Yes, it is. But
peole do it. Craig did it. Don did it. I'm hoping Niall will do it
soon with LazyDynaBeans, and that Hubert will do the same.
Do most of the components come from committers? Yes, they do.
Sometimes they were committers first. And sometimes they made
committer afterwards. It's not a coincidence, since if we believe in
the code, and the community behind the code, then we tend to believe
in the coder too.
But, the committers don't ask anyone to do anything that we don't do
ourselves. All of us put new components through the sandbox or an
external site first. The main difference between a committer and a
developer, is that committers are willing to do it ourselves,
regardless of whether something is added to the main project or not.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Since what version have the tags been separate? I just looked in my 1.2.4
struts.jar I have deployed in production and all the tag classes are there
(well, the couple I looked for anyway, including BaseHandlerTag and
ButtonTag). Are you saying that they are in fact separate NOW but all
RELEASED versions of Struts actually still includes them? Just trying to
understand :)
In any case, I think your assessment is correct in that I myself view this
as just an extension to the tags. But, with the caveat that its the
BaseHandlerTag class that is altered, so it's not an extension you can
just ADD to an app, you'll have to REPLACE something (whether a full jar
or a single class or however else you might want to do it).
Doing it by extension instead is an interesting idea, and as long as I
could make it work without having to duplicate a bunch of code from the
existing BaseHandlerTag class, I'd be OK with that, and then it would be
suitable for struts.sf.net. Knowing how it works now, it's not clear to
me how to pull that off, but it's worth exploring.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Thu, April 7, 2005 9:44 am, Hubert Rabago said:
> My understanding of your initial email is that the Ajax-aware tags
> were really just extensions to the tags. Was I wrong?
>
> While I was reading it, I kept thinking they were going to be like
> what the EL tags are now. If you want the classic tags, use this tag
> library, if you want the Ajax tags, use this other one. The classes
> in the Ajax-aware tags would extend those in the taglib project.
>
> In any case, this wouldn't require a new struts.jar because the tags
> are in their own jar. It looks to me as a very good fit for an
> optional jar. People not interested in Ajax, or those wishing to use
> another Ajax solution, won't have to carry the Ajax-aware tag jar.
> Those who want to use it will just need to add an additional jar and
> use this other tag declaration.
>
> Hubert
>
>
> On Apr 7, 2005 8:31 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
>> I think the problem I see with that is that if you are making changes to
>> existing code in the Struts distribution it means that people have to
>> make
>> a conscious choice to go down a potentially incompatible path.
>>
>> I think struts.sf.net works fine for things that truly are extensions,
>> i.e., things that don't require an updated struts.jar for instance...
>> But, anything that would require that, like these Ajax-aware tags
>> requires
>> one existing class be altered, makes it more difficult...
>>
>> If I were to finish this up and post it on struts.sf.net (or the Wiki,
>> same argument) and then people decide to use it, they won't be able to
>> move to 1.3... well, *theoretically* they couldn't, in this case they
>> actually probably could, but for something like my setupItems a while
>> back
>> for instance, they couldn't. They would be relying on ME to upgrade it
>> for each new Struts version (or prior versions maybe even) or they would
>> have to do it themselves.
>>
>> But, if it was accepted into the Struts project proper, then it would be
>> dealt with as part of the project, and while I myself still might be
>> responsible for making sure it works with the next version, I am then
>> doing so in the context of the larger project.
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>>
>> On Thu, April 7, 2005 2:01 am, Don Brown said:
>> > I haven't really been following closely, but what is wrong with using
>> > struts.sf.net for distributing struts-related extensions? I've been
>> > using that site for years with good results. Some ideas became struts
>> > subprojects and others didn't go anywhere. We've been very accepting
>> of
>> > new projects over there and I believe Martin or Ted have already
>> > suggested it. struts.sf.net gets tons of hits and is a very good way
>> to
>> > get your project out there and known.
>> >
>> > Don
>> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by Hubert Rabago <hr...@gmail.com>.
My understanding of your initial email is that the Ajax-aware tags
were really just extensions to the tags. Was I wrong?
While I was reading it, I kept thinking they were going to be like
what the EL tags are now. If you want the classic tags, use this tag
library, if you want the Ajax tags, use this other one. The classes
in the Ajax-aware tags would extend those in the taglib project.
In any case, this wouldn't require a new struts.jar because the tags
are in their own jar. It looks to me as a very good fit for an
optional jar. People not interested in Ajax, or those wishing to use
another Ajax solution, won't have to carry the Ajax-aware tag jar.
Those who want to use it will just need to add an additional jar and
use this other tag declaration.
Hubert
On Apr 7, 2005 8:31 AM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> I think the problem I see with that is that if you are making changes to
> existing code in the Struts distribution it means that people have to make
> a conscious choice to go down a potentially incompatible path.
>
> I think struts.sf.net works fine for things that truly are extensions,
> i.e., things that don't require an updated struts.jar for instance...
> But, anything that would require that, like these Ajax-aware tags requires
> one existing class be altered, makes it more difficult...
>
> If I were to finish this up and post it on struts.sf.net (or the Wiki,
> same argument) and then people decide to use it, they won't be able to
> move to 1.3... well, *theoretically* they couldn't, in this case they
> actually probably could, but for something like my setupItems a while back
> for instance, they couldn't. They would be relying on ME to upgrade it
> for each new Struts version (or prior versions maybe even) or they would
> have to do it themselves.
>
> But, if it was accepted into the Struts project proper, then it would be
> dealt with as part of the project, and while I myself still might be
> responsible for making sure it works with the next version, I am then
> doing so in the context of the larger project.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> On Thu, April 7, 2005 2:01 am, Don Brown said:
> > I haven't really been following closely, but what is wrong with using
> > struts.sf.net for distributing struts-related extensions? I've been
> > using that site for years with good results. Some ideas became struts
> > subprojects and others didn't go anywhere. We've been very accepting of
> > new projects over there and I believe Martin or Ted have already
> > suggested it. struts.sf.net gets tons of hits and is a very good way to
> > get your project out there and known.
> >
> > Don
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I think the problem I see with that is that if you are making changes to
existing code in the Struts distribution it means that people have to make
a conscious choice to go down a potentially incompatible path.
I think struts.sf.net works fine for things that truly are extensions,
i.e., things that don't require an updated struts.jar for instance...
But, anything that would require that, like these Ajax-aware tags requires
one existing class be altered, makes it more difficult...
If I were to finish this up and post it on struts.sf.net (or the Wiki,
same argument) and then people decide to use it, they won't be able to
move to 1.3... well, *theoretically* they couldn't, in this case they
actually probably could, but for something like my setupItems a while back
for instance, they couldn't. They would be relying on ME to upgrade it
for each new Struts version (or prior versions maybe even) or they would
have to do it themselves.
But, if it was accepted into the Struts project proper, then it would be
dealt with as part of the project, and while I myself still might be
responsible for making sure it works with the next version, I am then
doing so in the context of the larger project.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Thu, April 7, 2005 2:01 am, Don Brown said:
> I haven't really been following closely, but what is wrong with using
> struts.sf.net for distributing struts-related extensions? I've been
> using that site for years with good results. Some ideas became struts
> subprojects and others didn't go anywhere. We've been very accepting of
> new projects over there and I believe Martin or Ted have already
> suggested it. struts.sf.net gets tons of hits and is a very good way to
> get your project out there and known.
>
> Don
>
> Dakota Jack wrote:
>> The below is a continuing problem. At this stage, Struts is pretty
>> mature and if you are not a committer able to make decisions, there
>> really is not too much you can do of interest with Struts other than
>> applications, although I will probably write my own branch this summer
>> for my own use with IoC. However, again, unless you are a committer
>> as in MappingDispatchAction, LookupDispatchAction, UploadAction, and
>> other like Strust application code not really part of the framework,
>> you face this problem Frank is facing because there is no effective
>> way to make these potential plugins available to the public. It would
>> be wonderful if there were a way to provide choices without having the
>> pecking order more important than the diversity of projects. I hope
>> to Hell that no one takes this as being a personal matter. Sometimes
>> you have to discuss principles and leave the personal trash at home.
>> A general scheme for application plugins would be really nice. There
>> should be a way for Frank's work to become available for people that
>> would like to use it. I don't think a rehash of the Wiki and like
>> recommendations really would be helpful on this, so please don't go
>> there unless you feel you must.
>>
>>
>> <SNIP>
>> On Apr 6, 2005 9:40 PM, Frank W. Zammetti <fz...@omnytex.com> wrote:
>>
>>>Martin Cooper wrote:
>>> > It's just a subset of
>>>
>>>>the possible schemes that people use for partial page rendering. By
>>>>adopting something like this as a Struts subproject, it gives the
>>>>appearance that Struts is endorsing this one particular approach to
>>>>the more general problem. That will carry a lot of weight in the
>>>>Struts community, and since I don't believe that this is the "one true
>>>>way" (LOTR again ;), that is not something I want to see.
>>>
>>>That's a valid point. No doubt there are 100 ways to skin this
>>>particular cat, and I wouldn't even claim to be proposing the best of
>>>the bunch.
>>
>> </SNIP.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by Dakota Jack <da...@gmail.com>.
The problem is one of access and planning. The solution is a hack.
Not a bad hack and one which some people are satisfied with
apparently. However, I hate a hack. And, it really does not work.
There are applications in the framework now. This is a hit or miss
thing based on personalities and predelictions rather than on a
coherent plan. DownloadAction, UploadAction, the whole panoply of
Struts upload and its insinuation into the RequestProcessor code in
inappropriate ways, LookupDispatchAction, etc., are all examples of
code that has a place but not the place they have.
Then there are things like Frank's proposal. I would love to have a
place in Struts where Struts based applications could be exposed,
debated, improved, etc.
Let me ask this question, what is wrong with having Struts, rather
than Struts SF, be the place for Struts applications and having Struts
SF be the place for developing Struts related applications? There is,
I would suggest, no coherent plan at the moment. You are, I think,
really missing a lot of submissions that would be great, if only you
had a way to do it that made sense. I have lots of code I have just
given up trying to provide because there is no way to do so
intelligently and without argument and rancor. My discussions on an
upload application were significant for me in this regard.
Essentially, I had to bastardize my appllication to fit the existing
Struts upload in order to present it to Struts. I decided that
crippling the code to accommodate an inferior but traditional product
just was not woth it. Struts SF cannot solve that problem.
I don't want to overstate the problem. I suspect a lot of people like
myself are constantly rewriting the underpinings of Struts to do their
own thing. I just took out everything associated with the upload so
that it did not get in the way.
I gave up discussing this because committers don't continue any
discussions but merely repeat the old saws. I have read the one you
offer about ten times, Don. Please don't take that personal. It is
not meant to be and I understand the legitimacy of your thoughts.
I expect the next usual suspects, a discussion of keeping things
consistent with existing code, etc. will be next. I am not an idiot
and realize all these rather obvious options and problems. That does
not change the fact that there is presently not an intelligent way to
add FINISHED applications to Struts.
I think that making plugin applications available would be more
important to Struts USERS than anything else you might do. I wonder
how many thousands of times the same basic applications are coded out
there with varying degrees of sophistication and success.
Anyway, you get the idea. I jsut thought I would note that the issues
arise again. They do this frequently.
On Apr 6, 2005 11:01 PM, Don Brown <mr...@twdata.org> wrote:
> I haven't really been following closely, but what is wrong with using
> struts.sf.net for distributing struts-related extensions? I've been
> using that site for years with good results. Some ideas became struts
> subprojects and others didn't go anywhere. We've been very accepting of
> new projects over there and I believe Martin or Ted have already
> suggested it. struts.sf.net gets tons of hits and is a very good way to
> get your project out there and known.
>
> Don
>
> Dakota Jack wrote:
> > The below is a continuing problem. At this stage, Struts is pretty
> > mature and if you are not a committer able to make decisions, there
> > really is not too much you can do of interest with Struts other than
> > applications, although I will probably write my own branch this summer
> > for my own use with IoC. However, again, unless you are a committer
> > as in MappingDispatchAction, LookupDispatchAction, UploadAction, and
> > other like Strust application code not really part of the framework,
> > you face this problem Frank is facing because there is no effective
> > way to make these potential plugins available to the public. It would
> > be wonderful if there were a way to provide choices without having the
> > pecking order more important than the diversity of projects. I hope
> > to Hell that no one takes this as being a personal matter. Sometimes
> > you have to discuss principles and leave the personal trash at home.
> > A general scheme for application plugins would be really nice. There
> > should be a way for Frank's work to become available for people that
> > would like to use it. I don't think a rehash of the Wiki and like
> > recommendations really would be helpful on this, so please don't go
> > there unless you feel you must.
> >
> >
> > <SNIP>
> > On Apr 6, 2005 9:40 PM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> >
> >>Martin Cooper wrote:
> >> > It's just a subset of
> >>
> >>>the possible schemes that people use for partial page rendering. By
> >>>adopting something like this as a Struts subproject, it gives the
> >>>appearance that Struts is endorsing this one particular approach to
> >>>the more general problem. That will carry a lot of weight in the
> >>>Struts community, and since I don't believe that this is the "one true
> >>>way" (LOTR again ;), that is not something I want to see.
> >>
> >>That's a valid point. No doubt there are 100 ways to skin this
> >>particular cat, and I wouldn't even claim to be proposing the best of
> >>the bunch.
> >
> > </SNIP.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by Don Brown <mr...@twdata.org>.
I haven't really been following closely, but what is wrong with using
struts.sf.net for distributing struts-related extensions? I've been
using that site for years with good results. Some ideas became struts
subprojects and others didn't go anywhere. We've been very accepting of
new projects over there and I believe Martin or Ted have already
suggested it. struts.sf.net gets tons of hits and is a very good way to
get your project out there and known.
Don
Dakota Jack wrote:
> The below is a continuing problem. At this stage, Struts is pretty
> mature and if you are not a committer able to make decisions, there
> really is not too much you can do of interest with Struts other than
> applications, although I will probably write my own branch this summer
> for my own use with IoC. However, again, unless you are a committer
> as in MappingDispatchAction, LookupDispatchAction, UploadAction, and
> other like Strust application code not really part of the framework,
> you face this problem Frank is facing because there is no effective
> way to make these potential plugins available to the public. It would
> be wonderful if there were a way to provide choices without having the
> pecking order more important than the diversity of projects. I hope
> to Hell that no one takes this as being a personal matter. Sometimes
> you have to discuss principles and leave the personal trash at home.
> A general scheme for application plugins would be really nice. There
> should be a way for Frank's work to become available for people that
> would like to use it. I don't think a rehash of the Wiki and like
> recommendations really would be helpful on this, so please don't go
> there unless you feel you must.
>
>
> <SNIP>
> On Apr 6, 2005 9:40 PM, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
>>Martin Cooper wrote:
>> > It's just a subset of
>>
>>>the possible schemes that people use for partial page rendering. By
>>>adopting something like this as a Struts subproject, it gives the
>>>appearance that Struts is endorsing this one particular approach to
>>>the more general problem. That will carry a lot of weight in the
>>>Struts community, and since I don't believe that this is the "one true
>>>way" (LOTR again ;), that is not something I want to see.
>>
>>That's a valid point. No doubt there are 100 ways to skin this
>>particular cat, and I wouldn't even claim to be proposing the best of
>>the bunch.
>
> </SNIP.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by Dakota Jack <da...@gmail.com>.
The below is a continuing problem. At this stage, Struts is pretty
mature and if you are not a committer able to make decisions, there
really is not too much you can do of interest with Struts other than
applications, although I will probably write my own branch this summer
for my own use with IoC. However, again, unless you are a committer
as in MappingDispatchAction, LookupDispatchAction, UploadAction, and
other like Strust application code not really part of the framework,
you face this problem Frank is facing because there is no effective
way to make these potential plugins available to the public. It would
be wonderful if there were a way to provide choices without having the
pecking order more important than the diversity of projects. I hope
to Hell that no one takes this as being a personal matter. Sometimes
you have to discuss principles and leave the personal trash at home.
A general scheme for application plugins would be really nice. There
should be a way for Frank's work to become available for people that
would like to use it. I don't think a rehash of the Wiki and like
recommendations really would be helpful on this, so please don't go
there unless you feel you must.
<SNIP>
On Apr 6, 2005 9:40 PM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Martin Cooper wrote:
> > It's just a subset of
> > the possible schemes that people use for partial page rendering. By
> > adopting something like this as a Struts subproject, it gives the
> > appearance that Struts is endorsing this one particular approach to
> > the more general problem. That will carry a lot of weight in the
> > Struts community, and since I don't believe that this is the "one true
> > way" (LOTR again ;), that is not something I want to see.
>
> That's a valid point. No doubt there are 100 ways to skin this
> particular cat, and I wouldn't even claim to be proposing the best of
> the bunch.
</SNIP.
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Martin Cooper wrote:
> I'm not sure what you're proposing here. If you're looking for
> feedback on something that might become a Struts extension, for
> example as part of the Struts SourceForge project, then I would say
> knock yourself out. ;-) However, if you're proposing this as a future
> Struts subproject here at the ASF, then I would be against it, for the
> following reasons:
I wasn't proposing anything more than getting feedback, see if there was
any interest in this. I figured I had done enough to get the general
idea across and I didn't see any sense in putting in the rest of the
effort if no one was going to support it. If there was support, my
feeling was that it would just be a new version of the HTML taglib,
perhaps released in concert with Struts 1.3, perhaps not. Ted mentioned
the idea of a new subproject, which I wasn't against, but it wasn't what
I was thinking when I first posted.
> 1) Ajax is just the latest buzzword for something people have been
> doing with browser based applications for years.
You and I know that (we've had some exchanges in the past, I know you do
many of the more complex client apps like I do), but many people are
just coming to the realization that you don't have to refresh entire
pages all the time, and whether it's a new buzzword for something old or
not (it is!), it does seem to be something new to a lot of people, and
there is growing interest in such techniques.
> It's just a subset of
> the possible schemes that people use for partial page rendering. By
> adopting something like this as a Struts subproject, it gives the
> appearance that Struts is endorsing this one particular approach to
> the more general problem. That will carry a lot of weight in the
> Struts community, and since I don't believe that this is the "one true
> way" (LOTR again ;), that is not something I want to see.
That's a valid point. No doubt there are 100 ways to skin this
particular cat, and I wouldn't even claim to be proposing the best of
the bunch.
But then again, knowing what you know about more complex client-side
development, wouldn't it perhaps be helpful to people wanting to do
things like this to have some degree of this type of functionality built
in to the tags they already know and use?
Mind you, I'm all for walking with you or anyone else that is interested
right in to Mt. Doom and trying to forge that One True Way :) If its
something completely different than this, so be it, but I'd have to be
convinced, just like anyone else :)
> 2) Many people are already using existing libraries to build Ajax-like
> applications. I don't believe that Struts should be providing yet
> another client-side implementation. If we really want to have an
> Ajax-like taglib as part of Struts, then it should be capable of using
> whatever client-side library the developer wants, whether that's Dojo,
> nWidgets, Burst, f(m) or Zammetti Special. ;-)
But aren't those people already away from using Struts tags? I admit I
am not familiar with the four libraries (and the one you posit :) ), but
I would assume you don't use Struts tags with them (at least not the
HTML tags). If that is the case, I don't see why that would clash with
the idea of having some Ajax-type capabilities in what you could view as
the more "generic" Struts HTML tags at that point.
For those people who are still using the Struts tags, and I'd bet most
of them are building more "classical" web applications, why not open
things up for them a bit? For those using more robust libraries, no
problem, just ignore the HTML tags, as I'm betting they do already.
It's kind of like saying people shouldn't have access to a Ford because
there are Lamborghini, Jaguars and Lexuses out there. Some don't need
or want a Jaguar, but it's nice that they can get a Ford that suits
them. I'm proposing providing the Ford :)
> 3) This seems to me to be a particularly restrictive implementation of
> the Ajax concept.
I'd be interested to know in what way you see restrictions... Perhaps
they are things that could be addressed...
> While it might be possible to expand this to cover
> all of the possibilities, I suspect that the end result would be
> horribly complicated, making it much simpler to go back to just using
> the existing onXXX attributes and defining the rest in JavaScript.
Hibernate is way too complicated. Doesn't stop anyone from using it.
EJBs are far too complex. Many use them. JSF is quite complex, many
people have no aversion to it. I don't think this would be even as
complex as the simplest of that bunch :)
Not that I'm saying complexity isn't to be avoided. It almost always is
in my mind. And I would agree, for anyone with the knowledge and
capability to do something like this themselves, they frankly probably
should as you point out.
Well, I asked for feedback and that's what I got :) You have a huge say
in how things go Martin, so if this doesn't fit your vision then I
suppose it's dead in the water.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by Martin Cooper <mf...@gmail.com>.
I'm not sure what you're proposing here. If you're looking for
feedback on something that might become a Struts extension, for
example as part of the Struts SourceForge project, then I would say
knock yourself out. ;-) However, if you're proposing this as a future
Struts subproject here at the ASF, then I would be against it, for the
following reasons:
1) Ajax is just the latest buzzword for something people have been
doing with browser based applications for years. It's just a subset of
the possible schemes that people use for partial page rendering. By
adopting something like this as a Struts subproject, it gives the
appearance that Struts is endorsing this one particular approach to
the more general problem. That will carry a lot of weight in the
Struts community, and since I don't believe that this is the "one true
way" (LOTR again ;), that is not something I want to see.
2) Many people are already using existing libraries to build Ajax-like
applications. I don't believe that Struts should be providing yet
another client-side implementation. If we really want to have an
Ajax-like taglib as part of Struts, then it should be capable of using
whatever client-side library the developer wants, whether that's Dojo,
nWidgets, Burst, f(m) or Zammetti Special. ;-)
3) This seems to me to be a particularly restrictive implementation of
the Ajax concept. While it might be possible to expand this to cover
all of the possibilities, I suspect that the end result would be
horribly complicated, making it much simpler to go back to just using
the existing onXXX attributes and defining the rest in JavaScript.
--
Martin Cooper
On Apr 6, 2005 12:37 PM, Frank W. Zammetti <fz...@omnytex.com> wrote:
> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 <fz...@omnytex.com> 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: dev-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by Andres Paz Sampedro <ra...@gmail.com>.
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 <fz...@omnytex.com> 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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RFC: Struts HTML Ajax-Aware Tags
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org