IMPORTANT(usability/core logic for ajax): hijacking IMarkupWriter

[Jesse Kuhnert <jk...@gmail.com>]

The initial thought I'm having in regard to rendering "ajax" responses back
to client browsers is that all of the infrastructure/components in place
already do an awful lot of work writing their very important content to
IMarkupWriter, so why not use that to sort of bootstrap the abililty to make
your service JSON/XML/html-able?

This idea is spawned from looking at the PropertySelection component,
specifically in how to do a pure JSON call/response to get a filtered list
of values. In this example, we'll say we have a list of fruits with key (for
html select values) values using two letter abbreviations.

orange -> or
pear -> pr
apple -> al

The standard html markup response would typically look like(taking out a lot
of things for brevity):

<select name="fruit">
  <option value="or">orange</option>
  <option value="pr">pear</option>
  <option value="al">apple</option>
</select>

The JSON sort of equivalent to this would be something like:

{
propertyselect:{name:"fruit", values:{ "orange":"or", "pear":"pr",
"apple":"al"} }
}

So, it pretty much describes the exact same thing, with different semantics
for what the marked up result should look like.

=============================================

The end goal is to replace the default MarkupWriterImpl with one that knows
how to deal with the response type in question, whether it be
json/xml/whatever...

In theory, you could  argue that the content being written in it's pure form
is already more than enough to do this JSON response, but the reality of the
situation is that there is an awful lot of non-json friendly content going
out. Things like "onChange" and others just don't make sense to write to a
json response. The whole point being a very minimal and pure data model.

So, we need a way to describe how the data already being written should
structurally look. Ie, I know I'm writing 10 things, but I really only want
these 5 specific things...And while you're at it, the names don't really
make sense to me (like value="1", or you may very well be working with a
client side library with well defined names that you have no control over...
), so map them to something else with this name instead.

This is the part I'm feeling very very ~iffy~ about. Using the fruit example
above, I could for instance add an @Annotation to the PropertySelect
component class. (Whether on the class, or method rendering in question
isn't imporant) like:

@Translate(response="JSON", translation="propertyselect:{name:id, values:{
iterate over values?? } }")

There will probably be some weirdness dealing with lists/arrays and
efficient conversion to string values, but you get the point.

This idea brings up all sorts of usability questions:

-) What if the structure created is too complicated to put into a simple
annotation?
 Can we tell them to put it into a .properties file and use some sort of
translation="message:key" notion instead?

-) What if the structure needs to look different depending on the library
being used on the client or some other weird constraint? Worse yet, what if
there is information the component has that is ~not~ being written to the
markup writer that we need in our JSON response?

It seems like there should be an easy way to let people override the
translation value, but the extra data part is kind of scary. It seems to
suggest the ability to do some sort of OGNL type logic in the definitions,
which would mean placing almost all of the objects here into the context of
this string definition:
http://jakarta.apache.org/tapestry/UsersGuide/properties.html.

It doesn't seem to call for it quite yet, but it hints at needing a more
robust ability to define weird logic for special cases, something similar to
the @Script script templates. It would feel really ugly if we ever had to
take it there, but I'm just throwing that out as an option.

========================================================


So, what does everyone think? This sort of thought is going to drive a lot
more than just JSON calls, so I REALLY really would appreciate any and all
input from anyone/everyone.

jesse

Re: [Tacos-devel] IMPORTANT(usability/core logic for ajax): hijacking IMarkupWriter

[Jesse Kuhnert <jk...@gmail.com>]

The return type idea sounds like something that will be useful for certain
scenerios, but I don't think I want to introduce another chain of subclasses
with AjaxComponent.

I think the intent is to move away from this pattern and use something more
flexible, like an object to add things into. (IE markup writer, or
equivalent)

On 2/23/06, Edgar Chan Carrillo <ed...@gmail.com> wrote:
>
> Hi!! .. In my opinion i think  the response part could be done in more
> natural way, something like the listener methods activate the response page
> with its return type.
>
> http://jakarta.apache.org/tapestry/UsersGuide/listenermethods.html
>
>
> Using the return type of the listeners and creating a new base
> AjaxComponent type that can be contributed later with json,xml or html
> implementations we could response not only ajax but whatever content type we
> need, for example:
>
>  @meta("ajaxType:json")
>  public AjaxComponent myListenerMethod(){
>     return myJsonComponent;
>  }
>

