Mailing-List: contact tapestry-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tapestry development" <tapestry-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of xela.org@gmail.com designates
 64.233.184.195 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=boLyJRAbmUmsmPY8Df5oQ1OPnV6l1+vEH//V0SbE09YzMF36yw/znsd/gNsL1ICB3N4LBmuvFfvrXxt0bskCvu2JM8rwlKhXT8e2EVeCmEHBioKtR3hjrQ+sPfHKEHeNaHy+vnkAYl4Qw5VAVERY20z9sFW+7WKSNBYgRMK/KN0=
Message-ID: <3c13bc0905032502383ec46a26@mail.gmail.com>
Date: Fri, 25 Mar 2005 18:38:56 +0800
From: Alex Ieong <xela.org@gmail.com>
Reply-To: Alex Ieong <xela.org@gmail.com>
To: Tapestry development <tapestry-dev@jakarta.apache.org>
Subject: Re: Suggestion: XMLHttpRequest support
In-Reply-To: <OFEKJGNNOMIFAFMNJABJMEFCFGAA.sporter217@yahoo.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
References: <9cab960d292c0bfe216c37cc13c6fbb2@ehatchersolutions.com>
	 <OFEKJGNNOMIFAFMNJABJMEFCFGAA.sporter217@yahoo.co.uk>

Would you show us some code sample which you did? 

On Fri, 25 Mar 2005 00:13:59 -0000, Steven Porter
<sporter217@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