[xwiki-devs] [Proposal] Inline mode for XWiki Syntax 2.0
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
Hi, Vincent Massol 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
Don't you rather mean the field "defaultEditSheet" ? 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.
* 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. Jerome.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Apr 18, 2009, at 11:01 AM, Jerome Velociter wrote:
Hi,
Vincent Massol 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
Don't you rather mean the field "defaultEditSheet" ?
I couldn't find that field in XWikiDocument. Do you mean introducing a new field for this? (I'm +1 for that)
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. 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. Thanks -Vincent
Vincent Massol wrote:
On Apr 18, 2009, at 11:01 AM, Jerome Velociter wrote:
Hi,
Vincent Massol 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 Don't you rather mean the field "defaultEditSheet" ?
I couldn't find that field in XWikiDocument. Do you mean introducing a new field for this? (I'm +1 for that)
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.
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.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Apr 18, 2009, at 11:29 AM, Jerome Velociter wrote:
Vincent Massol wrote:
On Apr 18, 2009, at 11:01 AM, Jerome Velociter wrote:
Hi,
Vincent Massol 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 Don't you rather mean the field "defaultEditSheet" ?
I couldn't find that field in XWikiDocument. Do you mean introducing a new field for this? (I'm +1 for that)
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.
in XWikiDocument thre are 2 fields: * a template field * a defaultTemplate field The defaultEditSheet/defaultViewSheet are in the BaseClass java class, i.e. they are used for XObjects. I don't see how they could be used for the main document's view or edit actions. Any idea what defaultTemplate is used for? (I'll research it, just asking in case you already know). 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.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Vincent Massol wrote:
On Apr 18, 2009, at 11:29 AM, Jerome Velociter wrote:
Vincent Massol wrote:
On Apr 18, 2009, at 11:01 AM, Jerome Velociter wrote:
Hi,
Vincent Massol 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 Don't you rather mean the field "defaultEditSheet" ? I couldn't find that field in XWikiDocument. Do you mean introducing a new field for this? (I'm +1 for that) 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.
in XWikiDocument thre are 2 fields: * a template field * a defaultTemplate field
The defaultEditSheet/defaultViewSheet are in the BaseClass java class, i.e. they are used for XObjects. I don't see how they could be used for the main document's view or edit actions.
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 ?)
Any idea what defaultTemplate is used for? (I'll research it, just asking in case you already know).
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.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Jerome Velociter wrote: > Vincent Massol wrote: >> On Apr 18, 2009, at 11:29 AM, Jerome Velociter wrote: >> >>> Vincent Massol wrote: >>>> On Apr 18, 2009, at 11:01 AM, Jerome Velociter wrote: >>>> >>>>> Hi, >>>>> >>>>> Vincent Massol 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 >>>>> Don't you rather mean the field "defaultEditSheet" ? >>>> I couldn't find that field in XWikiDocument. Do you mean >>>> introducing a >>>> new field for this? (I'm +1 for that) >>> 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. >> in XWikiDocument thre are 2 fields: >> * a template field >> * a defaultTemplate field >> >> The defaultEditSheet/defaultViewSheet are in the BaseClass java class, >> i.e. they are used for XObjects. I don't see how they could be used >> for the main document's view or edit actions. > > 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 ?) These will make sense once we have document types, but for the moment indeed they are not used. +1 for making use of them +1 for concatenating the rendering result of all the sheets found in documents Q: if a class has just one of the sheets specified, should we skip displaying the object in the other mode, or should we apply the only sheet specified for both modes? >> Any idea what defaultTemplate is used for? (I'll research it, just >> asking in case you already know). > > Isn't defaultTemplate a way to force an equivalent of > &template=XWiki.MyTemplate ? I'm not sure of this... template is set when copying a document from a template, like in: /save/New/Document?template=Template.Doc => $doc.template="Template.Doc". This field is not persisted to the database, so it's only valid as long as the document is in memory. defaultTemplate is indeed used for specifying an alternative to view.vm used for the /view/ action. You can see it used in c.x.x.web.ViewAction. > 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. -- Sergiu Dumitriu http://purl.org/net/sergiu/
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:
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 Sun, Apr 19, 2009 at 12:02, Vincent Massol <[email protected]> wrote:
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?
Good idea yes, we could extends the principle to a lots of thing like choosing which panels to show, hide the comments, etc.
Thanks -Vincent
On Apr 18, 2009, at 10:45 AM, Vincent Massol 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
-- Thomas Mortagne
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/OverhaulOfXWikiClassesAndObjectsM... 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
Hi, On Tue, Apr 21, 2009 at 2:49 PM, Jean-Vincent Drean <[email protected]>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).
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 ?
If adding viewSheet/editSheet properties to XWikiDocument can be done in a short timeframe without compromising the possibility of building a more comprehensive solution to this issue in the future, I think it's our best choice for now since the feature would need to be ready as soon as possible to make a default version of XWiki work in XWiki 2.0 syntax by default. Guillaume
[1] : http://dev.xwiki.org/xwiki/bin/view/Design/OverhaulOfXWikiClassesAndObjectsM...
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/
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).
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, I reached the same conclusion, and I already started working on this. If you also have some code, we should merge efforts.
[1] : http://dev.xwiki.org/xwiki/bin/view/Design/OverhaulOfXWikiClassesAndObjectsM...
-- Sergiu Dumitriu http://purl.org/net/sergiu/
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/OverhaulOfXWikiClassesAndObjectsM...
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
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 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)
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/OverhaulOfXWikiClassesAndObjectsM...
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
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 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)
+1 for the document metadata, but I also think that we should have the class type property, for later usage. No need to add it now, though.
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/OverhaulOfXWikiClassesAndObjectsM...
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)
-- Sergiu Dumitriu http://purl.org/net/sergiu/
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/OverhaulOfXWikiClassesAndObjectsM...
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
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/OverhaulOfXWikiClassesAndObjectsM...
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
On Tue, Apr 28, 2009 at 11:39 AM, Vincent Massol <[email protected]> wrote:
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.
Could you briefly explain why you think we're not ready for this ? Thanks, JV.
On Apr 28, 2009, at 11:49 AM, Jean-Vincent Drean wrote:
On Tue, Apr 28, 2009 at 11:39 AM, Vincent Massol <[email protected]> wrote:
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.
Could you briefly explain why you think we're not ready for this ?
See my previous mail :) Thanks -Vincent
Vincent Massol wrote:
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).
+1 Important changes done in a .m release are not a good idea anyway. -- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (6)
-
Guillaume Lerouge -
Jean-Vincent Drean -
Jerome Velociter -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol