28 Jun
2011
28 Jun
'11
6:43 p.m.
Hi devs,
A prerequisite for Application Within Minutes [1] is to be able to
specify the sheet that will be used to display a document without
touching the content of that document [2]. This can be done in multiple
ways, depending on how we define the notion of a sheet.
(1) Class sheets vs. document sheets
A class sheet displays an object of a particular type and is specified
in the definition of that type. This means that when you create or edit
a class, i.e. a type of object, you can specify which sheet should be
used to display the instances of that class.
Pro: Documents don't have to specify a sheet.
Con: We have to determine which sheet to use in case there are multiple
objects attached to a document.
A document sheet displays a document of a particular type and is
specified at document level because the document type, unlike the
xclass, does not exist actually. The document type is inferred from the
type of objects the document has, or from its content, or, why not, from
the type of attachments it has.
Pro: Doesn't have the class sheet con.
Con: Each document has to specify which sheet to use.
Class sheets are enough for Application Within Minutes because the
wizard will create a single class (with a sheet) and so the application
items will have only one object that specifies a sheet.
(2) Separate sheets per action?
The current practice is to define a single (class) sheet which either
checks for the current action in its code or uses doc.display method
whose output is action specific.
How often did you had the need to write separate sheets per action (e.g.
create, view, edit, search, changes)?
(3) Which actions require a sheet?
If we're talking about class sheets then the list of actions that target
an object and which require a sheet is limited. Currently we have "view"
and "edit", but Ludovic proposed also "create", "search" and
"changes".
If we're talking about document sheets then we can have custom actions
and so we need an extensible mechanism to map actions to sheets.
(4) Sheet parameters?
If we're talking about class sheets then they only need to specify how
an object is displayed. Document sheets on the other hand may need to
control elements like:
* which tabs (comments, annotations, attachments, etc.), if any, are
displayed
* show title field in edit mode
* the side panels
* the form buttons
WDYT?
Thanks,
Marius
[1] http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes
[2]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…
28 Jun
28 Jun
7:21 p.m.
On Tue, Jun 28, 2011 at 18:43, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Hi devs,
A prerequisite for Application Within Minutes [1] is to be able to
specify the sheet that will be used to display a document without
touching the content of that document [2]. This can be done in multiple
ways, depending on how we define the notion of a sheet.
(1) Class sheets vs. document sheets
A class sheet displays an object of a particular type and is specified
in the definition of that type. This means that when you create or edit
a class, i.e. a type of object, you can specify which sheet should be
used to display the instances of that class.
Pro: Documents don't have to specify a sheet.
Con: We have to determine which sheet to use in case there are multiple
objects attached to a document.
There could be a choice, i.e. one is used by default but you can
change it from a list in the UI (the same way you can switch from
object editor to content editor). There is still a problem to choose
the default one but it's less critical.
A document sheet displays a document of a particular type and is
specified at document level because the document type, unlike the
xclass, does not exist actually. The document type is inferred from the
type of objects the document has, or from its content, or, why not, from
the type of attachments it has.
Pro: Doesn't have the class sheet con.
Con: Each document has to specify which sheet to use.
Should not be class sheet against document sheet IMO, we should
instead define a chain of choice:
* is there an explicit sheet defined for the document ?
* if not then try to find it based on class of object stored in this document
That way for specific document that really need to explicitly force
the sheet to use they can but class sheet should do for 90% of the
others.
Class sheets are enough for Application Within Minutes because the
wizard will create a single class (with a sheet) and so the application
items will have only one object that specifies a sheet.
(2) Separate sheets per action?
The current practice is to define a single (class) sheet which either
checks for the current action in its code or uses doc.display method
whose output is action specific.
How often did you had the need to write separate sheets per action (e.g.
create, view, edit, search, changes)?
Yep the #if about action are not very nice, would be better for
developer to be able to associate the sheet to one or several actions
(maybe some like the #if after all ;))
(3) Which actions require a sheet?
If we're talking about class sheets then the list of actions that target
an object and which require a sheet is limited. Currently we have "view"
and "edit", but Ludovic proposed also "create", "search"
and "changes".
If we're talking about document sheets then we can have custom actions
and so we need an extensible mechanism to map actions to sheets.
Indeed if it's not just about editing there should probably be other
actions but I'm not sure which one. Not sure about search at document
level, if you really need a search at this level it probably mean you
have too many object in the same document and that there is a design
issue.
What is "changes" ?
(4) Sheet parameters?
If we're talking about class sheets then they only need to specify how
an object is displayed. Document sheets on the other hand may need to
control elements like:
* which tabs (comments, annotations, attachments, etc.), if any, are
displayed
* show title field in edit mode
* the side panels
* the form buttons
Indeed I only tough about document content display but could be nice
to have something to setup theses aspects outside of document content
too.
Now it's not easy to know what to put in there since skins could be
very different and some of them would not mean anything depending of
the context and it could goes as far as document skin. I'm not sure
it's really the same subject. Merging both would maybe create more
issues than it solve. Most of them are pretty specific to the view
action.
But again I don't know, it just feel too much to merge them.
WDYT?
Thanks,
Marius
[1] http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes
[2]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
8:23 p.m.
On Tue, Jun 28, 2011 at 7:21 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
Yes. Writing separate view and edit is really common place as of today. Note
that better exposure of the custom display feature would maybe help reducing
this (though one has to make that same #if inside the custom display then).
Also you definitely need to have separate view and edit sheets when for
example order of properties are not the same in both modes.
Jerome
On Tue, Jun 28, 2011 at 18:43, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
In my opinion they should rather be aggregated on the same page. Switching
view from the UI sounds contrived to me, from a UI point of view.
Still you have the order issue ; which can be solved by introducing a
priority factor in XClasses.
Hi devs,
A prerequisite for Application Within Minutes [1] is to be able to
specify the sheet that will be used to display a document without
touching the content of that document [2]. This can be done in multiple
ways, depending on how we define the notion of a sheet.
(1) Class sheets vs. document sheets
A class sheet displays an object of a particular type and is specified
in the definition of that type. This means that when you create or edit
a class, i.e. a type of object, you can specify which sheet should be
used to display the instances of that class.
Pro: Documents don't have to specify a sheet.
Con: We have to determine which sheet to use in case there are multiple
objects attached to a document.
There could be a choice, i.e. one is used by default but you can
change it from a list in the UI (the same way you can switch from
object editor to content editor). There is still a problem to choose
the default one but it's less critical.
A document sheet displays a document of a particular type and is
specified at document level because the document type, unlike the
xclass, does not exist actually. The document type is inferred from the
type of objects the document has, or from its content, or, why not, from
the type of attachments it has.
Pro: Doesn't have the class sheet con.
Con: Each document has to specify which sheet to use.
Should not be class sheet against document sheet IMO, we should
instead define a chain of choice:
* is there an explicit sheet defined for the document ?
* if not then try to find it based on class of object stored in this
document
That way for specific document that really need to explicitly force
the sheet to use they can but class sheet should do for 90% of the
others.
Class sheets are enough for Application Within Minutes because the
wizard will create a single class (with a sheet) and so the application
items will have only one object that specifies a sheet.
(2) Separate sheets per action?
The current practice is to define a single (class) sheet which either
checks for the current action in its code or uses doc.display method
whose output is action specific.
How often did you had the need to write separate sheets per action (e.g.
create, view, edit, search, changes)?
Yep the #if about action are not very nice, would be better for
developer to be able to associate the sheet to one or several actions
(maybe some like the #if after all ;))
(3) Which actions require a sheet?
If we're talking about class sheets then the list of actions that target
an object and which require a sheet is limited. Currently we have "view"
and "edit", but Ludovic proposed also "create", "search"
and "changes".
If we're talking about document sheets then we can have custom actions
and so we need an extensible mechanism to map actions to sheets.
Indeed if it's not just about editing there should probably be other
actions but I'm not sure which one. Not sure about search at document
level, if you really need a search at this level it probably mean you
have too many object in the same document and that there is a design
issue.
What is "changes" ?
(4) Sheet parameters?
If we're talking about class sheets then they only need to specify how
an object is displayed. Document sheets on the other hand may need to
control elements like:
* which tabs (comments, annotations, attachments, etc.), if any, are
displayed
* show title field in edit mode
* the side panels
* the form buttons
Indeed I only tough about document content display but could be nice
to have something to setup theses aspects outside of document content
too.
Now it's not easy to know what to put in there since skins could be
very different and some of them would not mean anything depending of
the context and it could goes as far as document skin. I'm not sure
it's really the same subject. Merging both would maybe create more
issues than it solve. Most of them are pretty specific to the view
action.
But again I don't know, it just feel too much to merge them.
WDYT?
Thanks,
Marius
[1] http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes
[2]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5 Jul
5 Jul
8:38 a.m.
On 06/28/2011 08:21 PM, Thomas Mortagne wrote:
On Tue, Jun 28, 2011 at 18:43, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Hi devs,
A prerequisite for Application Within Minutes [1] is to be able to
specify the sheet that will be used to display a document without
touching the content of that document [2]. This can be done in multiple
ways, depending on how we define the notion of a sheet.
(1) Class sheets vs. document sheets
A class sheet displays an object of a particular type and is specified
in the definition of that type. This means that when you create or edit
a class, i.e. a type of object, you can specify which sheet should be
used to display the instances of that class.
Pro: Documents don't have to specify a sheet.
Con: We have to determine which sheet to use in case there are multiple
objects attached to a document.
There could be a choice, i.e. one is used by default but you can
change it from a list in the UI (the same way you can switch from
object editor to content editor). There is still a problem to choose
the default one but it's less critical.
A document sheet displays a document of a particular type and is
specified at document level because the document type, unlike the
xclass, does not exist actually. The document type is inferred from the
type of objects the document has, or from its content, or, why not, from
the type of attachments it has.
Pro: Doesn't have the class sheet con.
Con: Each document has to specify which sheet to use.
Should not be class sheet against document sheet IMO, we should
instead define a chain of choice:
* is there an explicit sheet defined for the document ?
* if not then try to find it based on class of object stored in this document
That way for specific document that really need to explicitly force
the sheet to use they can but class sheet should do for 90% of the
others.
Class sheets are enough for Application Within Minutes because the
wizard will create a single class (with a sheet) and so the application
items will have only one object that specifies a sheet.
(2) Separate sheets per action?
The current practice is to define a single (class) sheet which either
checks for the current action in its code or uses doc.display method
whose output is action specific.
How often did you had the need to write separate sheets per action (e.g.
create, view, edit, search, changes)?
Yep the #if about action are not very nice, would be better for
developer to be able to associate the sheet to one or several actions
(maybe some like the #if after all ;))
(3) Which actions require a sheet?
If we're talking about class sheets then the list of actions that target
an object and which require a sheet is limited. Currently we have "view"
and "edit", but Ludovic proposed also "create", "search"
and "changes".
If we're talking about document sheets then we can have custom actions
and so we need an extensible mechanism to map actions to sheets.
Indeed if it's not just about editing there should probably be other
actions but I'm not sure which one. Not sure about search at document
level, if you really need a search at this level it probably mean you
have too many object in the same document and that there is a design
issue.
What is "changes" ?
A diff view, if I understood correctly from Ludovic's description:
"(for custom changes display) This could only apply for the changes
display of a specific OBJECT or the full changes page, or there could be
2 sheets one for the full changes page and one for an individual change."
Thanks,
Marius
(4) Sheet parameters?
If we're talking about class sheets then they only need to specify how
an object is displayed. Document sheets on the other hand may need to
control elements like:
* which tabs (comments, annotations, attachments, etc.), if any, are
displayed
* show title field in edit mode
* the side panels
* the form buttons
Indeed I only tough about document content display but could be nice
to have something to setup theses aspects outside of document content
too.
Now it's not easy to know what to put in there since skins could be
very different and some of them would not mean anything depending of
the context and it could goes as far as document skin. I'm not sure
it's really the same subject. Merging both would maybe create more
issues than it solve. Most of them are pretty specific to the view
action.
But again I don't know, it just feel too much to merge them.
WDYT?
Thanks,
Marius
[1] http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes
[2]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4 Jul
4 Jul
5:34 p.m.
On Tue, Jun 28, 2011 at 6:43 PM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Hi devs,
A prerequisite for Application Within Minutes [1] is to be able to
specify the sheet that will be used to display a document without
touching the content of that document [2]. This can be done in multiple
ways, depending on how we define the notion of a sheet.
(1) Class sheets vs. document sheets
A class sheet displays an object of a particular type and is specified
in the definition of that type. This means that when you create or edit
a class, i.e. a type of object, you can specify which sheet should be
used to display the instances of that class.
Pro: Documents don't have to specify a sheet.
Con: We have to determine which sheet to use in case there are multiple
objects attached to a document.
What about displaying objects one after the other ?
I think sheets must be seen as a way to display an object and not the
whole page [1].
http://dev.xwiki.org/xwiki/bin/download/Design/OverhaulOfXWikiClassesAndObj…
A document sheet displays a document of a particular type and is
specified at document level because the document type, unlike the
xclass, does not exist actually. The document type is inferred from the
type of objects the document has, or from its content, or, why not, from
the type of attachments it has.
Pro: Doesn't have the class sheet con.
Con: Each document has to specify which sheet to use.
If the document type can be inferred from the objects it contains, can
we say that each document has to specify the sheet it uses ?
Class sheets are enough for Application Within Minutes because the
wizard will create a single class (with a sheet) and so the application
items will have only one object that specifies a sheet.
[snip]
(4) Sheet parameters?
If we're talking about class sheets then they only need to specify how
an object is displayed. Document sheets on the other hand may need to
control elements like:
* which tabs (comments, annotations, attachments, etc.), if any, are
displayed
* show title field in edit mode
* the side panels
* the form buttons
I'd add "show document content" to the list.
Thanks,
JV.
5 Jul
5 Jul
8:35 a.m.
On 07/04/2011 06:34 PM, Jean-Vincent Drean wrote:
On Tue, Jun 28, 2011 at 6:43 PM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Hi devs,
A prerequisite for Application Within Minutes [1] is to be able to
specify the sheet that will be used to display a document without
touching the content of that document [2]. This can be done in multiple
ways, depending on how we define the notion of a sheet.
(1) Class sheets vs. document sheets
A class sheet displays an object of a particular type and is specified
in the definition of that type. This means that when you create or edit
a class, i.e. a type of object, you can specify which sheet should be
used to display the instances of that class.
Pro: Documents don't have to specify a sheet.
Con: We have to determine which sheet to use in case there are multiple
objects attached to a document.
What about displaying objects one after the other ?
I think sheets must be seen as a way to display an object and not the
whole page [1].
http://dev.xwiki.org/xwiki/bin/download/Design/OverhaulOfXWikiClassesAndObj…
I like this idea, but don't you think there are use cases when you need
a custom sheet that aggregates properties from different objects and
displays them in a mixed order?
A document sheet displays a document of a particular type and is
specified at document level because the document type, unlike the
xclass, does not exist actually. The document type is inferred from the
type of objects the document has, or from its content, or, why not, from
the type of attachments it has.
Pro: Doesn't have the class sheet con.
Con: Each document has to specify which sheet to use.
If the document type can be inferred from the objects
it contains, can
we say that each document has to specify the sheet it uses ?
The difference comes from the way you specify the sheet:
* indirectly: you just add some objects and the sheet(s) is (are)
automatically detected from the type of objects
* directly: you add some (data) objects + an object to explicitly
specify the sheet to use (in fact, there could be more sheet objects,
each mapping a sheet to an action)
Thanks,
Marius
Class sheets are enough for Application Within Minutes because the
wizard will create a single class (with a sheet) and so the application
items will have only one object that specifies a sheet.
[snip]
(4) Sheet parameters?
If we're talking about class sheets then they only need to specify how
an object is displayed. Document sheets on the other hand may need to
control elements like:
* which tabs (comments, annotations, attachments, etc.), if any, are
displayed
* show title field in edit mode
* the side panels
* the form buttons
I'd add "show document content" to the list.
Thanks,
JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
8:44 a.m.
On Tue, Jul 5, 2011 at 8:35 AM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On 07/04/2011 06:34 PM, Jean-Vincent Drean wrote:
Probably, but it's the marginal use case.
Displaying objects one after another is the standard use case.
What this mean in my opinion is that the later (one sheet per object)
should be *easy* to achieve while the first (one sheet for all
objects) should be *possible* to achieve.
Jerome.
On Tue, Jun 28, 2011 at 6:43 PM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Hi devs,
A prerequisite for Application Within Minutes [1] is to be able to
specify the sheet that will be used to display a document without
touching the content of that document [2]. This can be done in multiple
ways, depending on how we define the notion of a sheet.
(1) Class sheets vs. document sheets
A class sheet displays an object of a particular type and is specified
in the definition of that type. This means that when you create or edit
a class, i.e. a type of object, you can specify which sheet should be
used to display the instances of that class.
Pro: Documents don't have to specify a sheet.
Con: We have to determine which sheet to use in case there are multiple
objects attached to a document.
What about displaying objects one after the other
?
I think sheets must be seen as a way to display an object and not the
whole page [1].
http://dev.xwiki.org/xwiki/bin/download/Design/OverhaulOfXWikiClassesAndObj…
I like this idea, but don't you think there are use cases when you need
a custom sheet that aggregates properties from different objects and
displays them in a mixed order?
A document sheet displays a document of a particular type and is
specified at document level because the document type, unlike the
xclass, does not exist actually. The document type is inferred from the
type of objects the document has, or from its content, or, why not, from
the type of attachments it has.
Pro: Doesn't have the class sheet con.
Con: Each document has to specify which sheet to use.
If the document type can be inferred from the
objects it contains, can
we say that each document has to specify the sheet it uses ?
The difference comes from the way you specify the sheet:
* indirectly: you just add some objects and the sheet(s) is (are)
automatically detected from the type of objects
* directly: you add some (data) objects + an object to explicitly
specify the sheet to use (in fact, there could be more sheet objects,
each mapping a sheet to an action)
Thanks,
Marius
Class sheets are enough for Application Within Minutes because the
wizard will create a single class (with a sheet) and so the application
items will have only one object that specifies a sheet.
[snip]
(4) Sheet parameters?
If we're talking about class sheets then they only need to specify how
an object is displayed. Document sheets on the other hand may need to
control elements like:
* which tabs (comments, annotations, attachments, etc.), if any, are
displayed
* show title field in edit mode
* the side panels
* the form buttons
I'd add "show document content" to the list.
Thanks,
JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:26 a.m.
On Tue, Jul 5, 2011 at 08:35, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
That's how I understand it too. Will makes easy to do powerful things
and also add a lot of new extensions possibilities.
On 07/04/2011 06:34 PM, Jean-Vincent Drean wrote:
That's would be the default behavior when you only have object and
their sheets, then if you want custom sheet for a document you set one
which is doing anything you wants.
On Tue, Jun 28, 2011 at 6:43 PM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Hi devs,
A prerequisite for Application Within Minutes [1] is to be able to
specify the sheet that will be used to display a document without
touching the content of that document [2]. This can be done in multiple
ways, depending on how we define the notion of a sheet.
(1) Class sheets vs. document sheets
A class sheet displays an object of a particular type and is specified
in the definition of that type. This means that when you create or edit
a class, i.e. a type of object, you can specify which sheet should be
used to display the instances of that class.
Pro: Documents don't have to specify a sheet.
Con: We have to determine which sheet to use in case there are multiple
objects attached to a document.
What about displaying objects one after the other
?
I think sheets must be seen as a way to display an object and not the
whole page [1].
http://dev.xwiki.org/xwiki/bin/download/Design/OverhaulOfXWikiClassesAndObj…
I like this idea, but don't you think there are use cases when you need
a custom sheet that aggregates properties from different objects and
displays them in a mixed order?
A document sheet displays a document of a particular type and is
specified at document level because the document type, unlike the
xclass, does not exist actually. The document type is inferred from the
type of objects the document has, or from its content, or, why not, from
the type of attachments it has.
Pro: Doesn't have the class sheet con.
Con: Each document has to specify which sheet to use.
If the document type can be inferred from the
objects it contains, can
we say that each document has to specify the sheet it uses ?
The difference comes from the way you specify the sheet:
* indirectly: you just add some objects and the sheet(s) is (are)
automatically detected from the type of objects
* directly: you add some (data) objects + an object to explicitly
specify the sheet to use (in fact, there could be more sheet objects,
each mapping a sheet to an action)
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
Class sheets are enough for Application Within Minutes because the
wizard will create a single class (with a sheet) and so the application
items will have only one object that specifies a sheet.
[snip]
(4) Sheet parameters?
If we're talking about class sheets then they only need to specify how
an object is displayed. Document sheets on the other hand may need to
control elements like:
* which tabs (comments, annotations, attachments, etc.), if any, are
displayed
* show title field in edit mode
* the side panels
* the form buttons
I'd add "show document content" to the list.
Thanks,
JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
3:56 p.m.
2011/7/5 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
That's how I understand it too. Will makes easy to do powerful things
and also add a lot of new extensions possibilities.
>
> Thanks,
> Marius
>
>>
>>>
>>> Class sheets are enough for Application Within Minutes because the
>>> wizard will create a single class (with a sheet) and so the application
>>> items will have only one object that specifies a sheet.
>>>
>>> [snip]
>>>
>>> (4) Sheet parameters?
>>>
>>> If we're talking about class sheets then they only need to specify how
>>> an object is displayed. Document sheets on the other hand may need to
>>> control elements like:
>>>
>>> * which tabs (comments, annotations, attachments, etc.), if any, are
>>> displayed
>>> * show title field in edit mode
>>> * the side panels
>>> * the form buttons
>>>
>>
>> I'd add "show document content" to the list.
+1
The idea of these parameters is make sure we still have full control
on the view without having to go hack the skin
Ludovic
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
On Tue, Jul 5, 2011 at 08:35, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
90% of the cases will be defining the sheet to use for all documents
using 1 specific class (and only one).
Maybe 8% would be having additional classes in the same document and
still want to display the same for all documents like that
And 2% will be having an exception when a specific document would have
it's own specific display for what is in there.
Inside the 90% we might want to have some additional objects being
displayed as a tab at the bottom of the page (with comments,
information, etc..)
Inside the 90% (maybe half of them) you might want to have full
control of the complete display.
Generally I like the idea for modularizing the sheet notion but I'm
afraid that this can create more problems than what it solves, because
while it gives us great possibilities for the display of the object
itself, it does not gives us information about the rest of the display
(title, wether to put the content field or not, order of the objects
if there are multiple ones, etc..)
But as I said in many of the 90% of the cases you might want to have
full control of the display (it's done all the time on customer
projects), so you need a way to tell that for all these documents
(which have a specific class inside) you want the full view or edit
display displayed the way you decide it.
Now I think we could include a parameter that tells us if the sheet is
taking control of the full view/edit display or not.
So from my point of view:
- the sheets should be listed in the class
- the sheet and/or the class should include parameters
- the sheet and/or the class should tell if it applies top level or
object level only (there could be even 3 levels: the global level, the
edit/view mode level depending on the mode, the object level inside
the edit/view level, the bottom tab level)
We also need a way to tell which sheet to use for the mode
(view/edit/...). We could also have this either in the class or in the
sheet.
Once way to be consistent would be to all have this in the sheet and
then have the system find anything that matches the use case, include
an importance order.
"Give me a sheet for this document for the edit mode"
This function could return multiple valid sheets with an order of importance.
The first one from the list would be the one used by default.
Of course it could be possible to override that view with the menus
(and param in the URL), and a specific document could set a specific
sheet to be used for a specific mode.
On 07/04/2011 06:34 PM, Jean-Vincent Drean
wrote:
That's would be the default behavior when you only have object and
their sheets, then if you want custom sheet for a document you set one
which is doing anything you wants. On Tue, Jun 28, 2011 at 6:43 PM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
Hi devs,
A prerequisite for Application Within Minutes [1] is to be able to
specify the sheet that will be used to display a document without
touching the content of that document [2]. This can be done in multiple
ways, depending on how we define the notion of a sheet.
(1) Class sheets vs. document sheets
A class sheet displays an object of a particular type and is specified
in the definition of that type. This means that when you create or edit
a class, i.e. a type of object, you can specify which sheet should be
used to display the instances of that class.
Pro: Documents don't have to specify a sheet.
Con: We have to determine which sheet to use in case there are multiple
objects attached to a document.
What about displaying objects one after the other
?
I think sheets must be seen as a way to display an object and not the
whole page [1].
http://dev.xwiki.org/xwiki/bin/download/Design/OverhaulOfXWikiClassesAndObj…
I like this idea, but don't you think there are use cases when you need
a custom sheet that aggregates properties from different objects and
displays them in a mixed order?
A document sheet displays a document of a particular type and is
specified at document level because the document type, unlike the
xclass, does not exist actually. The document type is inferred from the
type of objects the document has, or from its content, or, why not, from
the type of attachments it has.
Pro: Doesn't have the class sheet con.
Con: Each document has to specify which sheet to use.
If the document type can be inferred from the
objects it contains, can
we say that each document has to specify the sheet it uses ?
The difference comes from the way you specify the sheet:
* indirectly: you just add some objects and the sheet(s) is (are)
automatically detected from the type of objects
* directly: you add some (data) objects + an object to explicitly
specify the sheet to use (in fact, there could be more sheet objects,
each mapping a sheet to an action) Thanks,
JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11 Jul
11 Jul
3:06 p.m.
Hi devs,
I'd like to make the following proposal based on your feedback:
(1) a sheet is a document that has an object of type XWiki.SheetClass
(2) the sheet code is stored in the sheet document content
(3) XWiki.SheetClass has the following properties:
display: Static List ('page', 'inline', 'meta')
action: String ('view', 'edit', etc.)
The 'display' property specifies where to place the sheet output:
* page: the sheet output overwrites the 'mainContentArea', 'xdocFooter'
and 'xwikidata' DIVs. This means everything besides the header (logo and
top menu), the content menu, the footer (version and license info) and
the side columns (panels).
* inline: the sheet output overwrites the content of the 'xwikicontent'
DIV in view mode and the form fields in edit mode (similar to the
current inline edit mode).
* meta: the sheet output is aggregated under the "Objects" document
extra tab. The bottom tabs are displayed only in view mode currently but
we can imagine ways to display 'meta' sheets in edit mode too.
The 'action' property specifies when to apply the sheet. The empty
string means the sheet can be applied on any action.
(4) Sheets can control the UI elements outside of their scope through
parameters, depending on the value of the display property:
* page: since sheets of this type control most of what is displayed the
only useful parameter is the list of left/right panels.
* inline: list of left/right panels, show/hide breadcrumb, show/hide
title, show/hide bottom tabs, list of bottom tabs, show/hide version
summary in edit mode.
* meta: no parameters because sheets of this type are used to display
secondary objects.
Now, regarding the way to set these parameters I think we have three
options:
(4A) String parameters
Use a generic class, XWiki.ParameterClass, with two string properties,
key and value.
pro: we can easily add a new parameter to the sheet (by adding a new
parameter object to the sheet document) without modifying the parameters
class.
con: error prone
(4B) Typed parameters
Use a specific class, XWiki.SheetConfigClass, with properties matching
configuration parameters.
pro: less error prone since parameters are typed and their names are
hard-coded
con: harder to add/remove/rename parameters
(4C) Velocity parameters
Add a TextArea property to the XWiki.SheetClass, called 'parameters',
where we can set velocity variables. The value of this property will be
evaluated in startpage.vm after xwikivars.vm and layoutvars.vm.
I prefer (4C).
(5) In order to declare a sheet a xclass (or a plain document) has to
use an object of type XWiki.SheetInclude that has only one Database list
property called 'sheet' which, obviously, specifies the sheet to be
applied. A xclass can include zero (no sheets) or more sheets (a
different sheet for a different action).
(6) The only case when sheets can conflict is when a document has
objects of different types that declare 'page' sheets for the same
action. Multiple objects with 'meta' sheets are aggregated under the
'Objects' tab. Multiple objects with 'inline' sheets are aggregated
inside the 'xwikicontent' element in view mode and inside the same HTML
form in edit mode. A 'page' sheet can choose to display 'inline' and
'meta' sheets, and of course 'inline' and 'meta' sheets can be
displayed
by the default view mode.
The conflict between 'page' sheets can be resolved by defining an order
between objects. I prefer an inherent order (e.g. the object that was
added first is the most/less important) rather than an explicit priority
field.
(7) Sheet resolution:
* if the current document has an object of type XWiki.SheetInclude and
the specified sheet has display:page and matches the current action then
apply it (in case there are more XWiki.SheetInclude objects that satisfy
this constraint then use the one with the lowest/highest index).
* if the current document has objects whose xclass declares a 'page'
sheet, then resolve the conflict and use the proper sheet.
* if there is no 'page' sheet included either by the current document or
by one of its objects then aggregate all 'inline' and 'meta' sheets
(from the objects and from the document itself).
* if there are no 'inline' sheets then simply display the default
view/edit mode.
WDYT?
Thanks,
Marius
On 06/28/2011 07:43 PM, Marius Dumitru Florea wrote:
Hi devs,
A prerequisite for Application Within Minutes [1] is to be able to
specify the sheet that will be used to display a document without
touching the content of that document [2]. This can be done in multiple
ways, depending on how we define the notion of a sheet.
(1) Class sheets vs. document sheets
A class sheet displays an object of a particular type and is specified
in the definition of that type. This means that when you create or edit
a class, i.e. a type of object, you can specify which sheet should be
used to display the instances of that class.
Pro: Documents don't have to specify a sheet.
Con: We have to determine which sheet to use in case there are multiple
objects attached to a document.
A document sheet displays a document of a particular type and is
specified at document level because the document type, unlike the
xclass, does not exist actually. The document type is inferred from the
type of objects the document has, or from its content, or, why not, from
the type of attachments it has.
Pro: Doesn't have the class sheet con.
Con: Each document has to specify which sheet to use.
Class sheets are enough for Application Within Minutes because the
wizard will create a single class (with a sheet) and so the application
items will have only one object that specifies a sheet.
(2) Separate sheets per action?
The current practice is to define a single (class) sheet which either
checks for the current action in its code or uses doc.display method
whose output is action specific.
How often did you had the need to write separate sheets per action (e.g.
create, view, edit, search, changes)?
(3) Which actions require a sheet?
If we're talking about class sheets then the list of actions that target
an object and which require a sheet is limited. Currently we have "view"
and "edit", but Ludovic proposed also "create", "search"
and "changes".
If we're talking about document sheets then we can have custom actions
and so we need an extensible mechanism to map actions to sheets.
(4) Sheet parameters?
If we're talking about class sheets then they only need to specify how
an object is displayed. Document sheets on the other hand may need to
control elements like:
* which tabs (comments, annotations, attachments, etc.), if any, are
displayed
* show title field in edit mode
* the side panels
* the form buttons
WDYT?
Thanks,
Marius
[1] http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes
[2]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…
1 Aug
1 Aug
2:40 p.m.
Hi Marius,
please see my answers below.
On Mon, Jul 11, 2011 at 3:06 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
space mapping anyway).
* page: since sheets of this type control most of what is displayed the
That I'm looking forward to seeing all this implemented ;-)
Thanks,
Guillaume
Thanks,
> Marius
> On 06/28/2011 07:43 PM, Marius Dumitru
Florea wrote:
> > Hi devs,
> > > A prerequisite for Application Within
Minutes [1] is to be able to
> > specify the sheet that will be used to display a document without
> > touching the content of that document [2]. This can be done in multiple
> > ways, depending on how we define the notion of a sheet.
> >
> > (1) Class sheets vs. document sheets
> > > A class sheet displays an object of a
particular type and is specified
> > in the definition of that type. This means that when you create or edit
> > a class, i.e. a type of object, you can specify which sheet should be
> > used to display the instances of that class.
> > > Pro: Documents don't have to
specify a sheet.
> > Con: We have to determine which sheet to use in case there are multiple
> > objects attached to a document.
> > > A document sheet displays a document
of a particular type and is
> > specified at document level because the document type, unlike the
> > xclass, does not exist actually. The document type is inferred from the
> > type of objects the document has, or from its content, or, why not, from
> > the type of attachments it has.
> > > Pro: Doesn't have the class sheet
con.
> > Con: Each document has to specify which sheet to use.
> > > Class sheets are enough for
Application Within Minutes because the
> > wizard will create a single class (with a sheet) and so the application
> > items will have only one object that specifies a sheet.
> >
> > (2) Separate sheets per action?
> > > The current practice is to define a
single (class) sheet which either
> > checks for the current action in its code or uses doc.display method
> > whose output is action specific.
> > > How often did you had the need to
write separate sheets per action (e.g.
> > create, view, edit, search, changes)?
> >
> > (3) Which actions require a sheet?
> > > If we're talking about class
sheets then the list of actions that target
> > an object and which require a sheet is limited. Currently we have
"view"
> > and "edit", but Ludovic proposed also "create",
"search" and "changes".
> > > If we're talking about document
sheets then we can have custom actions
> > and so we need an extensible mechanism to map actions to sheets.
> >
> > (4) Sheet parameters?
> > > If we're talking about class
sheets then they only need to specify how
> > an object is displayed. Document sheets on the other hand may need to
> > control elements like:
> > > * which tabs (comments, annotations,
attachments, etc.), if any, are
> > displayed
> > * show title field in edit mode
> > * the side panels
> > * the form buttons
> >
> > WDYT?
> > > Thanks,
> > Marius
> > > [1]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes
> > [2]
> >
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…
> >
_______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
Hi devs,
I'd like to make the following proposal based on your feedback:
(1) a sheet is a document that has an object of type XWiki.SheetClass
Ok.
(2) the sheet code is stored in the sheet document
content
Ok.
(3) XWiki.SheetClass has the following properties:
display: Static List ('page', 'inline', 'meta')
action: String ('view', 'edit', etc.)
The 'display' property specifies where to place the sheet output:
* page: the sheet output overwrites the 'mainContentArea', 'xdocFooter'
and 'xwikidata' DIVs. This means everything besides the header (logo and
top menu), the content menu, the footer (version and license info) and
the side columns (panels).
Ok.
* inline: the sheet output overwrites the content of
the 'xwikicontent'
DIV in view mode and the form fields in edit mode (similar to the
current inline edit mode).
So the title field is not included, correct? If so, I think it would be good
to display the title field by default in inline mode so that users can
access it and modify it.
* meta: the sheet output is aggregated under the
"Objects" document
extra tab. The bottom tabs are displayed only in view mode currently but
we can imagine ways to display 'meta' sheets in edit mode too.
I think it would be better to be able to create a custom tab rather than a
generic "Objects" tab. "Objects" is a technical term and I don't
think users
would have the reflex to go and look at that tab.
In that case you would need to be able to define the title to display in the
tab, maybe through a translation key stored in a field of the ClassSheet
object.
The 'action' property specifies when to apply
the sheet. The empty
string means the sheet can be applied on any action.
What about a multi-select instead of a string given that the list of
existing actions is already known?
(4) Sheets can control the UI elements outside of
their scope through
parameters, depending on the value of the display property:
I'm not sure I agree with this. Panels should not be affected by something
else than their existing interface, that will confuse users. I'm not sure I
see the added value of defining panels at the class level. It's a simple to
define them at the space level (and there's very often an application <= only useful parameter is the list of left/right
panels.
* inline: list of left/right panels, show/hide breadcrumb, show/hide
title, show/hide bottom tabs, list of bottom tabs, show/hide version
summary in edit mode.
And default bottom tab. I think all these options should be provided for
every page in the wiki under an "advanced" section (including normal wiki
pages). I don't see a reason to restrict those options only to pages that
have an object.
As for the interface, checkboxes would do. I'm not sure where they would be
stored though, maybe in a new "XWikiDocument" object?
* meta: no parameters because sheets of this type are
used to display
secondary objects.
Now, regarding the way to set these parameters I think we have three
options:
Based on what I said above, the need for such an interface would be only for
page-level settings. I have no preference about how to store them, a text
area would be fine as long as the user interface is made of checkboxes and
lists.
(4A) String parameters
Use a generic class, XWiki.ParameterClass, with two string properties,
key and value.
pro: we can easily add a new parameter to the sheet (by adding a new
parameter object to the sheet document) without modifying the parameters
class.
con: error prone
(4B) Typed parameters
Use a specific class, XWiki.SheetConfigClass, with properties matching
configuration parameters.
pro: less error prone since parameters are typed and their names are
hard-coded
con: harder to add/remove/rename parameters
(4C) Velocity parameters
Add a TextArea property to the XWiki.SheetClass, called 'parameters',
where we can set velocity variables. The value of this property will be
evaluated in startpage.vm after xwikivars.vm and layoutvars.vm.
I prefer (4C).
(5) In order to declare a sheet a xclass (or a plain document) has to
use an object of type XWiki.SheetInclude that has only one Database list
property called 'sheet' which, obviously, specifies the sheet to be
applied. A xclass can include zero (no sheets) or more sheets (a
different sheet for a different action).
Ok. We'll also need to update the XWiki.ClassSheet page to provide a nice
interface for this.
(6) The only case when sheets can conflict is when a document has
objects of different types that declare 'page'
sheets for the same
action. Multiple objects with 'meta' sheets are aggregated under the
'Objects' tab. Multiple objects with 'inline' sheets are aggregated
inside the 'xwikicontent' element in view mode and inside the same HTML
form in edit mode. A 'page' sheet can choose to display 'inline' and
'meta' sheets, and of course 'inline' and 'meta' sheets can be
displayed
by the default view mode.
The conflict between 'page' sheets can be resolved by defining an order
between objects. I prefer an inherent order (e.g. the object that was
added first is the most/less important) rather than an explicit priority
field.
I think that's going to be an edge use case. Usually when you go through the
hassle of building a complete new page to display specific objects, your
display is very customized anyway and you can write a page sheet that
aggregates 2 other page sheets if needed.
(7) Sheet resolution:
* if the current document has an object of type XWiki.SheetInclude and
the specified sheet has display:page and matches the current action then
apply it
Ok.
(in case there are more XWiki.SheetInclude objects
that satisfy
this constraint then use the one with the lowest/highest index).
I think that this is actually the sign of an error on the part of the dev
who created the application, but your solution would work.
* if the current document has objects whose xclass
declares a 'page'
sheet, then resolve the conflict and use the proper sheet.
* if there is no 'page' sheet included either by the current document or
by one of its objects then aggregate all 'inline' and 'meta' sheets
(from the objects and from the document itself).
* if there are no 'inline' sheets then simply display the default
view/edit mode.
Ok.
WDYT?
3 Aug
3 Aug
10:49 a.m.
Hi Guillaume,
First of all, thanks for your feedback. See my comments below.
On 08/01/2011 03:40 PM, Guillaume Lerouge wrote:
Hi Marius,
please see my answers below.
On Mon, Jul 11, 2011 at 3:06 PM, Marius Dumitru Florea<
mariusdumitru.florea(a)xwiki.com> wrote:
Hi devs,
I'd like to make the following proposal based on your feedback:
(1) a sheet is a document that has an object of type XWiki.SheetClass
Ok.
(2) the sheet code is stored in the sheet
document content
Ok.
(3) XWiki.SheetClass has the following
properties:
display: Static List ('page', 'inline', 'meta')
action: String ('view', 'edit', etc.)
The 'display' property specifies where to place the sheet output:
* page: the sheet output overwrites the 'mainContentArea', 'xdocFooter'
and 'xwikidata' DIVs. This means everything besides the header (logo and
top menu), the content menu, the footer (version and license info) and
the side columns (panels).
Ok.
* inline: the sheet output overwrites the content
of the 'xwikicontent'
DIV in view mode and the form fields in edit mode (similar to the
current inline edit mode).
So the title field is not included, correct? If so, I
think it would be good
to display the title field by default in inline mode so that users can
access it and modify it.
The output of an inline sheet is placed where the content of the
document is currently placed. This means that a sheet with
display:inline doesn't control the title of the document, i.e. the title
of the document is displayed whatever output the sheet may have.
When you edit (inline) a blog post the title of the document is
displayed followed by a title input field. They are synchronized because
document title is set to $doc.getValue("title"). With the new sheet
system we can (and should!) reuse the title and content of a document.
For instance we could remove the "title" and "content" fields from the
BlogPostClass and use instead the title and the content of the document
holding the blog post object.
With this in mind, do you think the current "inline" edit behaviour
(document title displayed read-only followed by sheet output) is bad? I
don't think so. I think it's best to let the sheet decide what form
fields to display. If we were to display the title input then what do we
do about document parent and document syntax? Should we also allow users
to edit them in "inline" edit mode? I don't think so.
* meta: the sheet output is aggregated under the
"Objects" document
extra tab. The bottom tabs are displayed only in view mode currently but
we can imagine ways to display 'meta' sheets in edit mode too.
I think it would be better to be able to create a
custom tab rather than a
generic "Objects" tab. "Objects" is a technical term and I don't
think users
would have the reflex to go and look at that tab.
I thought about this initially but I gave up the idea because I felt is
was too complicated considering how bottom tabs are currently
implemented (with velocity templates). I'm going to postpone the "meta"
sheets for a while and focus only on "page" and "inline" sheets.
In that case you would need to be able to define the title to display in the
tab, maybe through a translation key stored in a field of the ClassSheet
object.
The 'action' property specifies when to
apply the sheet. The empty
string means the sheet can be applied on any action.
What about a multi-select instead of a string given
that the list of
existing actions is already known?
In the near future actions will be implemented as components (with the
help of the xwiki-platform-action module). XWiki applications will be
able to define their own actions so we can't use a static list for the
"action" sheet property.
(4) Sheets can control the UI elements outside of
their scope through
parameters, depending on the value of the display property:
I'm not sure I agree with this. Panels should not
be affected by something
else than their existing interface, that will confuse users. I'm not sure I
see the added value of defining panels at the class level. It's a simple to
define them at the space level (and there's very often an application<=>
space mapping anyway).
Ludovic proposed this btw.
* page: since sheets of this type control most of what is displayed the
only useful parameter is the list of left/right
panels.
* inline: list of left/right panels, show/hide breadcrumb, show/hide
title, show/hide bottom tabs, list of bottom tabs, show/hide version
summary in edit mode.
And default bottom tab. I think all these options
should be provided for
every page in the wiki under an "advanced" section (including normal wiki
pages). I don't see a reason to restrict those options only to pages that
have an object.
I partially agree with you, but it would be a pain, for instance, to
have to configure all the blog post documents when you want change the
default bottom tab. It is a lot easier to just configure the
BlogPostSheet document and then enforce its configuration to all
documents holding a BlogPostClass object.
I think you'll agree with me that a system that allows us to configure a
wiki page, defaulting to the sheet configuration (when that document has
a sheet of course) is the best option.
As for the interface, checkboxes would do. I'm not sure where they would be
stored though, maybe in a new "XWikiDocument" object?
* meta: no parameters because sheets of this type
are used to display
secondary objects.
Now, regarding the way to set these parameters I think we have three
options:
Based on what I said above, the need for such an interface would be only for
page-level settings. I have no preference about how to store them, a text
area would be fine as long as the user interface is made of checkboxes and
lists.
(4A) String parameters
Use a generic class, XWiki.ParameterClass, with two string properties,
key and value.
pro: we can easily add a new parameter to the sheet (by adding a new
parameter object to the sheet document) without modifying the parameters
class.
con: error prone
(4B) Typed parameters
Use a specific class, XWiki.SheetConfigClass, with properties matching
configuration parameters.
pro: less error prone since parameters are typed and their names are
hard-coded
con: harder to add/remove/rename parameters
(4C) Velocity parameters
Add a TextArea property to the XWiki.SheetClass, called 'parameters',
where we can set velocity variables. The value of this property will be
evaluated in startpage.vm after xwikivars.vm and layoutvars.vm.
I prefer (4C).
(5) In order to declare a sheet a xclass (or a plain document) has to
use an object of type XWiki.SheetInclude that has only one Database list
property called 'sheet' which, obviously, specifies the sheet to be
applied. A xclass can include zero (no sheets) or more sheets (a
different sheet for a different action).
Ok. We'll also need to update the XWiki.ClassSheet
page to provide a nice
interface for this.
For sure.
(6) The only case when sheets can conflict is when a document has
Yep.
objects of different types that declare
'page' sheets for the same
action. Multiple objects with 'meta' sheets are aggregated under the
'Objects' tab. Multiple objects with 'inline' sheets are aggregated
inside the 'xwikicontent' element in view mode and inside the same HTML
form in edit mode. A 'page' sheet can choose to display 'inline' and
'meta' sheets, and of course 'inline' and 'meta' sheets can be
displayed
by the default view mode.
The conflict between 'page' sheets can be resolved by defining an order
between objects. I prefer an inherent order (e.g. the object that was
added first is the most/less important) rather than an explicit priority
field.
I think that's going to be an edge use case. Usually when you go through the
hassle of building a complete new page to display specific objects, your
display is very customized anyway and you can write a page sheet that
aggregates 2 other page sheets if needed.
(7) Sheet resolution:
* if the current document has an object of type XWiki.SheetInclude and
the specified sheet has display:page and matches the current action then
apply it
Ok.
(in case there are more XWiki.SheetInclude
objects that satisfy
this constraint then use the one with the lowest/highest index).
I think that this is actually the sign of an error on the part of the dev
who created the application, but your solution would work.
* if the current document has objects whose
xclass declares a 'page'
sheet, then resolve the conflict and use the proper sheet.
* if there is no 'page' sheet included either by the current document or
by one of its objects then aggregate all 'inline' and 'meta' sheets
(from the objects and from the document itself).
* if there are no 'inline' sheets then simply display the default
view/edit mode.
Ok.
WDYT?
That I'm looking forward to seeing all this
implemented ;-)
I'm going to create a feature branch ASAP.
Thanks again for your feedback,
Marius
Thanks,
Guillaume
Thanks,
Marius
On 06/28/2011 07:43 PM, Marius Dumitru Florea wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi devs,
A prerequisite for Application Within Minutes [1] is to be able to
specify the sheet that will be used to display a document without
touching the content of that document [2]. This can be done in multiple
ways, depending on how we define the notion of a sheet.
(1) Class sheets vs. document sheets
A class sheet displays an object of a particular type and is specified
in the definition of that type. This means that when you create or edit
a class, i.e. a type of object, you can specify which sheet should be
used to display the instances of that class.
Pro: Documents don't have to specify a sheet.
Con: We have to determine which sheet to use in case there are multiple
objects attached to a document.
A document sheet displays a document of a particular type and is
specified at document level because the document type, unlike the
xclass, does not exist actually. The document type is inferred from the
type of objects the document has, or from its content, or, why not, from
the type of attachments it has.
Pro: Doesn't have the class sheet con.
Con: Each document has to specify which sheet to use.
Class sheets are enough for Application Within Minutes because the
wizard will create a single class (with a sheet) and so the application
items will have only one object that specifies a sheet.
(2) Separate sheets per action?
The current practice is to define a single (class) sheet which either
checks for the current action in its code or uses doc.display method
whose output is action specific.
How often did you had the need to write separate sheets per action (e.g.
create, view, edit, search, changes)?
(3) Which actions require a sheet?
If we're talking about class sheets then the list of actions that target
an object and which require a sheet is limited. Currently we have "view"
and "edit", but Ludovic proposed also "create", "search"
and "changes".
If we're talking about document sheets then we can have custom actions
and so we need an extensible mechanism to map actions to sheets.
(4) Sheet parameters?
If we're talking about class sheets then they only need to specify how
an object is displayed. Document sheets on the other hand may need to
control elements like:
* which tabs (comments, annotations, attachments, etc.), if any, are
displayed
* show title field in edit mode
* the side panels
* the form buttons
WDYT?
Thanks,
Marius
[1] http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes
[2]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…
3:15 p.m.
Hi Marius,
On Wed, Aug 3, 2011 at 10:49 AM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
Ok. It's indeed less important than the other 2 options at this stage
anyway.
Even with actions implemented as components, you can still programatically
generate a list of existing actions and provide a list interface to select
them.
As we can see from WYSIWYG macros, users tend to be lost when they cannot
pick from a list of explicit values when they have to fill a field that only
accepts values from a predefined subset.
I still don't agree about it, unless I get further details about this use
case that make me change my mind of course :-)
Hi Guillaume,
First of all, thanks for your feedback. See my comments below.
On 08/01/2011 03:40 PM, Guillaume Lerouge wrote:
Yes, that would be good.
Hi Marius,
please see my answers below.
On Mon, Jul 11, 2011 at 3:06 PM, Marius Dumitru Florea<
mariusdumitru.florea(a)xwiki.com> wrote:
Hi devs,
I'd like to make the following proposal based on your feedback:
(1) a sheet is a document that has an object of type XWiki.SheetClass
Ok.
(2) the sheet code is stored in the sheet
document content
Ok.
(3) XWiki.SheetClass has the following
properties:
display: Static List ('page', 'inline', 'meta')
action: String ('view', 'edit', etc.)
The 'display' property specifies where to place the sheet output:
* page: the sheet output overwrites the 'mainContentArea', 'xdocFooter'
and 'xwikidata' DIVs. This means everything besides the header (logo and
top menu), the content menu, the footer (version and license info) and
the side columns (panels).
Ok.
* inline: the sheet output overwrites the content
of the 'xwikicontent'
DIV in view mode and the form fields in edit mode (similar to the
current inline edit mode).
So the title field is not included, correct? If
so, I think it would be
good
to display the title field by default in inline
mode so that users can
access it and modify it.
The output of an inline sheet is placed where the content of the
document is currently placed. This means that a sheet with
display:inline doesn't control the title of the document, i.e. the title
of the document is displayed whatever output the sheet may have.
When you edit (inline) a blog post the title of the document is
displayed followed by a title input field. They are synchronized because
document title is set to $doc.getValue("title"). With the new sheet
system we can (and should!) reuse the title and content of a document.
For instance we could remove the "title" and "content" fields from
the
BlogPostClass and use instead the title and the content of the document
holding the blog post object.
With this in mind, do you think the current
"inline" edit behaviour
(document title displayed read-only followed by sheet output) is bad? I
don't think so. I think it's best to let the sheet decide what form
fields to display. If we were to display the title input then what do we
do about document parent and document syntax? Should we also allow users
to edit them in "inline" edit mode? I don't think so.
Why not? These are wiki-wide document options. Why should they not be
available for all content types? This would go towards standardizing the
display of wiki pages in edition mode. What's not to like about that?
* meta: the
sheet output is aggregated under the "Objects" document
extra tab. The bottom tabs are displayed only in
view mode currently but
we can imagine ways to display 'meta' sheets in edit mode too.
I think it would be better to be able to create a
custom tab rather than
a
generic "Objects" tab.
"Objects" is a technical term and I don't think
users
would have the reflex to go and look at that tab.
I thought about this initially but I gave up the idea because I felt is
was too complicated considering how bottom tabs are currently
implemented (with velocity templates). I'm going to postpone the "meta"
sheets for a while and focus only on "page" and "inline" sheets.
In that case
you would need to be able to define the title to display in
the
tab, maybe through a translation key stored in a
field of the ClassSheet
object.
The 'action' property specifies when to
apply the sheet. The empty
string means the sheet can be applied on any action.
What about a multi-select instead of a string
given that the list of
existing actions is already known?
In the near future actions will be implemented as components (with the
help of the xwiki-platform-action module). XWiki applications will be
able to define their own actions so we can't use a static list for the
"action" sheet property.
(4) Sheets can
control the UI elements outside of their scope through
> parameters, depending on the value of the display property:
I'm not sure I agree with this. Panels should
not be affected by
something
else than their existing interface, that will
confuse users. I'm not sure
I
see the added value of defining panels at the
class level. It's a simple
to
define them at the space level (and there's
very often an application<=>
space mapping anyway).
Ludovic proposed this btw.
* page: since sheets of this type control most of what
is displayed the
Right.
> only useful parameter is the list of
left/right panels.
> * inline: list of left/right panels, show/hide breadcrumb, show/hide
> title, show/hide bottom tabs, list of bottom tabs, show/hide version
> summary in edit mode.
And default bottom tab. I think all these options
should be provided for
every page in the wiki under an "advanced" section (including normal wiki
pages). I don't see a reason to restrict those options only to pages that
have an object.
I partially agree with you, but it would be a pain, for instance, to
have to configure all the blog post documents when you want change the
default bottom tab. It is a lot easier to just configure the
BlogPostSheet document and then enforce its configuration to all
documents holding a BlogPostClass object.
I think you'll agree with me that a system that
allows us to configure a
wiki page, defaulting to the sheet configuration (when that document has
a sheet of course) is the best option.
Indeed, I agree.
Guillaume
As for the interface, checkboxes would do. I'm not
sure where they would
be
stored though, maybe in a new
"XWikiDocument" object?
for
* meta: no parameters because sheets of this type
are used to display
secondary objects.
Now, regarding the way to set these parameters I think we have three
options:
Based on what I said above, the need for such an interface would be only page-level settings. I have no preference about
how to store them, a text
area would be fine as long as the user interface is made of checkboxes
and
lists.
(4A) String parameters
Use a generic class, XWiki.ParameterClass, with two string properties,
key and value.
pro: we can easily add a new parameter to the sheet (by adding a new
parameter object to the sheet document) without modifying the parameters
class.
con: error prone
(4B) Typed parameters
Use a specific class, XWiki.SheetConfigClass, with properties matching
configuration parameters.
pro: less error prone since parameters are typed and their names are
hard-coded
con: harder to add/remove/rename parameters
(4C) Velocity parameters
Add a TextArea property to the XWiki.SheetClass, called 'parameters',
where we can set velocity variables. The value of this property will be
evaluated in startpage.vm after xwikivars.vm and layoutvars.vm.
I prefer (4C).
(5) In order to declare a sheet a xclass (or a plain document) has to
use an object of type XWiki.SheetInclude that has only one Database list
property called 'sheet' which, obviously, specifies the sheet to be
applied. A xclass can include zero (no sheets) or more sheets (a
different sheet for a different action).
Ok. We'll also need to update the
XWiki.ClassSheet page to provide a nice
interface for this.
For sure.
(6) The only case when sheets can conflict is when a document has
the
objects of different types that declare
'page' sheets for the same
action. Multiple objects with 'meta' sheets are aggregated under the
'Objects' tab. Multiple objects with 'inline' sheets are aggregated
inside the 'xwikicontent' element in view mode and inside the same HTML
form in edit mode. A 'page' sheet can choose to display 'inline' and
'meta' sheets, and of course 'inline' and 'meta' sheets can be
displayed
by the default view mode.
The conflict between 'page' sheets can be resolved by defining an order
between objects. I prefer an inherent order (e.g. the object that was
added first is the most/less important) rather than an explicit priority
field.
I think that's going to be an edge use case. Usually when you go through hassle of building a complete new page to display
specific objects, your
display is very customized anyway and you can write a page sheet that
aggregates 2 other page sheets if needed.
Yep.
(7) Sheet resolution:
* if the current document has an object of type XWiki.SheetInclude and
the specified sheet has display:page and matches the current action then
apply it
Ok.
(in case there are more XWiki.SheetInclude
objects that satisfy
this constraint then use the one with the lowest/highest index).
I think that this is actually the sign of an error on the part of the dev
who created the application, but your solution would work.
* if the current document has objects whose
xclass declares a 'page'
sheet, then resolve the conflict and use the proper sheet.
* if there is no 'page' sheet included either by the current document or
by one of its objects then aggregate all 'inline' and 'meta' sheets
(from the objects and from the document itself).
* if there are no 'inline' sheets then simply display the default
view/edit mode.
Ok.
WDYT?
That I'm looking forward to seeing all this
implemented ;-)
I'm going to create a feature branch ASAP.
Thanks again for your feedback,
Marius
Thanks,
Guillaume
Thanks,
> Marius
>
> On 06/28/2011 07:43 PM, Marius Dumitru Florea wrote:
>> Hi devs,
>>
>> A prerequisite for Application Within Minutes [1] is to be able to
>> specify the sheet that will be used to display a document without
>> touching the content of that document [2]. This can be done in multiple
>> ways, depending on how we define the notion of a sheet.
>>
>>
>> (1) Class sheets vs. document sheets
>>
>> A class sheet displays an object of a particular type and is specified
>> in the definition of that type. This means that when you create or edit
>> a class, i.e. a type of object, you can specify which sheet should be
>> used to display the instances of that class.
>>
>> Pro: Documents don't have to specify a sheet.
>> Con: We have to determine which sheet to use in case there are multiple
>> objects attached to a document.
>>
>> A document sheet displays a document of a particular type and is
>> specified at document level because the document type, unlike the
>> xclass, does not exist actually. The document type is inferred from the
>> type of objects the document has, or from its content, or, why not,
from
>> the type of attachments it has.
>>
>> Pro: Doesn't have the class sheet con.
>> Con: Each document has to specify which sheet to use.
>>
>> Class sheets are enough for Application Within Minutes because the
>> wizard will create a single class (with a sheet) and so the application
>> items will have only one object that specifies a sheet.
>>
>>
>> (2) Separate sheets per action?
>>
>> The current practice is to define a single (class) sheet which either
>> checks for the current action in its code or uses doc.display method
>> whose output is action specific.
>>
>> How often did you had the need to write separate sheets per action
(e.g.
>> create, view, edit, search, changes)?
>>
>>
>> (3) Which actions require a sheet?
>>
>> If we're talking about class sheets then the list of actions that
target
>> an object and which require a sheet is
limited. Currently we have
"view"
>> and "edit", but Ludovic
proposed also "create", "search" and "changes".
>>
>> If we're talking about document sheets then we can have custom actions
>> and so we need an extensible mechanism to map actions to sheets.
>>
>>
>> (4) Sheet parameters?
>>
>> If we're talking about class sheets then they only need to specify how
>> an object is displayed. Document sheets on the other hand may need to
>> control elements like:
>>
>> * which tabs (comments, annotations, attachments, etc.), if any, are
>> displayed
>> * show title field in edit mode
>> * the side panels
>> * the form buttons
>>
>>
>> WDYT?
>>
>> Thanks,
>> Marius
>>
>> [1]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes
>> [2]
>>
>
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…
4:15 p.m.
Hi Guillaume,
On 08/03/2011 04:15 PM, Guillaume Lerouge wrote:
Ok. It's indeed less important than the other 2 options at this stage
anyway.
I still don't agree about it, unless I get further details about this use
case that make me change my mind of course :-)
Hi Marius,
On Wed, Aug 3, 2011 at 10:49 AM, Marius Dumitru Florea<
mariusdumitru.florea(a)xwiki.com> wrote:
Hi Guillaume,
First of all, thanks for your feedback. See my comments below.
On 08/01/2011 03:40 PM, Guillaume Lerouge wrote:
Yes, that would be good.
Hi Marius,
please see my answers below.
On Mon, Jul 11, 2011 at 3:06 PM, Marius Dumitru Florea<
mariusdumitru.florea(a)xwiki.com> wrote:
Hi devs,
I'd like to make the following proposal based on your feedback:
(1) a sheet is a document that has an object of type XWiki.SheetClass
Ok.
(2) the sheet code is stored in the sheet
document content
Ok.
(3) XWiki.SheetClass has the following
properties:
display: Static List ('page', 'inline', 'meta')
action: String ('view', 'edit', etc.)
The 'display' property specifies where to place the sheet output:
* page: the sheet output overwrites the 'mainContentArea', 'xdocFooter'
and 'xwikidata' DIVs. This means everything besides the header (logo and
top menu), the content menu, the footer (version and license info) and
the side columns (panels).
Ok.
* inline: the sheet output overwrites the content
of the 'xwikicontent'
DIV in view mode and the form fields in edit mode (similar to the
current inline edit mode).
So the title field is not included, correct? If
so, I think it would be
good
to display the title field by default in inline
mode so that users can
access it and modify it.
The output of an inline sheet is placed where the content of the
document is currently placed. This means that a sheet with
display:inline doesn't control the title of the document, i.e. the title
of the document is displayed whatever output the sheet may have.
When you edit (inline) a blog post the title of the document is
displayed followed by a title input field. They are synchronized because
document title is set to $doc.getValue("title"). With the new sheet
system we can (and should!) reuse the title and content of a document.
For instance we could remove the "title" and "content" fields from
the
BlogPostClass and use instead the title and the content of the document
holding the blog post object.
With this in mind, do you think the current
"inline" edit behaviour
(document title displayed read-only followed by sheet output) is bad? I
don't think so. I think it's best to let the sheet decide what form
fields to display. If we were to display the title input then what do we
do about document parent and document syntax? Should we also allow users
to edit them in "inline" edit mode? I don't think so.
Why not? These are wiki-wide document options. Why
should they not be
available for all content types? This would go towards standardizing the
display of wiki pages in edition mode. What's not to like about that?
Regarding the document title, I'm thinking that once we start using it
instead of an object property we might have the need to edit it in a
special way:
* don't edit at all because it is automatically generated
* edit partially, e.g. only a suffix
That's why I think it's better to let the sheet decide if and how the
title of the page is edited.
Regarding the document parent, I'm thinking that for some applications
you may want to enforce a specific parent (e.g. the home page of the
application space). Again, the sheet can decide if the parent should be
editable or should be automatically set.
As for the page syntax, I think it is a bit too technical and you don't
need to change it when you edit the structured data of an XWiki application.
* meta:
the sheet output is aggregated under the "Objects" document
extra tab. The bottom tabs are displayed only in
view mode currently but
we can imagine ways to display 'meta' sheets in edit mode too.
I think it would be better to be able to create a
custom tab rather than
a
generic "Objects" tab.
"Objects" is a technical term and I don't think
users
would have the reflex to go and look at that tab.
I thought about this initially but I gave up the idea because I felt is
was too complicated considering how bottom tabs are currently
implemented (with velocity templates). I'm going to postpone the "meta"
sheets for a while and focus only on "page" and "inline" sheets.
In that
case you would need to be able to define the title to display in
the
tab, maybe through a translation key stored in a
field of the ClassSheet
object.
The 'action' property specifies when to
apply the sheet. The empty
string means the sheet can be applied on any action.
What about a multi-select instead of a string
given that the list of
existing actions is already known?
In the near future actions will be implemented as components (with the
help of the xwiki-platform-action module). XWiki applications will be
able to define their own actions so we can't use a static list for the
"action" sheet property.
Even with actions implemented as components, you can
still programatically
generate a list of existing actions and provide a list interface to select
them.
As we can see from WYSIWYG macros, users tend to be lost when they cannot
pick from a list of explicit values when they have to fill a field that only
accepts values from a predefined subset.
We can have an UI (e.g. in ClassSheet) that lets you choose from some
well known actions, but I don't think we should limit the type of the
"action" sheet property to StaticList.
Thanks,
Marius
(4)
Sheets can control the UI elements outside of their scope through
> parameters, depending on the value of the display property:
I'm not sure I agree with this. Panels should
not be affected by
something
else than their existing interface, that will
confuse users. I'm not sure
I
see the added value of defining panels at the
class level. It's a simple
to
define them at the space level (and there's
very often an application<=>
space mapping anyway).
Ludovic proposed this btw.
* page: since sheets of this type control most of
what is displayed the
Right.
> only useful parameter is the list of
left/right panels.
> * inline: list of left/right panels, show/hide breadcrumb, show/hide
> title, show/hide bottom tabs, list of bottom tabs, show/hide version
> summary in edit mode.
And default bottom tab. I think all these options
should be provided for
every page in the wiki under an "advanced" section (including normal wiki
pages). I don't see a reason to restrict those options only to pages that
have an object.
I partially agree with you, but it would be a pain, for instance, to
have to configure all the blog post documents when you want change the
default bottom tab. It is a lot easier to just configure the
BlogPostSheet document and then enforce its configuration to all
documents holding a BlogPostClass object.
I think you'll agree with me that a system
that allows us to configure a
wiki page, defaulting to the sheet configuration (when that document has
a sheet of course) is the best option.
Indeed, I agree.
Guillaume
As for the interface, checkboxes would do.
I'm not sure where they would
be
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs stored though, maybe in a new
"XWikiDocument" object?
for
* meta: no parameters because sheets of this type
are used to display
secondary objects.
Now, regarding the way to set these parameters I think we have three
options:
Based on what I said above, the need for such an interface would be only page-level settings. I have no preference about
how to store them, a text
area would be fine as long as the user interface is made of checkboxes
and
lists.
(4A) String parameters
Use a generic class, XWiki.ParameterClass, with two string properties,
key and value.
pro: we can easily add a new parameter to the sheet (by adding a new
parameter object to the sheet document) without modifying the parameters
class.
con: error prone
(4B) Typed parameters
Use a specific class, XWiki.SheetConfigClass, with properties matching
configuration parameters.
pro: less error prone since parameters are typed and their names are
hard-coded
con: harder to add/remove/rename parameters
(4C) Velocity parameters
Add a TextArea property to the XWiki.SheetClass, called 'parameters',
where we can set velocity variables. The value of this property will be
evaluated in startpage.vm after xwikivars.vm and layoutvars.vm.
I prefer (4C).
(5) In order to declare a sheet a xclass (or a plain document) has to
use an object of type XWiki.SheetInclude that has only one Database list
property called 'sheet' which, obviously, specifies the sheet to be
applied. A xclass can include zero (no sheets) or more sheets (a
different sheet for a different action).
Ok. We'll also need to update the
XWiki.ClassSheet page to provide a nice
interface for this.
For sure.
(6) The only case when sheets can conflict is when a document has
the
objects of different types that declare
'page' sheets for the same
action. Multiple objects with 'meta' sheets are aggregated under the
'Objects' tab. Multiple objects with 'inline' sheets are aggregated
inside the 'xwikicontent' element in view mode and inside the same HTML
form in edit mode. A 'page' sheet can choose to display 'inline' and
'meta' sheets, and of course 'inline' and 'meta' sheets can be
displayed
by the default view mode.
The conflict between 'page' sheets can be resolved by defining an order
between objects. I prefer an inherent order (e.g. the object that was
added first is the most/less important) rather than an explicit priority
field.
I think that's going to be an edge use case. Usually when you go through hassle of building a complete new page to display
specific objects, your
display is very customized anyway and you can write a page sheet that
aggregates 2 other page sheets if needed.
Yep.
(7) Sheet resolution:
* if the current document has an object of type XWiki.SheetInclude and
the specified sheet has display:page and matches the current action then
apply it
Ok.
(in case there are more XWiki.SheetInclude
objects that satisfy
this constraint then use the one with the lowest/highest index).
I think that this is actually the sign of an error on the part of the dev
who created the application, but your solution would work.
* if the current document has objects whose
xclass declares a 'page'
sheet, then resolve the conflict and use the proper sheet.
* if there is no 'page' sheet included either by the current document or
by one of its objects then aggregate all 'inline' and 'meta' sheets
(from the objects and from the document itself).
* if there are no 'inline' sheets then simply display the default
view/edit mode.
Ok.
WDYT?
That I'm looking forward to seeing all this
implemented ;-)
I'm going to create a feature branch ASAP.
Thanks again for your feedback,
Marius
Thanks,
Guillaume
Thanks,
> Marius
>
> On 06/28/2011 07:43 PM, Marius Dumitru Florea wrote:
>> Hi devs,
>>
>> A prerequisite for Application Within Minutes [1] is to be able to
>> specify the sheet that will be used to display a document without
>> touching the content of that document [2]. This can be done in multiple
>> ways, depending on how we define the notion of a sheet.
>>
>>
>> (1) Class sheets vs. document sheets
>>
>> A class sheet displays an object of a particular type and is specified
>> in the definition of that type. This means that when you create or edit
>> a class, i.e. a type of object, you can specify which sheet should be
>> used to display the instances of that class.
>>
>> Pro: Documents don't have to specify a sheet.
>> Con: We have to determine which sheet to use in case there are multiple
>> objects attached to a document.
>>
>> A document sheet displays a document of a particular type and is
>> specified at document level because the document type, unlike the
>> xclass, does not exist actually. The document type is inferred from the
>> type of objects the document has, or from its content, or, why not,
from
>> the type of attachments it has.
>>
>> Pro: Doesn't have the class sheet con.
>> Con: Each document has to specify which sheet to use.
>>
>> Class sheets are enough for Application Within Minutes because the
>> wizard will create a single class (with a sheet) and so the application
>> items will have only one object that specifies a sheet.
>>
>>
>> (2) Separate sheets per action?
>>
>> The current practice is to define a single (class) sheet which either
>> checks for the current action in its code or uses doc.display method
>> whose output is action specific.
>>
>> How often did you had the need to write separate sheets per action
(e.g.
>> create, view, edit, search, changes)?
>>
>>
>> (3) Which actions require a sheet?
>>
>> If we're talking about class sheets then the list of actions that
target
>> an object and which require a sheet is
limited. Currently we have
"view"
>> and "edit", but Ludovic
proposed also "create", "search" and "changes".
>>
>> If we're talking about document sheets then we can have custom actions
>> and so we need an extensible mechanism to map actions to sheets.
>>
>>
>> (4) Sheet parameters?
>>
>> If we're talking about class sheets then they only need to specify how
>> an object is displayed. Document sheets on the other hand may need to
>> control elements like:
>>
>> * which tabs (comments, annotations, attachments, etc.), if any, are
>> displayed
>> * show title field in edit mode
>> * the side panels
>> * the form buttons
>>
>>
>> WDYT?
>>
>> Thanks,
>> Marius
>>
>> [1]
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes
>> [2]
>>
>
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…
4 Aug
4 Aug
3:20 p.m.
Hi Marius,
On Wed, Aug 3, 2011 at 4:15 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
in
I still don't agree about it, unless I get further details about this use
case that make me change my mind of course :-)
> * page: since sheets of this type control most of what is displayed the
>>> only useful parameter is the list of left/right panels.
>>> * inline: list of left/right panels, show/hide breadcrumb, show/hide
>>> title, show/hide bottom tabs, list of bottom tabs, show/hide version
>>> summary in edit mode.
>
>> And default bottom tab. I think all these options should be provided for
Right.
only
Hi Guillaume,
On 08/03/2011 04:15 PM, Guillaume Lerouge wrote:
Yes, that would be good.
You're right, I had overlooked those use cases. We might still want to
provide sheet creators with tools to easily include the title / parent field
should they wish to use them (through a macro maybe?).
As for the page syntax, I think it is a bit too technical and you don't
Hi Marius,
On Wed, Aug 3, 2011 at 10:49 AM, Marius Dumitru Florea<
mariusdumitru.florea(a)xwiki.com> wrote:
> Hi Guillaume,
>
> First of all, thanks for your feedback. See my comments below.
>
> On 08/01/2011 03:40 PM, Guillaume Lerouge wrote:
>> Hi Marius,
>>
>> please see my answers below.
>>
>> On Mon, Jul 11, 2011 at 3:06 PM, Marius Dumitru Florea<
>> mariusdumitru.florea(a)xwiki.com> wrote:
>>
>>> Hi devs,
>>>
>>> I'd like to make the following proposal based on your feedback:
>>>
>>> (1) a sheet is a document that has an object of type XWiki.SheetClass
>>>
>>
>> Ok.
>>
>>
>>> (2) the sheet code is stored in the sheet document content
>>>
>>
>> Ok.
>>
>>
>>> (3) XWiki.SheetClass has the following properties:
>>>
>>> display: Static List ('page', 'inline', 'meta')
>>> action: String ('view', 'edit', etc.)
>>>
>>> The 'display' property specifies where to place the sheet output:
>>>
>>> * page: the sheet output overwrites the 'mainContentArea',
'xdocFooter'
>>> and 'xwikidata' DIVs. This
means everything besides the header (logo
and
>>> top menu), the content menu, the
footer (version and license info) and
>>> the side columns (panels).
>>>
>>
>> Ok.
>>
>>
>>> * inline: the sheet output overwrites the content of the
'xwikicontent'
> DIV in view mode and the form fields in edit mode
(similar to the
> current inline edit mode).
>
So the title field is not included, correct? If
so, I think it would be
good
to display the title field by default in inline
mode so that users can
access it and modify it.
The output of an inline sheet is placed where the content of the
document is currently placed. This means that a sheet with
display:inline doesn't control the title of the document, i.e. the title
of the document is displayed whatever output the sheet may have.
When you edit (inline) a blog post the title of the document is
displayed followed by a title input field. They are synchronized because
document title is set to $doc.getValue("title"). With the new sheet
system we can (and should!) reuse the title and content of a document.
For instance we could remove the "title" and "content" fields from
the
BlogPostClass and use instead the title and the content of the document
holding the blog post object.
With this in mind, do you think the current
"inline" edit behaviour
(document title displayed read-only followed by sheet output) is bad? I
don't think so. I think it's best to let the sheet decide what form
fields to display. If we were to display the title input then what do we
do about document parent and document syntax? Should we also allow users
to edit them in "inline" edit mode? I don't think so.
Why not? These are wiki-wide document options.
Why should they not be
available for all content types? This would go towards standardizing the
display of wiki pages in edition mode. What's not to like about that?
Regarding the document title, I'm thinking that once we start using it
instead of an object property we might have the need to edit it in a
special way:
* don't edit at all because it is automatically generated
* edit partially, e.g. only a suffix
That's why I think it's better to let the sheet decide if and how the
title of the page is edited.
Regarding the document parent, I'm thinking that for some applications
you may want to enforce a specific parent (e.g. the home page of the
application space). Again, the sheet can decide if the parent should be
editable or should be automatically set.
need to change it when you edit the structured data of
an XWiki
application.
Indeed.
Thanks,
Guillaume
> * meta:
the sheet output is aggregated under the "Objects" document
>>> extra tab. The bottom tabs are displayed only in view mode currently
but
>>> we can imagine ways to display
'meta' sheets in edit mode too.
>>>
>>
>
>> I think it would be better to be able to create a custom tab rather
than
a
Ok. It's indeed less important than the other 2 options at this stage
anyway.
>> In that case you would need to be able to define the title to display generic "Objects" tab.
"Objects" is a technical term and I don't think
users
would have the reflex to go and look at that tab.
I thought about this initially but I gave up the idea because I felt is
was too complicated considering how bottom tabs are currently
implemented (with velocity templates). I'm going to postpone the "meta"
sheets for a while and focus only on "page" and "inline" sheets.
> the
>> tab, maybe through a translation key stored in a field of the
ClassSheet
object.
> The 'action' property specifies when to apply the sheet. The empty
> string means the sheet can be applied on any action.
>
What about a multi-select instead of a string
given that the list of
existing actions is already known?
In the near future actions will be implemented as components (with the
help of the xwiki-platform-action module). XWiki applications will be
able to define their own actions so we can't use a static list for the
"action" sheet property.
Even with actions implemented as components, you
can still
programatically
generate a list of existing actions and provide a
list interface to
select
them.
As we can see from WYSIWYG macros, users tend to be lost when they cannot
pick from a list of explicit values when they have to fill a field that
only
accepts values from a predefined subset.
We can have an UI (e.g. in ClassSheet) that lets you choose from some
well known actions, but I don't think we should limit the type of the
"action" sheet property to StaticList.
Thanks,
Marius
>> (4) Sheets can control the UI elements outside of their scope through
>>> parameters, depending on the value of the display property:
>
>> I'm not sure I agree with this. Panels should not be affected by
> something
>> else than their existing interface, that will confuse users. I'm not
sure
> I
>> see the added value of defining panels at the class level. It's a
simple
> to
>> define them at the space level (and there's very often an
application<=>
space mapping anyway).
Ludovic proposed this btw.
>> every page in the wiki under an
"advanced" section (including normal
wiki
>> pages). I don't see a reason to
restrict those options only to pages
that
have an object.
I partially agree with you, but it would be a pain, for instance, to
have to configure all the blog post documents when you want change the
default bottom tab. It is a lot easier to just configure the
BlogPostSheet document and then enforce its configuration to all
documents holding a BlogPostClass object.
I think you'll agree with me that a system
that allows us to configure a
wiki page, defaulting to the sheet configuration (when that document has
a sheet of course) is the best option.
Indeed, I agree.
Guillaume
> As for the interface, checkboxes would do. I'm not sure where they would
> be
>> stored though, maybe in a new "XWikiDocument" object?
>>
>>
>>> * meta: no parameters because sheets of this type are used to display
>>> secondary objects.
>>>
>>> Now, regarding the way to set these parameters I think we have three
>>> options:
>>>
>>
>> Based on what I said above, the need for such an interface would be > for
>> page-level settings. I have no preference about how to store them, a
text
>> area would be fine as long as the user
interface is made of checkboxes
> and
>> lists.
>>
>> (4A) String parameters
>>>
>>> Use a generic class, XWiki.ParameterClass, with two string properties,
>>> key and value.
>>>
>>> pro: we can easily add a new parameter to the sheet (by adding a new
>>> parameter object to the sheet document) without modifying the
parameters
>>> class.
>>>
>>> con: error prone
>>>
>>> (4B) Typed parameters
>>>
>>> Use a specific class, XWiki.SheetConfigClass, with properties matching
>>> configuration parameters.
>>>
>>> pro: less error prone since parameters are typed and their names are
>>> hard-coded
>>>
>>> con: harder to add/remove/rename parameters
>>>
>>> (4C) Velocity parameters
>>>
>>> Add a TextArea property to the XWiki.SheetClass, called
'parameters',
>>> where we can set velocity variables. The value of this property will
be
>>> evaluated in startpage.vm after
xwikivars.vm and layoutvars.vm.
>>>
>>> I prefer (4C).
>>>
>>> (5) In order to declare a sheet a xclass (or a plain document) has to
>>> use an object of type XWiki.SheetInclude that has only one Database
list
>>> property called 'sheet'
which, obviously, specifies the sheet to be
>>> applied. A xclass can include zero (no sheets) or more sheets (a
>>> different sheet for a different action).
>>>
>>
>
>> Ok. We'll also need to update the XWiki.ClassSheet page to provide a
nice
>> interface for this.
>
> For sure.
>
>>
>> (6) The only case when sheets can conflict is when a document has
>>> objects of different types that declare 'page' sheets for the same
>>> action. Multiple objects with 'meta' sheets are aggregated under the
>>> 'Objects' tab. Multiple objects with 'inline' sheets are
aggregated
>>> inside the 'xwikicontent' element in view mode and inside the same
HTML
>>> form in edit mode. A 'page'
sheet can choose to display 'inline' and
>>> 'meta' sheets, and of course 'inline' and 'meta'
sheets can be
displayed
>>> by the default view mode.
>>>
>>> The conflict between 'page' sheets can be resolved by defining an
order
>>> between objects. I prefer an inherent
order (e.g. the object that was
>>> added first is the most/less important) rather than an explicit
priority
>>> field.
>>>
>>
>> I think that's going to be an edge use case. Usually when you go
through
> the
>> hassle of building a complete new page to display specific objects,
your
>> display is very customized anyway and you
can write a page sheet that
>> aggregates 2 other page sheets if needed.
>
> Yep.
>
>>
>> (7) Sheet resolution:
>>>
>>> * if the current document has an object of type XWiki.SheetInclude and
>>> the specified sheet has display:page and matches the current action
then
>>> apply it
>>
>>
>> Ok.
>>
>>
>>> (in case there are more XWiki.SheetInclude objects that satisfy
>>> this constraint then use the one with the lowest/highest index).
>>>
>>
>> I think that this is actually the sign of an error on the part of the
dev
>> who created the application, but your
solution would work.
>>
>>
>>> * if the current document has objects whose xclass declares a 'page'
>>> sheet, then resolve the conflict and use the proper sheet.
>>> * if there is no 'page' sheet included either by the current document
or
>>> by one of its objects then aggregate
all 'inline' and 'meta' sheets
>>> (from the objects and from the document itself).
>>> * if there are no 'inline' sheets then simply display the default
>>> view/edit mode.
>>>
>>
>> Ok.
>>
>> WDYT?
>>>
>>
>
>> That I'm looking forward to seeing all this implemented ;-)
>
> I'm going to create a feature branch ASAP.
>
> Thanks again for your feedback,
> Marius
>
>>
>> Thanks,
>>
>> Guillaume
>>
>> Thanks,
>>> Marius
>>>
>>> On 06/28/2011 07:43 PM, Marius Dumitru Florea wrote:
>>>> Hi devs,
>>>>
>>>> A prerequisite for Application Within Minutes [1] is to be able to
>>>> specify the sheet that will be used to display a document without
>>>> touching the content of that document [2]. This can be done in
multiple
>>>> ways, depending on how we define
the notion of a sheet.
>>>>
>>>>
>>>> (1) Class sheets vs. document sheets
>>>>
>>>> A class sheet displays an object of a particular type and is
specified
>>>> in the definition of that type.
This means that when you create or
edit
>>>> a class, i.e. a type of object,
you can specify which sheet should be
>>>> used to display the instances of that class.
>>>>
>>>> Pro: Documents don't have to specify a sheet.
>>>> Con: We have to determine which sheet to use in case there are
multiple
>>>> objects attached to a document.
>>>>
>>>> A document sheet displays a document of a particular type and is
>>>> specified at document level because the document type, unlike the
>>>> xclass, does not exist actually. The document type is inferred from
the
>>>> type of objects the document has,
or from its content, or, why not,
> from
>>>> the type of attachments it has.
>>>>
>>>> Pro: Doesn't have the class sheet con.
>>>> Con: Each document has to specify which sheet to use.
>>>>
>>>> Class sheets are enough for Application Within Minutes because the
>>>> wizard will create a single class (with a sheet) and so the
application
>>>> items will have only one object
that specifies a sheet.
>>>>
>>>>
>>>> (2) Separate sheets per action?
>>>>
>>>> The current practice is to define a single (class) sheet which either
>>>> checks for the current action in its code or uses doc.display method
>>>> whose output is action specific.
>>>>
>>>> How often did you had the need to write separate sheets per action
> (e.g.
>>>> create, view, edit, search, changes)?
>>>>
>>>>
>>>> (3) Which actions require a sheet?
>>>>
>>>> If we're talking about class sheets then the list of actions that
> target
>>>> an object and which require a sheet is limited. Currently we have
> "view"
>>>> and "edit", but Ludovic proposed also "create",
"search" and
"changes".
>>>>
>>>> If we're talking about document sheets then we can have custom
actions
>>>> and so we need an extensible
mechanism to map actions to sheets.
>>>>
>>>>
>>>> (4) Sheet parameters?
>>>>
>>>> If we're talking about class sheets then they only need to specify
how
>>>> an object is displayed. Document
sheets on the other hand may need to
>>>> control elements like:
>>>>
>>>> * which tabs (comments, annotations, attachments, etc.), if any, are
>>>> displayed
>>>> * show title field in edit mode
>>>> * the side panels
>>>> * the form buttons
>>>>
>>>>
>>>> WDYT?
>>>>
>>>> Thanks,
>>>> Marius
>>>>
>>>> [1]
> http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes
>>>> [2]
>>>>
>>>
>
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…
4792
days inactive
4829
days old
14 comments
7 participants
participants (7)
-
Guillaume Lerouge -
Jean-Vincent Drean -
Jerome Velociter -
Jerome Velociter -
Ludovic Dubost -
Marius Dumitru Florea -
Thomas Mortagne