Hi, Vincent Massol wrote: Don't you rather mean the field "defaultEditSheet" ?

template is for choosing the .vm to render the document against IIRC The template field set to what ? This sounds like a hack and will prevent using the template field for what its meant for.

I think we'd better not make a too quick decision on that, since if we don't make a sound choice, it potentially will create us more work for the moment we really refactor/remove the inline mode. I would say "defaultEditSheet" is our best option, but I have to think more about it. Feedback from JV and Ludovic would help, they both worked on such refactoring of the inline mode.

Vincent Massol wrote: No, this already exists. Maybe there is no API to set it in XWikiDocument, but check the XML of an exported doc, you'll see it.

And I think it is also already usable (at least in syntax 1.0), XWiki will use the document indicated in this field (if present) as the sheet in edit mode. There is an equivalent for view mode : defaultViewSheet. This is for the case you don't want to use the content to that. For example, I used it in workspaces since I wanted the content to be editable with the (old) WYSIWYG that potentially would alter the #includeForm statement. (And I also did not wanted to expose this statement to users). Now, I probably could have used defaultEditSheet and defaultViewSheet instead, and thus have my presentation code for edit and view in the wiki rather than in the skin (or templates/ folder). So to sum up: - "template" is for using a specific .vm to render the document against (it will supersede view.vm or edit.vm) - "defaultViewSheet" or "defaultEditSheet" is to force a wiki document as sheet in view or edit mode Jerome. _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Vincent Massol wrote: Exact, that's why I could not use it for pages in XWS :) Note that those fields are still what ultimately should be used to replace the inline mode, I believe. Inline mode does not have any sense for a page without XObject(s). What is to resolve is what should be done for pages with several XObjects with such fields not empty (concatenation of all XObjects classes default(View|Edit)Sheet sheets ?)

Isn't defaultTemplate a way to force an equivalent of &template=XWiki.MyTemplate ? I'm not sure of this...

Jerome. > Thanks > -Vincent > >> And >> I think it is also already usable (at least in syntax 1.0), XWiki will >> use the document indicated in this field (if present) as the sheet in >> edit mode. There is an equivalent for view mode : defaultViewSheet. >>>> template is for >>>> choosing the .vm to render the document against IIRC >>>> >>>>> * When a page has the template field set, when the user clicks on >>>>> the >>>>> edit button it goes automatically in inline edit mode >>>> The template field set to what ? This sounds like a hack and will >>>> prevent using the template field for what its meant for. >>> I wasn't sure what it was meant for since it's never been used. I'm >>> still unsure what it's for since you can put the way to display the >>> page in the page content itself so I'm unsure why you'd need a >>> template specified. >> This is for the case you don't want to use the content to that. For >> example, I used it in workspaces since I wanted the content to be >> editable with the (old) WYSIWYG that potentially would alter the >> #includeForm statement. (And I also did not wanted to expose this >> statement to users). Now, I probably could have used defaultEditSheet >> and defaultViewSheet instead, and thus have my presentation code for >> edit and view in the wiki rather than in the skin (or templates/ >> folder). >> >> So to sum up: >> - "template" is for using a specific .vm to render the document >> against >> (it will supersede view.vm or edit.vm) >> - "defaultViewSheet" or "defaultEditSheet" is to force a wiki document >> as sheet in view or edit mode >> >> Jerome. >>> But I'm ok to use an editTemplate (and rename template to >>> viewTemplate >>> - after I understand why we need it). >>> >>>>> * Add a new field in the information edit panel to set the template >>>>> (only for advanced users I think) >>>>> >>>>> WDYT? >>>> I think we'd better not make a too quick decision on that, since >>>> if we >>>> don't make a sound choice, it potentially will create us more work >>>> for >>>> the moment we really refactor/remove the inline mode. >>>> I would say "defaultEditSheet" is our best option, but I have to >>>> think >>>> more about it. Feedback from JV and Ludovic would help, they both >>>> worked >>>> on such refactoring of the inline mode. >>> The point of this email is to make people react and so that we come >>> to >>> a quick conclusion. I've been trying to push this issue for months >>> now >>> without success so I'm now going to handle it and implement it >>> myself. >>> We also need this fast since otherwise we can't set the default >>> syntax >>> to xwiki 2.0.

Another idea while waiting for a full-fledged document type solution is to implement the metadata properties syntax in xwiki syntax 2.0 (this is http://jira.xwiki.org/jira/browse/XWIKI-3320) and write the following for pages that want inline as a default for their edits: %automaticInlineEdit true Then XWikiDocument.getDefaultEditURL() will check (when the syntax is 2.0) if that document metadata property is set. WDYT?

Thanks -Vincent On Apr 18, 2009, at 10:45 AM, Vincent Massol wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

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). 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: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

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).

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

On Apr 27, 2009, at 9:34 AM, Vincent Massol wrote: 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) >

> > 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/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)

On Apr 27, 2009, at 9:34 AM, Vincent Massol 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

On Tue, Apr 28, 2009 at 11:39 AM, Vincent Massol <vincent(a)massol.net> wrote: Could you briefly explain why you think we're not ready for this ?