-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Florent Guillaume wrote:
> I'd like to detail the future of flexible documents.
[...]
>
> This is problematic for several reasons:
> - the schema isn't fixed, so there's no way of starting to use Zope 3
> schemas (which can't be persistent at the moment), and there are big
> variations between schemas for the same nominal "document type",
> - there is additional persistent metainformation stored in the document,
> which has to be imported/exported,
> - because there are local schemas, it's hard to modify things for "all
> instances of a given document type",
> - in edit mode, you can't create new widgets without saving the
> document; this is problematic during creation also.
>
ok with all the points above.
> In the future I want to have a different way of doing flexible documents:
>
> 1. Define new field types, for instance RichTextTupleField,
> ImageTupleField, LinkTupleField. For instance they could store python
> information like:
> richtexts = (('html', "<p>Some HTML</p>"), ('rst',
> 'Title\n====\n\nHello'))
> images = (image1, image2)
> links = (('http://google.com', "Google", "The Google search engine"),
> ...)
> Each of the basic field (RichTextField, ImageField, ...) would have
> associated widgets for individual rendering.
>
> 2. Define a new LayoutField that holds layout information, probably a
> tuple, see below.
>
> 3. Define a new kind of widget called FlexibleWidget which is
> parametrized using:
> - field_ids = ('richtexts', 'images', 'links')
> - layout_field_id = 'layout'
>
> The layout field would store information like (format subject to change):
> images/0:floatright richtexts/0 :clearboth images/1 links/0 richtexts/1
>
> This would do a rendering of individual components of the above data
> using something like:
> <div style="float:right"><img src="...image1"></div>
> <div><p>Some HTML</p></div>
> <div style="clear:both"></div>
> <div><img src="...image2"></div>
> <div><a href="http://google.com";>Google</a> The google search engine</div>
> ...
>
> This means that the layout itself would be part of the content. So the
> FlexibleWidget can have an edit mode where you create/delete subwidgets
> directly.
>
> A schema could define a ImageTupleField with additional config saying
> minimum 1, maximum 3, which would be used by the FlexibleWidget to
> enforce some limits.
>
>
> All this will make for cleaner schemas and documents, more powerful
> editing modes. It will make migration to Zope 3 schemas possible. It
> will also simplify import/export of documents.
ok with this.
Note that the real short term goal towards the schema migration is the
XML Schema support on CPS-3 document types that will be added on top of
Zope3 schemas, Zope3 side. Short term means 3.5.x in this case.
>
>
> I'd welcome opinions on this. I'm not sure yet if I can do it before
> 3.4.0 but it would be very useful, as we could start the migration then.
I'm +1 only if you provide 100% (tested!) BBB with this modifications ;)
J.
- --
Julien Anguenot | Nuxeo R&D (Paris, France)
CPS Platform : http://www.cps-project.org
Zope3 / ECM : http://www.z3lab.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFDfLY8GhoG8MxZ/pIRAo8vAJ9zIMMXIT5ZM2xFLZSzYi0zSzsqpQCghv9l
K2bxKyVLUV6A620PE8rpavQ=
=s/FH
-----END PGP SIGNATURE-----
_______________________________________________
cps-devel mailing list
http://lists.nuxeo.com/mailman/listinfo/cps-devel
