2009/11/26 Martijn Faassen <faas...@startifact.com>:
> Jan-Wijbrand Kolman wrote:
>> I'm about to work a bit on z3c.schema2json . As has been briefly
>> discussed before (a while ago ), z3c. schema2json is so similar to
>> z3c.schema2xml  in what it does and how it does it, that I wonder
>> about merging the two packages somehow.
>> One way to do this - maybe - is to use named registrations for the
>> (de)serialization adapters. The name could reflect the serialization
>> "mode" - for example "xml" or "json".
>> But maybe there're other ideas to achieve this? Or, could it be that
>> merging has no real benefit?
> I'm still not sure there'd be a real benefit. It depends on how much
> code would end up being shared. If a lot of code is shared it might make
> sense to merge them (or factor the code out into a general schema-based
> serialization and deserialization framework). If it turns out your
> improvements to z3c.schema2json also make sense in z3c.schema2xml then
> that's an argument in favor of sharing code between them.
I can't see much core code being shared to be honest. However, the
benefits of merging would be more apparent to clients of these modules
who want to be able to use z3c.schema2json and z3c.schema2xml together
to support both serialization formats.
I can see two use cases from the perspective of client code:
* I want to have my objects serialized and deserialized but don't
want to know what format is used, just use an agnostic interface
(z3c.autoinclude wires the correct implementation from the list of
* I want to present a list of possible serialization formats and have
the user select the appropriate one.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -