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