Guys after a lot of thinking I think we're not ready for implementing
the target mechanism for doc types and co and thus I don't think I
should implement auto inline edit using this.
I'm thus proposing a temporary solution which is the same as for xwiki
syntax 1.0:
- introduce a macro alias for incluide: includeForm
Let me know quickly if you don't agree and if you don't what solution
you're proposing instead (trust me I've considered a lot of options
before reaching this conclusion).
Thanks
-Vincent
On Apr 28, 2009, at 10:08 AM, Vincent Massol wrote:
>
> On Apr 27, 2009, at 9:34 AM, Vincent Massol wrote:
>
>>
>> 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?
>
> Thinking more about all this I'm unsure whether we should hardcode
> the notion of classsheet into the core. I think I'd prefer to use an
> object (e.g. XWikiSheetClass) which would allow overriding the
> default view/edit sheets to use.
>
> Basically I'm wondering whether the notion of sheet should be kept
> in an extended Application (XAR) in the future. By extended I mean a
> XAR that contains wiki pages + java classes. For example, once we've
> moved to the new xwiki-action module applications can provide action
> components including action components that override base actions.
> So we can imagine an application providing a ViewAction (that
> extends the basic ViewAction class) that would first look for an
> object named XWikiSheetClass in a document and use it to render the
> page if defined. Same for EditAction.
>
> So the question is really: do we want to keep the core very small
> and focused (only Objects and Classes) and provide higher-level
> features in Applications instead?
>
> 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
