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 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)
WDYT?
Thanks
-Vincent
>
>
> If we all agree that this is what we want to handle document types
> then I think the best would be to develop the first part ("document
> types" handling) during 1.9. If we can't develop this in the
> timeframe, adding viewSheet/editSheet properties to XWikiDocument does
> not conflict with the scenario above (they could be the first
> properties checked by Document#get*Sheet). The only issue I foresee is
> that it could make things look more complex when we'll have class
> types and everything. WDYT ?
>
> [1] :
> http://dev.xwiki.org/xwiki/bin/view/Design/OverhaulOfXWikiClassesAndObjectsManagement
>
> JV.
>
> On Sat, Apr 18, 2009 at 10:45 AM, Vincent Massol
> <[email protected]> wrote:
>> Hi,
>>
>> We need to have automatic inline edit mode for XWiki Syntax 2.0
>> (http://jira.xwiki.org/jira/browse/XWIKI-2891)
>>
>> I'd like to implement this quickly since it prevents to use the xwiki
>> syntax 2.0 as the default syntax (for ex if you create a user in 2.0
>> syntax and click edit you'll edit it in wysiwyg mode instead of
>> inline
>> mode).
>>
>> A quick solution I have:
>>
>> * Use the XWikiDocument template field to set the sheet to use
>> * When a page has the template field set, when the user clicks on the
>> edit button it goes automatically in inline edit mode
>> * Add a new field in the information edit panel to set the template
>> (only for advanced users I think)
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs