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
