Hi
We moved #jsonOn: from Javascript-Core to Seaside-JSON-Core. This makes implementing #jsonOn: much nicer because you can now use a canvas api. Instead of using JSStream#encodeDictionary:on: and #encodeCollection:on: and first having to convert them to dictionaries or collections you can "render" them similarly to components. However the dependencies between the JSON and Javascript packages are not yet clearly defined. Right now the dependencies are: - Seaside-JSON-Core depends on JSStream for encodeString:on: - Javascript-Core-JSON contains a JSON parser, right now this is only used by JQuery This opens the following questions: - What should the dependencies be? Should Javascript depend on JSON? Or vice versa? Or should they be independent? - Should we move JSJsonParser to Seaside-JSON-Core? - Should we rename Seaside-JSON-Core to JSON-Core? Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Am 19.02.2012 um 10:48 schrieb Philippe Marschall: > Hi > > We moved #jsonOn: from Javascript-Core to Seaside-JSON-Core. This > makes implementing #jsonOn: much nicer because you can now use a > canvas api. Instead of using JSStream#encodeDictionary:on: and > #encodeCollection:on: and first having to convert them to dictionaries > or collections you can "render" them similarly to components. However > the dependencies between the JSON and Javascript packages are not yet > clearly defined. Right now the dependencies are: > - Seaside-JSON-Core depends on JSStream for encodeString:on: > - Javascript-Core-JSON contains a JSON parser, right now this is only > used by JQuery > > This opens the following questions: > - What should the dependencies be? Should Javascript depend on JSON? > Or vice versa? Or should they be independent? > - Should we move JSJsonParser to Seaside-JSON-Core? > - Should we rename Seaside-JSON-Core to JSON-Core? I'm not sure I understand the rationale of the canvas API. From a seaside point of view this seems to be good thing. If I take my own angle which deals with web APIs I'm not sure if it is the best thing. Using javascript/json from seaside is generation only. In a web api there needs to be writing and reading. Taking the canvas API what would be the counterpart for reading such a format? Not having to produce Dictionaries before writing something json sounds good. But on the other hand it is the best intermediate representation before serialization. I use Mongo at the moment. In the MongoTalk driver there is a conversion from Dictionaries to BSON. I'm not sure which way it would be more cumbersome: Having to produce Dictionaries or having to write a new canvas for BSON. This is all more like questions because I didn't spend a lot of time thinking about it. I have the same problem seeing a good solution for Magritte JSON. If you would like to build a Magritte BSON I would have to create a completely new module which shouldn't be necessary IMHO. Norbert_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Free forum by Nabble | Edit this page |