On Apr 21, 2009, at 2:49 PM, Jean-Vincent Drean
wrote:
Hi,
I wrote a POC about document types a while back. Some mockups are
available [1]. Summary:
- Introduce a new property in xwiki classes: class type. 3 different
class types: document type, document meta, system. More below.
- Make defaultViewSheet and defaultEditSheet properties (BaseClass)
persistent.
- New Document API methods : getViewSheet, getEditSheet. Those
methods loop over documents objects and resolve the sheet to use.
-- On the first object from a "document type" class (Users, Blog
articles, etc) the sheet to use for this class is returned.
-- Document meta / System classes (comments, tags, etc) never trigger
the use of a sheet.
- When viewing/editing a page getViewSheet/getEditSheet is called and
the returned sheet is used.
- If there's no object from a "document type" class in a document,
"document meta" objects are displayed before or after the content
(depending on a class property) with their custom viewSheet/editSheet
or with the default sheet we provide (an improved version of what we
currenlty have in the object editor).
I'm not sure about the class type stuff.
This looks complex to me
(the user will need to understand it when creating a class) and I
can see use cases where it breaks a bit. For example you mention
comments. While they are document meta in most cases, if you start
putting them in separate documents (as we have the ability to do in
some refactored version for ex) they become document type. I don't
think the class type is a static information. It only depends what
you want to do with the object IMO.
I think it's better if it's the author of a document who decides how
to display his document since he knows what he wants to have (rather
than automatically 'guessing' what sheet to use).
This can be done by letting him choose the document's view/editSheet
value from a combo listing all sheets that are defined for existing
objects + adding a special sheet that displays content + object
content as in the object editor (2 entries if you want to allow
objects printed before and after content) + a "custom" entry which
allows the user to enter in a field the name of a custom sheet.
If the user doesn't set the view/editSheet we simply display only
the content as in normal view mode (we could look for the first
object that has a sheet defined and use it but I don't like this too
much since it's magical again).
I forgot to mention that when using HTML forms and templates this view/
editSheet fields will be able to be set automatically of course. So a
user creating a blog post for ex will create documents which have the
view/editSheet set correctly for blog viewing/editing.
-Vincent
>
> I think this makes it simpler (no need for class type), more
> explicit (less magic) and more flexible (the user chooses how he
> wants it displayed)
>