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=
