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