On 06/28/2011 08:21 PM, Thomas Mortagne wrote: > On Tue, Jun 28, 2011 at 18:43, Marius Dumitru Florea > <[email protected]> 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/ApplicationWithinMinutesCoreChangeSheetDisplay >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
