5 Jul
2011
5 Jul
'11
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