2011/7/5 Thomas Mortagne <[email protected]>: > On Tue, Jul 5, 2011 at 08:35, Marius Dumitru Florea > <[email protected]> wrote: >> On 07/04/2011 06:34 PM, Jean-Vincent Drean wrote: >>> On Tue, Jun 28, 2011 at 6:43 PM, 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. >>> >> >>> 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/OverhaulOfXWikiClassesAndObjectsManagement/full-edit.png >> >> 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? > > 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.
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. > >> >>> >>>> >>>> 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) > > 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 >>> Thanks, >>> JV. >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> 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 > -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
