28 Apr
2009
28 Apr
'09
11:39 a.m.
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:
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
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? > 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/OverhaulOfXWikiClassesAndObjects…
>
> JV.
>
> On Sat, Apr 18, 2009 at 10:45 AM, Vincent Massol
> <vincent(a)massol.net> 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