You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Alex Ieong <xe...@gmail.com> on 2005/03/24 09:55:53 UTC
Suggestion: XMLHttpRequest support
Hi Everybody,
XMLHttpRequest is widely supported in most browsers. With
XMLHttpRequest, we can do make our webapp more interactive. Now Google
has demostrated its power:
* Gmail: http://www.gmail.com
fast transition when changing different views, fast dynamic loading
mail content etc.
* Google suggest: http://www.google.com/webhp?complete=1&hl=en
auto-complete and suggest search keywords during you're typing.
But it's quite difficult to make Tapestry support XMLHttpRequest
technology at this moment, for example:
* For the business logic handling, Tapestry hasn't provided any easy
way to do so. We have to code some servlet on our own.
* For the interface rendering, there isn't any basic component ready
for this use for further application development.
* If the dynamic part is used in HTML forms, there isn't any service
can handle the request. This case applies to all interactive-rendering
HTML forms.
I hope we can discuss about this topic. As far as I know, there isn't
any web application framework able to handle this easily, but I
believe it's the best technology for the future of web applications -
we don't want to see only rich internet application or smart client
rule the future, right?
--
Alex Ieong, Macau
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Suggestion: XMLHttpRequest support
Posted by Alex Ieong <xe...@gmail.com>.
I'd like to share this article about Ajax:
http://www.adaptivepath.com/publications/essays/archives/000385.php
On Fri, 25 Mar 2005 00:13:59 -0000, Steven Porter
<sp...@yahoo.co.uk> wrote:
> > Ajax-savvy components would want
> > to wire in a callback type of facility to allow a page to provide data
> > when a remote call is made back to the component.
>
> It's definitely preferable to have the component itself respond to the
> XMLHttpRequest(s), since this means you can encapsulate the logic within the
> component itself.
>
> We've done this at the page level, by embedding DirectLinks within the page
> that handle the 2 or 3 XML HttpRequest call backs. We plugged in "empty
> link renders" since the link is only really used to serve as a call-back via
> the JavaScript rather than a true link that gets clicked on by the user.
>
> In fact, we created a trivial component for that purpose that wraps up
> DirectLink, but automatically plugs in an "empty" link renderer.
>
> The DirectLink triggers are specified as listener methods on the page, and
> these take direct control over the http response to serve back the
> appropriate XML. We use some hackery/extensions to then suppress the
> regular page rendering that you get after the direct link trigger.
>
> The JavaScript that's generated by the page is able to ask the DirectLink
> what it's URL is, and thus use it for the call-back.
>
> For all of the above, where you read "page", there's no reason why this
> couldn't apply to a "component".
>
> I guess it's a bit hacky to be using DirectLink as the XMLHttpRequest
> call-back mechanism, but it works. It might be nicer just to use a special
> ajax tapestry service that calls back to the component to really serve the
> XML.
>
> How we provide this support within tapestry in a more "automatic" and
> "easily accessible" way is not that obvious to me.
>
> sp
>
> >
> > Erik
> >
> >
> > On Mar 24, 2005, at 3:55 AM, Alex Ieong wrote:
> >
> > > Hi Everybody,
> > >
> > > XMLHttpRequest is widely supported in most browsers. With
> > > XMLHttpRequest, we can do make our webapp more interactive. Now Google
> > > has demostrated its power:
> > > * Gmail: http://www.gmail.com
> > > fast transition when changing different views, fast dynamic loading
> > > mail content etc.
> > > * Google suggest: http://www.google.com/webhp?complete=1&hl=en
> > > auto-complete and suggest search keywords during you're typing.
> > >
> > > But it's quite difficult to make Tapestry support XMLHttpRequest
> > > technology at this moment, for example:
> > > * For the business logic handling, Tapestry hasn't provided any easy
> > > way to do so. We have to code some servlet on our own.
> > > * For the interface rendering, there isn't any basic component ready
> > > for this use for further application development.
> > > * If the dynamic part is used in HTML forms, there isn't any service
> > > can handle the request. This case applies to all interactive-rendering
> > > HTML forms.
> > >
> > > I hope we can discuss about this topic. As far as I know, there isn't
> > > any web application framework able to handle this easily, but I
> > > believe it's the best technology for the future of web applications -
> > > we don't want to see only rich internet application or smart client
> > > rule the future, right?
> > >
> > > --
> > > Alex Ieong, Macau
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Alex Ieong, MO
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Suggestion: XMLHttpRequest support
Posted by Alex Ieong <xe...@gmail.com>.
Would you show us some code sample which you did?
On Fri, 25 Mar 2005 00:13:59 -0000, Steven Porter
<sp...@yahoo.co.uk> wrote:
> > Ajax-savvy components would want
> > to wire in a callback type of facility to allow a page to provide data
> > when a remote call is made back to the component.
>
> It's definitely preferable to have the component itself respond to the
> XMLHttpRequest(s), since this means you can encapsulate the logic within the
> component itself.
>
> We've done this at the page level, by embedding DirectLinks within the page
> that handle the 2 or 3 XML HttpRequest call backs. We plugged in "empty
> link renders" since the link is only really used to serve as a call-back via
> the JavaScript rather than a true link that gets clicked on by the user.
>
> In fact, we created a trivial component for that purpose that wraps up
> DirectLink, but automatically plugs in an "empty" link renderer.
>
> The DirectLink triggers are specified as listener methods on the page, and
> these take direct control over the http response to serve back the
> appropriate XML. We use some hackery/extensions to then suppress the
> regular page rendering that you get after the direct link trigger.
>
> The JavaScript that's generated by the page is able to ask the DirectLink
> what it's URL is, and thus use it for the call-back.
>
> For all of the above, where you read "page", there's no reason why this
> couldn't apply to a "component".
>
> I guess it's a bit hacky to be using DirectLink as the XMLHttpRequest
> call-back mechanism, but it works. It might be nicer just to use a special
> ajax tapestry service that calls back to the component to really serve the
> XML.
>
> How we provide this support within tapestry in a more "automatic" and
> "easily accessible" way is not that obvious to me.
>
> sp
>
> >
> > Erik
> >
> >
> > On Mar 24, 2005, at 3:55 AM, Alex Ieong wrote:
> >
> > > Hi Everybody,
> > >
> > > XMLHttpRequest is widely supported in most browsers. With
> > > XMLHttpRequest, we can do make our webapp more interactive. Now Google
> > > has demostrated its power:
> > > * Gmail: http://www.gmail.com
> > > fast transition when changing different views, fast dynamic loading
> > > mail content etc.
> > > * Google suggest: http://www.google.com/webhp?complete=1&hl=en
> > > auto-complete and suggest search keywords during you're typing.
> > >
> > > But it's quite difficult to make Tapestry support XMLHttpRequest
> > > technology at this moment, for example:
> > > * For the business logic handling, Tapestry hasn't provided any easy
> > > way to do so. We have to code some servlet on our own.
> > > * For the interface rendering, there isn't any basic component ready
> > > for this use for further application development.
> > > * If the dynamic part is used in HTML forms, there isn't any service
> > > can handle the request. This case applies to all interactive-rendering
> > > HTML forms.
> > >
> > > I hope we can discuss about this topic. As far as I know, there isn't
> > > any web application framework able to handle this easily, but I
> > > believe it's the best technology for the future of web applications -
> > > we don't want to see only rich internet application or smart client
> > > rule the future, right?
> > >
> > > --
> > > Alex Ieong, Macau
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Alex Ieong, MO
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Suggestion: XMLHttpRequest support
Posted by Jamie Orchard-Hays <ja...@dang.com>.
And just to add a little motivation...
Rails release 0.11.0 came out two days ago with Ajax support:
http://weblog.rubyonrails.com/archives/2005/03/22/rails-0110-ajax-pagination-non-vhost-incoming-mail/
and
http://www.rubyonrails.com/media/video/rails-ajax.mov
----- Original Message -----
From: "Erik Hatcher" <er...@ehatchersolutions.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Thursday, March 24, 2005 4:44 AM
Subject: Re: Suggestion: XMLHttpRequest support
> We're all ears! Do you have a proposal for how Tapestry can support
> XMLHttpRequest natively?
>
> I suspect that my project will benefit from some fancy Ajax features in
> the near future, so I'll be investigating this. It'd be trivial to wire
> up a service that can send XML, for example. But you may want to return
> plain text or HTML fragments. Ajax-savvy components would want to wire in
> a callback type of facility to allow a page to provide data when a remote
> call is made back to the component.
>
> Erik
>
>
> On Mar 24, 2005, at 3:55 AM, Alex Ieong wrote:
>
>> Hi Everybody,
>>
>> XMLHttpRequest is widely supported in most browsers. With
>> XMLHttpRequest, we can do make our webapp more interactive. Now Google
>> has demostrated its power:
>> * Gmail: http://www.gmail.com
>> fast transition when changing different views, fast dynamic loading
>> mail content etc.
>> * Google suggest: http://www.google.com/webhp?complete=1&hl=en
>> auto-complete and suggest search keywords during you're typing.
>>
>> But it's quite difficult to make Tapestry support XMLHttpRequest
>> technology at this moment, for example:
>> * For the business logic handling, Tapestry hasn't provided any easy
>> way to do so. We have to code some servlet on our own.
>> * For the interface rendering, there isn't any basic component ready
>> for this use for further application development.
>> * If the dynamic part is used in HTML forms, there isn't any service
>> can handle the request. This case applies to all interactive-rendering
>> HTML forms.
>>
>> I hope we can discuss about this topic. As far as I know, there isn't
>> any web application framework able to handle this easily, but I
>> believe it's the best technology for the future of web applications -
>> we don't want to see only rich internet application or smart client
>> rule the future, right?
>>
>> --
>> Alex Ieong, Macau
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: Suggestion: XMLHttpRequest support
Posted by Steven Porter <sp...@yahoo.co.uk>.
> Ajax-savvy components would want
> to wire in a callback type of facility to allow a page to provide data
> when a remote call is made back to the component.
It's definitely preferable to have the component itself respond to the
XMLHttpRequest(s), since this means you can encapsulate the logic within the
component itself.
We've done this at the page level, by embedding DirectLinks within the page
that handle the 2 or 3 XML HttpRequest call backs. We plugged in "empty
link renders" since the link is only really used to serve as a call-back via
the JavaScript rather than a true link that gets clicked on by the user.
In fact, we created a trivial component for that purpose that wraps up
DirectLink, but automatically plugs in an "empty" link renderer.
The DirectLink triggers are specified as listener methods on the page, and
these take direct control over the http response to serve back the
appropriate XML. We use some hackery/extensions to then suppress the
regular page rendering that you get after the direct link trigger.
The JavaScript that's generated by the page is able to ask the DirectLink
what it's URL is, and thus use it for the call-back.
For all of the above, where you read "page", there's no reason why this
couldn't apply to a "component".
I guess it's a bit hacky to be using DirectLink as the XMLHttpRequest
call-back mechanism, but it works. It might be nicer just to use a special
ajax tapestry service that calls back to the component to really serve the
XML.
How we provide this support within tapestry in a more "automatic" and
"easily accessible" way is not that obvious to me.
sp
>
> Erik
>
>
> On Mar 24, 2005, at 3:55 AM, Alex Ieong wrote:
>
> > Hi Everybody,
> >
> > XMLHttpRequest is widely supported in most browsers. With
> > XMLHttpRequest, we can do make our webapp more interactive. Now Google
> > has demostrated its power:
> > * Gmail: http://www.gmail.com
> > fast transition when changing different views, fast dynamic loading
> > mail content etc.
> > * Google suggest: http://www.google.com/webhp?complete=1&hl=en
> > auto-complete and suggest search keywords during you're typing.
> >
> > But it's quite difficult to make Tapestry support XMLHttpRequest
> > technology at this moment, for example:
> > * For the business logic handling, Tapestry hasn't provided any easy
> > way to do so. We have to code some servlet on our own.
> > * For the interface rendering, there isn't any basic component ready
> > for this use for further application development.
> > * If the dynamic part is used in HTML forms, there isn't any service
> > can handle the request. This case applies to all interactive-rendering
> > HTML forms.
> >
> > I hope we can discuss about this topic. As far as I know, there isn't
> > any web application framework able to handle this easily, but I
> > believe it's the best technology for the future of web applications -
> > we don't want to see only rich internet application or smart client
> > rule the future, right?
> >
> > --
> > Alex Ieong, Macau
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Suggestion: XMLHttpRequest support
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
We're all ears! Do you have a proposal for how Tapestry can support
XMLHttpRequest natively?
I suspect that my project will benefit from some fancy Ajax features in
the near future, so I'll be investigating this. It'd be trivial to
wire up a service that can send XML, for example. But you may want to
return plain text or HTML fragments. Ajax-savvy components would want
to wire in a callback type of facility to allow a page to provide data
when a remote call is made back to the component.
Erik
On Mar 24, 2005, at 3:55 AM, Alex Ieong wrote:
> Hi Everybody,
>
> XMLHttpRequest is widely supported in most browsers. With
> XMLHttpRequest, we can do make our webapp more interactive. Now Google
> has demostrated its power:
> * Gmail: http://www.gmail.com
> fast transition when changing different views, fast dynamic loading
> mail content etc.
> * Google suggest: http://www.google.com/webhp?complete=1&hl=en
> auto-complete and suggest search keywords during you're typing.
>
> But it's quite difficult to make Tapestry support XMLHttpRequest
> technology at this moment, for example:
> * For the business logic handling, Tapestry hasn't provided any easy
> way to do so. We have to code some servlet on our own.
> * For the interface rendering, there isn't any basic component ready
> for this use for further application development.
> * If the dynamic part is used in HTML forms, there isn't any service
> can handle the request. This case applies to all interactive-rendering
> HTML forms.
>
> I hope we can discuss about this topic. As far as I know, there isn't
> any web application framework able to handle this easily, but I
> believe it's the best technology for the future of web applications -
> we don't want to see only rich internet application or smart client
> rule the future, right?
>
> --
> Alex Ieong, Macau
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org