Use of Javascript [was] Re: AJAX: Whoa, Nellie!
Jesse Alexander (KBSA 21) wrote the following on 4/19/2005 5:30 AM: I also think that a well-designed web-UI does not need JS at all... Sorry to jump on the train late, but the above is completely BS. If you want to use standard HTML, then there will be some things you will HAVE to do with Javascript or else without its use, just the opposite would be true, you'd have a totally CRAPPY-designed UI. I'll give you an example. In quick summary, this application has to have the user select various checkboxes in a tree-list structure and as they select various checkboxes different lines need to change color (turn to gray for example to show that inheritance is implied). Not only that, but based on whether a certain checkbox is selected in a row a date div box needs to become enabled and visible. The bottom line is if you do not use javascript you'd have to go to the server for everything creating a completely unsatisfactory user experience. The users should be able to click all over the place without having to wait for the server to respond each time. Even if you wanted to go to the server for every single possible checkbox click, how could you even do that without some javascript? Tell me how you can design a good UI that does not involve javascript for this application (other than saying use Flash or some other font end presentation). Bottom line is any somewhat complex UI for a company will have to involve the use of some javascript. If you disgree than I'll send screen shots of various internal applications I have to code and you tell me how you can get around not using Javascript? I could just look around on the web and give examples where you'd need javascript. Think of cases where on a form you select one option from a drop down and the other list needs to change. Even if you go to the server to repopulate the other list (which I like to do), it still requires and onChange event on the initial drop down list to fire off the submit. How do you do this without javascript? - create a walk-through UI design? That would be completely unacceptable under a lot of circumstances. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use of Javascript [was] Re: AJAX: Whoa, Nellie!
I liked the smartclient technology very much! It's great! Just wondering if there will be a similar possibility in Java Server Faces? Can I combine the capabilities of JSF and AJAX ? RR Jesse Alexander (KBSA 21) wrote the following on 4/19/2005 5:30 AM: I also think that a well-designed web-UI does not need JS at all... RR Sorry to jump on the train late, but the above is completely BS. If you RR want to use standard HTML, then there will be some things you will HAVE RR to do with Javascript or else without its use, just the opposite would RR be true, you'd have a totally CRAPPY-designed UI. RR I'll give you an example. In quick summary, this application has to have RR the user select various checkboxes in a tree-list structure and as they RR select various checkboxes different lines need to change color (turn to RR gray for example to show that inheritance is implied). Not only that, RR but based on whether a certain checkbox is selected in a row a date div RR box needs to become enabled and visible. The bottom line is if you do RR not use javascript you'd have to go to the server for everything RR creating a completely unsatisfactory user experience. The users should RR be able to click all over the place without having to wait for the RR server to respond each time. Even if you wanted to go to the server for RR every single possible checkbox click, how could you even do that without RR some javascript? Tell me how you can design a good UI that does not RR involve javascript for this application (other than saying use Flash or RR some other font end presentation). Bottom line is any somewhat complex RR UI for a company will have to involve the use of some javascript. RR If you disgree than I'll send screen shots of various internal RR applications I have to code and you tell me how you can get around not RR using Javascript? I could just look around on the web and give examples RR where you'd need javascript. Think of cases where on a form you select RR one option from a drop down and the other list needs to change. Even if RR you go to the server to repopulate the other list (which I like to do), RR it still requires and onChange event on the initial drop down list to RR fire off the submit. How do you do this without javascript? - create a RR walk-through UI design? That would be completely unacceptable under a RR lot of circumstances. -- regards, Sergey mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use of Javascript [was] Re: AJAX: Whoa, Nellie!
On 5/2/05, Sergey Livanov [EMAIL PROTECTED] wrote: I liked the smartclient technology very much! It's great! Just wondering if there will be a similar possibility in Java Server Faces? Can I combine the capabilities of JSF and AJAX ? Yes. The general idea is that you encapsulate the creation of your Javascript and template code (or links to corresponding resource files) into a JavaServer Faces component, which the developer can incorporate on their page just like any other component. On the client side, the rendered code would do XmlHttpRequest transactions with the host, using whatever your favorite binding technology is (dojo, dwr, ...). I know of several commercial libraries that already do this sort of thing (jsfcentral.com is a good starting place for pointers). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
I must have missed getting across what I was trying to convey...
Basically the below was a proof-of-concept to show the same code that
would be added to taglibs could be added to a javascript library and be
freely distributed which would resolve the issues at hand. Then only
the implementers would need to write javascript, everyone else would
just need to learn the functions available and call the appropriate ones
(and of course add the javascript include).
So as far as reading back a table, etc, etc. those can just as easily be
a javascript api as a taglib update. The javascript api version would
appear to give the same benefits for less cost from what I can tell so
far. You would just need to instruct the user: if you need to replace
inner html, call function a with the element to have the html replaced
and the url to use to replaced the information. For an existing user,
they're likely already calling a javascript function so they can
re-direct from their own function in to the library as needed.
Conceivably you could do the same for xml returns and anything else
since we are talking client-side here.
I haven't really used any of this ajax approach personally so I don't
really know what kinds of needs people have when they are using it.
Once the needs are determined it should be easy enough to write a good
abstraction layer and I'd be willing to help there if this isn't
something that's already planned by someone.
I'd be interested to hear re: your ideas of handler types at
[EMAIL PROTECTED] I'm moving this weekend (and have a newborn at
home) so I'll be busy for the next week or so setting up and after that
should have time to help out if it looks like something that I believe
adds value.
Regards...djsuarez
-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 20, 2005 4:31 PM
To: David Suarez
Cc: Struts Users Mailing List
Subject: Re: AJAX: Whoa, Nellie!
David Suarez wrote:
Saw the flood of these AJAX messages and was interested so I did a
quick
test using a plain html page to see how easy it is to create a generic
javascript to handle the ajax call-back pieces in question. My test
showed it is easily possible so I'm not sure how much value you'll get
from creating another server-side component. Another javascript
library
that wraps dojo would probably be all you need.
If you consider a taglib to be server-side, than granted.
Either way, the benefit is the fact that you don't have to write any
code, even admittedly simple code.
This is the general idea of the test I did in terms of the dojo/ajax
conversation:
Generic Javascript function always included if you need to use ajax
(some javascript include that is added to the page):
//updates the inner html of the passed object
updateInnerHtml(theobj, theurl)
{
dojo.io.bind({
url: theurl,
load: function(type, data) {
theobj.innerHTML = data; }, //Note: theobj
variable is accessible here in firefox and IE... that was my test
mimetype: text/plain
});
}
That's fine if what you want to do is update innerHTML of something.
But what if you want to take XML that was returned and populate a table?
That is, I think you'd agree, more involved code.
Using the example, something like the below would be on the page:
html:button property=button1 value=Click to do Ajax!
onClick=updateObject(this,http://xxx.yyy.zzz?a=bc=d;)/
And that works well if all your looking to do is submit a query string
to a URL. If you want to do something more complex (like create an XML
document from a collection of form elements), that too is more involved.
These are the types of functions I envision the tags providing for you
as standard actions. If you need to do something non-standard, no
problem either.
and it could be reused for any innerHTML replacements by changing the
url in the function call. I don't think button has an innerHTML
property but just to use the example given, you get the idea
Probably having a javascript library with updateValue() and other
useful
often changed properties would do the trick.
That is a good idea! I'll think I'll steal that for some of my standard
actions :)
If anyone ever takes this on I'd appreciate it if you could keep me in
the loop on development of it. I would help as well as needed. Maybe
the dojo team has something like this already in mind?
One note: you would in fact be able to do what you are doing here with
my tags as well, the only difference is that you wouldn't have to write
that code, either the function or the event handler. You could instead
specify it in an XML config file.
The quick sample I put together doesn't use dojo so I haven't tested
the
specific code but I have tested the idea with a test script and it
does
work.
Hope the above makes sense. Does anyone see negatives to using the
above? It seems to take care of the code
Re: AJAX: Whoa, Nellie!
Craig McClanahan wrote: The 3000 or so people that are here want to be able to ask questions about using Struts IMO, using Struts with client side technologies such as .js, dojo and ajax is on topic. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: AJAX: Whoa, Nellie!
The point is that few, if any, of the 140+ posts in the thread are DIRECTLY related to struts. The majority are in the arena of discussing the merits/pitfalls AJAX-related technologies. And to be honest, I think all salient points have been made. I think we can all agree that the horse is dead and needn't be flogged any more. Dennis Vic Cekvenich (netsql) [EMAIL PROTECTED] Sent by: news [EMAIL PROTECTED] 04/21/2005 08:58 AM Please respond to Struts Users Mailing List user@struts.apache.org To user@struts.apache.org cc Subject Re: AJAX: Whoa, Nellie! Craig McClanahan wrote: The 3000 or so people that are here want to be able to ask questions about using Struts IMO, using Struts with client side technologies such as .js, dojo and ajax is on topic. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] [Friday] Re: AJAX: Whoa, Nellie!
[EMAIL PROTECTED] wrote: I think all salient points have been made. Agree. It's almost friday: http://www.moronland.com/image.php?media=Apple%20Weed .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] [Friday] Re: AJAX: Whoa, Nellie!
Heh. Normally I hate stuff like this, but for some reason, that one was so silly it just cracked me up. Must be because I just woke up. :) Erik Vic Cekvenich (netsql) wrote: [EMAIL PROTECTED] wrote: I think all salient points have been made. Agree. It's almost friday: http://www.moronland.com/image.php?media=Apple%20Weed .V - 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]
[OT] Re: AJAX: Whoa, Nellie!
Frank W. Zammetti wrote:
On Tue, April 19, 2005 10:47 am, Erik Weber said:
I, with respect for the author, disagree with this entirely.
I am people, and this is not what I expect or desire at all. As a user,
I expect and desire 1) A fast download 2) my bookmarks to work/easy to
remember URLs 3) an organized and well-thought-out left rail 4) a go
home link at the top 5) a two-field registration 6) an encrypted log on
7) content I can read in a text-only browser. None of these require any
browser scripting at all.
You describe a good web SITE, and I couldn't agree with your criteria
more! However, what you don't describe well is a web APPLICATION.
Web APPLICATIONS are where the scripting is, generally, needed, and where
the UI tends to be more complex.
Well, you are right, but that's also my point. I think it's comical that
here we are in 2005, and Web application developers are just now able to
provide users with a way to launch an asynchronous task via a GUI
control. And it's still hackish as far as I can tell (embedding
engines in hidden frames? -- come on . . .). Wouldn't you rather use a
real API to a real windowing/graphics library, not to mention a real
threading API?
final int threadPriority = MEDIUM_THREAD_PRIORITY;
final int iterationYieldFrequency = 100;
final int callbackFrequency = 25;
final ProgressListener listener = getGUIUpdater();
button.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
SwingWorker worker = new CustomSwingWorker(long time job,
threadPriority) {
public Object construct() {
JobManager manager = new JobManager();
int statusCode = manager.launchLongJob(foo job,
iterationYieldFrequency, callbackFrequency, listener);
return new Integer(statusCode);
}
public void finished() {
updateGUI(statusCode.intValue());
}
};
worker.start();
}
};
I guess I'm in the wrong forum.
:)
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: AJAX: Whoa, Nellie!
Erik Weber wrote:
SwingWorker worker = new CustomSwingWorker(GET_XML_RPC_DATA) {
I guess I'm in the wrong forum.
:)
Erik
Ahh it's the right forum ;-).
My code is VERY similar to above.
.V
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: AJAX: Whoa, Nellie!
There are lots of issues besides just wanting this to happen. All
serious attempts so far have pretty much failed. Have you looked at
Flash, if this is your big interest? Flash ActionScript pretty much
does what you want. But, I don't think it is a good idea. I think
you have to keep some things serverside.
Jack
On 4/20/05, Erik Weber [EMAIL PROTECTED] wrote:
Frank W. Zammetti wrote:
On Tue, April 19, 2005 10:47 am, Erik Weber said:
I, with respect for the author, disagree with this entirely.
I am people, and this is not what I expect or desire at all. As a user,
I expect and desire 1) A fast download 2) my bookmarks to work/easy to
remember URLs 3) an organized and well-thought-out left rail 4) a go
home link at the top 5) a two-field registration 6) an encrypted log on
7) content I can read in a text-only browser. None of these require any
browser scripting at all.
You describe a good web SITE, and I couldn't agree with your criteria
more! However, what you don't describe well is a web APPLICATION.
Web APPLICATIONS are where the scripting is, generally, needed, and where
the UI tends to be more complex.
Well, you are right, but that's also my point. I think it's comical that
here we are in 2005, and Web application developers are just now able to
provide users with a way to launch an asynchronous task via a GUI
control. And it's still hackish as far as I can tell (embedding
engines in hidden frames? -- come on . . .). Wouldn't you rather use a
real API to a real windowing/graphics library, not to mention a real
threading API?
final int threadPriority = MEDIUM_THREAD_PRIORITY;
final int iterationYieldFrequency = 100;
final int callbackFrequency = 25;
final ProgressListener listener = getGUIUpdater();
button.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
SwingWorker worker = new CustomSwingWorker(long time job,
threadPriority) {
public Object construct() {
JobManager manager = new JobManager();
int statusCode = manager.launchLongJob(foo job,
iterationYieldFrequency, callbackFrequency, listener);
return new Integer(statusCode);
}
public void finished() {
updateGUI(statusCode.intValue());
}
};
worker.start();
}
};
I guess I'm in the wrong forum.
:)
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
You can lead a horse to water but you cannot make it float on its back.
~Dakota Jack~
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: AJAX: Whoa, Nellie!
You know, if what you want is Swing on the client, i.e., you write code to
do everything, then my VisML project that I mentioned yesterday is one
such option.
But you start to see in a pretty big hurry that it isn't a good idea...
One of the most powerful aspects of web development is the way you can
separate presentation from data and describe both in a meta language.
That is of course what HTML is! I mean, think of it this way...
When you write...
img src=myImage.gif
... this is essentially a meta description for something like (assuming
Windows):
int xLocation = calculateImageLocationX(browser.getWindow());
int yLocation = calculateImageLocationY(browser.getWindow());
DirectX d = new DirectX();
DXImage i = d.getImage(%imageSrc%);
browser.getWindow().drawImage(i, xLocation, yLocation);
...now, don't for a second think that is legitmiate code! It is
completely made up :) The point I'm trying to make though is that a great
deal of code is being executed, potentially anyway, as a result of a
seemingly simple img tag.
Now, if you had to write all that code instead of just dropping a tag in a
page, UGH! And that doesn't even mention the hassle of now having
something to compile as opposed to something to simply drop in a directory
somewhere and let the app server recompile on-the-fly.
I forget who it was but someone mentioned the idea of having custom tags
that generate the underlying code... this is an intersting idea to me
because you get the whole Swing-ish code-centric approach underlying it
all, but with custom tags so you don't have to do all the code if you
don't want to. If I took my VisML project and wrapped a taglib around it,
that could be interesting (although I'd still have any number of
concerns). Maybe for down the road...
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Wed, April 20, 2005 9:31 am, Dakota Jack said:
There are lots of issues besides just wanting this to happen. All
serious attempts so far have pretty much failed. Have you looked at
Flash, if this is your big interest? Flash ActionScript pretty much
does what you want. But, I don't think it is a good idea. I think
you have to keep some things serverside.
Jack
On 4/20/05, Erik Weber [EMAIL PROTECTED] wrote:
Frank W. Zammetti wrote:
On Tue, April 19, 2005 10:47 am, Erik Weber said:
I, with respect for the author, disagree with this entirely.
I am people, and this is not what I expect or desire at all. As a
user,
I expect and desire 1) A fast download 2) my bookmarks to work/easy to
remember URLs 3) an organized and well-thought-out left rail 4) a go
home link at the top 5) a two-field registration 6) an encrypted log
on
7) content I can read in a text-only browser. None of these require
any
browser scripting at all.
You describe a good web SITE, and I couldn't agree with your criteria
more! However, what you don't describe well is a web APPLICATION.
Web APPLICATIONS are where the scripting is, generally, needed, and
where
the UI tends to be more complex.
Well, you are right, but that's also my point. I think it's comical that
here we are in 2005, and Web application developers are just now able to
provide users with a way to launch an asynchronous task via a GUI
control. And it's still hackish as far as I can tell (embedding
engines in hidden frames? -- come on . . .). Wouldn't you rather use a
real API to a real windowing/graphics library, not to mention a real
threading API?
final int threadPriority = MEDIUM_THREAD_PRIORITY;
final int iterationYieldFrequency = 100;
final int callbackFrequency = 25;
final ProgressListener listener = getGUIUpdater();
button.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
SwingWorker worker = new CustomSwingWorker(long time job,
threadPriority) {
public Object construct() {
JobManager manager = new JobManager();
int statusCode = manager.launchLongJob(foo job,
iterationYieldFrequency, callbackFrequency, listener);
return new Integer(statusCode);
}
public void finished() {
updateGUI(statusCode.intValue());
}
};
worker.start();
}
};
I guess I'm in the wrong forum.
:)
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
You can lead a horse to water but you cannot make it float on its back.
~Dakota Jack~
-
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]
Re: [OT] Re: AJAX: Whoa, Nellie!
Frank W. Zammetti wrote: someone mentioned the idea of having custom tags that generate the underlying code... this is an intersting idea to me because you get the whole Swing-ish code-centric approach underlying it all, but with custom tags so you don't have to do all the code if you don't want to. http://javadesktop.org/jdnc/0_5/docs/tutorial/index.html Did I link this this week? :-} It be great if javascript DHTML could do this so we all separate the UI. If you need is now, look at dojo, but no tags. If you need best I conculded JDNC is best for me. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: AJAX: Whoa, Nellie!
Good idea. There is an incipient similar thing going on with the
image package in the commons sandbox. Abey Mullasery's work there is
interesting. I think it needs a bit more practical grounding, but
that will come. These two projects do not overlap, but the point
does.
On 4/20/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
You know, if what you want is Swing on the client, i.e., you write code to
do everything, then my VisML project that I mentioned yesterday is one
such option.
But you start to see in a pretty big hurry that it isn't a good idea...
One of the most powerful aspects of web development is the way you can
separate presentation from data and describe both in a meta language.
That is of course what HTML is! I mean, think of it this way...
When you write...
img src=myImage.gif
... this is essentially a meta description for something like (assuming
Windows):
int xLocation = calculateImageLocationX(browser.getWindow());
int yLocation = calculateImageLocationY(browser.getWindow());
DirectX d = new DirectX();
DXImage i = d.getImage(%imageSrc%);
browser.getWindow().drawImage(i, xLocation, yLocation);
...now, don't for a second think that is legitmiate code! It is
completely made up :) The point I'm trying to make though is that a great
deal of code is being executed, potentially anyway, as a result of a
seemingly simple img tag.
Now, if you had to write all that code instead of just dropping a tag in a
page, UGH! And that doesn't even mention the hassle of now having
something to compile as opposed to something to simply drop in a directory
somewhere and let the app server recompile on-the-fly.
I forget who it was but someone mentioned the idea of having custom tags
that generate the underlying code... this is an intersting idea to me
because you get the whole Swing-ish code-centric approach underlying it
all, but with custom tags so you don't have to do all the code if you
don't want to. If I took my VisML project and wrapped a taglib around it,
that could be interesting (although I'd still have any number of
concerns). Maybe for down the road...
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Wed, April 20, 2005 9:31 am, Dakota Jack said:
There are lots of issues besides just wanting this to happen. All
serious attempts so far have pretty much failed. Have you looked at
Flash, if this is your big interest? Flash ActionScript pretty much
does what you want. But, I don't think it is a good idea. I think
you have to keep some things serverside.
Jack
On 4/20/05, Erik Weber [EMAIL PROTECTED] wrote:
Frank W. Zammetti wrote:
On Tue, April 19, 2005 10:47 am, Erik Weber said:
I, with respect for the author, disagree with this entirely.
I am people, and this is not what I expect or desire at all. As a
user,
I expect and desire 1) A fast download 2) my bookmarks to work/easy to
remember URLs 3) an organized and well-thought-out left rail 4) a go
home link at the top 5) a two-field registration 6) an encrypted log
on
7) content I can read in a text-only browser. None of these require
any
browser scripting at all.
You describe a good web SITE, and I couldn't agree with your criteria
more! However, what you don't describe well is a web APPLICATION.
Web APPLICATIONS are where the scripting is, generally, needed, and
where
the UI tends to be more complex.
Well, you are right, but that's also my point. I think it's comical that
here we are in 2005, and Web application developers are just now able to
provide users with a way to launch an asynchronous task via a GUI
control. And it's still hackish as far as I can tell (embedding
engines in hidden frames? -- come on . . .). Wouldn't you rather use a
real API to a real windowing/graphics library, not to mention a real
threading API?
final int threadPriority = MEDIUM_THREAD_PRIORITY;
final int iterationYieldFrequency = 100;
final int callbackFrequency = 25;
final ProgressListener listener = getGUIUpdater();
button.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
SwingWorker worker = new CustomSwingWorker(long time job,
threadPriority) {
public Object construct() {
JobManager manager = new JobManager();
int statusCode = manager.launchLongJob(foo job,
iterationYieldFrequency, callbackFrequency, listener);
return new Integer(statusCode);
}
public void finished() {
updateGUI(statusCode.intValue());
}
};
worker.start();
}
};
I guess I'm in the wrong forum.
:)
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
You can lead a horse to water
[_Severely_ OT; linguistics, end of thread (for me)] Re: AJAX: Whoa, Nellie!
Dakota Jack wrote: According to the linguists, the beauty of language is just the opposite, viz. its public nature, so that private meanings are not only allowed, they categorically make no sense. That's swell, from an academic point of view, but the fact is that people mean different things with the same words. Sometimes hugely different, sometimes only a subtle internal difference brought forth by their physiology, upbringing, etc. Take the word life, for instance, and enjoy. This has been the rock-hard basis for modern linguistic analysis for as long as the Sun has risen. Er... Technical terms can have technical definitions, but normal words in normal contexts, including scientific and technical contexts, must have the meaning given to them in use by their users. That is why I talked about how the word is used, rather than about how we can mean anything we want. And if two people use the same word in two different ways then it means two different things to two different people, and this happens more than I prefer. All _I_ said was that HTML isn't rendered until it's drawn on the screen, but a view, perhaps, could be rendered to HTML, which in turn is rendered by the browser. Which uses two different meanings of render, which is fine, and I already said that I can live with the term used this way, albeit grudgingly. _I_ still think the view _generates_ HTML. Interestingly, I was just thinking about this, and if the view was generating PostScript, I might actually use rendered, even though PostScript is just Forth (almost my favorite language, next to Lisp-y things). Isn't that interesting? See? I even contradict my _own_ meaning of render, and I'm okay with that (for now; I may have to think about this and normalize my use of the word one way or the other). Perhaps my views on linguistics were colored a bit too much by Roger Schank, I dunno... working near him rubs off on you whether you like it or not--but the moniker L'enfant Terrible of Linguistics wasn't bestowed upon him lightly :D Dave Doesn't like going back and forth about nothing as much as you do Newton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
Oops! Changed the name of the function when writing the email and
didn't update the name of the caller. The example would be like so:
//In generic javascript include
//updates the inner html of the passed object
updateInnerHtml(theobj, theurl)
{
dojo.io.bind({
url: theurl,
load: function(type, data) {
theobj.innerHTML = data; }, //Note: theobj
variable is accessible here in firefox and IE... that was my test
mimetype: text/plain
});
}
//In Page
Using the example, something like the below would be on the page:
html:button property=button1 value=Click to do Ajax!
onClick=updateInnerHtml(this,http://xxx.yyy.zzz?a=bc=d;)/
Same caveats as below apply...djsuarez
-Original Message-
From: David Suarez
Sent: Wednesday, April 20, 2005 3:26 PM
To: '[EMAIL PROTECTED]'; Struts Users Mailing List
Subject: RE: AJAX: Whoa, Nellie!
Saw the flood of these AJAX messages and was interested so I did a quick
test using a plain html page to see how easy it is to create a generic
javascript to handle the ajax call-back pieces in question. My test
showed it is easily possible so I'm not sure how much value you'll get
from creating another server-side component. Another javascript library
that wraps dojo would probably be all you need.
This is the general idea of the test I did in terms of the dojo/ajax
conversation:
Generic Javascript function always included if you need to use ajax
(some javascript include that is added to the page):
//updates the inner html of the passed object
updateInnerHtml(theobj, theurl)
{
dojo.io.bind({
url: theurl,
load: function(type, data) {
theobj.innerHTML = data; }, //Note: theobj
variable is accessible here in firefox and IE... that was my test
mimetype: text/plain
});
}
Using the example, something like the below would be on the page:
html:button property=button1 value=Click to do Ajax!
onClick=updateObject(this,http://xxx.yyy.zzz?a=bc=d;)/
and it could be reused for any innerHTML replacements by changing the
url in the function call. I don't think button has an innerHTML
property but just to use the example given, you get the idea
Probably having a javascript library with updateValue() and other useful
often changed properties would do the trick.
If anyone ever takes this on I'd appreciate it if you could keep me in
the loop on development of it. I would help as well as needed. Maybe
the dojo team has something like this already in mind?
The quick sample I put together doesn't use dojo so I haven't tested the
specific code but I have tested the idea with a test script and it does
work.
Hope the above makes sense. Does anyone see negatives to using the
above? It seems to take care of the code duplication concerns. The url
concern can be handled by making it a variable passed from the server
side I would guess from a form or other similar mechanism would do the
trick there.
I was interested in the conversation, hope this adds some value.
Regards...djsuarez
-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 19, 2005 10:49 PM
To: Struts Users Mailing List
Subject: Re: AJAX: Whoa, Nellie!
Martin Cooper wrote:
My Huh? comment was in reference you your statement that the
approach I
was describing doesn't really help people with existing apps, which
I take
issue with. If you put the JavaScript methods in separate file, it has
the
exact same impact on the JSP pages as your approach does, but without
needing the custom attributes. You say 'ajaxRef=button1' and I say
'onclick=doButton1()'.
Ok, I may have misunderstood that.
Moving on though...
If you put the JavaScript methods in separate file, it has the
exact same impact on the JSP pages as your approach does
I do not belive this is true, and here's why... as far as the event
handlers go, I agree, the impact is virtually identical... But in terms
of what the event handler calls there is I think a big difference.
Going back to your original example, you state:
Elsewhere in the JSP page, or maybe somewhere else:
function doButton1() {
dojo.io.bind({
url:
http://www.omnytex.com?buttonValue=button1textValue=text1;,
load: function(type, data) {
document.getElementById(resultLayer).innerHTML = data; },
mimetype: text/plain
});
}
Now, that looks like more work to me because, if nothing else, I'm
writing the return handler myself. And if I had to write 20 of these
functions for a single page, ugh! You mentioned DynaActionForms saving
a lot of tedious coding... this is about as tedious as it gets :)
If you want to argue that moving these functions out to another file
that you include makes the situation better, I'd say only marginally
better because the benefit of separating the code is offset somewhat by
the fact that now there are two files to maintain
Re: AJAX: Whoa, Nellie!
David Suarez wrote:
Saw the flood of these AJAX messages and was interested so I did a quick
test using a plain html page to see how easy it is to create a generic
javascript to handle the ajax call-back pieces in question. My test
showed it is easily possible so I'm not sure how much value you'll get
from creating another server-side component. Another javascript library
that wraps dojo would probably be all you need.
If you consider a taglib to be server-side, than granted.
Either way, the benefit is the fact that you don't have to write any
code, even admittedly simple code.
This is the general idea of the test I did in terms of the dojo/ajax
conversation:
Generic Javascript function always included if you need to use ajax
(some javascript include that is added to the page):
//updates the inner html of the passed object
updateInnerHtml(theobj, theurl)
{
dojo.io.bind({
url: theurl,
load: function(type, data) {
theobj.innerHTML = data; }, //Note: theobj
variable is accessible here in firefox and IE... that was my test
mimetype: text/plain
});
}
That's fine if what you want to do is update innerHTML of something.
But what if you want to take XML that was returned and populate a table?
That is, I think you'd agree, more involved code.
Using the example, something like the below would be on the page:
html:button property=button1 value=Click to do Ajax!
onClick=updateObject(this,http://xxx.yyy.zzz?a=bc=d;)/
And that works well if all your looking to do is submit a query string
to a URL. If you want to do something more complex (like create an XML
document from a collection of form elements), that too is more involved.
These are the types of functions I envision the tags providing for you
as standard actions. If you need to do something non-standard, no
problem either.
and it could be reused for any innerHTML replacements by changing the
url in the function call. I don't think button has an innerHTML
property but just to use the example given, you get the idea
Probably having a javascript library with updateValue() and other useful
often changed properties would do the trick.
That is a good idea! I'll think I'll steal that for some of my standard
actions :)
If anyone ever takes this on I'd appreciate it if you could keep me in
the loop on development of it. I would help as well as needed. Maybe
the dojo team has something like this already in mind?
One note: you would in fact be able to do what you are doing here with
my tags as well, the only difference is that you wouldn't have to write
that code, either the function or the event handler. You could instead
specify it in an XML config file.
The quick sample I put together doesn't use dojo so I haven't tested the
specific code but I have tested the idea with a test script and it does
work.
Hope the above makes sense. Does anyone see negatives to using the
above? It seems to take care of the code duplication concerns. The url
concern can be handled by making it a variable passed from the server
side I would guess from a form or other similar mechanism would do the
trick there.
I don't have any concerns with it per se, but I do think there is more
that can be done, and I still think the tags are the best way to present it.
Hey, if you'd like to be involved with my efforts, I could certainly use
the help in creating the transmission and reception handlers (a new
concept in my approach, I can bring you up to speed privately if you are
interested). This way you could even do one version that uses Dojo if
you want!
Frank
I was interested in the conversation, hope this adds some value.
Regards...djsuarez
-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 19, 2005 10:49 PM
To: Struts Users Mailing List
Subject: Re: AJAX: Whoa, Nellie!
Martin Cooper wrote:
My Huh? comment was in reference you your statement that the
approach I
was describing doesn't really help people with existing apps, which
I take
issue with. If you put the JavaScript methods in separate file, it has
the
exact same impact on the JSP pages as your approach does, but without
needing the custom attributes. You say 'ajaxRef=button1' and I say
'onclick=doButton1()'.
Ok, I may have misunderstood that.
Moving on though...
If you put the JavaScript methods in separate file, it has the
exact same impact on the JSP pages as your approach does
I do not belive this is true, and here's why... as far as the event
handlers go, I agree, the impact is virtually identical... But in terms
of what the event handler calls there is I think a big difference.
Going back to your original example, you state:
Elsewhere in the JSP page, or maybe somewhere else:
function doButton1() {
dojo.io.bind({
url:
http://www.omnytex.com?buttonValue=button1textValue=text1;,
load: function(type, data) {
document.getElementById(resultLayer
Re: [_Severely_ OT; linguistics, end of thread (for me)] Re: AJAX: Whoa, Nellie!
The fact that words have multiple meanings/uses does not mean the meanings are private. If the meanings are private, they have absolutely no use whatsoever. That is a DOH! SNIP On 4/20/05, Dave Newton [EMAIL PROTECTED] wrote: That's swell, from an academic point of view, but the fact is that people mean different things with the same words. /SNIP Really? LOL SNIP Dave Doesn't like going back and forth about nothing as much as you do Newton /SNIP I can tell. ///;-) -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti wrote:I do think there is more that can be done, and I still think the tags are the best way to present it. Maybe tags that leverage dojo.js? Hey, if you'd like to be involved with my efforts, I could certainly use the help in ... Do you sf.net or wiki type resources? .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Vic Cekvenich (netsql) wrote: Frank W. Zammetti wrote:I do think there is more that can be done, and I still think the tags are the best way to present it. Maybe tags that leverage dojo.js? Today I did some refactoring of the whole thing, and the important point of it all is that a developer will be able to quite easily use Dojo if they wish. Basically, there will be a bunch of standard actions that can be performed, the idea being that they may be sufficient 80% of the time and so NO code has to be written by the developer, but you will have the ability to write your own (and also register them with the tags for easy reuse, more on that later!) if you want. I don't want to say Dojo is the answer period, or that something else is the only answer, including whatever I might dream up, but I want to make sure I allow for flexibility to choose, which I think this does. Hey, if you'd like to be involved with my efforts, I could certainly use the help in ... Do you sf.net or wiki type resources? I'll be doing sf.net... Once I have a complete codebase (not final, just more complete than what I posted previously) I'll see about getting it set up as a project on struts.sf.net. I think that's the right place for it. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
Re: AJAX: Whoa, Nellie!
On 4/20/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: I'll be doing sf.net... Once I have a complete codebase (not final, just more complete than what I posted previously) I'll see about getting it set up as a project on struts.sf.net. I think that's the right place for it. In the mean time, would you guys please have your development discussions someplace other than the Struts user list? Indeed, struts.sf.net has a mailing list (struts-apps) that is precisely for this purpose. The 3000 or so people that are here want to be able to ask questions about using Struts, not get subjected to 80-message threads about someone's ideas for what the future might look like. That is what developer lists (here or at SF) are for. .V Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
Re: AJAX: Whoa, Nellie!
I apologize... I was not paying attention and didn't realize this was on the users list. There has simultaneously been a thread about this on the user list and the dev list (we were told it was appropriate for the dev list by the way), and I didn't notice. My bad. Frank Craig McClanahan wrote: On 4/20/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: I'll be doing sf.net... Once I have a complete codebase (not final, just more complete than what I posted previously) I'll see about getting it set up as a project on struts.sf.net. I think that's the right place for it. In the mean time, would you guys please have your development discussions someplace other than the Struts user list? Indeed, struts.sf.net has a mailing list (struts-apps) that is precisely for this purpose. The 3000 or so people that are here want to be able to ask questions about using Struts, not get subjected to 80-message threads about someone's ideas for what the future might look like. That is what developer lists (here or at SF) are for. .V Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] -- 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]
Re: AJAX: Whoa, Nellie!
I noticed that the last few days there were four and five posts to this list, so the damage should be minimal. I am not going to state the obvious I noticed the following Shale thread here as well. http://marc.theaimsgroup.com/?l=struts-userm=111272767800458w=2 Let's keep a clean ship, shipmates. ///;-) On 4/20/05, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/20/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: I'll be doing sf.net... Once I have a complete codebase (not final, just more complete than what I posted previously) I'll see about getting it set up as a project on struts.sf.net. I think that's the right place for it. In the mean time, would you guys please have your development discussions someplace other than the Struts user list? Indeed, struts.sf.net has a mailing list (struts-apps) that is precisely for this purpose. The 3000 or so people that are here want to be able to ask questions about using Struts, not get subjected to 80-message threads about someone's ideas for what the future might look like. That is what developer lists (here or at SF) are for. .V Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Hey - please write to the Mailing List and no CC please. Thx Axel Frank W. Zammetti wrote: I apologize... I was not paying attention and didn't realize this was on the users list. There has simultaneously been a thread about this on the user list and the dev list (we were told it was appropriate for the dev list by the way), and I didn't notice. My bad. Frank Craig McClanahan wrote: On 4/20/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: I'll be doing sf.net... Once I have a complete codebase (not final, just more complete than what I posted previously) I'll see about getting it set up as a project on struts.sf.net. I think that's the right place for it. In the mean time, would you guys please have your development discussions someplace other than the Struts user list? Indeed, struts.sf.net has a mailing list (struts-apps) that is precisely for this purpose. The 3000 or so people that are here want to be able to ask questions about using Struts, not get subjected to 80-message threads about someone's ideas for what the future might look like. That is what developer lists (here or at SF) are for. .V Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] -- profiIT e.K. , die Dienstleistungsplattform für IT - Profis Axel Sachmann Amtsgericht Köln, HR A 21756 Melanchthonstraße 29a 51061 Köln Telefon: +49 221 97716 - 11 Telefax: +49 221 97716 - 12 Internet: http://www.profiIT.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On 4/18/05, Martin Cooper [EMAIL PROTECTED] wrote: To get beyond doing the grunt work yourself for Ajax, I recommend taking a look at this: http://dojotoolkit.org/intro_to_dojo_io.html and downloading the dojo.io package from their site. Personally, I'm not convinced that we need anything new in Struts to make using Ajax easier. I'm building products today that make extensive use of the two technologies together, and haven't found a need to enhance Struts to do it. However, if we do add any Ajax (or Ajax-like) support to Struts, I want to be able to plug in my plumbing of choice (which would be Dojo right now) to get the most robust communication scheme available. -- Martin Cooper This is exactly the area I've been having trouble with this proposal as well ... tell me again why you can't use Ajax techniques with the standard Struts HTML tags? If you can do it with handwritten HTML pages (which you certainly can), you can also do it with existing Struts HTML tags (or the standard JSF components, for that matter) that offer attributes like onchange and onclick to plug in your calls to JavaScript methods that do the actual background calls, and then update the client side DOM of your page. It seems to me that a framework can provide value add in primarily the following areas: * Provide a client side JavaScript library that does the grunt work of making the back-end XmlHttpRequest call, and updating the corresponding portion of your DOM. Martin likes DOJO for this; there are also a bunch of other libraries that do the same sort of thing that should be leveraged, instead of inventing something new. * Provide a server side framework that makes it easy to map a particular XHR invocation to the corresponding business logic, and (for extra credit) maps the response data to a generic data format so you don't have to write specific formatting logic for every single response type. I sort of like what JSON provides as a transport protocol, but there's room for value add here on the server side, with a generic data abstraction that maps into the appropriate transport formats. * Provide encapsulated functionality (JSP custom tags, JSF component tags, whatever) that totally hides the fact that Ajax techniques are used into the HTML and JavaScript markup that is automatically generated. If you make the page developer have to do a *lot* more (i.e. a bunch of nested tags) on every Ajax-sensitive component, that doesn't seem to make application development easier ... it only makes it more tedious. Use case to consider -- as an application developer, I want to use a progress bar widget that periodically polls the server for the progress of a long running function, and then updates the client side visual representation. If I have to do more than add a single attribute (some way to map to the server side function that returns the completion percentage to be displayed), plus an optional parameter that says how often to check, over what it takes to specify a static image with an html:img tag (for example), then I'm likely to say thanks but no thanks to your version of that widget. If, on the other hand, you let me say: html:progressBar progressURL=/filecopy.do/ or html:progressBar progressURL=/filecopy.do interval=3/ then I'm fat, dumb, and happy. Why should *i* (the application developer) care that you're using XmlHttpRequest behind the scenes? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
-Original Message- Users that turn off JS are akin, in my mind, to automobile drivers who decide they would rather play Fred Flintstone, cut holes in the floorboards and not bother starting the engine. Oh, you'll get around, but your missing out! While I am certainly not trying to say there aren't very legitimate concerns with using JS, like most things they are overcome with knowledge and ability. I mean, no one complains because Windows ships with fdisk and format, they are at least as dangerous potentially! -Original Message- Well,... If we look behind the problems that could arise with JavaScript... I am really convinced that JS in a webapp is a really BAD idea. Think about Cross-Scripting. It is not that your web-applicaiton is the culprit, but someoneelse's bad-behaving Javascript that does the damage. I am just waiting to here about the first case where a developer has to take the responsibilities for real damage to a use, because he required JS for a web-app and in this way forcing the user to switch on JS-support in his browser, rendering him susceptible to damage by another websites ill-behaving JS-code... I also think that a well-designed web-UI does not need JS at all... regards Alexander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti wrote: On Mon, April 18, 2005 11:12 am, Emmanouil Batsis said: I haven't really studied the samples yet, but it would seem more semantically correct to me if the html:form was used to make this work. I'll try to come up with more concrete suggestions. I thought of that too, but what changed my mind is the question of how do you handle it if you want to have a number of different elements doing different things. For instance, if you have three select elements and you want one to populate a textarea with text retrieved from the server when changed, another to pop up an alert with a message from the server when changed, and the other to go to the URL selected with a query string appended on that is generated by the server when changed... If the functionality was tied to the form, how would you allow for that? Good point, but my perspective is focused on basic 80/20 functionality and fallback behavior, plus proper semantics (the last one just as a practice that usually pays back). To clarify, i support implementing this in (or on top of!) the existing html taglib and start specifically from the html:form simply because it's the only way to include proper fallback behaviour for UAs unable to handle the client side of things by making a normal form submission. For this to work however, the action has to know whether it has to send back the complete document or the document fragment. I'm looking for a way to meaningfully make all this easier. Also, i don't think the client side of things can be left as a developer's choice for the same reason the validator scripting is not a developer's choice; there is no way to manage the complexity of that in a usefull way. That's why i'm offering the sarissa code to be put under the Apache license; about 18 versions have been published since early 2003 (long before the ajax hype), it has an active and healthy user/developer base, is well documented and is used by other open source projects like OSCOM's Kupu editor. Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Jesse Alexander (KBSA 21) a écrit : Well,... If we look behind the problems that could arise with JavaScript... I am really convinced that JS in a webapp is a really BAD idea. Think about Cross-Scripting. It is not that your web-applicaiton is the culprit, but someoneelse's bad-behaving Javascript that does the damage. I am just waiting to here about the first case where a developer has to take the responsibilities for real damage to a use, because he required JS for a web-app and in this way forcing the user to switch on JS-support in his browser, rendering him susceptible to damage by another websites ill-behaving JS-code... I also think that a well-designed web-UI does not need JS at all... Mmmh. Well, Firefox lets users choose which site have the right to popup() or not. Let's do the same for JavaScript, and the problem disappears (of course, the other browsers should do the same). -- Stéphane Zuckerman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Based on my experience porting the Struts tags to AJAX/SWF
(swf.dev.java.net), I would agree with Craig that the existing Struts
tags would be sufficient; however, tweaking the event handler attrs,
as in SWF, does provide some simplification. For example (in SWF), w/
o the tweak we would need ...onchanged=updateEvent('#userSelected',
'')... whereas with the tweak we
have ...onchanged=swf:userSelected...
Not necessary, but nice.
On another note, there are ways to use AJAX that degrade gracefully
to regular form submits and reloads when the AJAX preconditions are
not met or ill advised. The dominate AJAX view point at the moment is
service oriented: 1) something (even an interval or timeout hook)
happens in the browser, 2) a service call is made to the server, and
3) the DOM is possibly modified. There is another way to view AJAX
that I believe fits better with existing frameworks like Struts,
WebWork, and Spring. Coming from a windowing system view point, AJAX
can look like the means of refreshing dirty regions in the page: 1)
something happens, 2) the form is submitted, and 3) any modified
regions are rendered and sent back to the browser. You can do all the
same things as AJAX-the-service-mechanism plus 1) to the server side
it looks just like the same ole form submits, 2) as a result of (1)
the page can degrade gracefully to submit/reload, and 3) the
application engineer rarely needs to get into JavaScript.
As evidence for my point, the SWF works this way very effectively
and is built upon the single primitive of an updateable region. I
have ported this primitive to Struts using a very small (8k) tag lib
with two trivial tags and no modifications to Struts itself (https://
swf.dev.java.net/docs/Struts.html.) Given this primitive, everything
else is possible once one has switched from viewing AJAX as a service
mechanism to a means of updating regions in a page. IMO, this
direction would be an interesting way to resolve the AJAX/Struts
debate in this thread.
Cheers!
On Apr 19, 2005, at 12:47 AM, Craig McClanahan wrote:
On 4/18/05, Martin Cooper [EMAIL PROTECTED] wrote:
To get beyond doing the grunt work yourself for Ajax, I recommend
taking a
look at this:
http://dojotoolkit.org/intro_to_dojo_io.html
and downloading the dojo.io package from their site.
Personally, I'm not convinced that we need anything new in Struts
to make
using Ajax easier. I'm building products today that make extensive
use of
the two technologies together, and haven't found a need to enhance
Struts to
do it. However, if we do add any Ajax (or Ajax-like) support to
Struts, I
want to be able to plug in my plumbing of choice (which would be
Dojo right
now) to get the most robust communication scheme available.
--
Martin Cooper
This is exactly the area I've been having trouble with this proposal
as well ... tell me again why you can't use Ajax techniques with the
standard Struts HTML tags? If you can do it with handwritten HTML
pages (which you certainly can), you can also do it with existing
Struts HTML tags (or the standard JSF components, for that matter)
that offer attributes like onchange and onclick to plug in your
calls to JavaScript methods that do the actual background calls, and
then update the client side DOM of your page.
It seems to me that a framework can provide value add in primarily the
following areas:
* Provide a client side JavaScript library that does the grunt work
of making the back-end XmlHttpRequest call, and updating the
corresponding portion of your DOM. Martin likes DOJO for this;
there are also a bunch of other libraries that do the same sort
of thing that should be leveraged, instead of inventing something
new.
* Provide a server side framework that makes it easy to map
a particular XHR invocation to the corresponding business logic,
and (for extra credit) maps the response data to a generic data
format so you don't have to write specific formatting logic for
every single response type. I sort of like what JSON provides as a
transport protocol, but there's room for value add here on the
server side, with a generic data abstraction that maps into
the appropriate transport formats.
* Provide encapsulated functionality (JSP custom tags, JSF component
tags, whatever) that totally hides the fact that Ajax techniques
are used
into the HTML and JavaScript markup that is automatically generated.
If you make the page developer have to do a *lot* more (i.e. a
bunch of
nested tags) on every Ajax-sensitive component, that doesn't seem to
make application development easier ... it only makes it more
tedious.
Use case to consider -- as an application developer, I want to use a
progress bar widget that periodically polls the server for the
progress of a long running function, and then updates the client side
visual representation. If I have to do more than add a single
attribute (some way to map to the
Re: AJAX: Whoa, Nellie!
On Tue, April 19, 2005 2:47 am, Craig McClanahan said: This is exactly the area I've been having trouble with this proposal as well ... tell me again why you can't use Ajax techniques with the standard Struts HTML tags? No one, at least not me, has made that statement at any point. I frankly do not use the Struts tags most of the time, yet I do AJAX just fine. There is no debate on this point: there is no NEED for the Struts HTML tags to do AJAX. If you can do it with handwritten HTML pages (which you certainly can), you can also do it with existing Struts HTML tags (or the standard JSF components, for that matter) that offer attributes like onchange and onclick to plug in your calls to JavaScript methods that do the actual background calls, and then update the client side DOM of your page. Agreed. But then you have to do everything yourself. If 80% of the time people are doing the same kinds of things like replacing the content of a specific DOM elements' innerHTML, why not provide a standard approach to that? Further, we are constantly talking about the dichotomy of having a separate group of page developers and back-end developers. Why should a page developer need to know Javascript? Isn't that like saying they need to know Java on the server? You could of course make the argument that scripting is appropriately a part of a page developers' reportoire, and I don't think I would argue, but they already avoid a great deal of scripting by using various taglibs, so why shouldn't they want to avoid scripting to implement at least basic AJAX techniques? That is what is at the heart of what I did. It seems to me that a framework can provide value add in primarily the following areas: See, when we start talking about a framework we are starting to talk about something more grandiose than what I put together. That is in no way to say it isn't a good idea, just that it is different. * Provide a client side JavaScript library that does the grunt work of making the back-end XmlHttpRequest call, and updating the corresponding portion of your DOM. Martin likes DOJO for this; there are also a bunch of other libraries that do the same sort of thing that should be leveraged, instead of inventing something new. Not everyone likes throwing the kitchen sink into their projects to provide a relatively small amount of functionality. It is amazing to me that anyone would make the argument against something that is too simple! Why do we always have to develop the next big thing rather than something that will help 80% of the people 80% of the time? Why is the later a seemingly Bad Thing? * Provide a server side framework that makes it easy to map a particular XHR invocation to the corresponding business logic, and (for extra credit) maps the response data to a generic data format so you don't have to write specific formatting logic for every single response type. I sort of like what JSON provides as a transport protocol, but there's room for value add here on the server side, with a generic data abstraction that maps into the appropriate transport formats. I do actually like this idea, but again, the difference between this and what I put together is night and day... this is leading down a much more complex and expansive path. It's a path I would be excited to walk down, but it puts delivered results further away as opposed to what I did that could be completed in relatively short order and help people NOW. Also, what you are talking about, and what Martin has been talking about, while a good idea to be sure, doesn't really help people with existing apps. It is akin to my Struts Web Services project... I have never at any time promoted that as the be-all and end-all of Web Services. What I have said is that if you have an existing Strtus-based application and need to expose parts of it as Web Services, here's one quick and easy way to do it. Likewise, what I proposed is a quick and easy way to introduce AJAX functionality into an existing app with a minimum of fuss and muss. There is not a lot of code to write (none if I do it right) and it's not an all-or-nothing proposition, you don't have to use a whole new framework on the client and the server to make it work. The what you and Martin are talking about, I can't see how that would be the case. So, while the ideas may have a great deal of merit, they require a far greater change for developers and don't, I think, help anyone NOW. * Provide encapsulated functionality (JSP custom tags, JSF component tags, whatever) that totally hides the fact that Ajax techniques are used into the HTML and JavaScript markup that is automatically generated. If you make the page developer have to do a *lot* more (i.e. a bunch of nested tags) on every Ajax-sensitive component, that doesn't seem to make application development easier ... it only makes it more tedious. Granted. My proposal very much
Re: AJAX: Whoa, Nellie!
On Tue, April 19, 2005 12:53 am, Martin Cooper said: To get beyond doing the grunt work yourself for Ajax, I recommend taking a look at this: http://dojotoolkit.org/intro_to_dojo_io.html and downloading the dojo.io package from their site. It does look cool. However, in some ways what I provided is actually better... I have the concept of default return handlers (and default submission handlers) that would save the developer, in some percentage of situations at least, from writing ANY server-side code whatsoever. True enough, one could implement that concept with Dojo too, but then I'm just helping develop Dojo! Personally, I'm not convinced that we need anything new in Struts to make using Ajax easier. Easier for who? For you? You are a super-genius Martin :) It's a cakewalk for you. For me too frankly. *I* certainly don't need new tags because I don't even use the tags as they are now 95% of the time! Let's look at it this way... I don't consider the validation framework to be any great shakes. I mean, the client-side portion of it anyway. I don't need tags that can write validation logic for me. I suspect you don't need it either. Was it a bad idea then? Most certainly not! Same thing here... if we can provide to 80% of the people a capability that requires so very little extra work for them (a single config file and a single attribute on any tag involved) that will handle 80% of their needs, why in the world wouldn't we jump at the chance? I'm building products today that make extensive use of the two technologies together, and haven't found a need to enhance Struts to do it. You and I both :) However, if we do add any Ajax (or Ajax-like) support to Struts, I want to be able to plug in my plumbing of choice (which would be Dojo right now) to get the most robust communication scheme available. And that is a reasonable point I feel. But, then you get into a situation where you have to build something more complex in all probability to provide that degree of flexibility... I have to make sure it is generic enough to handle any plumbing you want to put in, and then what happens when some new plumbing comes down the pipe that doesn't quite fit? I would rather take the tact here is an available method to do this AJAX stuff, here are the limitations, and when you bump up against them you will have to use something else. I just don't see that as a bad thing because it helps some people now, as opposed to helping no one, or more precisely, leaving them out to entirely help themselves. P.S. - Take a look at my proposal again... If you really wanted to use Dojo, I believe you could with just one minor change: I would have to allow for calling custom functions when submitting to the server. This was on the slate anyway, and that means you could use your dojo.io.bind() stuff here). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
On Tue, April 19, 2005 5:30 am, Jesse Alexander (KBSA 21) said: I also think that a well-designed web-UI does not need JS at all... Then what results is exactly what you say: a WEB UI. This was good enough five years ago, it isn't today. People expect, generally, more robust UIs delivered in a browser. They expect webapps that look, feel and work more like fat clients. This is all a virtual impossibility without some dergee of scripting. There are of course cases where this doesn't natter... sometimes the simplistic Google front page approach is perfect. But you'll pretty quickly run up against some serious roadblocks to developing anything other than classic web UIs without scripting. Your point is well-taken... scripting does indeed entail some level of danger... but so does driving a car, and we all do that without much thought :) (which is of course part of the problem with driving today, but I digress...) -- 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]
RE: AJAX: Whoa, Nellie!
-Original Message- I also think that a well-designed web-UI does not need JS at all... Then what results is exactly what you say: a WEB UI. This was good enough five years ago, it isn't today. People expect, generally, more robust UIs delivered in a browser. They expect webapps that look, feel and work more like fat clients. This is all a virtual impossibility without some dergee of scripting. There are of course cases where this doesn't natter... sometimes the simplistic Google front page approach is perfect. But you'll pretty quickly run up against some serious roadblocks to developing anything other than classic web UIs without scripting. Your point is well-taken... scripting does indeed entail some level of danger... but so does driving a car, and we all do that without much thought :) (which is of course part of the problem with driving today, but I digress...) -Original Message- Maybe I'm to old (in respect to IT-technology), but for me most of those highly sophisticated apps (be them client or web) are not very usable... I prefer a simple processing scheme. And from there comes my preference for pure HTML-UI's without any javascript If it MUST be more, then something like Canoo's ULC http://www.canoo.com/ulc/index.html is a possible way to go... but that's (according to my assessment of normal business apps) about 0.001% of all web-applications... Most user-requirements for RIA might be fulfilled by intensively refactoring the UI's... for more simplicity regards Alexander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
On Tue, April 19, 2005 10:37 am, Jesse Alexander (KBSA 21) said: Maybe I'm to old (in respect to IT-technology), but for me most of those highly sophisticated apps (be them client or web) are not very usable... I prefer a simple processing scheme. No doubt there were (are still are) some very highly unusable non-web applications out there. And from there comes my preference for pure HTML-UI's without any javascript Many people share this preference. There are some good reasons for it, but also some good arguments against not. Perfectly valid viewpoint though. If it MUST be more, then something like Canoo's ULC http://www.canoo.com/ulc/index.html is a possible way to go... but that's (according to my assessment of normal business apps) about 0.001% of all web-applications... I would say this is very highly environment-specific. Going by my own experience, I would say that only about 10% of the webapps I deal with in my enterprise are as simple as you are talking about. Even then I'm not sure *any* of them are completely script-free. This would echo what my experience in other environment is as well. The requirements themselves are dictating this by the way, not just some developer wanting to do something cool. Part of that comes from business analysts that know fat-clients reasonably well and expect similar experiences on the web. We might argue they have the wrong mindset, but it is what it is. I happen to agree with them, but there is room for disagrement there. Most user-requirements for RIA might be fulfilled by intensively refactoring the UI's... for more simplicity Depending on the target audience this can be good advice. If you are trying to reach the largest audience then indeed you should be thinking simplicity... Anyone ever trying accessing a more modern site with a browser on a cell phone? Ugh! Assuming it works at all, which is doubtful, it is painful in the extreme to try and use it. If this is a possibility then I think what your saying is good advice Alexander. regards Alexander - 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]
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti wrote: On Tue, April 19, 2005 5:30 am, Jesse Alexander (KBSA 21) said: I also think that a well-designed web-UI does not need JS at all... Then what results is exactly what you say: a WEB UI. This was good enough five years ago, it isn't today. People expect, generally, more robust UIs delivered in a browser. They expect webapps that look, feel and work more like fat clients. This is all a virtual impossibility without some dergee of scripting. I, with respect for the author, disagree with this entirely. I am people, and this is not what I expect or desire at all. As a user, I expect and desire 1) A fast download 2) my bookmarks to work/easy to remember URLs 3) an organized and well-thought-out left rail 4) a go home link at the top 5) a two-field registration 6) an encrypted log on 7) content I can read in a text-only browser. None of these require any browser scripting at all. And most importantly, I want information that I regard as being of great quality. Anything beyond the seven I mentioned only gets in my way. Erik -- who prefers mail2web to GMail. There are of course cases where this doesn't natter... sometimes the simplistic Google front page approach is perfect. But you'll pretty quickly run up against some serious roadblocks to developing anything other than classic web UIs without scripting. Your point is well-taken... scripting does indeed entail some level of danger... but so does driving a car, and we all do that without much thought :) (which is of course part of the problem with driving today, but I digress...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On Tue, April 19, 2005 10:46 am, Michael J. said:
Struts-only or JSP-only solution is not good enough. The more portable
is the better, so when I read Frank's proposal I thought, why those
input controls are generated with custom tags? What if controls were
created with Javascript? Custom tags would be generating setup
parameters for these Javascript instead of generating input controls
directly. The result is greater portability for the control library:
basically, it would be a pure Javascript library.
You may not believe this, but I started down this path something like five
years ago... In fact, I still have the first POC I threw together.
It treated a web UI much like SWING in the sense that you wouldn't
actually write markup, you would write code instead. Now, this is a **BAD
IDEA** imho, and I recognize that now, but it is interesting and somewhat
relevant none the less. Here's an example:
html
head
link rel=StyleSheet href=VisML_Styles.css type=text/css
script language=javascript src=VisML_Base.js/script
script language=javascript src=VisML_Spinner.js/script
script language=javascript src=VisML_Swapper.js/script
script language=javascript src=VisML_Button.js/script
script
var myGUI = new VisML(myGUI);
function createGUI() {
myGUI.createComponent(myGUI.componentButton, Button1, lyrComponent);
myGUI.Button1.registerCallback(myGUI.eventOnClick, Button1_onClick);
myGUI.Button1.setLabel(This is a button - CLICK ME);
myGUI.createComponent(myGUI.componentSpinner, Spinner1,
lyrComponent);
myGUI.Spinner1.setMinimum(5);
myGUI.Spinner1.setMaximum(15);
myGUI.Spinner1.setValue(10);
myGUI.createComponent(myGUI.componentSwapper, Swapper1,
lyrComponent);
myGUI.Swapper1.setWidth(80);
myGUI.Swapper1.addItem(myGUI.Swapper1.swapperSource, Item #1, I1);
myGUI.Swapper1.addItem(myGUI.Swapper1.swapperSource, Item #2, I2);
myGUI.Swapper1.addItem(myGUI.Swapper1.swapperSource, Item #3, I3);
myGUI.Swapper1.addItem(myGUI.Swapper1.swapperSource, Item #4, I4);
}
function Button1_onClick() {
alert(You clicked the button!);
}
/script
/head
body onLoad=createGUI();
td height=160 align=centerdiv id=lyrComponentnbsp;/div/td
/body
/html
I was starting to create custom widgets as well, aside from the usual...
the spinner is just like a spinner in windows with the up and down arrows,
and the swapper is two textboxes side to side where you can move items
from one side to another and reorder them. All of them could be rendered
in a completely custom way, i.e., they didn't have to use the base HTML
button at all (although they did the first time around).
Your idea is interesting because if we created a taglib to basically
create the code you see above, that could be something interesting. Just
provide for the ability for the event callbacks to be server-side and it
begins to look kinda cool. I also was beginning to create layout
managers, which would be another logical addition.
Frank
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On Tue, April 19, 2005 10:47 am, Erik Weber said: I, with respect for the author, disagree with this entirely. I am people, and this is not what I expect or desire at all. As a user, I expect and desire 1) A fast download 2) my bookmarks to work/easy to remember URLs 3) an organized and well-thought-out left rail 4) a go home link at the top 5) a two-field registration 6) an encrypted log on 7) content I can read in a text-only browser. None of these require any browser scripting at all. You describe a good web SITE, and I couldn't agree with your criteria more! However, what you don't describe well is a web APPLICATION. Web APPLICATIONS are where the scripting is, generally, needed, and where the UI tends to be more complex. And most importantly, I want information that I regard as being of great quality. Anything beyond the seven I mentioned only gets in my way. No doubt, information is what makes it all worth it, absolutely. I might have a nice Mac OS UI, but if all it can show me is Wiggles videos and 3rd-grade math and naked pictures of Rue Paul, the information stinks and the whole thing isn't worth anything to me. Erik -- who prefers mail2web to GMail. Frank -- who would prefer to never have the words naked pictures of Rue Paul enter his brain again under ANY circumstances! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
Hear-hear. My users would brain me if I just provided that amount of interface on a web application. -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: 19 April 2005 16:17 To: Struts Users Mailing List Cc: Struts Users Mailing List Subject: Re: AJAX: Whoa, Nellie! On Tue, April 19, 2005 10:47 am, Erik Weber said: I, with respect for the author, disagree with this entirely. I am people, and this is not what I expect or desire at all. As a user, I expect and desire 1) A fast download 2) my bookmarks to work/easy to remember URLs 3) an organized and well-thought-out left rail 4) a go home link at the top 5) a two-field registration 6) an encrypted log on 7) content I can read in a text-only browser. None of these require any browser scripting at all. You describe a good web SITE, and I couldn't agree with your criteria more! However, what you don't describe well is a web APPLICATION. Web APPLICATIONS are where the scripting is, generally, needed, and where the UI tends to be more complex. And most importantly, I want information that I regard as being of great quality. Anything beyond the seven I mentioned only gets in my way. No doubt, information is what makes it all worth it, absolutely. I might have a nice Mac OS UI, but if all it can show me is Wiggles videos and 3rd-grade math and naked pictures of Rue Paul, the information stinks and the whole thing isn't worth anything to me. Erik -- who prefers mail2web to GMail. Frank -- who would prefer to never have the words naked pictures of Rue Paul enter his brain again under ANY circumstances! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. 3167 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
I wholeheartedly agree that often times, simplicity is the best way to go for web (and webapp) UIs. However, end-user simplicity does not always imply developer simplicity (i.e. bare-bones HTML). Case in point: Google Maps vs. Mapquest, specifically in the Scroll Map use case. Which one is simpler and more intuitive for the user? For me, grabbing and dragging the map with my cursor (in any direction I desire) is more intuitive than clicking on arrow buttons to scroll the map (in N/S and E/W directions only). Sometimes it takes more developer effort/technology to create something that's easier to use. Sometimes it doesn't. But to say that client-side scripting is completely unnecessary for well designed application UIs is incorrect, IMO. It depends on what your users need to do. - Scott -Original Message- From: Erik Weber [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 10:48 AM To: Struts Users Mailing List Subject: Re: AJAX: Whoa, Nellie! Frank W. Zammetti wrote: On Tue, April 19, 2005 5:30 am, Jesse Alexander (KBSA 21) said: I also think that a well-designed web-UI does not need JS at all... Then what results is exactly what you say: a WEB UI. This was good enough five years ago, it isn't today. People expect, generally, more robust UIs delivered in a browser. They expect webapps that look, feel and work more like fat clients. This is all a virtual impossibility without some dergee of scripting. I, with respect for the author, disagree with this entirely. I am people, and this is not what I expect or desire at all. As a user, I expect and desire 1) A fast download 2) my bookmarks to work/easy to remember URLs 3) an organized and well-thought-out left rail 4) a go home link at the top 5) a two-field registration 6) an encrypted log on 7) content I can read in a text-only browser. None of these require any browser scripting at all. And most importantly, I want information that I regard as being of great quality. Anything beyond the seven I mentioned only gets in my way. Erik -- who prefers mail2web to GMail. There are of course cases where this doesn't natter... sometimes the simplistic Google front page approach is perfect. But you'll pretty quickly run up against some serious roadblocks to developing anything other than classic web UIs without scripting. Your point is well-taken... scripting does indeed entail some level of danger... but so does driving a car, and we all do that without much thought :) (which is of course part of the problem with driving today, but I digress...) - 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]
Re: AJAX: Whoa, Nellie!
Sometimes it takes more developer effort/technology to create something that's easier to use. Sometimes it doesn't. But to say that client-side scripting is completely unnecessary for well designed application UIs is incorrect, IMO. It depends on what your users need to do. People just should stop thinking in terms of client-side scripting and start thinking multi-tier programming ;) Webapp is an _application_ after all. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
We need to agree to disagree on the virtue/detriment of javascript in web pages. Different applications for different audiences with different purposes have different solutions. At my company we've implemented intranet apps where the users do a significant amount of heads-down data entry. They need validation and adding in of date and telephone mark-up and they want it to happen without waiting for a server round-trip. That needed some heavy js. Other applications have been internet apps where we needed to support the widest variety of browsers and os'es. For that environment js is anathema. Frank W. Zammetti wrote: On Tue, April 19, 2005 10:47 am, Erik Weber said: I, with respect for the author, disagree with this entirely. I am people, and this is not what I expect or desire at all. As a user, I expect and desire 1) A fast download 2) my bookmarks to work/easy to remember URLs 3) an organized and well-thought-out left rail 4) a go home link at the top 5) a two-field registration 6) an encrypted log on 7) content I can read in a text-only browser. None of these require any browser scripting at all. You describe a good web SITE, and I couldn't agree with your criteria more! However, what you don't describe well is a web APPLICATION. Web APPLICATIONS are where the scripting is, generally, needed, and where the UI tends to be more complex. And most importantly, I want information that I regard as being of great quality. Anything beyond the seven I mentioned only gets in my way. No doubt, information is what makes it all worth it, absolutely. I might have a nice Mac OS UI, but if all it can show me is Wiggles videos and 3rd-grade math and naked pictures of Rue Paul, the information stinks and the whole thing isn't worth anything to me. Erik -- who prefers mail2web to GMail. Frank -- who would prefer to never have the words naked pictures of Rue Paul enter his brain again under ANY circumstances! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
+1 Frank! Good old agility and Xtreme principles say do it and worry about all this wah wah wah wah later. You have a simple and very useful idea which is at the beginning stages but which is well-thought out and which is based on a solid engineering foundation. Go for it as you initially conceived it. Jack On 4/19/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Tue, April 19, 2005 2:47 am, Craig McClanahan said: This is exactly the area I've been having trouble with this proposal as well ... tell me again why you can't use Ajax techniques with the standard Struts HTML tags? No one, at least not me, has made that statement at any point. I frankly do not use the Struts tags most of the time, yet I do AJAX just fine. There is no debate on this point: there is no NEED for the Struts HTML tags to do AJAX. If you can do it with handwritten HTML pages (which you certainly can), you can also do it with existing Struts HTML tags (or the standard JSF components, for that matter) that offer attributes like onchange and onclick to plug in your calls to JavaScript methods that do the actual background calls, and then update the client side DOM of your page. Agreed. But then you have to do everything yourself. If 80% of the time people are doing the same kinds of things like replacing the content of a specific DOM elements' innerHTML, why not provide a standard approach to that? Further, we are constantly talking about the dichotomy of having a separate group of page developers and back-end developers. Why should a page developer need to know Javascript? Isn't that like saying they need to know Java on the server? You could of course make the argument that scripting is appropriately a part of a page developers' reportoire, and I don't think I would argue, but they already avoid a great deal of scripting by using various taglibs, so why shouldn't they want to avoid scripting to implement at least basic AJAX techniques? That is what is at the heart of what I did. It seems to me that a framework can provide value add in primarily the following areas: See, when we start talking about a framework we are starting to talk about something more grandiose than what I put together. That is in no way to say it isn't a good idea, just that it is different. * Provide a client side JavaScript library that does the grunt work of making the back-end XmlHttpRequest call, and updating the corresponding portion of your DOM. Martin likes DOJO for this; there are also a bunch of other libraries that do the same sort of thing that should be leveraged, instead of inventing something new. Not everyone likes throwing the kitchen sink into their projects to provide a relatively small amount of functionality. It is amazing to me that anyone would make the argument against something that is too simple! Why do we always have to develop the next big thing rather than something that will help 80% of the people 80% of the time? Why is the later a seemingly Bad Thing? * Provide a server side framework that makes it easy to map a particular XHR invocation to the corresponding business logic, and (for extra credit) maps the response data to a generic data format so you don't have to write specific formatting logic for every single response type. I sort of like what JSON provides as a transport protocol, but there's room for value add here on the server side, with a generic data abstraction that maps into the appropriate transport formats. I do actually like this idea, but again, the difference between this and what I put together is night and day... this is leading down a much more complex and expansive path. It's a path I would be excited to walk down, but it puts delivered results further away as opposed to what I did that could be completed in relatively short order and help people NOW. Also, what you are talking about, and what Martin has been talking about, while a good idea to be sure, doesn't really help people with existing apps. It is akin to my Struts Web Services project... I have never at any time promoted that as the be-all and end-all of Web Services. What I have said is that if you have an existing Strtus-based application and need to expose parts of it as Web Services, here's one quick and easy way to do it. Likewise, what I proposed is a quick and easy way to introduce AJAX functionality into an existing app with a minimum of fuss and muss. There is not a lot of code to write (none if I do it right) and it's not an all-or-nothing proposition, you don't have to use a whole new framework on the client and the server to make it work. The what you and Martin are talking about, I can't see how that would be the case. So, while the ideas may have a great deal of merit, they require a far greater change for developers and don't, I think, help anyone NOW. * Provide
Re: AJAX: Whoa, Nellie!
I don't think he said absolutely everyone, including specifically Erik Weber, Erik. You turn out, in the end, to be just a person: not people. ///;-) Jack On 4/19/05, Erik Weber [EMAIL PROTECTED] wrote: Frank W. Zammetti wrote: On Tue, April 19, 2005 5:30 am, Jesse Alexander (KBSA 21) said: I also think that a well-designed web-UI does not need JS at all... Then what results is exactly what you say: a WEB UI. This was good enough five years ago, it isn't today. People expect, generally, more robust UIs delivered in a browser. They expect webapps that look, feel and work more like fat clients. This is all a virtual impossibility without some dergee of scripting. I, with respect for the author, disagree with this entirely. I am people, and this is not what I expect or desire at all. As a user, I expect and desire 1) A fast download 2) my bookmarks to work/easy to remember URLs 3) an organized and well-thought-out left rail 4) a go home link at the top 5) a two-field registration 6) an encrypted log on 7) content I can read in a text-only browser. None of these require any browser scripting at all. And most importantly, I want information that I regard as being of great quality. Anything beyond the seven I mentioned only gets in my way. Erik -- who prefers mail2web to GMail. There are of course cases where this doesn't natter... sometimes the simplistic Google front page approach is perfect. But you'll pretty quickly run up against some serious roadblocks to developing anything other than classic web UIs without scripting. Your point is well-taken... scripting does indeed entail some level of danger... but so does driving a car, and we all do that without much thought :) (which is of course part of the problem with driving today, but I digress...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Michael J. wrote: People just should stop thinking in terms of client-side scripting and start thinking in terms of client-side rendering :-) (XAML, XUL, Flex, JDNC, DHTML(Ajax, JavaScript)). UI naturaly should be done on client side, asking for domain and other services from the server. The more you do client-side the richer the UI. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
HUZZAH! +1 This is about AJAX, not about JavaScript. I am with those who say that if you don't like abortion, don't have one. Also, if you don't like JavaScript, don't use it. But, in the middle of an AJAX discussion all this pro and con JavaScript discussion is ridiculous. Jack On 4/19/05, Jason King [EMAIL PROTECTED] wrote: We need to agree to disagree on the virtue/detriment of javascript in web pages. Different applications for different audiences with different purposes have different solutions. At my company we've implemented intranet apps where the users do a significant amount of heads-down data entry. They need validation and adding in of date and telephone mark-up and they want it to happen without waiting for a server round-trip. That needed some heavy js. Other applications have been internet apps where we needed to support the widest variety of browsers and os'es. For that environment js is anathema. Frank W. Zammetti wrote: On Tue, April 19, 2005 10:47 am, Erik Weber said: I, with respect for the author, disagree with this entirely. I am people, and this is not what I expect or desire at all. As a user, I expect and desire 1) A fast download 2) my bookmarks to work/easy to remember URLs 3) an organized and well-thought-out left rail 4) a go home link at the top 5) a two-field registration 6) an encrypted log on 7) content I can read in a text-only browser. None of these require any browser scripting at all. You describe a good web SITE, and I couldn't agree with your criteria more! However, what you don't describe well is a web APPLICATION. Web APPLICATIONS are where the scripting is, generally, needed, and where the UI tends to be more complex. And most importantly, I want information that I regard as being of great quality. Anything beyond the seven I mentioned only gets in my way. No doubt, information is what makes it all worth it, absolutely. I might have a nice Mac OS UI, but if all it can show me is Wiggles videos and 3rd-grade math and naked pictures of Rue Paul, the information stinks and the whole thing isn't worth anything to me. Erik -- who prefers mail2web to GMail. Frank -- who would prefer to never have the words naked pictures of Rue Paul enter his brain again under ANY circumstances! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
That's an interesting comment Vic... are you saying you favor an approach where the entire client view itself is rendered on the client? I ask because that used to be my thinking, and I'm moved away from it to some degree. By way of example: * The little proof of concept thing I mentioned ealier that treated the UI more like Swing, i.e., what came back from the server was essentially nothing but code that was executed on the client to create the UI on-the-fly. * I've previously done two apps that when you first access them you download about 200K of HTML that is stuck in some frames (a couple hidden). From that point on all you get back from the server regardless of what you do is some Javascript variables, and those variables are used to populate the HTML that is already on the client and the proper page shown. What I'm getting at is that it is more than possible that every request to the server results in very little being returned (maybe XML, maybe just comma-separated data, maybe just some Javascript), which implies the entire UI is either rendered on-the-fly on the client with each request or else it already exists and is just modified with the data returned by the server. I'm interested in knowing if that's what you are actually saying because, while I have moved away from it a bit as I've said, I still believe that approach has significant advantages, but for a long time I thought I was the only one that thought so! :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, April 19, 2005 12:57 pm, Vic Cekvenich (netsql) said: Michael J. wrote: People just should stop thinking in terms of client-side scripting and start thinking in terms of client-side rendering :-) (XAML, XUL, Flex, JDNC, DHTML(Ajax, JavaScript)). UI naturaly should be done on client side, asking for domain and other services from the server. The more you do client-side the richer the UI. .V - 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]
Re: AJAX: Whoa, Nellie!
Dakota Jack wrote: I don't think he said absolutely everyone, including specifically Erik Weber, Erik. You turn out, in the end, to be just a person: not people. ///;-) Not me, though; I'm actually people. I may be schizophrenic, but at least I have each other. on-topic obligatory='true' I like fast download times, but I hate the web: I want any page that's more complicated than Here, download this, you'll be better off to have functionality that doesn't make me wait all the time. For a server round-trip. Sometimes it's faster the Ajax way, as far as I can tell. I _hate_ the way maps work on mapquest; I _love_ the google maps--much more intuitive, much easier to maintain continuity across map sections, etc. Blows me away every time I drag that sucker. /on-topic Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On 4/19/05, Dave Newton [EMAIL PROTECTED] wrote: on-topic obligatory='true' I like fast download times, but I hate the web: I want any page that's more complicated than Here, download this, you'll be better off to have functionality that doesn't make me wait all the time. For a server round-trip. Sometimes it's faster the Ajax way, as far as I can tell. I _hate_ the way maps work on mapquest; I _love_ the google maps--much more intuitive, much easier to maintain continuity across map sections, etc. Blows me away every time I drag that sucker. /on-topic Dave offtopic Have you tried this one: http://map.search.ch/ Try to magnify ;) /offtopic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
You would, I think, love some of the apps I've put together. The problem though, as far as other developers go, is that they really are a whole different paradigm than what most are used to. Ironically, the very first web app I did for my current employer some five years ago is the best example of it... You have to sit through a 10-second delay at startup, give or take, and after that it is blazingly fast (except when database or mainframe access has to happen). Simply put, there isn't the usual HTML rendering happening on the server because the HTML essentially already exists. Any request simply results in what amounts to token replacements in existing markup. It is a bit more dependant on the capabilities of the client, i.e., you can notice a difference in the performance of the app between a 500MHz P3 and a 2GHz P4, more than you would a typical webapp. To think it could be even better now with the dawning of the AJAX age (XMLHttpRequest was brand-spanking new then, the app was already nearing completion) is an amazing thought. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, April 19, 2005 1:10 pm, Dave Newton said: Dakota Jack wrote: I don't think he said absolutely everyone, including specifically Erik Weber, Erik. You turn out, in the end, to be just a person: not people. ///;-) Not me, though; I'm actually people. I may be schizophrenic, but at least I have each other. on-topic obligatory='true' I like fast download times, but I hate the web: I want any page that's more complicated than Here, download this, you'll be better off to have functionality that doesn't make me wait all the time. For a server round-trip. Sometimes it's faster the Ajax way, as far as I can tell. I _hate_ the way maps work on mapquest; I _love_ the google maps--much more intuitive, much easier to maintain continuity across map sections, etc. Blows me away every time I drag that sucker. /on-topic Dave - 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]
Re: AJAX: Whoa, Nellie!
Michael J. wrote: offtopic Have you tried this one: http://map.search.ch/ Try to magnify ;) /offtopic Oh, that's neat. If you could drag it it'd be like a real application! Cool! Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti wrote: Simply put, there isn't the usual HTML rendering happening on the server because the HTML essentially already exists. Just a nitpick; there's never any HTML rendering on the server. Generation, perhaps, but not rendering. /bitchiness Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
This may be straying a bit from the AJAX discussion? On 4/19/05, Michael J. [EMAIL PROTECTED] wrote: On 4/19/05, Dave Newton [EMAIL PROTECTED] wrote: on-topic obligatory='true' I like fast download times, but I hate the web: I want any page that's more complicated than Here, download this, you'll be better off to have functionality that doesn't make me wait all the time. For a server round-trip. Sometimes it's faster the Ajax way, as far as I can tell. I _hate_ the way maps work on mapquest; I _love_ the google maps--much more intuitive, much easier to maintain continuity across map sections, etc. Blows me away every time I drag that sucker. /on-topic Dave offtopic Have you tried this one: http://map.search.ch/ Try to magnify ;) /offtopic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Well, to the extent that AJAX techniques can make a site seem faster, it is actually on-topic. And I don't care if this map thing is on-topic or not, it is cool as hell :) By the way, not sure who said it, but you can in fact scroll around this map, just like Google Maps, by dragging. The zoom is very nice, and cross-browser... I'm surprised the pixelation effect worked in Firefox, I thought that was still an IE-specific DirectX-based filter. Sweet! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, April 19, 2005 1:27 pm, Dakota Jack said: This may be straying a bit from the AJAX discussion? On 4/19/05, Michael J. [EMAIL PROTECTED] wrote: On 4/19/05, Dave Newton [EMAIL PROTECTED] wrote: on-topic obligatory='true' I like fast download times, but I hate the web: I want any page that's more complicated than Here, download this, you'll be better off to have functionality that doesn't make me wait all the time. For a server round-trip. Sometimes it's faster the Ajax way, as far as I can tell. I _hate_ the way maps work on mapquest; I _love_ the google maps--much more intuitive, much easier to maintain continuity across map sections, etc. Blows me away every time I drag that sucker. /on-topic Dave offtopic Have you tried this one: http://map.search.ch/ Try to magnify ;) /offtopic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - 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]
Re: AJAX: Whoa, Nellie!
That's actually a good point... We've all heard about JSF and ASP.Net, how they handle client-side events server-side, which is a concept I've never been especially enamored with. But, when you see some actual examples of this in things like what Google is doing, you start to reconsider that position a bit. This isn't about richer UIs because, let's be honest folks, GMail is no great shakes interface-wise. What is cool about it is the overall performance and efficiency of it, and as Jack says, that is all about interaction with the server, not what the user sees. Another benefit of AJAX that I haven't seen mentioned much is error handling... Instead of seeing 404s or 500s or cryptic stack dumps or whatever else the server spews out, the user only sees what the AJAX developer wants them to see. Error handling no longer results in the entire flow of a web app breaking down, it can be handled considerably more gracefully than before, especially now that try...catch is a supported JS function (it wasn't always as I recall). All this is of course in the realm of client-server interaction as Jack is talking about, but in this case it ALSO results in a better user experience. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, April 19, 2005 1:23 pm, Dakota Jack said: I have another perspective on this. Rich UIs are good, but what I like about AJAX in addition to that somewhat peripheral concern (to me) is that it cooperates with the serverside and allows the serverside to be more efficient. The relationship between the server and the client in AJAX is what is most interesting and is what makes it so useful. There is a reason why the sites using AJAX, e.g. Google, do so. It is not because they are seeking, necessarily, any sort of rich clients. They are seeking robustness and usefulness. That is where AJAX is at, I think. All this other talk is fine, but it misses the main point of what makes AJAX interesting for Struts. The rich client stuff can be a dark hole for serverside discussions. AJAX is not. Jack On 4/19/05, Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Michael J. wrote: People just should stop thinking in terms of client-side scripting and start thinking in terms of client-side rendering :-) (XAML, XUL, Flex, JDNC, DHTML(Ajax, JavaScript)). UI naturaly should be done on client side, asking for domain and other services from the server. The more you do client-side the richer the UI. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - 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]
Re: AJAX: Whoa, Nellie!
I may be nuts, many have said I am on this list, unfairly, but isn't rendering HTML capable of being understood either as rendering the HTML meaning creating the HTML or rendering the HTML meaning creating the view from the HTML? At least people like David Geary talk about serverside rendering all the time with layout applications. Jack On 4/19/05, Dave Newton [EMAIL PROTECTED] wrote: Frank W. Zammetti wrote: Simply put, there isn't the usual HTML rendering happening on the server because the HTML essentially already exists. Just a nitpick; there's never any HTML rendering on the server. Generation, perhaps, but not rendering. /bitchiness Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Dakota Jack wrote: This may be straying a bit from the AJAX discussion? ...which is straying a bit from Struts? Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
I think this AJAX discussion was about integrating AJAX and Struts. Not complaining about your asides, Dave. Just trying to maintain some focus. ///;-) On 4/19/05, Dave Newton [EMAIL PROTECTED] wrote: Dakota Jack wrote: This may be straying a bit from the AJAX discussion? ...which is straying a bit from Struts? Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Dakota Jack wrote: I may be nuts, many have said I am on this list, unfairly, but isn't rendering HTML capable of being understood either as rendering the HTML meaning creating the HTML or rendering the HTML meaning creating the view from the HTML? At least people like David Geary talk about serverside rendering all the time with layout applications. Sure, we can define it to be whatever you want, that's the beauty of language. Maybe you could say rendering a view and the view is rendered _as_ HTML, but the HTML still isn't rendered until it's drawn on a screen (or other media, yeah yeah). Or maybe rendering _to_ HTML, as one definition of render means to express in another language. Rendered sounds funny now. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Not if I complete my project! ;) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, April 19, 2005 1:37 pm, Dave Newton said: Dakota Jack wrote: This may be straying a bit from the AJAX discussion? ...which is straying a bit from Struts? Dave - 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]
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti wrote: Not if I complete my project! ;) I hope you do! See if you can put some version on struts.sf.net, this is how some committers got in. I am no JavaScript guru, but something similar to XUL and new W3 XForms, were it's even possible to just send XML-RPC style XML to the server, beyond the XMLRequest or inside it. And then have a .js library that generates HTML. I got this from MC (not CM), but it's a strech I think. http://nwidgets.org http://dojotoolkit.org The more generating of html you do in browser, the more scalability you have on server and the faster it appears to user. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On Tue, April 19, 2005 2:33 pm, Vic Cekvenich (netsql) said: Frank W. Zammetti wrote: Not if I complete my project! ;) I hope you do! See if you can put some version on struts.sf.net, this is how some committers got in. That's my plan at the moment. There frankly isn't a ton left to do to get it to an initial release, maybe 20 hours or so of solid wokr, so if I can find some time this week or next I should be able to bang it out, then the fun of testing and blowing it up begins :) I am no JavaScript guru, but something similar to XUL and new W3 XForms, were it's even possible to just send XML-RPC style XML to the server, beyond the XMLRequest or inside it. And then have a .js library that generates HTML. My only concern with those ideas is the requirement of using XML. To be honest, where I've used AJAX-type techniques in the past, I've only used XML one time. I plan on allowing for both with what I'm doing, but looking down the road, I'm not really convinced that XML being sent and received all the time is the way to go... XML has never seemed to me a good way to go for things that are essentially transactional (where transactional here really just means potentially numerous and rapid-fire, i.e., UI events). The transport time is greater, although that concern isn't as great as it used to be, and there is also the added delay of parsing and creating it. Then again, I wouldn't want to create my own protocol for something like that, so it's a tough call either way. I got this from MC (not CM), but it's a strech I think. http://nwidgets.org http://dojotoolkit.org The Dojo things looks cool, but at least upon a quick read through it, didn't strike me as much more than a wrapper (albeit a very nice one) around XMLHttpRequest, with the added capability of using other transports, whatever that means in this case. That isn't meant to belittle it in any way, it does look nice for what it is, but my initial impression is that it's just a piece of the puzzle, not a full-fledged solution. I'll check it out in more detail though, I could certainly have missed something as quick as I went through it. The more generating of html you do in browser, the more scalability you have on server and the faster it appears to user. I agree, however, the caveat is that if you do too much you'll have just the opposite effect. Case in point... The app I've been referring to today from a couple of years back had on one screen the ability to page through data and do real-time sorting. This was done by making calls to the server to get chunks of data which was returned something along these lines: htmlheadscript a = new Array(); a[0][0] = Frank; a[0][1] = Zammetti; a[1][0] = Cindy; a[1][1] = Crawford; /script/head body onLoad=window.top.fraAPI.doLoad();/body /html So, when this is returned (to a hidden frame), it fires the doLoad() function in another hidden frame (named fraAPI), which would take the data from the array and generate the HTML. It's nice because only data is ever returned from the server (plus the small amount of scripting and page infrastructure). The problem arose, initially, because we were allowing for something like 300 records max at a time. Such a request was taking like 5 seconds on a P3 550. As it turns out, the response from the server was sub-second (VERY low, better than anything we see even today in current apps doing everything on the server), the rest was the actual rendering. We simply reduced the number of records you could look at at one time, but you could see a big different if you went to a more powerful PC. This isn't ideal either, so you have to deal with the tradeoffs well to make this approach work well. Frank .V - 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]
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti wrote: The problem arose, initially, because we were allowing for something like 300 records max at a time. Such a request was taking like 5 seconds on a P3 550. As it turns out, the response from the server was sub-second (VERY low, better than anything we see even today in current apps doing everything on the server), the rest was the actual rendering. We simply reduced the number of records you could look at at one time, but you could see a big different if you went to a more powerful PC. See for rich UI, you assume people have better PC's. Do look more into dojo, it be nice to integrate some .js componet libraries w/. I am sure that some devs are doing very rich .js and know .js component libs. (similar to how validate tag emits .js and then leverage the onclient library to render an avialbe component. Like a .js tree. again, my ignorance of .js will get me in trouble) GOOD LUCK! .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Perhaps I'm missing the simplicity of your proposal. Let's take the example
from your original RFC. Here it is, for convenience:
In the JSP page:
html:button property=button1 value=Click to do Ajax!
ajaxRef=button1/
In the Ajax config file:
AjaxConfig
ajaxElement
idbutton1/id
event
typeonClick/type
submitTypequeryString/submitType
submitItemsbuttonValue=button1,textValue=text1/submitItems
submitTargethttp://www.omnytex.com/submitTarget
returnActionstdInnerHTML/returnAction
returnTargetsresultLayer/returnTargets
/event
/ajaxElement
/AjaxConfig
Now let's look at the equivalent if I use the existing Struts HTML tags and
Dojo.
In the JSP page:
html: button property=button1 value=Click to do Ajax!
onclick=doButton1()/
Elsewhere in the JSP page, or maybe somewhere else:
function doButton1() {
dojo.io.bind({
url: http://www.omnytex.com?buttonValue=button1textValue=text1;,
load: function(type, data) {
document.getElementById(resultLayer).innerHTML = data; },
mimetype: text/plain
});
}
That's all there is to it.
Perhaps for XML-heads, your proposal is easier to deal with. But you still
need to understand how the URL is constructed from the different pieces and
what things like 'stdInnerHTML' mean, not to mention the fun of having
generated JavaScript to debug your problems through, rather than a simple
function call that you wrote yourself.
Personally, I think I'll stick with the simpler (to me, anyway) Dojo
solution. :-)
By the way, while Dojo's goals extend far beyond just dojo.io.bind, one of
the great things about it is that you can just pick up the pieces that you
want. So if all you want is Ajax-like functionality, that's all you need to
include. But if you want a full-blown client side framework, widgets and
all, you can get that too. (Or at least you will when it's done. ;)
--
Martin Cooper
Frank W. Zammetti [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Tue, April 19, 2005 12:53 am, Martin Cooper said:
To get beyond doing the grunt work yourself for Ajax, I recommend taking
a
look at this:
http://dojotoolkit.org/intro_to_dojo_io.html
and downloading the dojo.io package from their site.
It does look cool. However, in some ways what I provided is actually
better... I have the concept of default return handlers (and default
submission handlers) that would save the developer, in some percentage of
situations at least, from writing ANY server-side code whatsoever. True
enough, one could implement that concept with Dojo too, but then I'm just
helping develop Dojo!
Personally, I'm not convinced that we need anything new in Struts to
make
using Ajax easier.
Easier for who? For you? You are a super-genius Martin :) It's a
cakewalk for you. For me too frankly. *I* certainly don't need new tags
because I don't even use the tags as they are now 95% of the time!
Let's look at it this way... I don't consider the validation framework to
be any great shakes. I mean, the client-side portion of it anyway. I
don't need tags that can write validation logic for me. I suspect you
don't need it either. Was it a bad idea then? Most certainly not! Same
thing here... if we can provide to 80% of the people a capability that
requires so very little extra work for them (a single config file and a
single attribute on any tag involved) that will handle 80% of their needs,
why in the world wouldn't we jump at the chance?
I'm building products today that make extensive use of
the two technologies together, and haven't found a need to enhance
Struts
to
do it.
You and I both :)
However, if we do add any Ajax (or Ajax-like) support to Struts, I
want to be able to plug in my plumbing of choice (which would be Dojo
right
now) to get the most robust communication scheme available.
And that is a reasonable point I feel. But, then you get into a situation
where you have to build something more complex in all probability to
provide that degree of flexibility... I have to make sure it is generic
enough to handle any plumbing you want to put in, and then what happens
when some new plumbing comes down the pipe that doesn't quite fit?
I would rather take the tact here is an available method to do this AJAX
stuff, here are the limitations, and when you bump up against them you
will have to use something else. I just don't see that as a bad thing
because it helps some people now, as opposed to helping no one, or more
precisely, leaving them out to entirely help themselves.
P.S. - Take a look at my proposal again... If you really wanted to use
Dojo, I believe you could with just one minor change: I would have to
allow for calling custom functions when submitting to the server. This
was on the slate anyway, and that means you could use your dojo.io.bind()
stuff here).
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Tue, April 19, 2005 2:47 am, Craig McClanahan said: This is exactly the area I've been having trouble with this proposal as well ... tell me again why you can't use Ajax techniques with the standard Struts HTML tags? No one, at least not me, has made that statement at any point. I frankly do not use the Struts tags most of the time, yet I do AJAX just fine. There is no debate on this point: there is no NEED for the Struts HTML tags to do AJAX. If you can do it with handwritten HTML pages (which you certainly can), you can also do it with existing Struts HTML tags (or the standard JSF components, for that matter) that offer attributes like onchange and onclick to plug in your calls to JavaScript methods that do the actual background calls, and then update the client side DOM of your page. Agreed. But then you have to do everything yourself. If 80% of the time people are doing the same kinds of things like replacing the content of a specific DOM elements' innerHTML, why not provide a standard approach to that? I just posted an example of how you would handle your example using Dojo. The do everything yourself can be much easier than you might think. Further, we are constantly talking about the dichotomy of having a separate group of page developers and back-end developers. Why should a page developer need to know Javascript? Isn't that like saying they need to know Java on the server? You could of course make the argument that scripting is appropriately a part of a page developers' reportoire, and I don't think I would argue, but they already avoid a great deal of scripting by using various taglibs, so why shouldn't they want to avoid scripting to implement at least basic AJAX techniques? That is what is at the heart of what I did. It seems to me that a framework can provide value add in primarily the following areas: See, when we start talking about a framework we are starting to talk about something more grandiose than what I put together. That is in no way to say it isn't a good idea, just that it is different. * Provide a client side JavaScript library that does the grunt work of making the back-end XmlHttpRequest call, and updating the corresponding portion of your DOM. Martin likes DOJO for this; there are also a bunch of other libraries that do the same sort of thing that should be leveraged, instead of inventing something new. Not everyone likes throwing the kitchen sink into their projects to provide a relatively small amount of functionality. Where's the kitchen sink in the dojo.io.bind package? It's lean and mean and robust. It does one thing, and does it very well. It is amazing to me that anyone would make the argument against something that is too simple! Why do we always have to develop the next big thing rather than something that will help 80% of the people 80% of the time? Why is the later a seemingly Bad Thing? * Provide a server side framework that makes it easy to map a particular XHR invocation to the corresponding business logic, and (for extra credit) maps the response data to a generic data format so you don't have to write specific formatting logic for every single response type. I sort of like what JSON provides as a transport protocol, but there's room for value add here on the server side, with a generic data abstraction that maps into the appropriate transport formats. I do actually like this idea, but again, the difference between this and what I put together is night and day... this is leading down a much more complex and expansive path. It's a path I would be excited to walk down, but it puts delivered results further away as opposed to what I did that could be completed in relatively short order and help people NOW. Also, what you are talking about, and what Martin has been talking about, while a good idea to be sure, doesn't really help people with existing apps. Huh? You can take any existing Struts app today, add in Dojo, and make Ajax-like invocations wherever you like. No other changes necessary. It is akin to my Struts Web Services project... I have never at any time promoted that as the be-all and end-all of Web Services. What I have said is that if you have an existing Strtus-based application and need to expose parts of it as Web Services, here's one quick and easy way to do it. Likewise, what I proposed is a quick and easy way to introduce AJAX functionality into an existing app with a minimum of fuss and muss. There is not a lot of code to write (none if I do it right) and it's not an all-or-nothing proposition, you don't have to use a whole new framework on the client and the server to make it work. The what you and Martin are talking about, I can't see how that would be the case. So, while the ideas may have a great deal of merit,
Re: AJAX: Whoa, Nellie!
Martin Cooper wrote:
Perhaps I'm missing the simplicity of your proposal. Let's take the example
from your original RFC. Here it is, for convenience:
snip
Now let's look at the equivalent if I use the existing Struts HTML tags and
Dojo.
In the JSP page:
html: button property=button1 value=Click to do Ajax!
onclick=doButton1()/
Elsewhere in the JSP page, or maybe somewhere else:
function doButton1() {
dojo.io.bind({
url: http://www.omnytex.com?buttonValue=button1textValue=text1;,
load: function(type, data) {
document.getElementById(resultLayer).innerHTML = data; },
mimetype: text/plain
});
}
That's all there is to it.
My approach is more declarative, that's where it is simpler: less
code=simpler, as a generality. Kind of ironic to me that you would be
advocating MORE code in a page... isn't that the whole point of a taglib
in the first place? Isn't that why we all agree scriplets are Evil
Incarnate?
What you demonstrate here I would also argue is worse for page authors,
who now have to be concerned with script writing as well as layout of
simple HTML tags. You can argue that a page author would know
Javascript as well, and you may be right in most cases, but the idea
that everyone seems to be pushing is that the page authors should really
be glorified graphics artists who just do markup and worry about layout,
not code. That doesn't jive, to me at least, with the example you post.
Also in your example you are explicitly constructing the query string...
my tags do that for you. I presume you could dynamically create it with
Dojo as well, but then your talking about more code. Plus, we're
talking a bunch of inline code which, to my eyes, is very ugly, in much
the same way anonymous inner classes are in Swing coding.
Come to think of it, at first glance I'm not even sure I understand what
is going on in that code! I don't recall ever having seem Javascript
done that way, which immediately makes me think twice about this... it's
going to be harder to find someone that understand such code than more
straight-forward Javascript. I'm sure if I spent two minutes on it I'd
get it no problem (looks like a bunch of nested functions, akin to
anonymous inner classes in a sense... ugh!)
Perhaps for XML-heads, your proposal is easier to deal with. But you still
need to understand how the URL is constructed from the different pieces and
what things like 'stdInnerHTML' mean, not to mention the fun of having
generated JavaScript to debug your problems through, rather than a simple
function call that you wrote yourself.
Yes, those that prefer a declarative approach will like mine better, but
isn't that the direction Struts has been moving for years?
DynaActionForms, validation, and so on? All of this requires MORE XML,
not less. Why would it be any different here?
Also, I'm not sure what you mean about ...need to understand how the
URL is constructed... in fact, all you need to be aware of is what
fields in your form you wish to be on the query string, beyond that you
have no care at all about it. I didn't get around to implementing the
simple XML generator, but the same would be true there. You are simply
naming the elements you wish to be submitted, and what key to place them
under. I would argue that anyone that knows what an HTML form is would
have no problem picking this up.
As far as generated Javascript goes, the same holds true for using
someone else' library... What if Dojo isn't working for some reason?
Whether the script is generated on-the-fly or part of some external .js
file I didn't write, either way I have code to debug that I didn't
write. What's the difference? Heck, the same holds true if something
in Struts isn't working right! What happens when the script emitted by
the validation framework doesn't work quite right? It's the same
hassle, but your OK with that I presume? :)
Fair point about the stdInnerHTML thing, but that's just a part of the
learning curve that goes along with any new technology. What the hell
does the parameter attribute of an Action mapping have to do with using
a DispatchAction? Doesn't make much sense at first glance, but you have
to do a little learning then it's crystal clear. Same thing here.
Personally, I think I'll stick with the simpler (to me, anyway) Dojo
solution. :-)
By all means! :) I never was trying to push this as the One True Ajax
Approach, and I believe I said that during the original RFC thread.
There are undoubtedly many ways to go about this, and I would be foolish
to assume I was proposing the best. I *DO* however still believe my
approach has merits that others may not.
By the way, while Dojo's goals extend far beyond just dojo.io.bind, one of
the great things about it is that you can just pick up the pieces that you
want. So if all you want is Ajax-like functionality, that's all you need to
include. But if you want a full-blown client side framework,
Re: AJAX: Whoa, Nellie!
Martin Cooper wrote: * Provide a client side JavaScript library that does the grunt work of making the back-end XmlHttpRequest call, and updating the corresponding portion of your DOM. Martin likes DOJO for this; there are also a bunch of other libraries that do the same sort of thing that should be leveraged, instead of inventing something new. Not everyone likes throwing the kitchen sink into their projects to provide a relatively small amount of functionality. Where's the kitchen sink in the dojo.io.bind package? It's lean and mean and robust. It does one thing, and does it very well. I was referring to Craig's bullet point there, not specifically Dojo. I'd have to look at it more before I would say the same about it, and maybe I'd come to the same conclusion you have in the end. Huh? You can take any existing Struts app today, add in Dojo, and make Ajax-like invocations wherever you like. No other changes necessary. But it requires adding CODE. That to me is an intrusive way to go about it. If it is possible to simple add the capability to the tags that are ALREADY ON THE PAGES, backed by a little XML, that is far less intrusive in my mind than having to add a bunch of code, and if you go the Dojo route, hand-crafted code. I disagree, at least with respect to what _I_ am talking about. ;-) See my other post. Fair enough. We have a difference of opinion here. Nothing wrong with that. If I was presenting this as the way everyone should do things, then it would be a problem, but that has never been my tact on it. I would hope you are not presenting Dojo as the way everyone should do things either Martin :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Martin Cooper wrote:
Perhaps I'm missing the simplicity of your proposal. Let's take the
example
from your original RFC. Here it is, for convenience:
snip
Now let's look at the equivalent if I use the existing Struts HTML tags
and
Dojo.
In the JSP page:
html: button property=button1 value=Click to do Ajax!
onclick=doButton1()/
Elsewhere in the JSP page, or maybe somewhere else:
function doButton1() {
dojo.io.bind({
url: http://www.omnytex.com?buttonValue=button1textValue=text1;,
load: function(type, data) {
document.getElementById(resultLayer).innerHTML = data; },
mimetype: text/plain
});
}
That's all there is to it.
My approach is more declarative, that's where it is simpler: less
code=simpler, as a generality. Kind of ironic to me that you would be
advocating MORE code in a page... isn't that the whole point of a taglib
in the first place? Isn't that why we all agree scriplets are Evil
Incarnate?
That's why I said or maybe somewhere else. It would be perfectly fine to
put the JavaScript functions in a separate .js file and linked to from the
page. And neither of us are talking scriptlets here. ;-)
What you demonstrate here I would also argue is worse for page authors,
who now have to be concerned with script writing as well as layout of
simple HTML tags. You can argue that a page author would know
Javascript as well, and you may be right in most cases, but the idea
that everyone seems to be pushing is that the page authors should really
be glorified graphics artists who just do markup and worry about layout,
not code. That doesn't jive, to me at least, with the example you post.
Again, move the JavaScript out to a separate file. That's essentially all
you've done with your Ajax config file, other than using a new XML syntax
for it. Now the only difference between your JSP page and mine is that yours
uses customised tags while mine doesn't need them. ;-)
Also in your example you are explicitly constructing the query string...
my tags do that for you. I presume you could dynamically create it with
Dojo as well, but then your talking about more code. Plus, we're
talking a bunch of inline code which, to my eyes, is very ugly, in much
the same way anonymous inner classes are in Swing coding.
Well, at least going from your example, your construction is little more
than string concatenation. I don't think you're saving much.
Come to think of it, at first glance I'm not even sure I understand what
is going on in that code! I don't recall ever having seem Javascript
done that way, which immediately makes me think twice about this... it's
going to be harder to find someone that understand such code than more
straight-forward Javascript. I'm sure if I spent two minutes on it I'd
get it no problem (looks like a bunch of nested functions, akin to
anonymous inner classes in a sense... ugh!)
Hmm, perhaps we're used to different JavaScript. That's pretty normal stuff
to me. Certainly nothing unusual.
Perhaps for XML-heads, your proposal is easier to deal with. But you
still
need to understand how the URL is constructed from the different pieces
and
what things like 'stdInnerHTML' mean, not to mention the fun of having
generated JavaScript to debug your problems through, rather than a
simple
function call that you wrote yourself.
Yes, those that prefer a declarative approach will like mine better, but
isn't that the direction Struts has been moving for years?
DynaActionForms, validation, and so on? All of this requires MORE XML,
not less. Why would it be any different here?
Going from writing ActionForm classes to dyna beans defined in XML saves you
a lot of tedious coding. In contrast, this lets you use a *more* verbose
syntax to say the same thing. I don't see the advantage. Moreover, if you
move the JavaScript code into a separate file, you actually save in clarity
and maintainability, at least IMHO.
Also, I'm not sure what you mean about ...need to understand how the
URL is constructed... in fact, all you need to be aware of is what
fields in your form you wish to be on the query string, beyond that you
have no care at all about it. I didn't get around to implementing the
simple XML generator, but the same would be true there. You are simply
naming the elements you wish to be submitted, and what key to place them
under. I would argue that anyone that knows what an HTML form is would
have no problem picking this up.
And my point is that anyone who knows what an HTML form is would wonder why
they had to use this new syntax for specifying the URL, instead of just
writing the URL in the first place.
As far as generated Javascript goes, the same holds true for using
someone else' library... What if Dojo isn't working for some reason?
Whether the script is generated on-the-fly or part of some
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Martin Cooper wrote: * Provide a client side JavaScript library that does the grunt work of making the back-end XmlHttpRequest call, and updating the corresponding portion of your DOM. Martin likes DOJO for this; there are also a bunch of other libraries that do the same sort of thing that should be leveraged, instead of inventing something new. Not everyone likes throwing the kitchen sink into their projects to provide a relatively small amount of functionality. Where's the kitchen sink in the dojo.io.bind package? It's lean and mean and robust. It does one thing, and does it very well. I was referring to Craig's bullet point there, not specifically Dojo. I'd have to look at it more before I would say the same about it, and maybe I'd come to the same conclusion you have in the end. Huh? You can take any existing Struts app today, add in Dojo, and make Ajax-like invocations wherever you like. No other changes necessary. But it requires adding CODE. That to me is an intrusive way to go about it. If it is possible to simple add the capability to the tags that are ALREADY ON THE PAGES, backed by a little XML, that is far less intrusive in my mind than having to add a bunch of code, and if you go the Dojo route, hand-crafted code. My Huh? comment was in reference you your statement that the approach I was describing doesn't really help people with existing apps, which I take issue with. If you put the JavaScript methods in separate file, it has the exact same impact on the JSP pages as your approach does, but without needing the custom attributes. You say 'ajaxRef=button1' and I say 'onclick=doButton1()'. I disagree, at least with respect to what _I_ am talking about. ;-) See my other post. Fair enough. We have a difference of opinion here. Nothing wrong with that. If I was presenting this as the way everyone should do things, then it would be a problem, but that has never been my tact on it. I would hope you are not presenting Dojo as the way everyone should do things either Martin :) Let me think about that... ;-) ;-) -- Martin Cooper Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
What you demonstrate here I would also argue is worse for page authors, who now have to be concerned with script writing as well as layout of simple HTML tags. You can argue that a page author would know Javascript as well, and you may be right in most cases, but the idea that everyone seems to be pushing is that the page authors should really be glorified graphics artists who just do markup and worry about layout, not code. That doesn't jive, to me at least, with the example you post. +1. I agree with Frank's point of view over Martin's. Usually in a larger organization, you have to work with different groups of people with different roles i.e. page authors/UI experts. Page authors/UI experts don't have to know about scripting and just focus on page layouts or usabilities. If you are in a smaller organization where one person does it all, then that is fine. Frank's proposal adds great values in the organization I am working in. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On 4/19/05, Shihgian Lee [EMAIL PROTECTED] wrote: What you demonstrate here I would also argue is worse for page authors, who now have to be concerned with script writing as well as layout of simple HTML tags. You can argue that a page author would know Javascript as well, and you may be right in most cases, but the idea that everyone seems to be pushing is that the page authors should really be glorified graphics artists who just do markup and worry about layout, not code. That doesn't jive, to me at least, with the example you post. +1. I agree with Frank's point of view over Martin's. Usually in a larger organization, you have to work with different groups of people with different roles i.e. page authors/UI experts. Page authors/UI experts don't have to know about scripting and just focus on page layouts or usabilities. If you are in a smaller organization where one person does it all, then that is fine. Frank's proposal adds great values in the organization I am working in. Glorified graphics artists do not do markup, they create nice mockups in Photoshop, which adore big bosses, who tell those unglofied ones to implement unearthy coolness in code. And those implementing this fancy stuff better know [at least about existence of] Javascript, XHTML, CSS, XML, DOM, XSLT, Flash and other buzzthings along with Photoshop. Those who do not know, create pages which look ok with single window and font size, at best. The separation between server-side programmers, Javascript coders and graphic artists is a wrong thing. Ok, the initial visual design is done by artist in Photoshop, but everyting else is programmed. Javascript is the same part of the toolbox, as Struts tags or JDBC. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Michael J. wrote: Glorified graphics artists do not do markup, they create nice mockups in Photoshop, which adore big bosses, who tell those unglofied ones to implement unearthy coolness in code. And those implementing this fancy stuff better know [at least about existence of] Javascript, XHTML, CSS, XML, DOM, XSLT, Flash and other buzzthings along with Photoshop. I don't argue that snowed-over bosses tend to tell those who do not get the glory yet do all the work to implement unearthly coolnes in code :) But, seriously, many environment have a high degree of separation, as Shihgian said. *I* don't happen to work in such an environment, we our a shop full of jacks of all trades, but even we are moving to the specialization end of the spectrum. In such a situation, there really is a very rigid set of requirements for each job. Page designers deal in CSS and HTML and that's it. They expect that any code that needs to go into a page will be inserted as a result of using the tags they are given. I personally can't imagine how that actually works, but I'm told it does in some places :) Those who do not know, create pages which look ok with single window and font size, at best. No question about that :) The separation between server-side programmers, Javascript coders and graphic artists is a wrong thing. Ok, the initial visual design is done by artist in Photoshop, but everyting else is programmed. Javascript is the same part of the toolbox, as Struts tags or JDBC. I don't think saying it is wrong is accurate... It is just an environment you are probably not used to. Some argue it is better that way and many say that's the way we should be moving. Not sure I agree, but some say that. -- 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]
[OT] RE: AJAX: Whoa, Nellie!
The move towards specialization has ups and downs, depending on where you live, what you do, and what your company's management thinks. As we specialize into very discreet tasks (that presumably can have very precise requirements wrapped around them) the business owners begin to gain the ability to leverage alternative methods of development. (think offshore). Now as a business owner this may (or may not) make sense, but the more offshore that happens... well you see the cycle. So it depends on where you live :) Of course, at least in the US, we have mostly caused this ourselves with the dismal public education system, but that's an argument for a different forum. Specialization also means that should a business not want to do offshore they can now look for precise skills. I think this began to show up a couple three years ago in strength when managers started looking for very precise skills. When I moved to Atlanta I interviewed with several companies but one interview that sticks out is one where they were using Websphere Commerce. I didn't get the job and even though I have tons of experience with a competing product they wanted the exact experience (or at least that is what I was told is the reason) so you can see that even within a particular sector (lets call it server side architecture) businesses are getting even more particular. Al p.s. funny side of the story is that I got hired by a different company and eventually went on a contract to the exact company that did not hire me, to do the job I interviewed for. Seems the guy they hired didn't like the hours. So as the line goes sometimes you eat the bear, other times the bear eats you. -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 8:16 PM To: Struts Users Mailing List Cc: Shihgian Lee Subject: Re: AJAX: Whoa, Nellie! I don't think saying it is wrong is accurate... It is just an environment you are probably not used to. Some argue it is better that way and many say that's the way we should be moving. Not sure I agree, but some say that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Martin Cooper wrote: Frank W. Zammetti [EMAIL PROTECTED] wrote in message Again, by all means, use Dojo. Not everyone will agree it's a good answer though. Not everyone will see it as the greatest thing since sliced bread. Poor fools. ;-) ;-) ;-) -- Martin Cooper Headline for tmrw bloogers: *Struts chairman endorses Dojo* :-} .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
You say it jokingly, but... Vic Cekvenich (netsql) wrote: Martin Cooper wrote: Frank W. Zammetti [EMAIL PROTECTED] wrote in message Again, by all means, use Dojo. Not everyone will agree it's a good answer though. Not everyone will see it as the greatest thing since sliced bread. Poor fools. ;-) ;-) ;-) -- Martin Cooper Headline for tmrw bloogers: *Struts chairman endorses Dojo* :-} .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
Re: [OT] RE: AJAX: Whoa, Nellie!
Good insight Allen, thank you! Your experience echoes mine as well. P.S. - The way my father always said it is sometimes you eat the salami, sometimes the salami eats you. I bet everyones' dad told them that with a different something or other eating something or other :) Fogleson, Allen wrote: The move towards specialization has ups and downs, depending on where you live, what you do, and what your company's management thinks. As we specialize into very discreet tasks (that presumably can have very precise requirements wrapped around them) the business owners begin to gain the ability to leverage alternative methods of development. (think offshore). Now as a business owner this may (or may not) make sense, but the more offshore that happens... well you see the cycle. So it depends on where you live :) Of course, at least in the US, we have mostly caused this ourselves with the dismal public education system, but that's an argument for a different forum. Specialization also means that should a business not want to do offshore they can now look for precise skills. I think this began to show up a couple three years ago in strength when managers started looking for very precise skills. When I moved to Atlanta I interviewed with several companies but one interview that sticks out is one where they were using Websphere Commerce. I didn't get the job and even though I have tons of experience with a competing product they wanted the exact experience (or at least that is what I was told is the reason) so you can see that even within a particular sector (lets call it server side architecture) businesses are getting even more particular. Al p.s. funny side of the story is that I got hired by a different company and eventually went on a contract to the exact company that did not hire me, to do the job I interviewed for. Seems the guy they hired didn't like the hours. So as the line goes sometimes you eat the bear, other times the bear eats you. -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 8:16 PM To: Struts Users Mailing List Cc: Shihgian Lee Subject: Re: AJAX: Whoa, Nellie! I don't think saying it is wrong is accurate... It is just an environment you are probably not used to. Some argue it is better that way and many say that's the way we should be moving. Not sure I agree, but some say that. -- 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]
Re: AJAX: Whoa, Nellie!
Martin Cooper wrote: That's why I said or maybe somewhere else. It would be perfectly fine to put the JavaScript functions in a separate .js file and linked to from the page. And neither of us are talking scriptlets here. ;-) Glad neither of us are talking scriplets :) Didn't think we were anyway, but confirmation is always good! I agree linking it in is a better answer, and that's one of the changes I intend to make when I complete the work. However, there is still a basic difference of opinion here... you are saying you have no problem with a developer having to write the code that (a) makes the call to the imported library and (b) handles the returned data. My contention is that, at least for some percentage of us cases (I've been saying 80%, may actually be more or less), the tags themselves can be made to do that work automatically. That's the one thing Dojo, or other such options that I've seen, does not address. They provide very nice wrappers around the server call part, and there is most certainly value in that, but they say nothing about what happens when the response is accepted. I belive at last basic things can be provided, hence my notion of the std actions. As long as that's not ALL you can do with it, I see that as a good thing. Again, move the JavaScript out to a separate file. That's essentially all you've done with your Ajax config file, other than using a new XML syntax for it. Now the only difference between your JSP page and mine is that yours uses customised tags while mine doesn't need them. ;-) That's really not all that I've done though Martin. You are equating a declarative approach with a shared piece of code. That really is not accurate IMHO. It's like saying that instead of being able to write validation rules in a config file people should instead just simply import some JS library that has all the validation logic in it, and then you just make calls to those imported functions. Same difference. Why you say my solution requires custom tags I don't understand... yes, it requires custom tags if you aren't already using the Struts HTML tags, and if that's what you meant then I certainly agree with you :) But, since my solution seeks to address people using Struts and the HTML tags specifically, this isn't a limitation. Also in your example you are explicitly constructing the query string... my tags do that for you. I presume you could dynamically create it with Dojo as well, but then your talking about more code. Plus, we're talking a bunch of inline code which, to my eyes, is very ugly, in much the same way anonymous inner classes are in Swing coding. Well, at least going from your example, your construction is little more than string concatenation. I don't think you're saving much. The code that is emitted it precisely that, true, but it's the fact that you can change what gets concatenating without touching the page that is nice. It's all defined in the config file. Hmm, perhaps we're used to different JavaScript. That's pretty normal stuff to me. Certainly nothing unusual. It is an unusual syntax, but that says nothing about it's correctness or anything else. If no one else finds it unusual then just chalk it up to something unusual for me :) Going from writing ActionForm classes to dyna beans defined in XML saves you a lot of tedious coding. In contrast, this lets you use a *more* verbose syntax to say the same thing. I don't see the advantage. Moreover, if you move the JavaScript code into a separate file, you actually save in clarity and maintainability, at least IMHO. Agreed on the point about moving the JS out... what I plan on doing is having a tag that imports the requisite JS depending on what is done in the tags (I'm frankly not sure how to accomplish this yet, ideally it would be automatic in the html:for tag, but as a last resort I can introduce a new tag, something like enableAjax/ that must be used in the head of the page) I think we have to agree to disagree on which is more verbose though. Your way may save in line count (just barely), but it is at the cost, in my opinion, of a more complex JSP. And my point is that anyone who knows what an HTML form is would wonder why they had to use this new syntax for specifying the URL, instead of just writing the URL in the first place. But the page author wouldn't be worrying about specifying the URL, and even if they did it is the same syntax they specify any other URL with, it's just in an XML file. Perhaps I don't understand your point here? I'm not referring to the code that does the actuall server call; that's going to be hidden code in either approach, as you say. I'm referring to the way in which, in your approach, the 'onclick' function is dynamically generated from your XML config. You may not have quite gotten how this works... as originally written, the code that does the actual server call *IS* hidden, it is just inline in the onClick handler
Re: AJAX: Whoa, Nellie!
Martin Cooper wrote:
My Huh? comment was in reference you your statement that the approach I
was describing doesn't really help people with existing apps, which I take
issue with. If you put the JavaScript methods in separate file, it has the
exact same impact on the JSP pages as your approach does, but without
needing the custom attributes. You say 'ajaxRef=button1' and I say
'onclick=doButton1()'.
Ok, I may have misunderstood that.
Moving on though...
If you put the JavaScript methods in separate file, it has the
exact same impact on the JSP pages as your approach does
I do not belive this is true, and here's why... as far as the event
handlers go, I agree, the impact is virtually identical... But in terms
of what the event handler calls there is I think a big difference.
Going back to your original example, you state:
Elsewhere in the JSP page, or maybe somewhere else:
function doButton1() {
dojo.io.bind({
url: http://www.omnytex.com?buttonValue=button1textValue=text1;,
load: function(type, data) {
document.getElementById(resultLayer).innerHTML = data; },
mimetype: text/plain
});
}
Now, that looks like more work to me because, if nothing else, I'm
writing the return handler myself. And if I had to write 20 of these
functions for a single page, ugh! You mentioned DynaActionForms saving
a lot of tedious coding... this is about as tedious as it gets :)
If you want to argue that moving these functions out to another file
that you include makes the situation better, I'd say only marginally
better because the benefit of separating the code is offset somewhat by
the fact that now there are two files to maintain. Then again, you
could also argue that THAT is better because you can have coders
handling the JS while you have page authors handling just the markup :)
(beat you to the punch on that one!)
**
You know, it just dawned on me... in all of this, recall that my
proposal allowed for you to call whatever JS function you want rather
than have the code generated for you... there is absolutely nothing to
stop you from calling a function that uses Dojo! This gives you, I
think, the best of both worlds: you get to use Dojo, but you can still
do so in a declative way... although, you'd take on the responsibility
of importing the necassery JS code and implementing the send and receive
handlers, at which point there probably isn't a whole lot to be gained
by the config file anyway, in fact it would probably be
counterproductive... but the point is you *can* do this.
**
You know, when all is said and done, we simply have a difference of
opinion in all this. I'd bet neither of us really wants to debate this
for the next week :) I think we're probably at that point where we
aren't going to convince each other of anything but some relatively
small points at best.
I don't deny that Dojo looks cool, and if you are happily using it I am
genuinely happy about it! If you want to tell people how great it is,
that is fine with me too (although I would hope you recognize your
position gives your opinions weight and would be a little careful about
proclaiming anything to be the endorsed answer).
I am going to go off and implement my idea because if nothing else I
have seen a decent amount of interest amidst all this debate. The
simple fact that the whole concept was reopened by someone else (I had
nothing to do with it, I was actually completely off this whole idea
after the initial RFC thread died down) should indicate it isn't just me
that thinks it has merit.
In the end, choice is good. Like all FOSS projects, if when it's done
people find it useful and want to use it, that will make me rather
happy. If they discover Dojo and think it's the cat's meow, that is
sweet too. If they go off in a completely different direction, things
are working as they are supposed to because a choice was made between a
number of options :)
Frank
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
+1 also to Frank's suggestions, although I realize he was not ready to cash in the ticket yet. On the whole, I like his no nonsense and non-convoluted approach to these problems. That is what I liked about Struts from the beginning. The present course is not clear. Nor is there any perceived need to make it clear, I think. I suspect Frank will do what we all must do at this point. Just code and don't pay attention to all the flak. Jack On 4/19/05, Shihgian Lee [EMAIL PROTECTED] wrote: What you demonstrate here I would also argue is worse for page authors, who now have to be concerned with script writing as well as layout of simple HTML tags. You can argue that a page author would know Javascript as well, and you may be right in most cases, but the idea that everyone seems to be pushing is that the page authors should really be glorified graphics artists who just do markup and worry about layout, not code. That doesn't jive, to me at least, with the example you post. +1. I agree with Frank's point of view over Martin's. Usually in a larger organization, you have to work with different groups of people with different roles i.e. page authors/UI experts. Page authors/UI experts don't have to know about scripting and just focus on page layouts or usabilities. If you are in a smaller organization where one person does it all, then that is fine. Frank's proposal adds great values in the organization I am working in. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
According to the linguists, the beauty of language is just the opposite, viz. its public nature, so that private meanings are not only allowed, they categorically make no sense. This has been the rock-hard basis for modern linguistic analysis for as long as the Sun has risen. Technical terms can have technical definitions, but normal words in normal contexts, including scientific and technical contexts, must have the meaning given to them in use by their users. That is why I talked about how the word is used, rather than about how we can mean anything we want. I am definitely not an anarchist in matters linguistic. We, as programming related workers, should understand at least this about language, it has rules which are the bedrock upon which we communicate. I recommend an excellent article written by a Harvard philosopher, Stanley Cavell on this called Must We Mean What We Say? which is in a book by the same title. On 4/19/05, Dave Newton [EMAIL PROTECTED] wrote: Dakota Jack wrote: I may be nuts, many have said I am on this list, unfairly, but isn't rendering HTML capable of being understood either as rendering the HTML meaning creating the HTML or rendering the HTML meaning creating the view from the HTML? At least people like David Geary talk about serverside rendering all the time with layout applications. Sure, we can define it to be whatever you want, that's the beauty of language. Maybe you could say rendering a view and the view is rendered _as_ HTML, but the HTML still isn't rendered until it's drawn on a screen (or other media, yeah yeah). Or maybe rendering _to_ HTML, as one definition of render means to express in another language. Rendered sounds funny now. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
The problem with NET and JSF is not what they do client side but what they do server side. They are just too heavy and will never scale. This does not mean that they will not have a market. Hopefully they will so that those who love them will have money and leave us alone. But, for people who can code without tools, they are not a viable solution, in my opinion. On 4/19/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: That's actually a good point... We've all heard about JSF and ASP.Net, how they handle client-side events server-side, which is a concept I've never been especially enamored with. But, when you see some actual examples of this in things like what Google is doing, you start to reconsider that position a bit. This isn't about richer UIs because, let's be honest folks, GMail is no great shakes interface-wise. What is cool about it is the overall performance and efficiency of it, and as Jack says, that is all about interaction with the server, not what the user sees. Another benefit of AJAX that I haven't seen mentioned much is error handling... Instead of seeing 404s or 500s or cryptic stack dumps or whatever else the server spews out, the user only sees what the AJAX developer wants them to see. Error handling no longer results in the entire flow of a web app breaking down, it can be handled considerably more gracefully than before, especially now that try...catch is a supported JS function (it wasn't always as I recall). All this is of course in the realm of client-server interaction as Jack is talking about, but in this case it ALSO results in a better user experience. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, April 19, 2005 1:23 pm, Dakota Jack said: I have another perspective on this. Rich UIs are good, but what I like about AJAX in addition to that somewhat peripheral concern (to me) is that it cooperates with the serverside and allows the serverside to be more efficient. The relationship between the server and the client in AJAX is what is most interesting and is what makes it so useful. There is a reason why the sites using AJAX, e.g. Google, do so. It is not because they are seeking, necessarily, any sort of rich clients. They are seeking robustness and usefulness. That is where AJAX is at, I think. All this other talk is fine, but it misses the main point of what makes AJAX interesting for Struts. The rich client stuff can be a dark hole for serverside discussions. AJAX is not. Jack On 4/19/05, Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Michael J. wrote: People just should stop thinking in terms of client-side scripting and start thinking in terms of client-side rendering :-) (XAML, XUL, Flex, JDNC, DHTML(Ajax, JavaScript)). UI naturaly should be done on client side, asking for domain and other services from the server. The more you do client-side the richer the UI. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - 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] -- No one ever went blind looking at the bright side of life. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Where do we find information about this marvellous stuff? Rodolfo __ Dakota Jack [EMAIL PROTECTED] 18/04/2005 15:02 Por favor, responda a Struts Users Mailing List Para: Struts Users Mailing List user@struts.apache.org cc: (cco: Rodolfo García Esteban/CYII) Asunto: AJAX: Whoa, Nellie! I have been taking another look at the AJAX stuff that Frank Zammetti has provided. This stuff is revolutionary. Someone ought to be taking a close look at integrating such solutions, so far as it makes sense, into Struts. This is not a passing fancy, in my estimation. This is a real solution to a persistent problem. Further, this moves the solution to where the problem exists, on the client. I, for one, am getting excited. I am not saying to be precipitous, so the usual mundane warnings can be kept aside. But, this is not the usual thing. This is a fundamental shift in architecture that makes clear sense. Jack -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Dakota Jack a écrit : This is a fundamental shift in architecture that makes clear sense. I tend to agree with you, and if this were to be integrated in Struts, my life would be easier (I am using AJAX stuff in some parts of my webapp). However, I have a serious concern related to security : this is still JavaScript :-) -- Stéphane Zuckerman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Rodolfo García Esteban/CYII a écrit : Where do we find information about this marvellous stuff? Rodolfo __ Look for XMLHttpRequest and/or ActiveXObject(Microsoft.XMLHTTP) XML.com and the Apple dev center have good introductory articles about it. Basically, this is a way to make server call from JavaScript via the XMLHttpRequest (Safari/Gecko browsers) or XMLHTTP (Internet Explorer) objects. Thus it enables you to make dynamic calls to refresh some parts of a web page without reloading everything. This is used with gmail for instance. -- Stéphane Zuckerman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
http://wiki.apache.org/struts/AjaxStruts On 4/18/05, Rodolfo García Esteban/CYII [EMAIL PROTECTED] wrote: Where do we find information about this marvellous stuff? Rodolfo __ Dakota Jack [EMAIL PROTECTED] 18/04/2005 15:02 Por favor, responda a Struts Users Mailing List Para: Struts Users Mailing List user@struts.apache.org cc: (cco: Rodolfo García Esteban/CYII) Asunto: AJAX: Whoa, Nellie! I have been taking another look at the AJAX stuff that Frank Zammetti has provided. This stuff is revolutionary. Someone ought to be taking a close look at integrating such solutions, so far as it makes sense, into Struts. This is not a passing fancy, in my estimation. This is a real solution to a persistent problem. Further, this moves the solution to where the problem exists, on the client. I, for one, am getting excited. I am not saying to be precipitous, so the usual mundane warnings can be kept aside. But, this is not the usual thing. This is a fundamental shift in architecture that makes clear sense. Jack -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
http://wiki.apache.org/struts/AjaxStruts On 4/18/05, Stéphane Zuckerman [EMAIL PROTECTED] wrote: Rodolfo García Esteban/CYII a écrit : Where do we find information about this marvellous stuff? Rodolfo __ Look for XMLHttpRequest and/or ActiveXObject(Microsoft.XMLHTTP) XML.com and the Apple dev center have good introductory articles about it. Basically, this is a way to make server call from JavaScript via the XMLHttpRequest (Safari/Gecko browsers) or XMLHTTP (Internet Explorer) objects. Thus it enables you to make dynamic calls to refresh some parts of a web page without reloading everything. This is used with gmail for instance. -- Stéphane Zuckerman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Good overview, Stephane On 4/18/05, Stéphane Zuckerman [EMAIL PROTECTED] wrote: Rodolfo García Esteban/CYII a écrit : Where do we find information about this marvellous stuff? Rodolfo __ Look for XMLHttpRequest and/or ActiveXObject(Microsoft.XMLHTTP) XML.com and the Apple dev center have good introductory articles about it. Basically, this is a way to make server call from JavaScript via the XMLHttpRequest (Safari/Gecko browsers) or XMLHTTP (Internet Explorer) objects. Thus it enables you to make dynamic calls to refresh some parts of a web page without reloading everything. This is used with gmail for instance. -- Stéphane Zuckerman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
For articles, blogs, libraries, etc, related to this technology, take a look at http://www.ajaxmatters.com/ Our own Frank wrote an article about using it on http://www.omnytex.com/articles/xhrstruts/ He also proposed integrating the technology with the Struts taglibs: http://marc.theaimsgroup.com/?t=11128162732r=3w=2 Hubert On 4/18/05, Rodolfo García Esteban/CYII [EMAIL PROTECTED] wrote: Where do we find information about this marvellous stuff? Rodolfo __ Dakota Jack [EMAIL PROTECTED] 18/04/2005 15:02 Por favor, responda a Struts Users Mailing List Para: Struts Users Mailing List user@struts.apache.org cc: (cco: Rodolfo García Esteban/CYII) Asunto: AJAX: Whoa, Nellie! I have been taking another look at the AJAX stuff that Frank Zammetti has provided. This stuff is revolutionary. Someone ought to be taking a close look at integrating such solutions, so far as it makes sense, into Struts. This is not a passing fancy, in my estimation. This is a real solution to a persistent problem. Further, this moves the solution to where the problem exists, on the client. I, for one, am getting excited. I am not saying to be precipitous, so the usual mundane warnings can be kept aside. But, this is not the usual thing. This is a fundamental shift in architecture that makes clear sense. Jack -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - 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]
Re: AJAX: Whoa, Nellie!
Stéphane Zuckerman wrote: if this were to be integrated in Struts, my life would be easier. I too will now check it out. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
eee... javascript... yuck, ptooey! ptooey!! --- Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Stéphane Zuckerman wrote: if this were to be integrated in Struts, my life would be easier. I too will now check it out. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On 4/6 I posted the following message to the Struts dev list... I can't
seem to find the thread in the list archives, if anyone else can I would
appreciate very much you posting the link to it...
This was discussing my proposal for integrating AJAX functionality into
the existing Struts taglibs. There were some legitimate dissenting points
raised about this, and ultimately the idea was shot down. However, I
still feel the idea has significant merit.
The proposal wasn't posted to the user list, and maybe I should have done
so... if there is support for this in the user community, I would be
willing to persue it further and provide it as part of the SF Struts
project.
P.S., I've added some notes here for some things that may not be as clear
as I would have liked, especially if you aren't terribly familiar with the
Struts code base, so if you see minor difference between this and what is
in the archives, that's all it is...
Subject: RFC: Struts HTML Ajax-Aware Tags
Afternoon all,
Please reference the code at:
http://www.omnytex.com/ajaxtags.zip
This is a complete webapp demonstrating the proposal (it isn't complete,
it is just to get the ideas across).
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 (in the
BaseTagHandler class) looks something like this now:
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
idbutton1/id
event
typeonClick/type
submitTypequeryString/submitType
submitItemsbuttonValue=button1,textValue=text1/submitItems
submitTargethttp://www.omnytex.com/submitTarget
returnActionstdInnerHTML/returnAction
returnTargetsresultLayer/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
is found, then the prepareAjax() method does its thing (note that
developer-defined event handler functions will take precedent, so no
existing code would be broken by this). And what is its thing you ask?
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=1textValue=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
Re: AJAX: Whoa, Nellie!
ptooey... I've always wanted to know how to spell that :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 10:29 am, Woodchuck said: eee... javascript... yuck, ptooey! ptooey!! --- Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Stéphane Zuckerman wrote: if this were to be integrated in Struts, my life would be easier. I too will now check it out. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - 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]
Re: AJAX: Whoa, Nellie!
Frank,
You must've started typing this response a while ago. I already sent
a message on this thread linking to the dev email with your proposal.
Hubert
On 4/18/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
On 4/6 I posted the following message to the Struts dev list... I can't
seem to find the thread in the list archives, if anyone else can I would
appreciate very much you posting the link to it...
This was discussing my proposal for integrating AJAX functionality into
the existing Struts taglibs. There were some legitimate dissenting points
raised about this, and ultimately the idea was shot down. However, I
still feel the idea has significant merit.
The proposal wasn't posted to the user list, and maybe I should have done
so... if there is support for this in the user community, I would be
willing to persue it further and provide it as part of the SF Struts
project.
P.S., I've added some notes here for some things that may not be as clear
as I would have liked, especially if you aren't terribly familiar with the
Struts code base, so if you see minor difference between this and what is
in the archives, that's all it is...
Subject: RFC: Struts HTML Ajax-Aware Tags
Afternoon all,
Please reference the code at:
http://www.omnytex.com/ajaxtags.zip
This is a complete webapp demonstrating the proposal (it isn't complete,
it is just to get the ideas across).
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 (in the
BaseTagHandler class) looks something like this now:
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
idbutton1/id
event
typeonClick/type
submitTypequeryString/submitType
submitItemsbuttonValue=button1,textValue=text1/submitItems
submitTargethttp://www.omnytex.com/submitTarget
returnActionstdInnerHTML/returnAction
returnTargetsresultLayer/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
is found, then the prepareAjax() method does its thing (note that
developer-defined event handler functions will take precedent, so no
existing code would be broken by this). And what is its thing you ask?
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=1textValue=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
Re: AJAX: Whoa, Nellie!
Yep, sorry about that... I had it in my drafts folder because I got called
away in the middle of it, and I didn't check all the replies to the
current thread before sending it so I didn't see your link until
afterwards. My bad :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Mon, April 18, 2005 10:41 am, Hubert Rabago said:
Frank,
You must've started typing this response a while ago. I already sent
a message on this thread linking to the dev email with your proposal.
Hubert
On 4/18/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
On 4/6 I posted the following message to the Struts dev list... I can't
seem to find the thread in the list archives, if anyone else can I would
appreciate very much you posting the link to it...
This was discussing my proposal for integrating AJAX functionality into
the existing Struts taglibs. There were some legitimate dissenting
points
raised about this, and ultimately the idea was shot down. However, I
still feel the idea has significant merit.
The proposal wasn't posted to the user list, and maybe I should have
done
so... if there is support for this in the user community, I would be
willing to persue it further and provide it as part of the SF Struts
project.
P.S., I've added some notes here for some things that may not be as
clear
as I would have liked, especially if you aren't terribly familiar with
the
Struts code base, so if you see minor difference between this and what
is
in the archives, that's all it is...
Subject: RFC: Struts HTML Ajax-Aware Tags
Afternoon all,
Please reference the code at:
http://www.omnytex.com/ajaxtags.zip
This is a complete webapp demonstrating the proposal (it isn't complete,
it is just to get the ideas across).
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 (in the
BaseTagHandler class) looks something like this now:
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
idbutton1/id
event
typeonClick/type
submitTypequeryString/submitType
submitItemsbuttonValue=button1,textValue=text1/submitItems
submitTargethttp://www.omnytex.com/submitTarget
returnActionstdInnerHTML/returnAction
returnTargetsresultLayer/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
is found, then the prepareAjax() method does its thing (note that
developer-defined event handler functions will take precedent, so no
existing code would be broken by this). And what is its thing you
ask?
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=1textValue=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
Re: AJAX: Whoa, Nellie!
JavaScript provides a client side rather developed engine in JavaScript as well as Flash, etc. This is merely a resource. The yuck, ptooey! ptooey response to these ideas, especially ones in production and successful for quite a while, strikes me as rather less than professional. I think it is interesting that JavaScript, which I have avoided like the plague, has kept building a market despite a lot of prejudice from people like myself, not to mention Woodchuck. ///;-) On 4/18/05, Woodchuck [EMAIL PROTECTED] wrote: eee... javascript... yuck, ptooey! ptooey!! --- Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Stéphane Zuckerman wrote: if this were to be integrated in Struts, my life would be easier. I too will now check it out. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Let me first say that IMHO, introducing AJAX capabilities into the html taglib is an awesome idea. Frank W. Zammetti wrote: So, the question is, does anyone see this as something interesting? Very. I was also thinking about working on AJAX taglibs using Sarissa [1] (introductory article at [2]), but i was aiming for more than XMLHttpRequest, for example to allow XSLT transformations to be applied on the XML either the server or client, depending on what the browser supports. 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. I would happily help (although i have little time) and even donate the JS code under the ASL if wanted. Questions? Comments? Whatever? Thanks all! I haven't really studied the samples yet, but it would seem more semantically correct to me if the html:form was used to make this work. I'll try to come up with more concrete suggestions. [1] http://sarissa.sf.net/ [2] http://www.xml.com/pub/a/2005/02/23/sarissa.html Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
sorry, i couldn't resist . actually, why don't we address this problem at the source rather than using this javascript patch solution? (at least this is how i see it) why don't the browser makers build internal mechanisms to allow posting of forms without the need to refresh the html page? why don't we re-architect the browswer and address this problem (and others) at that fundamental level? is this not conceivable? woodchuck --- Dakota Jack [EMAIL PROTECTED] wrote: JavaScript provides a client side rather developed engine in JavaScript as well as Flash, etc. This is merely a resource. The yuck, ptooey! ptooey response to these ideas, especially ones in production and successful for quite a while, strikes me as rather less than professional. I think it is interesting that JavaScript, which I have avoided like the plague, has kept building a market despite a lot of prejudice from people like myself, not to mention Woodchuck. ///;-) On 4/18/05, Woodchuck [EMAIL PROTECTED] wrote: eee... javascript... yuck, ptooey! ptooey!! --- Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Stéphane Zuckerman wrote: if this were to be integrated in Struts, my life would be easier. I too will now check it out. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
Frank, will Ajax support be tied into reporting form errors? It would be interesting to break down the validator into individual validations, so errors can be reported to the user as he types. -Original Message- From: Emmanouil Batsis [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 11:12 AM To: Struts Users Mailing List; Dakota Jack Subject: Re: AJAX: Whoa, Nellie! Let me first say that IMHO, introducing AJAX capabilities into the html taglib is an awesome idea. Frank W. Zammetti wrote: So, the question is, does anyone see this as something interesting? Very. I was also thinking about working on AJAX taglibs using Sarissa [1] (introductory article at [2]), but i was aiming for more than XMLHttpRequest, for example to allow XSLT transformations to be applied on the XML either the server or client, depending on what the browser supports. 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. I would happily help (although i have little time) and even donate the JS code under the ASL if wanted. Questions? Comments? Whatever? Thanks all! I haven't really studied the samples yet, but it would seem more semantically correct to me if the html:form was used to make this work. I'll try to come up with more concrete suggestions. [1] http://sarissa.sf.net/ [2] http://www.xml.com/pub/a/2005/02/23/sarissa.html Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Not sure what to say, Woodchuck, about your suggestion that a request be sent that does not want a response and does not affect the HTML page. What would happen next? And, how? This is perfectly conceivable. Heck, I think that it might be possible as is. But, I don't see this as even addressing the problem that AJAX is so neato, keen on. Jack On 4/18/05, Woodchuck [EMAIL PROTECTED] wrote: sorry, i couldn't resist . actually, why don't we address this problem at the source rather than using this javascript patch solution? (at least this is how i see it) why don't the browser makers build internal mechanisms to allow posting of forms without the need to refresh the html page? why don't we re-architect the browswer and address this problem (and others) at that fundamental level? is this not conceivable? woodchuck --- Dakota Jack [EMAIL PROTECTED] wrote: JavaScript provides a client side rather developed engine in JavaScript as well as Flash, etc. This is merely a resource. The yuck, ptooey! ptooey response to these ideas, especially ones in production and successful for quite a while, strikes me as rather less than professional. I think it is interesting that JavaScript, which I have avoided like the plague, has kept building a market despite a lot of prejudice from people like myself, not to mention Woodchuck. ///;-) On 4/18/05, Woodchuck [EMAIL PROTECTED] wrote: eee... javascript... yuck, ptooey! ptooey!! --- Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Stéphane Zuckerman wrote: if this were to be integrated in Struts, my life would be easier. I too will now check it out. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
No problemo. As far as the extension itself is concerned, I'd still
be interested in it, but like I mentioned earlier, only as a plugin
that doesn't change the base tags. The reasons are many and they are
mentioned in the dev thread you started. My main concern is
implementation lock-in. Another message in this thread already
illustrates that there could be several approaches to adding this
functionality. I wouldn't want to limit how everyone else applies the
technology. As Martin said, if an implementation is built into
Struts, it should support whatever client-side library the developer
would want to use (
http://marc.theaimsgroup.com/?l=struts-devm=111284722931074w=2 ). A
separate plugin wouldn't have to have that burden.
A separated plugin would result in code duplication, true, but in my
view it's worth it. In some aspects, the ajax-aware tags you propose
are in a better position than the EL tags. You only need to override
some methods, whose implementation can be moved to a util-type class.
EL had to add duplicate fields, getters, and setters. Just take a
look at the source of some of those tags, like ELCheckboxTag and
ELRadioTag.
Hubert
On 4/18/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Yep, sorry about that... I had it in my drafts folder because I got called
away in the middle of it, and I didn't check all the replies to the
current thread before sending it so I didn't see your link until
afterwards. My bad :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Mon, April 18, 2005 10:41 am, Hubert Rabago said:
Frank,
You must've started typing this response a while ago. I already sent
a message on this thread linking to the dev email with your proposal.
Hubert
On 4/18/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
On 4/6 I posted the following message to the Struts dev list... I can't
seem to find the thread in the list archives, if anyone else can I would
appreciate very much you posting the link to it...
This was discussing my proposal for integrating AJAX functionality into
the existing Struts taglibs. There were some legitimate dissenting
points
raised about this, and ultimately the idea was shot down. However, I
still feel the idea has significant merit.
The proposal wasn't posted to the user list, and maybe I should have
done
so... if there is support for this in the user community, I would be
willing to persue it further and provide it as part of the SF Struts
project.
P.S., I've added some notes here for some things that may not be as
clear
as I would have liked, especially if you aren't terribly familiar with
the
Struts code base, so if you see minor difference between this and what
is
in the archives, that's all it is...
Subject: RFC: Struts HTML Ajax-Aware Tags
Afternoon all,
Please reference the code at:
http://www.omnytex.com/ajaxtags.zip
This is a complete webapp demonstrating the proposal (it isn't complete,
it is just to get the ideas across).
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 (in the
BaseTagHandler class) looks something like this now:
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
idbutton1/id
event
typeonClick/type
submitTypequeryString/submitType
submitItemsbuttonValue=button1,textValue=text1/submitItems
submitTargethttp://www.omnytex.com/submitTarget
returnActionstdInnerHTML/returnAction
returnTargetsresultLayer/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
is found, then the prepareAjax() method does its thing (note that
developer-defined event handler functions will take precedent, so no
existing code would be broken by this). And what is its thing you
ask?
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
Re: AJAX: Whoa, Nellie!
SNIP On 4/18/05, Dave Newton [EMAIL PROTECTED] wrote: Or we could just use ActiveX controls. *psych!* /SNIP Or JavaScript, or Applets, or Flash, or .. but, most importantly, in this thread, AJAX with STRUTS. Jack -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
