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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