Re: [Tacos-devel] Re: IMPORTANT(usability/core logic for ajax): hijacking IMarkupWriter

[Jesse Kuhnert <jk...@gmail.com>]

Good point. It does feel a little hacky upon further reflection.

Maybe something more like:

IComponent.renderJsonComponent(IJsonWriter writer, IRequestCycle cycle);

Still not sure about the ajax response part. It would be easy to add in:

IComponent.renderAjaxComponent(IAjaxWriter writer, IRequestCycle cycle);

but a lot of logic would be duplicated between renderComponent and
renderAjaxComponent if not coded carefully...

I will have to re-think this one I think :)

On 2/23/06, Danny Angus <da...@apache.org> wrote:
>
>
>
>
> "Jesse Kuhnert" <jk...@gmail.com> wrote on 23/02/2006 04:45:34:
>
> > The initial thought I'm having in regard to rendering "ajax" responses
> back
> > to client browsers is that all of the infrastructure/components in place
> > already do an awful lot of work writing their very important content to
> > IMarkupWriter, so why not use that to sort of bootstrap the abililty to
> make
> > your service JSON/XML/html-able?
>
>
> We use (tap 3) IMarkupwriter to rewrite form names and form component
> names
> for Oracle portal (9ias), and to add the original value of the "name" as
> the value of the "id".
> We've just extended that to also rewrite those same names in all script
> refrences, inlcuding <script> and element attributes like event handlers
> and URL's.
> It also detects when the app is being called by portal and doesn't rewrite
> at all when it isn't, meaning that our portlet apps can be developed stnad
> alone and will Just Work (tm) when called by portal.
>
> We've achieved all of this in around 300 lines of code, it is encapsulated
> in a single markup writer and we haven't had to hack Tapestry in any way
> at
> all.
>
> Its a simple but wickedly powerful way to munge every piece of output from
> any component.
>
> I'd quite like to see Tapestry enforcing XHTML so that markup writers
> could
> use XSLT. But just using indexOf and subString gives us extraordinary
> power. Muahhahha.
> The only two issue I have is that the contract for components is not
> strict
> enough that we can reason that a markupwriter will work in all cases,
> effectively because component developers have the freedom to come up with
> any kind of raw output.
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Tacos-devel mailing list
> Tacos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tacos-devel
>

Re: IMPORTANT(usability/core logic for ajax): hijacking IMarkupWriter

[Danny Angus <da...@apache.org>]

"Jesse Kuhnert" <jk...@gmail.com> wrote on 23/02/2006 04:45:34:

> The initial thought I'm having in regard to rendering "ajax" responses
back
> to client browsers is that all of the infrastructure/components in place
> already do an awful lot of work writing their very important content to
> IMarkupWriter, so why not use that to sort of bootstrap the abililty to
make
> your service JSON/XML/html-able?


We use (tap 3) IMarkupwriter to rewrite form names and form component names
for Oracle portal (9ias), and to add the original value of the "name" as
the value of the "id".
We've just extended that to also rewrite those same names in all script
refrences, inlcuding <script> and element attributes like event handlers
and URL's.
It also detects when the app is being called by portal and doesn't rewrite
at all when it isn't, meaning that our portlet apps can be developed stnad
alone and will Just Work (tm) when called by portal.

We've achieved all of this in around 300 lines of code, it is encapsulated
in a single markup writer and we haven't had to hack Tapestry in any way at
all.

Its a simple but wickedly powerful way to munge every piece of output from
any component.

I'd quite like to see Tapestry enforcing XHTML so that markup writers could
use XSLT. But just using indexOf and subString gives us extraordinary
power. Muahhahha.
The only two issue I have is that the contract for components is not strict
enough that we can reason that a markupwriter will work in all cases,
effectively because component developers have the freedom to come up with
any kind of raw output.



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org