cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: 2.2 using cocoon-ajax-impl
Date Thu, 24 May 2007 07:01:27 GMT


Grzegorz Kossakowski wrote:
> Marc Portier pisze:
>>> Yes. I did this way (I didn't touch paths, directory structure, 
>>> sitemap) because I didn't understand the stuff fully. There is only 
>>> one sample in Cocoon (in Forms) that uses this stuff but it does not 
>>> work up to date. I mentioned problem few times and asked for help, 
>>> last time here:
>>> http://article.gmane.org/gmane.text.xml.cocoon.devel/72629
>>>
>>
>> ok, sorry for not being around with plenty of time when that happened
> 
> No problem. I hope that you will be able to help with fixing that sample.
> 

Well, I am around now, but still not with 'plenty of time'
I am however on an assignment where ajax-json-cocoon22 should be working 
for me, so let's for now assume that somewhere along the way we get to 
fixing that sample as a side effect?

>>> I didn't know that some may want to use JSON js files directly 
>>> instead of calling sitemap in system. Now I think that all the 
>>> functionality 
>>
>> as far as I understand now, loading the System.JSON.js is the only way 
>> to  be able to add json-serialization for your own beans...
>>
>> But I have to say I would welcome a more Java based solution for that 
>> anyway (probably based on the www.json.org/java/ stuff)
>>
>> something that could register custom json serializers so the send-json 
>> pipe could actually serialize out all your domain models
> 
> Could you explain more what you mean? I really don't know JSON that much 
> (I know basics, though).
> 

same as me

anyways trying to explain the issue: System.JSON.js quite clearly states 
that it only supports serialization of some basic types, and collections 
and maps

so people that want to serialize out custom java beans to JSON have two 
options

1. add that functionality to the JSON stuff by overriding the 
_serializeValue function (or using dojo-binding-like  -yes on the server 
side- aop advise on it

2. convert their java-objects first to maps and collections of the 
mentioned basic structures...


both feel patchy to me at this moment, and I think json support should 
be thought off in a more systematic way as to be able to convert between 
json-notation, xml(sax) and plain java (business) objects more easily

(more below)

>>> should be moved to the root sitemap and necessary resources should be 
>>> shared via "resource/internal/**".
>>>
>>
>> I had the same feeling
> 
> Go for it! :-)
> 
>>> Giacomo, as you seem to be more experienced with the JSON, could take 
>>> care of doing that? I can help you with any trouble you encounter. If 
>>
>> I think it makes sense to talk about how we should be addressing the 
>> json serialization of custom beans...
> 
> As already explained I confused you Marc, and Giacomo (sorry guys). This 
> way, I was referring to you Marc as someone experienced with JSON.

I am gladly honoured, but still confused :-)
as I really don't think I am the expert on json around...

now, svn praise showed me jeremy added the JSON.js file originally I'm 
polling him off-list to see if he has any more educated opinion in this 
(that and if the provide json.js from the www.json.org site would be a 
valid alternative)

I also remember a really old post of Sylvain in this area 
http://bluxte.net/blog/2005-11/17-49-57.html suggesting we also should 
add a json serializer, which brings me back to my previous remark on the 
multiple conversions we need:


1. uploaded json strings should be readable into objects (some 
registered cocoon-component aka spring-bean in c22) and sax-streams 
(generator?)

note: that registered (spring) component should be extensible so 
readers/writers for specific object-types could be added

I would prefer a java component over the current js approach (with a 
need for overwrites or interception for extending functionality) as this 
stuff should be available without involving flowscript/rhino (ie also 
from apples, javaflow, actions or common pipelines)


2. data to be send as json strings could be originating as in memory 
objects (sendObject idea, probably using the same registered component) 
or from xml (serializer)


and while rethinking all of the above: converting first to standard 
objects, maps and collections (or even the JSONObject from 
http://www.json.org/java/) might provide a nice middle ground from where 
both xml and json could pick up, leaving the mentioned java-component to 
an extensible pojo to-from jsonObject convertor (needs more thought though)


> Can you move current functionality and then we could discuss about 
> alternatives?
> 

above should have the broader discussion started


but, just one more question before starting on the move:
are we still sharing block sources between cocoon 2.1 and cocoon 2.2. 
branches? and if so doe anyone have a clue on the impact over there?


regards,
-marc=

Mime
View raw message