You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Martin Marinschek <ma...@gmail.com> on 2006/06/15 05:07:43 UTC
PPR - client-side
Hi *,
Ernst Fastl - in his SoC beginning review - has worked on comparing the
different PPR solutions so far. He's compared AjaxAnywhere, PPR in Trinidad,
and some of the Avatar approach.
What he's come up with so far is that he really likes the server-side
integration of Trinidad, especially the syntax of integrating it in the view
definition - not so much the client-side portion of it for doing PPR. Would
you be happy with work being done on the client side portion of the PPR
interaction in Trinidad in the SoC project?
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: PPR - client-side
Posted by Enrique Medina <e....@gmail.com>.
Are you also considering Ajax4Jsf from Exadel guys (open-source, of course)?
On 6/14/06, Martin Marinschek <ma...@gmail.com> wrote:
>
> Hi *,
>
> Ernst Fastl - in his SoC beginning review - has worked on comparing the
> different PPR solutions so far. He's compared AjaxAnywhere, PPR in
> Trinidad,
> and some of the Avatar approach.
>
> What he's come up with so far is that he really likes the server-side
> integration of Trinidad, especially the syntax of integrating it in the
> view
> definition - not so much the client-side portion of it for doing PPR.
> Would
> you be happy with work being done on the client side portion of the PPR
> interaction in Trinidad in the SoC project?
>
> regards,
>
> Martin
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
Re: PPR - client-side
Posted by Matthias Wessendorf <ma...@apache.org>.
Martin-
thanks for bringing this up here, too.
We should link from the adf status file to theses SoC projects, that
ADF / Trinidad is working with the community on these pieces.
-Matthias
On 6/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> Hi *,
>
> Ernst Fastl - in his SoC beginning review - has worked on comparing the
> different PPR solutions so far. He's compared AjaxAnywhere, PPR in Trinidad,
> and some of the Avatar approach.
>
> What he's come up with so far is that he really likes the server-side
> integration of Trinidad, especially the syntax of integrating it in the view
> definition - not so much the client-side portion of it for doing PPR. Would
> you be happy with work being done on the client side portion of the PPR
> interaction in Trinidad in the SoC project?
>
> regards,
>
> Martin
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: PPR - client-side
Posted by Cosma Colanicchia <co...@gmail.com>.
Thank you for the explanation of how AJAX Anywhere works. I'll
probably be looking into AJAX in a few days and my ideas are much more
clear now :-)
Cosma
2006/6/15, Ernst Fastl <er...@gmail.com>:
> Hi There!
>
> In the PPR-Implemetation I would rather like to avoid those iframes
> and do it completly
> with AJAX. The Client-Side Implementation of AJAY Anywhere seems
> pretty much straight
> forward to me. When using it together with MyFaces it works the following way:
>
> 1.) Defining Zones to reload in the jsp-file with the <aa:zoneJSF
> id="x">-Component
> those get rendered as <span>-tags with id="aazone.x"
>
> 2.) Define which zones are to be reloaded with AJAX-Calls by defining
> a JS-Function:
> getZonesToReload(url, submitButton)
>
> 3.) Substitute the submit-function of the main-Form to use submitAJAX instead
>
> 4.) if a button is pressed or a value changed that would lead to a
> submit of the mainForm, submitAJAX checks based on getZonesToReload if
> an AJAXRequest is to be done.
> if not the form is submitted as usual.
>
> 5.)If it is an AJAX request a post-request is build with all
> parameter/value pairs of the form
> elements +
> -aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper) its
> an AJAX-Request
> -aazones=id1,id2 - Tell which zones need to be updated
>
> 6.)If AAFilter on the Server side detects aaxmlrequest=true it parses
> the HTML in the Response to extract the specified zones (big
> disadvantage the whole component
> tree gets rendered internally).
>
> 7.)HTML-Code of the zones is packed into xml-tags with the name of the
> zones as attribute and send back to the client
>
> 8.)Client parses the response and sets element.innerHTML of the
> zone-span-elements with the contents from the response
>
> What I like in this approach is the Javascript-Code that generates the
> Post-Request and the Code that parses the
> response and updates the DOM.
>
> The Server Side is pretty ugly. I would prefer to find a way to invoke
> only the affected components which I think
> should also make it faster. I haven't yet completly understood how
> trinidad handles this, but I think they have
> the cleaner solution for the server-side.
>
> What I also don't like is the JS-Code you have to write in your JSPs
> (calling substitueSubmitFunction, defining getZonesToReload, ..)
>
> In this point I would much prefer something like the
> partialTriggers-Attribute in trinidad.
>
> The thing is you have to define
> 1. which elements are to be reloaded by AJAX
> 2. which elements trigger those reloads
>
> I could also think of a listener-Component that can be added to the
> to-be-updated-elements and specify
> by which components those updates are triggered (which is pretty much
> the other way around compared to trinidad).
>
> I'm not yet completly shure whats the optimal approach for this, but
> I'll start with writing a s:panelGroup which
> supports a partialTriggers-Attribute that takes ids of radio-buttons
> (whith onchange="submit()"). For a start
> I will integrate this with AJAX-Anywhere to have something to try the
> different approches for the JSP-Part.
> Just for playing around whith it.
>
> If anyone is interested I'll try to make this online available once I'm done.
>
> Suggestions, Objections, Ideas and advices are very welcome :-)
>
> regards
>
> Ernst
>
>
> On 6/15/06, Adam Winer <aw...@gmail.com> wrote:
> > I'd be thrilled!
> >
> > For background, PPR was developed back before XMLHttp existed.
> > Back then, the only decent way to communicate to the server was
> > via hidden iframes. That solution has *a lot* of problems - for
> > example, no decent way to handle errors, and the document that
> > comes back can get parsed as HTML, which leads to some ugliness
> > with handling Javascript, etc.. It was a great choice for the time, but
> > it's showing its age, and there's better technologies
> >
> > Swapping out the client-side piece for an XMLHttpRequest-based
> > submission, with probably a few tweaks to the syntax delivered
> > by the PPR ResponseWriter, would give us a much more robust
> > solution, and would be a great isolated task. I'd be more than
> > happy to point anyone tackling this in the right directions.
> >
> > -- Adam
> >
> >
> > On 6/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > Hi *,
> > >
> > > Ernst Fastl - in his SoC beginning review - has worked on comparing the
> > > different PPR solutions so far. He's compared AjaxAnywhere, PPR in Trinidad,
> > > and some of the Avatar approach.
> > >
> > > What he's come up with so far is that he really likes the server-side
> > > integration of Trinidad, especially the syntax of integrating it in the view
> > > definition - not so much the client-side portion of it for doing PPR. Would
> > > you be happy with work being done on the client side portion of the PPR
> > > interaction in Trinidad in the SoC project?
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> > >
> >
>
Re: PPR - client-side
Posted by Adam Winer <aw...@gmail.com>.
Ernst,
Well, you could also try rewriting the Javascript in
Trinidad to use XMLHttp,. and skip AJAX Anywhere. Like
I said, the iframes are purely a legacy implementation
choice. This'd save you any need to build new components,
etc.
-- Adam
On 6/15/06, Ernst Fastl <er...@gmail.com> wrote:
> Hi There!
>
> In the PPR-Implemetation I would rather like to avoid those iframes
> and do it completly
> with AJAX. The Client-Side Implementation of AJAY Anywhere seems
> pretty much straight
> forward to me. When using it together with MyFaces it works the following way:
>
> 1.) Defining Zones to reload in the jsp-file with the <aa:zoneJSF
> id="x">-Component
> those get rendered as <span>-tags with id="aazone.x"
>
> 2.) Define which zones are to be reloaded with AJAX-Calls by defining
> a JS-Function:
> getZonesToReload(url, submitButton)
>
> 3.) Substitute the submit-function of the main-Form to use submitAJAX instead
>
> 4.) if a button is pressed or a value changed that would lead to a
> submit of the mainForm, submitAJAX checks based on getZonesToReload if
> an AJAXRequest is to be done.
> if not the form is submitted as usual.
>
> 5.)If it is an AJAX request a post-request is build with all
> parameter/value pairs of the form
> elements +
> -aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper) its
> an AJAX-Request
> -aazones=id1,id2 - Tell which zones need to be updated
>
> 6.)If AAFilter on the Server side detects aaxmlrequest=true it parses
> the HTML in the Response to extract the specified zones (big
> disadvantage the whole component
> tree gets rendered internally).
>
> 7.)HTML-Code of the zones is packed into xml-tags with the name of the
> zones as attribute and send back to the client
>
> 8.)Client parses the response and sets element.innerHTML of the
> zone-span-elements with the contents from the response
>
> What I like in this approach is the Javascript-Code that generates the
> Post-Request and the Code that parses the
> response and updates the DOM.
>
> The Server Side is pretty ugly. I would prefer to find a way to invoke
> only the affected components which I think
> should also make it faster. I haven't yet completly understood how
> trinidad handles this, but I think they have
> the cleaner solution for the server-side.
>
> What I also don't like is the JS-Code you have to write in your JSPs
> (calling substitueSubmitFunction, defining getZonesToReload, ..)
>
> In this point I would much prefer something like the
> partialTriggers-Attribute in trinidad.
>
> The thing is you have to define
> 1. which elements are to be reloaded by AJAX
> 2. which elements trigger those reloads
>
> I could also think of a listener-Component that can be added to the
> to-be-updated-elements and specify
> by which components those updates are triggered (which is pretty much
> the other way around compared to trinidad).
>
> I'm not yet completly shure whats the optimal approach for this, but
> I'll start with writing a s:panelGroup which
> supports a partialTriggers-Attribute that takes ids of radio-buttons
> (whith onchange="submit()"). For a start
> I will integrate this with AJAX-Anywhere to have something to try the
> different approches for the JSP-Part.
> Just for playing around whith it.
>
> If anyone is interested I'll try to make this online available once I'm done.
>
> Suggestions, Objections, Ideas and advices are very welcome :-)
>
> regards
>
> Ernst
>
>
> On 6/15/06, Adam Winer <aw...@gmail.com> wrote:
> > I'd be thrilled!
> >
> > For background, PPR was developed back before XMLHttp existed.
> > Back then, the only decent way to communicate to the server was
> > via hidden iframes. That solution has *a lot* of problems - for
> > example, no decent way to handle errors, and the document that
> > comes back can get parsed as HTML, which leads to some ugliness
> > with handling Javascript, etc.. It was a great choice for the time, but
> > it's showing its age, and there's better technologies
> >
> > Swapping out the client-side piece for an XMLHttpRequest-based
> > submission, with probably a few tweaks to the syntax delivered
> > by the PPR ResponseWriter, would give us a much more robust
> > solution, and would be a great isolated task. I'd be more than
> > happy to point anyone tackling this in the right directions.
> >
> > -- Adam
> >
> >
> > On 6/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > Hi *,
> > >
> > > Ernst Fastl - in his SoC beginning review - has worked on comparing the
> > > different PPR solutions so far. He's compared AjaxAnywhere, PPR in Trinidad,
> > > and some of the Avatar approach.
> > >
> > > What he's come up with so far is that he really likes the server-side
> > > integration of Trinidad, especially the syntax of integrating it in the view
> > > definition - not so much the client-side portion of it for doing PPR. Would
> > > you be happy with work being done on the client side portion of the PPR
> > > interaction in Trinidad in the SoC project?
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> > >
> >
>
Re: PPR - client-side
Posted by Ernst Fastl <er...@gmail.com>.
Ok,
So the Client Side Code of Trinidad will be reworked as well. Nevertheless
I will start with the Tomahawk-AA example, because we will want to have
PPR there as well and I think its a good starting point.
regards
Ernst
On 6/16/06, Martin Marinschek <ma...@gmail.com> wrote:
> Hi Ernst,
>
> as for me - and I believe also Werner, who is your mentor, changing the
> scope to rework the Trinidad client side source code will be perfectly
> alright for your SoC project.
> It would still be great if you could get the tomahawk components to play
> their part in the whole thing.
>
> regards,
>
> Martin
>
> On 6/16/06, Ernst Fastl <er...@gmail.com> wrote:
> >
> > Yes I'll be looking into the Avatar PPR solution as well, I'ver heard
> > that they have some pretty good ideas. I also like the Idea of
> > a onPartialRefresh javascript attribute (although it seems indeed a
> > bit early :-)
> >
> > Regarding the question of AA dependencies, I'm not planning to use
> > this permanently, just to start with something for playing around
> > with new components that support attributes like partialTriggers,
> > or listener-components without having actually to implement the
> > client-side JS first. To make it clear I'm not suggesting to add
> > an AA dep in sandbox, we will want to have our own client-side
> > code don't we :-)
> >
> >
> >
> > On 6/16/06, Rogers Reilly <ro...@s-rod.com> wrote:
> > > I'm not a contributor, but that approach sounds perfect to me. I've
> > > used PPR for a couple of projects now, and swapping out the iFrame
> > > client-side for dojo.bind would be a great improvement. Would give you
> > > async, for one; and obviously does away with custom JS.
> > >
> > > Another nice feature (I know it's early for requests :-) ) would be to
> > > allow an "onPartialRefresh" javascript attribute to any component that
> > > triggers PPR. From time to time, I find myself with a rather lengthy
> > > PPR request, and would like to do something on the client to indicate
> > > more content is loading (beyond the native browser "I'm loading"
> > > behavior), and then undo that something when the new PPR content shows
> > > up. The first part I can do with an "onClick" handler on the control
> > > (although an explicit "onPartialRequest" would be better), but the
> > > second part I can't, because the custom JS that displays the page isn't
> > > exposed. I'm figuring by the time I get around to digging into the
> > > existing Trinidad JS and exposing it myself (which, I'm sorry to say,
> > > falls somewhere below watching World Cup on TV on my to-do list), you
> > > might be done. :-)
> > >
> > > Also, on the subject of PPR, what is the scoop on Avatar? They seemed
> > > to have a PPR solution pegged pretty well in the JavaOne demo, and being
> > > cooked into JSF itself, it would seem like the preferred route--at least
> > > on the server side. I know Adam was part of that presentation ... is
> > > that stuff just too far off to be worth counting on for Trinidad PPR
> > > under JSF 1.2?
> > >
> > > -Rogers
> > >
> > > Ernst Fastl wrote:
> > >
> > > > Thanks for your ideas guys, and yes overworking the existing PPR in
> > > > Trinidad
> > > > to make the Client-Side-Code to use XMLHttp sounds good to me. The
> > thing
> > > > is my Proposal for Google ist titled:
> > > >
> > > > "Implement AJAX Partial Page Rendering Support in Apache MyFaces"
> > > >
> > > >
> > > >
> > > > Since, if I understood it correctly, trinidad is now part of MyFaces
> > > > it should
> > > > be ok to work on that Code. But my original Idea was to compare the
> > > > Approaches of trinidad and AJAX Anywhere to find a solution for
> > > > MyFaces which combines advantages from Both.
> > > >
> > > > The AJAX-Anywhere based component in the sandbox ( not intended to be
> > > > commited
> > > > to MyFaces in this version) Is just to start "playing around" with PPR
> > > > in the tomahawk
> > > > library.
> > > >
> > > > I don't know if and when the component libraries of trinidad and
> > > > tomahawk are to be
> > > > merged, but I could think of implementing PPR in tomahawk reusing much
> > of
> > > > the trinidad Server Side PPR Code and Reimplementing the Client Side
> > Code
> > > > based on the existing AJAX Infrastructure in MyFaces (which I think
> > > > is using the DoJo-Library). Once this is finished this Client-Side
> > > > code may be
> > > > used to on the other side enhance the trinidad Client-Side Code. So in
> > > > the
> > > > end both Component libraries would benefit from each other.
> > > >
> > > > thoughts?
> > > > On 6/15/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > >
> > > >> Ernst,
> > > >>
> > > >> trying to get rid of all the custom JavaScript sounds very good.
> > Don't
> > > >> like that too!
> > > >>
> > > >> Is the suggestion from Adam valuable for you?
> > > >> I think it should be better to *enhance* Trinidad's PPR instead of
> > > >> "creating" new PPR style components for the sandbox. Also not having
> > a
> > > >> AA dependency sounds great, to me.
> > > >>
> > > >> I think enhancing an existing solution, or providing a new
> > > >> "architecture" should be fine with the SoC rules, right?
> > > >>
> > > >> -Matthias
> > > >>
> > > >> On 6/15/06, Ernst Fastl <er...@gmail.com> wrote:
> > > >> > Hi There!
> > > >> >
> > > >> > In the PPR-Implemetation I would rather like to avoid those iframes
> > > >> > and do it completly
> > > >> > with AJAX. The Client-Side Implementation of AJAY Anywhere seems
> > > >> > pretty much straight
> > > >> > forward to me. When using it together with MyFaces it works the
> > > >> following way:
> > > >> >
> > > >> > 1.) Defining Zones to reload in the jsp-file with the <aa:zoneJSF
> > > >> > id="x">-Component
> > > >> > those get rendered as <span>-tags with id="aazone.x"
> > > >> >
> > > >> > 2.) Define which zones are to be reloaded with AJAX-Calls by
> > defining
> > > >> > a JS-Function:
> > > >> > getZonesToReload(url, submitButton)
> > > >> >
> > > >> > 3.) Substitute the submit-function of the main-Form to use
> > > >> submitAJAX instead
> > > >> >
> > > >> > 4.) if a button is pressed or a value changed that would lead to a
> > > >> > submit of the mainForm, submitAJAX checks based on getZonesToReload
> > if
> > > >> > an AJAXRequest is to be done.
> > > >> > if not the form is submitted as usual.
> > > >> >
> > > >> > 5.)If it is an AJAX request a post-request is build with all
> > > >> > parameter/value pairs of the form
> > > >> > elements +
> > > >> > -aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper)
> > its
> > > >> > an AJAX-Request
> > > >> > -aazones=id1,id2 - Tell which zones need to be updated
> > > >> >
> > > >> > 6.)If AAFilter on the Server side detects aaxmlrequest=true it
> > parses
> > > >> > the HTML in the Response to extract the specified zones (big
> > > >> > disadvantage the whole component
> > > >> > tree gets rendered internally).
> > > >> >
> > > >> > 7.)HTML-Code of the zones is packed into xml-tags with the name of
> > the
> > > >> > zones as attribute and send back to the client
> > > >> >
> > > >> > 8.)Client parses the response and sets element.innerHTML of the
> > > >> > zone-span-elements with the contents from the response
> > > >> >
> > > >> > What I like in this approach is the Javascript-Code that generates
> > the
> > > >> > Post-Request and the Code that parses the
> > > >> > response and updates the DOM.
> > > >> >
> > > >> > The Server Side is pretty ugly. I would prefer to find a way to
> > invoke
> > > >> > only the affected components which I think
> > > >> > should also make it faster. I haven't yet completly understood how
> > > >> > trinidad handles this, but I think they have
> > > >> > the cleaner solution for the server-side.
> > > >> >
> > > >> > What I also don't like is the JS-Code you have to write in your
> > JSPs
> > > >> > (calling substitueSubmitFunction, defining getZonesToReload, ..)
> > > >> >
> > > >> > In this point I would much prefer something like the
> > > >> > partialTriggers-Attribute in trinidad.
> > > >> >
> > > >> > The thing is you have to define
> > > >> > 1. which elements are to be reloaded by AJAX
> > > >> > 2. which elements trigger those reloads
> > > >> >
> > > >> > I could also think of a listener-Component that can be added to the
> > > >> > to-be-updated-elements and specify
> > > >> > by which components those updates are triggered (which is pretty
> > much
> > > >> > the other way around compared to trinidad).
> > > >> >
> > > >> > I'm not yet completly shure whats the optimal approach for this,
> > but
> > > >> > I'll start with writing a s:panelGroup which
> > > >> > supports a partialTriggers-Attribute that takes ids of
> > radio-buttons
> > > >> > (whith onchange="submit()"). For a start
> > > >> > I will integrate this with AJAX-Anywhere to have something to try
> > the
> > > >> > different approches for the JSP-Part.
> > > >> > Just for playing around whith it.
> > > >> >
> > > >> > If anyone is interested I'll try to make this online available once
> > > >> I'm done.
> > > >> >
> > > >> > Suggestions, Objections, Ideas and advices are very welcome :-)
> > > >> >
> > > >> > regards
> > > >> >
> > > >> > Ernst
> > > >> >
> > > >> >
> > > >> > On 6/15/06, Adam Winer <aw...@gmail.com> wrote:
> > > >> > > I'd be thrilled!
> > > >> > >
> > > >> > > For background, PPR was developed back before XMLHttp existed.
> > > >> > > Back then, the only decent way to communicate to the server was
> > > >> > > via hidden iframes. That solution has *a lot* of problems - for
> > > >> > > example, no decent way to handle errors, and the document that
> > > >> > > comes back can get parsed as HTML, which leads to some ugliness
> > > >> > > with handling Javascript, etc.. It was a great choice for the
> > > >> time, but
> > > >> > > it's showing its age, and there's better technologies
> > > >> > >
> > > >> > > Swapping out the client-side piece for an XMLHttpRequest-based
> > > >> > > submission, with probably a few tweaks to the syntax delivered
> > > >> > > by the PPR ResponseWriter, would give us a much more robust
> > > >> > > solution, and would be a great isolated task. I'd be more than
> > > >> > > happy to point anyone tackling this in the right directions.
> > > >> > >
> > > >> > > -- Adam
> > > >> > >
> > > >> > >
> > > >> > > On 6/14/06, Martin Marinschek <ma...@gmail.com>
> > wrote:
> > > >> > > > Hi *,
> > > >> > > >
> > > >> > > > Ernst Fastl - in his SoC beginning review - has worked on
> > > >> comparing the
> > > >> > > > different PPR solutions so far. He's compared AjaxAnywhere, PPR
> > > >> in Trinidad,
> > > >> > > > and some of the Avatar approach.
> > > >> > > >
> > > >> > > > What he's come up with so far is that he really likes the
> > > >> server-side
> > > >> > > > integration of Trinidad, especially the syntax of integrating
> > > >> it in the view
> > > >> > > > definition - not so much the client-side portion of it for
> > > >> doing PPR. Would
> > > >> > > > you be happy with work being done on the client side portion of
> > > >> the PPR
> > > >> > > > interaction in Trinidad in the SoC project?
> > > >> > > >
> > > >> > > > regards,
> > > >> > > >
> > > >> > > > Martin
> > > >> > > >
> > > >> > > > --
> > > >> > > >
> > > >> > > > http://www.irian.at
> > > >> > > >
> > > >> > > > Your JSF powerhouse -
> > > >> > > > JSF Consulting, Development and
> > > >> > > > Courses in English and German
> > > >> > > >
> > > >> > > > Professional Support for Apache MyFaces
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >> Matthias Wessendorf
> > > >> Aechterhoek 18
> > > >> 48282 Emsdetten
> > > >> blog: http://jroller.com/page/mwessendorf
> > > >> mail: mwessendorf-at-gmail-dot-com
> > > >>
> > > >
> > > >
> > >
> > >
> >
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
Re: PPR - client-side
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Ernst,
as for me - and I believe also Werner, who is your mentor, changing the
scope to rework the Trinidad client side source code will be perfectly
alright for your SoC project.
It would still be great if you could get the tomahawk components to play
their part in the whole thing.
regards,
Martin
On 6/16/06, Ernst Fastl <er...@gmail.com> wrote:
>
> Yes I'll be looking into the Avatar PPR solution as well, I'ver heard
> that they have some pretty good ideas. I also like the Idea of
> a onPartialRefresh javascript attribute (although it seems indeed a
> bit early :-)
>
> Regarding the question of AA dependencies, I'm not planning to use
> this permanently, just to start with something for playing around
> with new components that support attributes like partialTriggers,
> or listener-components without having actually to implement the
> client-side JS first. To make it clear I'm not suggesting to add
> an AA dep in sandbox, we will want to have our own client-side
> code don't we :-)
>
>
>
> On 6/16/06, Rogers Reilly <ro...@s-rod.com> wrote:
> > I'm not a contributor, but that approach sounds perfect to me. I've
> > used PPR for a couple of projects now, and swapping out the iFrame
> > client-side for dojo.bind would be a great improvement. Would give you
> > async, for one; and obviously does away with custom JS.
> >
> > Another nice feature (I know it's early for requests :-) ) would be to
> > allow an "onPartialRefresh" javascript attribute to any component that
> > triggers PPR. From time to time, I find myself with a rather lengthy
> > PPR request, and would like to do something on the client to indicate
> > more content is loading (beyond the native browser "I'm loading"
> > behavior), and then undo that something when the new PPR content shows
> > up. The first part I can do with an "onClick" handler on the control
> > (although an explicit "onPartialRequest" would be better), but the
> > second part I can't, because the custom JS that displays the page isn't
> > exposed. I'm figuring by the time I get around to digging into the
> > existing Trinidad JS and exposing it myself (which, I'm sorry to say,
> > falls somewhere below watching World Cup on TV on my to-do list), you
> > might be done. :-)
> >
> > Also, on the subject of PPR, what is the scoop on Avatar? They seemed
> > to have a PPR solution pegged pretty well in the JavaOne demo, and being
> > cooked into JSF itself, it would seem like the preferred route--at least
> > on the server side. I know Adam was part of that presentation ... is
> > that stuff just too far off to be worth counting on for Trinidad PPR
> > under JSF 1.2?
> >
> > -Rogers
> >
> > Ernst Fastl wrote:
> >
> > > Thanks for your ideas guys, and yes overworking the existing PPR in
> > > Trinidad
> > > to make the Client-Side-Code to use XMLHttp sounds good to me. The
> thing
> > > is my Proposal for Google ist titled:
> > >
> > > "Implement AJAX Partial Page Rendering Support in Apache MyFaces"
> > >
> > >
> > >
> > > Since, if I understood it correctly, trinidad is now part of MyFaces
> > > it should
> > > be ok to work on that Code. But my original Idea was to compare the
> > > Approaches of trinidad and AJAX Anywhere to find a solution for
> > > MyFaces which combines advantages from Both.
> > >
> > > The AJAX-Anywhere based component in the sandbox ( not intended to be
> > > commited
> > > to MyFaces in this version) Is just to start "playing around" with PPR
> > > in the tomahawk
> > > library.
> > >
> > > I don't know if and when the component libraries of trinidad and
> > > tomahawk are to be
> > > merged, but I could think of implementing PPR in tomahawk reusing much
> of
> > > the trinidad Server Side PPR Code and Reimplementing the Client Side
> Code
> > > based on the existing AJAX Infrastructure in MyFaces (which I think
> > > is using the DoJo-Library). Once this is finished this Client-Side
> > > code may be
> > > used to on the other side enhance the trinidad Client-Side Code. So in
> > > the
> > > end both Component libraries would benefit from each other.
> > >
> > > thoughts?
> > > On 6/15/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > >
> > >> Ernst,
> > >>
> > >> trying to get rid of all the custom JavaScript sounds very good.
> Don't
> > >> like that too!
> > >>
> > >> Is the suggestion from Adam valuable for you?
> > >> I think it should be better to *enhance* Trinidad's PPR instead of
> > >> "creating" new PPR style components for the sandbox. Also not having
> a
> > >> AA dependency sounds great, to me.
> > >>
> > >> I think enhancing an existing solution, or providing a new
> > >> "architecture" should be fine with the SoC rules, right?
> > >>
> > >> -Matthias
> > >>
> > >> On 6/15/06, Ernst Fastl <er...@gmail.com> wrote:
> > >> > Hi There!
> > >> >
> > >> > In the PPR-Implemetation I would rather like to avoid those iframes
> > >> > and do it completly
> > >> > with AJAX. The Client-Side Implementation of AJAY Anywhere seems
> > >> > pretty much straight
> > >> > forward to me. When using it together with MyFaces it works the
> > >> following way:
> > >> >
> > >> > 1.) Defining Zones to reload in the jsp-file with the <aa:zoneJSF
> > >> > id="x">-Component
> > >> > those get rendered as <span>-tags with id="aazone.x"
> > >> >
> > >> > 2.) Define which zones are to be reloaded with AJAX-Calls by
> defining
> > >> > a JS-Function:
> > >> > getZonesToReload(url, submitButton)
> > >> >
> > >> > 3.) Substitute the submit-function of the main-Form to use
> > >> submitAJAX instead
> > >> >
> > >> > 4.) if a button is pressed or a value changed that would lead to a
> > >> > submit of the mainForm, submitAJAX checks based on getZonesToReload
> if
> > >> > an AJAXRequest is to be done.
> > >> > if not the form is submitted as usual.
> > >> >
> > >> > 5.)If it is an AJAX request a post-request is build with all
> > >> > parameter/value pairs of the form
> > >> > elements +
> > >> > -aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper)
> its
> > >> > an AJAX-Request
> > >> > -aazones=id1,id2 - Tell which zones need to be updated
> > >> >
> > >> > 6.)If AAFilter on the Server side detects aaxmlrequest=true it
> parses
> > >> > the HTML in the Response to extract the specified zones (big
> > >> > disadvantage the whole component
> > >> > tree gets rendered internally).
> > >> >
> > >> > 7.)HTML-Code of the zones is packed into xml-tags with the name of
> the
> > >> > zones as attribute and send back to the client
> > >> >
> > >> > 8.)Client parses the response and sets element.innerHTML of the
> > >> > zone-span-elements with the contents from the response
> > >> >
> > >> > What I like in this approach is the Javascript-Code that generates
> the
> > >> > Post-Request and the Code that parses the
> > >> > response and updates the DOM.
> > >> >
> > >> > The Server Side is pretty ugly. I would prefer to find a way to
> invoke
> > >> > only the affected components which I think
> > >> > should also make it faster. I haven't yet completly understood how
> > >> > trinidad handles this, but I think they have
> > >> > the cleaner solution for the server-side.
> > >> >
> > >> > What I also don't like is the JS-Code you have to write in your
> JSPs
> > >> > (calling substitueSubmitFunction, defining getZonesToReload, ..)
> > >> >
> > >> > In this point I would much prefer something like the
> > >> > partialTriggers-Attribute in trinidad.
> > >> >
> > >> > The thing is you have to define
> > >> > 1. which elements are to be reloaded by AJAX
> > >> > 2. which elements trigger those reloads
> > >> >
> > >> > I could also think of a listener-Component that can be added to the
> > >> > to-be-updated-elements and specify
> > >> > by which components those updates are triggered (which is pretty
> much
> > >> > the other way around compared to trinidad).
> > >> >
> > >> > I'm not yet completly shure whats the optimal approach for this,
> but
> > >> > I'll start with writing a s:panelGroup which
> > >> > supports a partialTriggers-Attribute that takes ids of
> radio-buttons
> > >> > (whith onchange="submit()"). For a start
> > >> > I will integrate this with AJAX-Anywhere to have something to try
> the
> > >> > different approches for the JSP-Part.
> > >> > Just for playing around whith it.
> > >> >
> > >> > If anyone is interested I'll try to make this online available once
> > >> I'm done.
> > >> >
> > >> > Suggestions, Objections, Ideas and advices are very welcome :-)
> > >> >
> > >> > regards
> > >> >
> > >> > Ernst
> > >> >
> > >> >
> > >> > On 6/15/06, Adam Winer <aw...@gmail.com> wrote:
> > >> > > I'd be thrilled!
> > >> > >
> > >> > > For background, PPR was developed back before XMLHttp existed.
> > >> > > Back then, the only decent way to communicate to the server was
> > >> > > via hidden iframes. That solution has *a lot* of problems - for
> > >> > > example, no decent way to handle errors, and the document that
> > >> > > comes back can get parsed as HTML, which leads to some ugliness
> > >> > > with handling Javascript, etc.. It was a great choice for the
> > >> time, but
> > >> > > it's showing its age, and there's better technologies
> > >> > >
> > >> > > Swapping out the client-side piece for an XMLHttpRequest-based
> > >> > > submission, with probably a few tweaks to the syntax delivered
> > >> > > by the PPR ResponseWriter, would give us a much more robust
> > >> > > solution, and would be a great isolated task. I'd be more than
> > >> > > happy to point anyone tackling this in the right directions.
> > >> > >
> > >> > > -- Adam
> > >> > >
> > >> > >
> > >> > > On 6/14/06, Martin Marinschek <ma...@gmail.com>
> wrote:
> > >> > > > Hi *,
> > >> > > >
> > >> > > > Ernst Fastl - in his SoC beginning review - has worked on
> > >> comparing the
> > >> > > > different PPR solutions so far. He's compared AjaxAnywhere, PPR
> > >> in Trinidad,
> > >> > > > and some of the Avatar approach.
> > >> > > >
> > >> > > > What he's come up with so far is that he really likes the
> > >> server-side
> > >> > > > integration of Trinidad, especially the syntax of integrating
> > >> it in the view
> > >> > > > definition - not so much the client-side portion of it for
> > >> doing PPR. Would
> > >> > > > you be happy with work being done on the client side portion of
> > >> the PPR
> > >> > > > interaction in Trinidad in the SoC project?
> > >> > > >
> > >> > > > regards,
> > >> > > >
> > >> > > > Martin
> > >> > > >
> > >> > > > --
> > >> > > >
> > >> > > > http://www.irian.at
> > >> > > >
> > >> > > > Your JSF powerhouse -
> > >> > > > JSF Consulting, Development and
> > >> > > > Courses in English and German
> > >> > > >
> > >> > > > Professional Support for Apache MyFaces
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >>
> > >> --
> > >> Matthias Wessendorf
> > >> Aechterhoek 18
> > >> 48282 Emsdetten
> > >> blog: http://jroller.com/page/mwessendorf
> > >> mail: mwessendorf-at-gmail-dot-com
> > >>
> > >
> > >
> >
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: PPR - client-side
Posted by Ernst Fastl <er...@gmail.com>.
Yes I'll be looking into the Avatar PPR solution as well, I'ver heard
that they have some pretty good ideas. I also like the Idea of
a onPartialRefresh javascript attribute (although it seems indeed a
bit early :-)
Regarding the question of AA dependencies, I'm not planning to use
this permanently, just to start with something for playing around
with new components that support attributes like partialTriggers,
or listener-components without having actually to implement the
client-side JS first. To make it clear I'm not suggesting to add
an AA dep in sandbox, we will want to have our own client-side
code don't we :-)
On 6/16/06, Rogers Reilly <ro...@s-rod.com> wrote:
> I'm not a contributor, but that approach sounds perfect to me. I've
> used PPR for a couple of projects now, and swapping out the iFrame
> client-side for dojo.bind would be a great improvement. Would give you
> async, for one; and obviously does away with custom JS.
>
> Another nice feature (I know it's early for requests :-) ) would be to
> allow an "onPartialRefresh" javascript attribute to any component that
> triggers PPR. From time to time, I find myself with a rather lengthy
> PPR request, and would like to do something on the client to indicate
> more content is loading (beyond the native browser "I'm loading"
> behavior), and then undo that something when the new PPR content shows
> up. The first part I can do with an "onClick" handler on the control
> (although an explicit "onPartialRequest" would be better), but the
> second part I can't, because the custom JS that displays the page isn't
> exposed. I'm figuring by the time I get around to digging into the
> existing Trinidad JS and exposing it myself (which, I'm sorry to say,
> falls somewhere below watching World Cup on TV on my to-do list), you
> might be done. :-)
>
> Also, on the subject of PPR, what is the scoop on Avatar? They seemed
> to have a PPR solution pegged pretty well in the JavaOne demo, and being
> cooked into JSF itself, it would seem like the preferred route--at least
> on the server side. I know Adam was part of that presentation ... is
> that stuff just too far off to be worth counting on for Trinidad PPR
> under JSF 1.2?
>
> -Rogers
>
> Ernst Fastl wrote:
>
> > Thanks for your ideas guys, and yes overworking the existing PPR in
> > Trinidad
> > to make the Client-Side-Code to use XMLHttp sounds good to me. The thing
> > is my Proposal for Google ist titled:
> >
> > "Implement AJAX Partial Page Rendering Support in Apache MyFaces"
> >
> >
> >
> > Since, if I understood it correctly, trinidad is now part of MyFaces
> > it should
> > be ok to work on that Code. But my original Idea was to compare the
> > Approaches of trinidad and AJAX Anywhere to find a solution for
> > MyFaces which combines advantages from Both.
> >
> > The AJAX-Anywhere based component in the sandbox ( not intended to be
> > commited
> > to MyFaces in this version) Is just to start "playing around" with PPR
> > in the tomahawk
> > library.
> >
> > I don't know if and when the component libraries of trinidad and
> > tomahawk are to be
> > merged, but I could think of implementing PPR in tomahawk reusing much of
> > the trinidad Server Side PPR Code and Reimplementing the Client Side Code
> > based on the existing AJAX Infrastructure in MyFaces (which I think
> > is using the DoJo-Library). Once this is finished this Client-Side
> > code may be
> > used to on the other side enhance the trinidad Client-Side Code. So in
> > the
> > end both Component libraries would benefit from each other.
> >
> > thoughts?
> > On 6/15/06, Matthias Wessendorf <ma...@apache.org> wrote:
> >
> >> Ernst,
> >>
> >> trying to get rid of all the custom JavaScript sounds very good. Don't
> >> like that too!
> >>
> >> Is the suggestion from Adam valuable for you?
> >> I think it should be better to *enhance* Trinidad's PPR instead of
> >> "creating" new PPR style components for the sandbox. Also not having a
> >> AA dependency sounds great, to me.
> >>
> >> I think enhancing an existing solution, or providing a new
> >> "architecture" should be fine with the SoC rules, right?
> >>
> >> -Matthias
> >>
> >> On 6/15/06, Ernst Fastl <er...@gmail.com> wrote:
> >> > Hi There!
> >> >
> >> > In the PPR-Implemetation I would rather like to avoid those iframes
> >> > and do it completly
> >> > with AJAX. The Client-Side Implementation of AJAY Anywhere seems
> >> > pretty much straight
> >> > forward to me. When using it together with MyFaces it works the
> >> following way:
> >> >
> >> > 1.) Defining Zones to reload in the jsp-file with the <aa:zoneJSF
> >> > id="x">-Component
> >> > those get rendered as <span>-tags with id="aazone.x"
> >> >
> >> > 2.) Define which zones are to be reloaded with AJAX-Calls by defining
> >> > a JS-Function:
> >> > getZonesToReload(url, submitButton)
> >> >
> >> > 3.) Substitute the submit-function of the main-Form to use
> >> submitAJAX instead
> >> >
> >> > 4.) if a button is pressed or a value changed that would lead to a
> >> > submit of the mainForm, submitAJAX checks based on getZonesToReload if
> >> > an AJAXRequest is to be done.
> >> > if not the form is submitted as usual.
> >> >
> >> > 5.)If it is an AJAX request a post-request is build with all
> >> > parameter/value pairs of the form
> >> > elements +
> >> > -aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper) its
> >> > an AJAX-Request
> >> > -aazones=id1,id2 - Tell which zones need to be updated
> >> >
> >> > 6.)If AAFilter on the Server side detects aaxmlrequest=true it parses
> >> > the HTML in the Response to extract the specified zones (big
> >> > disadvantage the whole component
> >> > tree gets rendered internally).
> >> >
> >> > 7.)HTML-Code of the zones is packed into xml-tags with the name of the
> >> > zones as attribute and send back to the client
> >> >
> >> > 8.)Client parses the response and sets element.innerHTML of the
> >> > zone-span-elements with the contents from the response
> >> >
> >> > What I like in this approach is the Javascript-Code that generates the
> >> > Post-Request and the Code that parses the
> >> > response and updates the DOM.
> >> >
> >> > The Server Side is pretty ugly. I would prefer to find a way to invoke
> >> > only the affected components which I think
> >> > should also make it faster. I haven't yet completly understood how
> >> > trinidad handles this, but I think they have
> >> > the cleaner solution for the server-side.
> >> >
> >> > What I also don't like is the JS-Code you have to write in your JSPs
> >> > (calling substitueSubmitFunction, defining getZonesToReload, ..)
> >> >
> >> > In this point I would much prefer something like the
> >> > partialTriggers-Attribute in trinidad.
> >> >
> >> > The thing is you have to define
> >> > 1. which elements are to be reloaded by AJAX
> >> > 2. which elements trigger those reloads
> >> >
> >> > I could also think of a listener-Component that can be added to the
> >> > to-be-updated-elements and specify
> >> > by which components those updates are triggered (which is pretty much
> >> > the other way around compared to trinidad).
> >> >
> >> > I'm not yet completly shure whats the optimal approach for this, but
> >> > I'll start with writing a s:panelGroup which
> >> > supports a partialTriggers-Attribute that takes ids of radio-buttons
> >> > (whith onchange="submit()"). For a start
> >> > I will integrate this with AJAX-Anywhere to have something to try the
> >> > different approches for the JSP-Part.
> >> > Just for playing around whith it.
> >> >
> >> > If anyone is interested I'll try to make this online available once
> >> I'm done.
> >> >
> >> > Suggestions, Objections, Ideas and advices are very welcome :-)
> >> >
> >> > regards
> >> >
> >> > Ernst
> >> >
> >> >
> >> > On 6/15/06, Adam Winer <aw...@gmail.com> wrote:
> >> > > I'd be thrilled!
> >> > >
> >> > > For background, PPR was developed back before XMLHttp existed.
> >> > > Back then, the only decent way to communicate to the server was
> >> > > via hidden iframes. That solution has *a lot* of problems - for
> >> > > example, no decent way to handle errors, and the document that
> >> > > comes back can get parsed as HTML, which leads to some ugliness
> >> > > with handling Javascript, etc.. It was a great choice for the
> >> time, but
> >> > > it's showing its age, and there's better technologies
> >> > >
> >> > > Swapping out the client-side piece for an XMLHttpRequest-based
> >> > > submission, with probably a few tweaks to the syntax delivered
> >> > > by the PPR ResponseWriter, would give us a much more robust
> >> > > solution, and would be a great isolated task. I'd be more than
> >> > > happy to point anyone tackling this in the right directions.
> >> > >
> >> > > -- Adam
> >> > >
> >> > >
> >> > > On 6/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> >> > > > Hi *,
> >> > > >
> >> > > > Ernst Fastl - in his SoC beginning review - has worked on
> >> comparing the
> >> > > > different PPR solutions so far. He's compared AjaxAnywhere, PPR
> >> in Trinidad,
> >> > > > and some of the Avatar approach.
> >> > > >
> >> > > > What he's come up with so far is that he really likes the
> >> server-side
> >> > > > integration of Trinidad, especially the syntax of integrating
> >> it in the view
> >> > > > definition - not so much the client-side portion of it for
> >> doing PPR. Would
> >> > > > you be happy with work being done on the client side portion of
> >> the PPR
> >> > > > interaction in Trinidad in the SoC project?
> >> > > >
> >> > > > regards,
> >> > > >
> >> > > > Martin
> >> > > >
> >> > > > --
> >> > > >
> >> > > > http://www.irian.at
> >> > > >
> >> > > > Your JSF powerhouse -
> >> > > > JSF Consulting, Development and
> >> > > > Courses in English and German
> >> > > >
> >> > > > Professional Support for Apache MyFaces
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >> Aechterhoek 18
> >> 48282 Emsdetten
> >> blog: http://jroller.com/page/mwessendorf
> >> mail: mwessendorf-at-gmail-dot-com
> >>
> >
> >
>
>
Re: PPR - client-side
Posted by Rogers Reilly <ro...@s-rod.com>.
I'm not a contributor, but that approach sounds perfect to me. I've
used PPR for a couple of projects now, and swapping out the iFrame
client-side for dojo.bind would be a great improvement. Would give you
async, for one; and obviously does away with custom JS.
Another nice feature (I know it's early for requests :-) ) would be to
allow an "onPartialRefresh" javascript attribute to any component that
triggers PPR. From time to time, I find myself with a rather lengthy
PPR request, and would like to do something on the client to indicate
more content is loading (beyond the native browser "I'm loading"
behavior), and then undo that something when the new PPR content shows
up. The first part I can do with an "onClick" handler on the control
(although an explicit "onPartialRequest" would be better), but the
second part I can't, because the custom JS that displays the page isn't
exposed. I'm figuring by the time I get around to digging into the
existing Trinidad JS and exposing it myself (which, I'm sorry to say,
falls somewhere below watching World Cup on TV on my to-do list), you
might be done. :-)
Also, on the subject of PPR, what is the scoop on Avatar? They seemed
to have a PPR solution pegged pretty well in the JavaOne demo, and being
cooked into JSF itself, it would seem like the preferred route--at least
on the server side. I know Adam was part of that presentation ... is
that stuff just too far off to be worth counting on for Trinidad PPR
under JSF 1.2?
-Rogers
Ernst Fastl wrote:
> Thanks for your ideas guys, and yes overworking the existing PPR in
> Trinidad
> to make the Client-Side-Code to use XMLHttp sounds good to me. The thing
> is my Proposal for Google ist titled:
>
> "Implement AJAX Partial Page Rendering Support in Apache MyFaces"
>
>
>
> Since, if I understood it correctly, trinidad is now part of MyFaces
> it should
> be ok to work on that Code. But my original Idea was to compare the
> Approaches of trinidad and AJAX Anywhere to find a solution for
> MyFaces which combines advantages from Both.
>
> The AJAX-Anywhere based component in the sandbox ( not intended to be
> commited
> to MyFaces in this version) Is just to start "playing around" with PPR
> in the tomahawk
> library.
>
> I don't know if and when the component libraries of trinidad and
> tomahawk are to be
> merged, but I could think of implementing PPR in tomahawk reusing much of
> the trinidad Server Side PPR Code and Reimplementing the Client Side Code
> based on the existing AJAX Infrastructure in MyFaces (which I think
> is using the DoJo-Library). Once this is finished this Client-Side
> code may be
> used to on the other side enhance the trinidad Client-Side Code. So in
> the
> end both Component libraries would benefit from each other.
>
> thoughts?
> On 6/15/06, Matthias Wessendorf <ma...@apache.org> wrote:
>
>> Ernst,
>>
>> trying to get rid of all the custom JavaScript sounds very good. Don't
>> like that too!
>>
>> Is the suggestion from Adam valuable for you?
>> I think it should be better to *enhance* Trinidad's PPR instead of
>> "creating" new PPR style components for the sandbox. Also not having a
>> AA dependency sounds great, to me.
>>
>> I think enhancing an existing solution, or providing a new
>> "architecture" should be fine with the SoC rules, right?
>>
>> -Matthias
>>
>> On 6/15/06, Ernst Fastl <er...@gmail.com> wrote:
>> > Hi There!
>> >
>> > In the PPR-Implemetation I would rather like to avoid those iframes
>> > and do it completly
>> > with AJAX. The Client-Side Implementation of AJAY Anywhere seems
>> > pretty much straight
>> > forward to me. When using it together with MyFaces it works the
>> following way:
>> >
>> > 1.) Defining Zones to reload in the jsp-file with the <aa:zoneJSF
>> > id="x">-Component
>> > those get rendered as <span>-tags with id="aazone.x"
>> >
>> > 2.) Define which zones are to be reloaded with AJAX-Calls by defining
>> > a JS-Function:
>> > getZonesToReload(url, submitButton)
>> >
>> > 3.) Substitute the submit-function of the main-Form to use
>> submitAJAX instead
>> >
>> > 4.) if a button is pressed or a value changed that would lead to a
>> > submit of the mainForm, submitAJAX checks based on getZonesToReload if
>> > an AJAXRequest is to be done.
>> > if not the form is submitted as usual.
>> >
>> > 5.)If it is an AJAX request a post-request is build with all
>> > parameter/value pairs of the form
>> > elements +
>> > -aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper) its
>> > an AJAX-Request
>> > -aazones=id1,id2 - Tell which zones need to be updated
>> >
>> > 6.)If AAFilter on the Server side detects aaxmlrequest=true it parses
>> > the HTML in the Response to extract the specified zones (big
>> > disadvantage the whole component
>> > tree gets rendered internally).
>> >
>> > 7.)HTML-Code of the zones is packed into xml-tags with the name of the
>> > zones as attribute and send back to the client
>> >
>> > 8.)Client parses the response and sets element.innerHTML of the
>> > zone-span-elements with the contents from the response
>> >
>> > What I like in this approach is the Javascript-Code that generates the
>> > Post-Request and the Code that parses the
>> > response and updates the DOM.
>> >
>> > The Server Side is pretty ugly. I would prefer to find a way to invoke
>> > only the affected components which I think
>> > should also make it faster. I haven't yet completly understood how
>> > trinidad handles this, but I think they have
>> > the cleaner solution for the server-side.
>> >
>> > What I also don't like is the JS-Code you have to write in your JSPs
>> > (calling substitueSubmitFunction, defining getZonesToReload, ..)
>> >
>> > In this point I would much prefer something like the
>> > partialTriggers-Attribute in trinidad.
>> >
>> > The thing is you have to define
>> > 1. which elements are to be reloaded by AJAX
>> > 2. which elements trigger those reloads
>> >
>> > I could also think of a listener-Component that can be added to the
>> > to-be-updated-elements and specify
>> > by which components those updates are triggered (which is pretty much
>> > the other way around compared to trinidad).
>> >
>> > I'm not yet completly shure whats the optimal approach for this, but
>> > I'll start with writing a s:panelGroup which
>> > supports a partialTriggers-Attribute that takes ids of radio-buttons
>> > (whith onchange="submit()"). For a start
>> > I will integrate this with AJAX-Anywhere to have something to try the
>> > different approches for the JSP-Part.
>> > Just for playing around whith it.
>> >
>> > If anyone is interested I'll try to make this online available once
>> I'm done.
>> >
>> > Suggestions, Objections, Ideas and advices are very welcome :-)
>> >
>> > regards
>> >
>> > Ernst
>> >
>> >
>> > On 6/15/06, Adam Winer <aw...@gmail.com> wrote:
>> > > I'd be thrilled!
>> > >
>> > > For background, PPR was developed back before XMLHttp existed.
>> > > Back then, the only decent way to communicate to the server was
>> > > via hidden iframes. That solution has *a lot* of problems - for
>> > > example, no decent way to handle errors, and the document that
>> > > comes back can get parsed as HTML, which leads to some ugliness
>> > > with handling Javascript, etc.. It was a great choice for the
>> time, but
>> > > it's showing its age, and there's better technologies
>> > >
>> > > Swapping out the client-side piece for an XMLHttpRequest-based
>> > > submission, with probably a few tweaks to the syntax delivered
>> > > by the PPR ResponseWriter, would give us a much more robust
>> > > solution, and would be a great isolated task. I'd be more than
>> > > happy to point anyone tackling this in the right directions.
>> > >
>> > > -- Adam
>> > >
>> > >
>> > > On 6/14/06, Martin Marinschek <ma...@gmail.com> wrote:
>> > > > Hi *,
>> > > >
>> > > > Ernst Fastl - in his SoC beginning review - has worked on
>> comparing the
>> > > > different PPR solutions so far. He's compared AjaxAnywhere, PPR
>> in Trinidad,
>> > > > and some of the Avatar approach.
>> > > >
>> > > > What he's come up with so far is that he really likes the
>> server-side
>> > > > integration of Trinidad, especially the syntax of integrating
>> it in the view
>> > > > definition - not so much the client-side portion of it for
>> doing PPR. Would
>> > > > you be happy with work being done on the client side portion of
>> the PPR
>> > > > interaction in Trinidad in the SoC project?
>> > > >
>> > > > regards,
>> > > >
>> > > > Martin
>> > > >
>> > > > --
>> > > >
>> > > > http://www.irian.at
>> > > >
>> > > > Your JSF powerhouse -
>> > > > JSF Consulting, Development and
>> > > > Courses in English and German
>> > > >
>> > > > Professional Support for Apache MyFaces
>> > > >
>> > > >
>> > >
>> >
>>
>>
>> --
>> Matthias Wessendorf
>> Aechterhoek 18
>> 48282 Emsdetten
>> blog: http://jroller.com/page/mwessendorf
>> mail: mwessendorf-at-gmail-dot-com
>>
>
>
Re: PPR - client-side
Posted by Matthias Wessendorf <ma...@apache.org>.
> Trinidad is incubation phase yet. Means, when is succeeds it will be a
> subproject of MyFaces, like Tomahawk or Tobago is today.
To be clear. MyFaces' PMC is the sponsor of Trinidad.
So there is a relation to MyFaces, even Trinidad is an incubating project ;)
Should be ok for your Google SoC thing ;)
> there is one w/ AA dep in sandbox?
...
> or just temporary on your box ?
nevermind.
-Matthias
> > I don't know if and when the component libraries of trinidad and
> > tomahawk are to be merged,
>
> there are some guys we definitly want to merge.
> You can use the TODO list ([1]) to add some of these guys.
>
> > but I could think of implementing PPR in tomahawk reusing much of
> > the trinidad Server Side PPR Code and Reimplementing the Client Side Code
> > based on the existing AJAX Infrastructure in MyFaces (which I think
> > is using the DoJo-Library). Once this is finished this Client-Side code may be
> > used to on the other side enhance the trinidad Client-Side Code. So in the
> > end both Component libraries would benefit from each other.
>
> what about going the Trinidad route and using it inside Tomahawk ?
> Like reimplementing/enhancing their code. You can use it in Tomahawk afterwards.
> Today it is possible to use both Trinidad and Tomahawk.
>
> So for me it makes sense to go that route. Just my $0.02
>
> -Matthias
>
> > thoughts?
> > On 6/15/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > Ernst,
> > >
> > > trying to get rid of all the custom JavaScript sounds very good. Don't
> > > like that too!
> > >
> > > Is the suggestion from Adam valuable for you?
> > > I think it should be better to *enhance* Trinidad's PPR instead of
> > > "creating" new PPR style components for the sandbox. Also not having a
> > > AA dependency sounds great, to me.
> > >
> > > I think enhancing an existing solution, or providing a new
> > > "architecture" should be fine with the SoC rules, right?
> > >
> > > -Matthias
> > >
> > > On 6/15/06, Ernst Fastl <er...@gmail.com> wrote:
> > > > Hi There!
> > > >
> > > > In the PPR-Implemetation I would rather like to avoid those iframes
> > > > and do it completly
> > > > with AJAX. The Client-Side Implementation of AJAY Anywhere seems
> > > > pretty much straight
> > > > forward to me. When using it together with MyFaces it works the following way:
> > > >
> > > > 1.) Defining Zones to reload in the jsp-file with the <aa:zoneJSF
> > > > id="x">-Component
> > > > those get rendered as <span>-tags with id="aazone.x"
> > > >
> > > > 2.) Define which zones are to be reloaded with AJAX-Calls by defining
> > > > a JS-Function:
> > > > getZonesToReload(url, submitButton)
> > > >
> > > > 3.) Substitute the submit-function of the main-Form to use submitAJAX instead
> > > >
> > > > 4.) if a button is pressed or a value changed that would lead to a
> > > > submit of the mainForm, submitAJAX checks based on getZonesToReload if
> > > > an AJAXRequest is to be done.
> > > > if not the form is submitted as usual.
> > > >
> > > > 5.)If it is an AJAX request a post-request is build with all
> > > > parameter/value pairs of the form
> > > > elements +
> > > > -aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper) its
> > > > an AJAX-Request
> > > > -aazones=id1,id2 - Tell which zones need to be updated
> > > >
> > > > 6.)If AAFilter on the Server side detects aaxmlrequest=true it parses
> > > > the HTML in the Response to extract the specified zones (big
> > > > disadvantage the whole component
> > > > tree gets rendered internally).
> > > >
> > > > 7.)HTML-Code of the zones is packed into xml-tags with the name of the
> > > > zones as attribute and send back to the client
> > > >
> > > > 8.)Client parses the response and sets element.innerHTML of the
> > > > zone-span-elements with the contents from the response
> > > >
> > > > What I like in this approach is the Javascript-Code that generates the
> > > > Post-Request and the Code that parses the
> > > > response and updates the DOM.
> > > >
> > > > The Server Side is pretty ugly. I would prefer to find a way to invoke
> > > > only the affected components which I think
> > > > should also make it faster. I haven't yet completly understood how
> > > > trinidad handles this, but I think they have
> > > > the cleaner solution for the server-side.
> > > >
> > > > What I also don't like is the JS-Code you have to write in your JSPs
> > > > (calling substitueSubmitFunction, defining getZonesToReload, ..)
> > > >
> > > > In this point I would much prefer something like the
> > > > partialTriggers-Attribute in trinidad.
> > > >
> > > > The thing is you have to define
> > > > 1. which elements are to be reloaded by AJAX
> > > > 2. which elements trigger those reloads
> > > >
> > > > I could also think of a listener-Component that can be added to the
> > > > to-be-updated-elements and specify
> > > > by which components those updates are triggered (which is pretty much
> > > > the other way around compared to trinidad).
> > > >
> > > > I'm not yet completly shure whats the optimal approach for this, but
> > > > I'll start with writing a s:panelGroup which
> > > > supports a partialTriggers-Attribute that takes ids of radio-buttons
> > > > (whith onchange="submit()"). For a start
> > > > I will integrate this with AJAX-Anywhere to have something to try the
> > > > different approches for the JSP-Part.
> > > > Just for playing around whith it.
> > > >
> > > > If anyone is interested I'll try to make this online available once I'm done.
> > > >
> > > > Suggestions, Objections, Ideas and advices are very welcome :-)
> > > >
> > > > regards
> > > >
> > > > Ernst
> > > >
> > > >
> > > > On 6/15/06, Adam Winer <aw...@gmail.com> wrote:
> > > > > I'd be thrilled!
> > > > >
> > > > > For background, PPR was developed back before XMLHttp existed.
> > > > > Back then, the only decent way to communicate to the server was
> > > > > via hidden iframes. That solution has *a lot* of problems - for
> > > > > example, no decent way to handle errors, and the document that
> > > > > comes back can get parsed as HTML, which leads to some ugliness
> > > > > with handling Javascript, etc.. It was a great choice for the time, but
> > > > > it's showing its age, and there's better technologies
> > > > >
> > > > > Swapping out the client-side piece for an XMLHttpRequest-based
> > > > > submission, with probably a few tweaks to the syntax delivered
> > > > > by the PPR ResponseWriter, would give us a much more robust
> > > > > solution, and would be a great isolated task. I'd be more than
> > > > > happy to point anyone tackling this in the right directions.
> > > > >
> > > > > -- Adam
> > > > >
> > > > >
> > > > > On 6/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > > > > Hi *,
> > > > > >
> > > > > > Ernst Fastl - in his SoC beginning review - has worked on comparing the
> > > > > > different PPR solutions so far. He's compared AjaxAnywhere, PPR in Trinidad,
> > > > > > and some of the Avatar approach.
> > > > > >
> > > > > > What he's come up with so far is that he really likes the server-side
> > > > > > integration of Trinidad, especially the syntax of integrating it in the view
> > > > > > definition - not so much the client-side portion of it for doing PPR. Would
> > > > > > you be happy with work being done on the client side portion of the PPR
> > > > > > interaction in Trinidad in the SoC project?
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > --
> > > > > >
> > > > > > http://www.irian.at
> > > > > >
> > > > > > Your JSF powerhouse -
> > > > > > JSF Consulting, Development and
> > > > > > Courses in English and German
> > > > > >
> > > > > > Professional Support for Apache MyFaces
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > > Aechterhoek 18
> > > 48282 Emsdetten
> > > blog: http://jroller.com/page/mwessendorf
> > > mail: mwessendorf-at-gmail-dot-com
> > >
> >
>
>
> --
> Matthias Wessendorf
> Aechterhoek 18
> 48282 Emsdetten
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: PPR - client-side
Posted by Matthias Wessendorf <ma...@apache.org>.
> Since, if I understood it correctly, trinidad is now part of MyFaces it should
> be ok to work on that Code. But my original Idea was to compare the
> Approaches of trinidad and AJAX Anywhere to find a solution for
> MyFaces which combines advantages from Both.
Trinidad is incubation phase yet. Means, when is succeeds it will be a
subproject of MyFaces, like Tomahawk or Tobago is today.
> The AJAX-Anywhere based component in the sandbox ( not intended to be commited
there is one w/ AA dep in sandbox?
> to MyFaces in this version) Is just to start "playing around" with PPR
> in the tomahawk
> library.
or just temporary on your box ?
> I don't know if and when the component libraries of trinidad and
> tomahawk are to be merged,
there are some guys we definitly want to merge.
You can use the TODO list ([1]) to add some of these guys.
> but I could think of implementing PPR in tomahawk reusing much of
> the trinidad Server Side PPR Code and Reimplementing the Client Side Code
> based on the existing AJAX Infrastructure in MyFaces (which I think
> is using the DoJo-Library). Once this is finished this Client-Side code may be
> used to on the other side enhance the trinidad Client-Side Code. So in the
> end both Component libraries would benefit from each other.
what about going the Trinidad route and using it inside Tomahawk ?
Like reimplementing/enhancing their code. You can use it in Tomahawk afterwards.
Today it is possible to use both Trinidad and Tomahawk.
So for me it makes sense to go that route. Just my $0.02
-Matthias
> thoughts?
> On 6/15/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > Ernst,
> >
> > trying to get rid of all the custom JavaScript sounds very good. Don't
> > like that too!
> >
> > Is the suggestion from Adam valuable for you?
> > I think it should be better to *enhance* Trinidad's PPR instead of
> > "creating" new PPR style components for the sandbox. Also not having a
> > AA dependency sounds great, to me.
> >
> > I think enhancing an existing solution, or providing a new
> > "architecture" should be fine with the SoC rules, right?
> >
> > -Matthias
> >
> > On 6/15/06, Ernst Fastl <er...@gmail.com> wrote:
> > > Hi There!
> > >
> > > In the PPR-Implemetation I would rather like to avoid those iframes
> > > and do it completly
> > > with AJAX. The Client-Side Implementation of AJAY Anywhere seems
> > > pretty much straight
> > > forward to me. When using it together with MyFaces it works the following way:
> > >
> > > 1.) Defining Zones to reload in the jsp-file with the <aa:zoneJSF
> > > id="x">-Component
> > > those get rendered as <span>-tags with id="aazone.x"
> > >
> > > 2.) Define which zones are to be reloaded with AJAX-Calls by defining
> > > a JS-Function:
> > > getZonesToReload(url, submitButton)
> > >
> > > 3.) Substitute the submit-function of the main-Form to use submitAJAX instead
> > >
> > > 4.) if a button is pressed or a value changed that would lead to a
> > > submit of the mainForm, submitAJAX checks based on getZonesToReload if
> > > an AJAXRequest is to be done.
> > > if not the form is submitted as usual.
> > >
> > > 5.)If it is an AJAX request a post-request is build with all
> > > parameter/value pairs of the form
> > > elements +
> > > -aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper) its
> > > an AJAX-Request
> > > -aazones=id1,id2 - Tell which zones need to be updated
> > >
> > > 6.)If AAFilter on the Server side detects aaxmlrequest=true it parses
> > > the HTML in the Response to extract the specified zones (big
> > > disadvantage the whole component
> > > tree gets rendered internally).
> > >
> > > 7.)HTML-Code of the zones is packed into xml-tags with the name of the
> > > zones as attribute and send back to the client
> > >
> > > 8.)Client parses the response and sets element.innerHTML of the
> > > zone-span-elements with the contents from the response
> > >
> > > What I like in this approach is the Javascript-Code that generates the
> > > Post-Request and the Code that parses the
> > > response and updates the DOM.
> > >
> > > The Server Side is pretty ugly. I would prefer to find a way to invoke
> > > only the affected components which I think
> > > should also make it faster. I haven't yet completly understood how
> > > trinidad handles this, but I think they have
> > > the cleaner solution for the server-side.
> > >
> > > What I also don't like is the JS-Code you have to write in your JSPs
> > > (calling substitueSubmitFunction, defining getZonesToReload, ..)
> > >
> > > In this point I would much prefer something like the
> > > partialTriggers-Attribute in trinidad.
> > >
> > > The thing is you have to define
> > > 1. which elements are to be reloaded by AJAX
> > > 2. which elements trigger those reloads
> > >
> > > I could also think of a listener-Component that can be added to the
> > > to-be-updated-elements and specify
> > > by which components those updates are triggered (which is pretty much
> > > the other way around compared to trinidad).
> > >
> > > I'm not yet completly shure whats the optimal approach for this, but
> > > I'll start with writing a s:panelGroup which
> > > supports a partialTriggers-Attribute that takes ids of radio-buttons
> > > (whith onchange="submit()"). For a start
> > > I will integrate this with AJAX-Anywhere to have something to try the
> > > different approches for the JSP-Part.
> > > Just for playing around whith it.
> > >
> > > If anyone is interested I'll try to make this online available once I'm done.
> > >
> > > Suggestions, Objections, Ideas and advices are very welcome :-)
> > >
> > > regards
> > >
> > > Ernst
> > >
> > >
> > > On 6/15/06, Adam Winer <aw...@gmail.com> wrote:
> > > > I'd be thrilled!
> > > >
> > > > For background, PPR was developed back before XMLHttp existed.
> > > > Back then, the only decent way to communicate to the server was
> > > > via hidden iframes. That solution has *a lot* of problems - for
> > > > example, no decent way to handle errors, and the document that
> > > > comes back can get parsed as HTML, which leads to some ugliness
> > > > with handling Javascript, etc.. It was a great choice for the time, but
> > > > it's showing its age, and there's better technologies
> > > >
> > > > Swapping out the client-side piece for an XMLHttpRequest-based
> > > > submission, with probably a few tweaks to the syntax delivered
> > > > by the PPR ResponseWriter, would give us a much more robust
> > > > solution, and would be a great isolated task. I'd be more than
> > > > happy to point anyone tackling this in the right directions.
> > > >
> > > > -- Adam
> > > >
> > > >
> > > > On 6/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > > > Hi *,
> > > > >
> > > > > Ernst Fastl - in his SoC beginning review - has worked on comparing the
> > > > > different PPR solutions so far. He's compared AjaxAnywhere, PPR in Trinidad,
> > > > > and some of the Avatar approach.
> > > > >
> > > > > What he's come up with so far is that he really likes the server-side
> > > > > integration of Trinidad, especially the syntax of integrating it in the view
> > > > > definition - not so much the client-side portion of it for doing PPR. Would
> > > > > you be happy with work being done on the client side portion of the PPR
> > > > > interaction in Trinidad in the SoC project?
> > > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > > >
> > > > > --
> > > > >
> > > > > http://www.irian.at
> > > > >
> > > > > Your JSF powerhouse -
> > > > > JSF Consulting, Development and
> > > > > Courses in English and German
> > > > >
> > > > > Professional Support for Apache MyFaces
> > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> > Aechterhoek 18
> > 48282 Emsdetten
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: PPR - client-side
Posted by Ernst Fastl <er...@gmail.com>.
Thanks for your ideas guys, and yes overworking the existing PPR in Trinidad
to make the Client-Side-Code to use XMLHttp sounds good to me. The thing
is my Proposal for Google ist titled:
"Implement AJAX Partial Page Rendering Support in Apache MyFaces"
Since, if I understood it correctly, trinidad is now part of MyFaces it should
be ok to work on that Code. But my original Idea was to compare the
Approaches of trinidad and AJAX Anywhere to find a solution for
MyFaces which combines advantages from Both.
The AJAX-Anywhere based component in the sandbox ( not intended to be commited
to MyFaces in this version) Is just to start "playing around" with PPR
in the tomahawk
library.
I don't know if and when the component libraries of trinidad and
tomahawk are to be
merged, but I could think of implementing PPR in tomahawk reusing much of
the trinidad Server Side PPR Code and Reimplementing the Client Side Code
based on the existing AJAX Infrastructure in MyFaces (which I think
is using the DoJo-Library). Once this is finished this Client-Side code may be
used to on the other side enhance the trinidad Client-Side Code. So in the
end both Component libraries would benefit from each other.
thoughts?
On 6/15/06, Matthias Wessendorf <ma...@apache.org> wrote:
> Ernst,
>
> trying to get rid of all the custom JavaScript sounds very good. Don't
> like that too!
>
> Is the suggestion from Adam valuable for you?
> I think it should be better to *enhance* Trinidad's PPR instead of
> "creating" new PPR style components for the sandbox. Also not having a
> AA dependency sounds great, to me.
>
> I think enhancing an existing solution, or providing a new
> "architecture" should be fine with the SoC rules, right?
>
> -Matthias
>
> On 6/15/06, Ernst Fastl <er...@gmail.com> wrote:
> > Hi There!
> >
> > In the PPR-Implemetation I would rather like to avoid those iframes
> > and do it completly
> > with AJAX. The Client-Side Implementation of AJAY Anywhere seems
> > pretty much straight
> > forward to me. When using it together with MyFaces it works the following way:
> >
> > 1.) Defining Zones to reload in the jsp-file with the <aa:zoneJSF
> > id="x">-Component
> > those get rendered as <span>-tags with id="aazone.x"
> >
> > 2.) Define which zones are to be reloaded with AJAX-Calls by defining
> > a JS-Function:
> > getZonesToReload(url, submitButton)
> >
> > 3.) Substitute the submit-function of the main-Form to use submitAJAX instead
> >
> > 4.) if a button is pressed or a value changed that would lead to a
> > submit of the mainForm, submitAJAX checks based on getZonesToReload if
> > an AJAXRequest is to be done.
> > if not the form is submitted as usual.
> >
> > 5.)If it is an AJAX request a post-request is build with all
> > parameter/value pairs of the form
> > elements +
> > -aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper) its
> > an AJAX-Request
> > -aazones=id1,id2 - Tell which zones need to be updated
> >
> > 6.)If AAFilter on the Server side detects aaxmlrequest=true it parses
> > the HTML in the Response to extract the specified zones (big
> > disadvantage the whole component
> > tree gets rendered internally).
> >
> > 7.)HTML-Code of the zones is packed into xml-tags with the name of the
> > zones as attribute and send back to the client
> >
> > 8.)Client parses the response and sets element.innerHTML of the
> > zone-span-elements with the contents from the response
> >
> > What I like in this approach is the Javascript-Code that generates the
> > Post-Request and the Code that parses the
> > response and updates the DOM.
> >
> > The Server Side is pretty ugly. I would prefer to find a way to invoke
> > only the affected components which I think
> > should also make it faster. I haven't yet completly understood how
> > trinidad handles this, but I think they have
> > the cleaner solution for the server-side.
> >
> > What I also don't like is the JS-Code you have to write in your JSPs
> > (calling substitueSubmitFunction, defining getZonesToReload, ..)
> >
> > In this point I would much prefer something like the
> > partialTriggers-Attribute in trinidad.
> >
> > The thing is you have to define
> > 1. which elements are to be reloaded by AJAX
> > 2. which elements trigger those reloads
> >
> > I could also think of a listener-Component that can be added to the
> > to-be-updated-elements and specify
> > by which components those updates are triggered (which is pretty much
> > the other way around compared to trinidad).
> >
> > I'm not yet completly shure whats the optimal approach for this, but
> > I'll start with writing a s:panelGroup which
> > supports a partialTriggers-Attribute that takes ids of radio-buttons
> > (whith onchange="submit()"). For a start
> > I will integrate this with AJAX-Anywhere to have something to try the
> > different approches for the JSP-Part.
> > Just for playing around whith it.
> >
> > If anyone is interested I'll try to make this online available once I'm done.
> >
> > Suggestions, Objections, Ideas and advices are very welcome :-)
> >
> > regards
> >
> > Ernst
> >
> >
> > On 6/15/06, Adam Winer <aw...@gmail.com> wrote:
> > > I'd be thrilled!
> > >
> > > For background, PPR was developed back before XMLHttp existed.
> > > Back then, the only decent way to communicate to the server was
> > > via hidden iframes. That solution has *a lot* of problems - for
> > > example, no decent way to handle errors, and the document that
> > > comes back can get parsed as HTML, which leads to some ugliness
> > > with handling Javascript, etc.. It was a great choice for the time, but
> > > it's showing its age, and there's better technologies
> > >
> > > Swapping out the client-side piece for an XMLHttpRequest-based
> > > submission, with probably a few tweaks to the syntax delivered
> > > by the PPR ResponseWriter, would give us a much more robust
> > > solution, and would be a great isolated task. I'd be more than
> > > happy to point anyone tackling this in the right directions.
> > >
> > > -- Adam
> > >
> > >
> > > On 6/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > > Hi *,
> > > >
> > > > Ernst Fastl - in his SoC beginning review - has worked on comparing the
> > > > different PPR solutions so far. He's compared AjaxAnywhere, PPR in Trinidad,
> > > > and some of the Avatar approach.
> > > >
> > > > What he's come up with so far is that he really likes the server-side
> > > > integration of Trinidad, especially the syntax of integrating it in the view
> > > > definition - not so much the client-side portion of it for doing PPR. Would
> > > > you be happy with work being done on the client side portion of the PPR
> > > > interaction in Trinidad in the SoC project?
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > --
> > > >
> > > > http://www.irian.at
> > > >
> > > > Your JSF powerhouse -
> > > > JSF Consulting, Development and
> > > > Courses in English and German
> > > >
> > > > Professional Support for Apache MyFaces
> > > >
> > > >
> > >
> >
>
>
> --
> Matthias Wessendorf
> Aechterhoek 18
> 48282 Emsdetten
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
Re: PPR - client-side
Posted by Ernst Fastl <er...@gmail.com>.
Thanks for your ideas guys, and yes overworking the existing PPR in Trinidad
to make the Client-Side-Code to use XMLHttp sounds good to me. The thing
is my Proposal for Google ist titled:
"Implement AJAX Partial Page Rendering Support in Apache MyFaces"
Since, if I understood it correctly, trinidad is now part of MyFaces it should
be ok to work on that Code. But my original Idea was to compare the
Approaches of trinidad and AJAX Anywhere to find a solution for
MyFaces which combines advantages from Both.
The AJAX-Anywhere based component in the sandbox ( not intended to be commited
to MyFaces in this version) Is just to start "playing around" with PPR
in the tomahawk
library.
I don't know if and when the component libraries of trinidad and
tomahawk are to be
merged, but I could think of implementing PPR in tomahawk reusing much of
the trinidad Server Side PPR Code and Reimplementing the Client Side Code
based on the existing AJAX Infrastructure in MyFaces (which I think
is using the DoJo-Library). Once this is finished this Client-Side code may be
used to on the other side enhance the trinidad Client-Side Code. So in the
end both Component libraries would benefit from each other.
thoughts?
On 6/15/06, Matthias Wessendorf <ma...@apache.org> wrote:
> Ernst,
>
> trying to get rid of all the custom JavaScript sounds very good. Don't
> like that too!
>
> Is the suggestion from Adam valuable for you?
> I think it should be better to *enhance* Trinidad's PPR instead of
> "creating" new PPR style components for the sandbox. Also not having a
> AA dependency sounds great, to me.
>
> I think enhancing an existing solution, or providing a new
> "architecture" should be fine with the SoC rules, right?
>
> -Matthias
>
> On 6/15/06, Ernst Fastl <er...@gmail.com> wrote:
> > Hi There!
> >
> > In the PPR-Implemetation I would rather like to avoid those iframes
> > and do it completly
> > with AJAX. The Client-Side Implementation of AJAY Anywhere seems
> > pretty much straight
> > forward to me. When using it together with MyFaces it works the following way:
> >
> > 1.) Defining Zones to reload in the jsp-file with the <aa:zoneJSF
> > id="x">-Component
> > those get rendered as <span>-tags with id="aazone.x"
> >
> > 2.) Define which zones are to be reloaded with AJAX-Calls by defining
> > a JS-Function:
> > getZonesToReload(url, submitButton)
> >
> > 3.) Substitute the submit-function of the main-Form to use submitAJAX instead
> >
> > 4.) if a button is pressed or a value changed that would lead to a
> > submit of the mainForm, submitAJAX checks based on getZonesToReload if
> > an AJAXRequest is to be done.
> > if not the form is submitted as usual.
> >
> > 5.)If it is an AJAX request a post-request is build with all
> > parameter/value pairs of the form
> > elements +
> > -aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper) its
> > an AJAX-Request
> > -aazones=id1,id2 - Tell which zones need to be updated
> >
> > 6.)If AAFilter on the Server side detects aaxmlrequest=true it parses
> > the HTML in the Response to extract the specified zones (big
> > disadvantage the whole component
> > tree gets rendered internally).
> >
> > 7.)HTML-Code of the zones is packed into xml-tags with the name of the
> > zones as attribute and send back to the client
> >
> > 8.)Client parses the response and sets element.innerHTML of the
> > zone-span-elements with the contents from the response
> >
> > What I like in this approach is the Javascript-Code that generates the
> > Post-Request and the Code that parses the
> > response and updates the DOM.
> >
> > The Server Side is pretty ugly. I would prefer to find a way to invoke
> > only the affected components which I think
> > should also make it faster. I haven't yet completly understood how
> > trinidad handles this, but I think they have
> > the cleaner solution for the server-side.
> >
> > What I also don't like is the JS-Code you have to write in your JSPs
> > (calling substitueSubmitFunction, defining getZonesToReload, ..)
> >
> > In this point I would much prefer something like the
> > partialTriggers-Attribute in trinidad.
> >
> > The thing is you have to define
> > 1. which elements are to be reloaded by AJAX
> > 2. which elements trigger those reloads
> >
> > I could also think of a listener-Component that can be added to the
> > to-be-updated-elements and specify
> > by which components those updates are triggered (which is pretty much
> > the other way around compared to trinidad).
> >
> > I'm not yet completly shure whats the optimal approach for this, but
> > I'll start with writing a s:panelGroup which
> > supports a partialTriggers-Attribute that takes ids of radio-buttons
> > (whith onchange="submit()"). For a start
> > I will integrate this with AJAX-Anywhere to have something to try the
> > different approches for the JSP-Part.
> > Just for playing around whith it.
> >
> > If anyone is interested I'll try to make this online available once I'm done.
> >
> > Suggestions, Objections, Ideas and advices are very welcome :-)
> >
> > regards
> >
> > Ernst
> >
> >
> > On 6/15/06, Adam Winer <aw...@gmail.com> wrote:
> > > I'd be thrilled!
> > >
> > > For background, PPR was developed back before XMLHttp existed.
> > > Back then, the only decent way to communicate to the server was
> > > via hidden iframes. That solution has *a lot* of problems - for
> > > example, no decent way to handle errors, and the document that
> > > comes back can get parsed as HTML, which leads to some ugliness
> > > with handling Javascript, etc.. It was a great choice for the time, but
> > > it's showing its age, and there's better technologies
> > >
> > > Swapping out the client-side piece for an XMLHttpRequest-based
> > > submission, with probably a few tweaks to the syntax delivered
> > > by the PPR ResponseWriter, would give us a much more robust
> > > solution, and would be a great isolated task. I'd be more than
> > > happy to point anyone tackling this in the right directions.
> > >
> > > -- Adam
> > >
> > >
> > > On 6/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > > Hi *,
> > > >
> > > > Ernst Fastl - in his SoC beginning review - has worked on comparing the
> > > > different PPR solutions so far. He's compared AjaxAnywhere, PPR in Trinidad,
> > > > and some of the Avatar approach.
> > > >
> > > > What he's come up with so far is that he really likes the server-side
> > > > integration of Trinidad, especially the syntax of integrating it in the view
> > > > definition - not so much the client-side portion of it for doing PPR. Would
> > > > you be happy with work being done on the client side portion of the PPR
> > > > interaction in Trinidad in the SoC project?
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > --
> > > >
> > > > http://www.irian.at
> > > >
> > > > Your JSF powerhouse -
> > > > JSF Consulting, Development and
> > > > Courses in English and German
> > > >
> > > > Professional Support for Apache MyFaces
> > > >
> > > >
> > >
> >
>
>
> --
> Matthias Wessendorf
> Aechterhoek 18
> 48282 Emsdetten
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
Re: PPR - client-side
Posted by Matthias Wessendorf <ma...@apache.org>.
Ernst,
trying to get rid of all the custom JavaScript sounds very good. Don't
like that too!
Is the suggestion from Adam valuable for you?
I think it should be better to *enhance* Trinidad's PPR instead of
"creating" new PPR style components for the sandbox. Also not having a
AA dependency sounds great, to me.
I think enhancing an existing solution, or providing a new
"architecture" should be fine with the SoC rules, right?
-Matthias
On 6/15/06, Ernst Fastl <er...@gmail.com> wrote:
> Hi There!
>
> In the PPR-Implemetation I would rather like to avoid those iframes
> and do it completly
> with AJAX. The Client-Side Implementation of AJAY Anywhere seems
> pretty much straight
> forward to me. When using it together with MyFaces it works the following way:
>
> 1.) Defining Zones to reload in the jsp-file with the <aa:zoneJSF
> id="x">-Component
> those get rendered as <span>-tags with id="aazone.x"
>
> 2.) Define which zones are to be reloaded with AJAX-Calls by defining
> a JS-Function:
> getZonesToReload(url, submitButton)
>
> 3.) Substitute the submit-function of the main-Form to use submitAJAX instead
>
> 4.) if a button is pressed or a value changed that would lead to a
> submit of the mainForm, submitAJAX checks based on getZonesToReload if
> an AJAXRequest is to be done.
> if not the form is submitted as usual.
>
> 5.)If it is an AJAX request a post-request is build with all
> parameter/value pairs of the form
> elements +
> -aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper) its
> an AJAX-Request
> -aazones=id1,id2 - Tell which zones need to be updated
>
> 6.)If AAFilter on the Server side detects aaxmlrequest=true it parses
> the HTML in the Response to extract the specified zones (big
> disadvantage the whole component
> tree gets rendered internally).
>
> 7.)HTML-Code of the zones is packed into xml-tags with the name of the
> zones as attribute and send back to the client
>
> 8.)Client parses the response and sets element.innerHTML of the
> zone-span-elements with the contents from the response
>
> What I like in this approach is the Javascript-Code that generates the
> Post-Request and the Code that parses the
> response and updates the DOM.
>
> The Server Side is pretty ugly. I would prefer to find a way to invoke
> only the affected components which I think
> should also make it faster. I haven't yet completly understood how
> trinidad handles this, but I think they have
> the cleaner solution for the server-side.
>
> What I also don't like is the JS-Code you have to write in your JSPs
> (calling substitueSubmitFunction, defining getZonesToReload, ..)
>
> In this point I would much prefer something like the
> partialTriggers-Attribute in trinidad.
>
> The thing is you have to define
> 1. which elements are to be reloaded by AJAX
> 2. which elements trigger those reloads
>
> I could also think of a listener-Component that can be added to the
> to-be-updated-elements and specify
> by which components those updates are triggered (which is pretty much
> the other way around compared to trinidad).
>
> I'm not yet completly shure whats the optimal approach for this, but
> I'll start with writing a s:panelGroup which
> supports a partialTriggers-Attribute that takes ids of radio-buttons
> (whith onchange="submit()"). For a start
> I will integrate this with AJAX-Anywhere to have something to try the
> different approches for the JSP-Part.
> Just for playing around whith it.
>
> If anyone is interested I'll try to make this online available once I'm done.
>
> Suggestions, Objections, Ideas and advices are very welcome :-)
>
> regards
>
> Ernst
>
>
> On 6/15/06, Adam Winer <aw...@gmail.com> wrote:
> > I'd be thrilled!
> >
> > For background, PPR was developed back before XMLHttp existed.
> > Back then, the only decent way to communicate to the server was
> > via hidden iframes. That solution has *a lot* of problems - for
> > example, no decent way to handle errors, and the document that
> > comes back can get parsed as HTML, which leads to some ugliness
> > with handling Javascript, etc.. It was a great choice for the time, but
> > it's showing its age, and there's better technologies
> >
> > Swapping out the client-side piece for an XMLHttpRequest-based
> > submission, with probably a few tweaks to the syntax delivered
> > by the PPR ResponseWriter, would give us a much more robust
> > solution, and would be a great isolated task. I'd be more than
> > happy to point anyone tackling this in the right directions.
> >
> > -- Adam
> >
> >
> > On 6/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > Hi *,
> > >
> > > Ernst Fastl - in his SoC beginning review - has worked on comparing the
> > > different PPR solutions so far. He's compared AjaxAnywhere, PPR in Trinidad,
> > > and some of the Avatar approach.
> > >
> > > What he's come up with so far is that he really likes the server-side
> > > integration of Trinidad, especially the syntax of integrating it in the view
> > > definition - not so much the client-side portion of it for doing PPR. Would
> > > you be happy with work being done on the client side portion of the PPR
> > > interaction in Trinidad in the SoC project?
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> > >
> >
>
--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: PPR - client-side
Posted by Ernst Fastl <er...@gmail.com>.
Hi There!
In the PPR-Implemetation I would rather like to avoid those iframes
and do it completly
with AJAX. The Client-Side Implementation of AJAY Anywhere seems
pretty much straight
forward to me. When using it together with MyFaces it works the following way:
1.) Defining Zones to reload in the jsp-file with the <aa:zoneJSF
id="x">-Component
those get rendered as <span>-tags with id="aazone.x"
2.) Define which zones are to be reloaded with AJAX-Calls by defining
a JS-Function:
getZonesToReload(url, submitButton)
3.) Substitute the submit-function of the main-Form to use submitAJAX instead
4.) if a button is pressed or a value changed that would lead to a
submit of the mainForm, submitAJAX checks based on getZonesToReload if
an AJAXRequest is to be done.
if not the form is submitted as usual.
5.)If it is an AJAX request a post-request is build with all
parameter/value pairs of the form
elements +
-aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper) its
an AJAX-Request
-aazones=id1,id2 - Tell which zones need to be updated
6.)If AAFilter on the Server side detects aaxmlrequest=true it parses
the HTML in the Response to extract the specified zones (big
disadvantage the whole component
tree gets rendered internally).
7.)HTML-Code of the zones is packed into xml-tags with the name of the
zones as attribute and send back to the client
8.)Client parses the response and sets element.innerHTML of the
zone-span-elements with the contents from the response
What I like in this approach is the Javascript-Code that generates the
Post-Request and the Code that parses the
response and updates the DOM.
The Server Side is pretty ugly. I would prefer to find a way to invoke
only the affected components which I think
should also make it faster. I haven't yet completly understood how
trinidad handles this, but I think they have
the cleaner solution for the server-side.
What I also don't like is the JS-Code you have to write in your JSPs
(calling substitueSubmitFunction, defining getZonesToReload, ..)
In this point I would much prefer something like the
partialTriggers-Attribute in trinidad.
The thing is you have to define
1. which elements are to be reloaded by AJAX
2. which elements trigger those reloads
I could also think of a listener-Component that can be added to the
to-be-updated-elements and specify
by which components those updates are triggered (which is pretty much
the other way around compared to trinidad).
I'm not yet completly shure whats the optimal approach for this, but
I'll start with writing a s:panelGroup which
supports a partialTriggers-Attribute that takes ids of radio-buttons
(whith onchange="submit()"). For a start
I will integrate this with AJAX-Anywhere to have something to try the
different approches for the JSP-Part.
Just for playing around whith it.
If anyone is interested I'll try to make this online available once I'm done.
Suggestions, Objections, Ideas and advices are very welcome :-)
regards
Ernst
On 6/15/06, Adam Winer <aw...@gmail.com> wrote:
> I'd be thrilled!
>
> For background, PPR was developed back before XMLHttp existed.
> Back then, the only decent way to communicate to the server was
> via hidden iframes. That solution has *a lot* of problems - for
> example, no decent way to handle errors, and the document that
> comes back can get parsed as HTML, which leads to some ugliness
> with handling Javascript, etc.. It was a great choice for the time, but
> it's showing its age, and there's better technologies
>
> Swapping out the client-side piece for an XMLHttpRequest-based
> submission, with probably a few tweaks to the syntax delivered
> by the PPR ResponseWriter, would give us a much more robust
> solution, and would be a great isolated task. I'd be more than
> happy to point anyone tackling this in the right directions.
>
> -- Adam
>
>
> On 6/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> > Hi *,
> >
> > Ernst Fastl - in his SoC beginning review - has worked on comparing the
> > different PPR solutions so far. He's compared AjaxAnywhere, PPR in Trinidad,
> > and some of the Avatar approach.
> >
> > What he's come up with so far is that he really likes the server-side
> > integration of Trinidad, especially the syntax of integrating it in the view
> > definition - not so much the client-side portion of it for doing PPR. Would
> > you be happy with work being done on the client side portion of the PPR
> > interaction in Trinidad in the SoC project?
> >
> > regards,
> >
> > Martin
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
> >
>
Re: PPR - client-side
Posted by Ernst Fastl <er...@gmail.com>.
Hi There!
In the PPR-Implemetation I would rather like to avoid those iframes
and do it completly
with AJAX. The Client-Side Implementation of AJAY Anywhere seems
pretty much straight
forward to me. When using it together with MyFaces it works the following way:
1.) Defining Zones to reload in the jsp-file with the <aa:zoneJSF
id="x">-Component
those get rendered as <span>-tags with id="aazone.x"
2.) Define which zones are to be reloaded with AJAX-Calls by defining
a JS-Function:
getZonesToReload(url, submitButton)
3.) Substitute the submit-function of the main-Form to use submitAJAX instead
4.) if a button is pressed or a value changed that would lead to a
submit of the mainForm, submitAJAX checks based on getZonesToReload if
an AJAXRequest is to be done.
if not the form is submitted as usual.
5.)If it is an AJAX request a post-request is build with all
parameter/value pairs of the form
elements +
-aaxmlrequest=true - Tell the AAFilter (=ServletRespone-Wrapper) its
an AJAX-Request
-aazones=id1,id2 - Tell which zones need to be updated
6.)If AAFilter on the Server side detects aaxmlrequest=true it parses
the HTML in the Response to extract the specified zones (big
disadvantage the whole component
tree gets rendered internally).
7.)HTML-Code of the zones is packed into xml-tags with the name of the
zones as attribute and send back to the client
8.)Client parses the response and sets element.innerHTML of the
zone-span-elements with the contents from the response
What I like in this approach is the Javascript-Code that generates the
Post-Request and the Code that parses the
response and updates the DOM.
The Server Side is pretty ugly. I would prefer to find a way to invoke
only the affected components which I think
should also make it faster. I haven't yet completly understood how
trinidad handles this, but I think they have
the cleaner solution for the server-side.
What I also don't like is the JS-Code you have to write in your JSPs
(calling substitueSubmitFunction, defining getZonesToReload, ..)
In this point I would much prefer something like the
partialTriggers-Attribute in trinidad.
The thing is you have to define
1. which elements are to be reloaded by AJAX
2. which elements trigger those reloads
I could also think of a listener-Component that can be added to the
to-be-updated-elements and specify
by which components those updates are triggered (which is pretty much
the other way around compared to trinidad).
I'm not yet completly shure whats the optimal approach for this, but
I'll start with writing a s:panelGroup which
supports a partialTriggers-Attribute that takes ids of radio-buttons
(whith onchange="submit()"). For a start
I will integrate this with AJAX-Anywhere to have something to try the
different approches for the JSP-Part.
Just for playing around whith it.
If anyone is interested I'll try to make this online available once I'm done.
Suggestions, Objections, Ideas and advices are very welcome :-)
regards
Ernst
On 6/15/06, Adam Winer <aw...@gmail.com> wrote:
> I'd be thrilled!
>
> For background, PPR was developed back before XMLHttp existed.
> Back then, the only decent way to communicate to the server was
> via hidden iframes. That solution has *a lot* of problems - for
> example, no decent way to handle errors, and the document that
> comes back can get parsed as HTML, which leads to some ugliness
> with handling Javascript, etc.. It was a great choice for the time, but
> it's showing its age, and there's better technologies
>
> Swapping out the client-side piece for an XMLHttpRequest-based
> submission, with probably a few tweaks to the syntax delivered
> by the PPR ResponseWriter, would give us a much more robust
> solution, and would be a great isolated task. I'd be more than
> happy to point anyone tackling this in the right directions.
>
> -- Adam
>
>
> On 6/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> > Hi *,
> >
> > Ernst Fastl - in his SoC beginning review - has worked on comparing the
> > different PPR solutions so far. He's compared AjaxAnywhere, PPR in Trinidad,
> > and some of the Avatar approach.
> >
> > What he's come up with so far is that he really likes the server-side
> > integration of Trinidad, especially the syntax of integrating it in the view
> > definition - not so much the client-side portion of it for doing PPR. Would
> > you be happy with work being done on the client side portion of the PPR
> > interaction in Trinidad in the SoC project?
> >
> > regards,
> >
> > Martin
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
> >
>
Re: PPR - client-side
Posted by Adam Winer <aw...@gmail.com>.
I'd be thrilled!
For background, PPR was developed back before XMLHttp existed.
Back then, the only decent way to communicate to the server was
via hidden iframes. That solution has *a lot* of problems - for
example, no decent way to handle errors, and the document that
comes back can get parsed as HTML, which leads to some ugliness
with handling Javascript, etc.. It was a great choice for the time, but
it's showing its age, and there's better technologies
Swapping out the client-side piece for an XMLHttpRequest-based
submission, with probably a few tweaks to the syntax delivered
by the PPR ResponseWriter, would give us a much more robust
solution, and would be a great isolated task. I'd be more than
happy to point anyone tackling this in the right directions.
-- Adam
On 6/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> Hi *,
>
> Ernst Fastl - in his SoC beginning review - has worked on comparing the
> different PPR solutions so far. He's compared AjaxAnywhere, PPR in Trinidad,
> and some of the Avatar approach.
>
> What he's come up with so far is that he really likes the server-side
> integration of Trinidad, especially the syntax of integrating it in the view
> definition - not so much the client-side portion of it for doing PPR. Would
> you be happy with work being done on the client side portion of the PPR
> interaction in Trinidad in the SoC project?
>
> regards,
>
> Martin
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>