Posted by nedjo on May 29, 2006 at 6:49pm
A key AJAX design choice is how we are going to handle client-server data transfers and client-side content rendering.
The two most obvious choices are:
- Data exchanges are in XML and content is rendered client-side via XSLT.
- Data exchanges are in JSON and content is rendered client-side via templates.
Each has its relative merits, and each will require some development on our part to implement. It might make sense to make a community decision around which of these options to pursue, as then we could pool efforts. For some SoC projects, e.g., the Form Builder, the data and content rendering model is a key early decision that will shape much of how the project is developed.
So here's an attempt to capture these options in a nutshell.
| XML/XSLT | JSON/Templating | |
| Explained | A good article at Ajaxpatterns Browser-Side XSLT. See also http://www.xml.com/pub/a/2005/02/23/sarissa.html | A good article at Ajaxpatterns Browser-Side Templating. |
| Server-side requirements | PHP <> XML. No Drupal solution in place, but GPL candidates exist. |
PHP > JSON: accomplished by drupal_to_js(). PHP < JSON: no solution in place, but candidates exist, e.g., PEAR's Services_JSON. |
| Examples | This is the model used in Google Maps, GMail, etc. | ? |
| GPL Javascript libraries | Sarissa provides cross-browser XSLT methods. Freja is a promising framework for XSLT-based development, though the fuller version 2 is still in alpha. | Trimpath's Javascript Templates is a very promising initiative that could greatly simplify our work. |
| Standards | XML and XSLT are W3C standards | JSON is a widely supported language construct. Templating is non-standard and requires custom implementations. |
| Drupal practice | Little XML/XSLT work to date in Drupal. However, XSLT could fairly readily be adapted from existing theme_ templates. | JSON has existing profile and support. Client-side templates could fairly readily be adapted from existing theme_ templates. |
Comments please! Merits or issues in either of these? What's our best approach?
Comments
XSLT--
From a pure developer standpoint, working with XSLT is a whole different mind game than working with arrays and objects. If we require XML transformations to be done in XSLT (and the requisite underlying XPath query language), I predict that we'll be closing out a whole class of developers.
Drupal as a whole is moving towards the "build and manipulate arrays" way of structuring data (forms API, Views definitions) and JSON fits in well with this. In the activeforms module I am able to send what is virtually the form array itself to the browser via JSON. The advantage of this is that I (the developer) am really aware of the data structure when it arrives there. If I then had to bother myself with getting at the various data elements in a "foreign language" (XSLT), I may have problems (note that I've worked with XSLT before and could do it now, but remember that it was hard to learn). The Javascript arrays that I end up with in the browser, on the other hand, is very intuitive and natural to a PHP developer.
Nedjo, you've done more research into this than I, and have used more varying approaches to the problem. Tell me it ain't the way I'm saying it is =)
PS no matter what we do, the sooner we can get away from the pipe splitting of the autocomplete fields and the activeselect module... the better.
Well...
I'd have to say, it probably is that way :)
My own proclivity is towards XML/XSLT as the standards-based choice. But practical considerations like "who actually knows or wants to know how to do things that way" are certainly relevant. And finding Javascript Templates helps address one of my biggest concerns with JSON--that we'd basically have to develop something like that.
This interesting quirksmode post shows that we're definitely not the only ones wrestling with this question.
I'm going to see if Avi, the Form Builder SoC student, wants to wade in here. He's after all one of the ones who's going to have to be implementing this stuff.
Expect my reply in next 24 hours :)
I went through he mail that you(nedjo) sent regarding the things I have to do. I am going through the links for XML/XSL and JSON. I'll be out with my suggestions soon enough and then It will be all upto you.
I'll say more once I read the things :)
Agreed - XSLT--
I fart in XSLT's general direction. :-P
I basically feel this way for the reason that Robert has already outlined - i.e. big extra learning curve for developers. XSLT really is a PITA, and is overkill for most templating needs. Additionally, I think that overall JSON is a 'lighter' option, in terms of LOC that need to be introduced into Drupal core to make it fully supported, and in terms of LOC that developers need to produce when writing templates based on it.
Drupal has traditionally kept away from internally dealing with data as XML/XSL, just as it has traditionally not been OO. In the cases where an exception has been made (e.g. XML-RPC library, RSS system), it is for components that we can do ourselves in a very lightweight fashion, without introducing 3rd-party library requirements (at least, not anymore, in the case of XML-RPC!). Also, the PHPTemplate theme engine is more aligned with the JSON model for its templating, and I think that a JS templating system should be consistent with this.
<my$0.02 note="Oh the irony... enclosing this sentence within XML tags ;-)">In summary, I think that the JSON way is the Drupal way.</my$0.02>
Jeremy Epstein - GreenAsh
Jeremy Epstein - GreenAsh
my Rs. 0.96
:) thats the indian equivalent of 2 cents.
neways I would like to make a few observations/notes, ask a few queries and give my suggestions.
Notes/Observations:
1. JSON is really easier to learn and deal with.
2. XML/XSLT are standards and the support for them in browsers is only going to increase with time.
3, From the pages I read, I found that XML can be verbose at times. Whereas JSON data is short comparitively.
4. Functionality-wise both offer similar things with small differences which can be removed or taken care of.
Queries:
1. In case of XML/XSLT, how does client side send data to the server?
One way is the normal form submission.
The second method will be using AJAX.
-- Now knowing the methods and assumng that we use XML-XSLT pair, do we need to creat XML on client and then send it to server? If we do so can we provide proper degradation in case of JS-less browsers? And is it worth doing given its inefficiency.
Anyways creating XML on client might be inefficient.
Suggestions:
If we can prioritize following points and answer them, We will have the solution to the problem:
1.Are we going to shift to other programming platform later(from JSON to XML)? - If it has to be done sometime... Now is the best time.
2.How many people will be interfacing or using the platform that is made?
3.How much code needs to be changed?
4.Which of the language is easier to learn.
Personally I would give more to json just because coding in it saves time and it is a bit more efficient.
Rest up to the experienced users :)
Avi
Proposed direction
JSON + templates seems to be the option with the most support, and the reasons are good ones. Sounds like we should work with that as our first direction. If big issues arise, we can fall back to looking again at XML/XSLT.
Pieces we'll need:
JSON > PHP. We havedrupal_to_js()forPHP > JSONbut lack the reverse. Various candidates are listed at: http://www.json.org/ under "JSON in PHP". Ideally, of course, we'd find something GPL. Robert, you used PEAR's JSON package in your activeforms. Did you look at any others? There's also the possibility (which I'm not necessarily recommending) of doing this conversion on the client. Awhile back I came across thefunction php_serialize(obj)here and got permission from the author to GPL it (though I didn't end up using it at that time).A templating system for outputting content. One candidate: the aforementioned Javascript Templates.
All, it looks like we have concensus as to moving forward with JSON + templates if it proves feasible, pls comment if otherwise.
Avi, maybe as part of your SoC work you could evalute these options and make some recommendations about what you'd like to use?
PEAR JSON
I actually hacked it because it didn't handle associative arrays the way I was expecting. In fact, the mismatch between Javascript arrays and PHP arrays is more pernicious than one thinks initially. Take our typical node object. If you serialize that to JS and bring it back again, no problems. If you cast it as a PHP array, serialize it and bring it back again, you'll have lost all of your keys. Just for people to be aware of. I think with some documentation about these issues we could use the PEAR package, though I think it is (typical of PEAR) more than we need. We might consider rolling our own.
I really think this should be a server-side operation because I can imagine cases where you would want to persist serialized JS and parse it into PHP later. So 1-- to depending on function php_serialize(obj).
JSON to download, simple
JSON to download, simple POST to upload
I always said that I do not think it's good to mix XML into this. But, in the end, all I care about is that Drupal has a nice form builder. Rock on!
I'm catching up on being so
I'm catching up on being so behind in this group :( sorry guys.
anyways, I would like to go with the JSON route.
I also want to get my inline (inplace) editing.
I was hoping someone interested feels like scheduling a time to review my code of what I have now.. and figure out how we want to make it properly use effect hooks, and use JSON for the data passing.
JSON or XML/XLST what would be the best for hOCR integration ?
Hi,
I am nor a programer nor a Drupal specialist, but can I suggest a question?.
We imagine that Drupal can import hocr output trough a XML/XSLT module or a JSON module?
Public Specification for the hOCR Format here:
http://docs.google.com/View?docid=dfxcv4vc_67g844kf
If possible, this means that a scan from a document can directly be loaded in Drupal on the same layout as the original document. Would be a great tool for library and digital collections with accurate ocr and manual correction facilities.
So what would be the best choice between JSON and XML/XSLT on the hocr integration point of view?
here a hocr editor plug-in for Firefox: https://addons.mozilla.org/fr/firefox/addon/11067
the ocropus project:
http://code.google.com/p/ocropus/
the hocr-tools project:
http://code.google.com/p/hocr-tools/