19 Sep
2011
19 Sep
'11
5:19 p.m.
My answer for release 3.2 is interspersed.
On Mon, Sep 19, 2011 at 16:34, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
Hi devs,
Here's the sheet resolution algorithm I have implemented in
https://github.com/xwiki/xwiki-platform/blob/cbad868094b9cc9d811621670e3205…
.
getSheets(document, action) : List<DocumentReference>
(1) If there is a "sheet" request parameter that points to a sheet
that supports the passed action, return a reference to that sheet.
+1, and I understand that this single sheet will manage all objects in the
document ?
(2) For each object of type XWiki.DocumentSheetBinding
attached to the
passed document check if the "sheet" property points to a sheet that
supports the passed action. Return the computed list, if not empty.
+1, and each sheet would be managing some of the objects at their sole
discretion ?
(3) For each type of object attached to the passed
document:
For 3.2, I agree with this, but in general I wonder if it is right to put
the binding in the class document ?
Should not the class stay more clean from display related stuffs in favor of
the sheet ?
The pros is of course that it concentrate the right management on the class
(if you follow my -1 below)
(3.1) For each object of type
XWiki.ClassSheetBinding attached to
the document defining the class check if the "sheet" property points
to a sheet that supports the passed action
+1, and so each sheet would be managing part of the object ?
(3.2) If the class doesn't have any
XWiki.ClassSheetBinding object
then check if <ClassName><ActionName>Sheet exists
-1, this would introduce document name convention, which is not good IMHO
The convention of document name are for WebHome, WebPreferences and
XWikiPreferences, and this is already too much.
The one mentioned by Thomas regarding XWikiServer document is even worse.
(3.3) If not, then check if <ClassName>Sheet
exists and supports
the passed action
-1, idem
(3.4) If not, then check if
"sheet.defaultClassSheetBinding"
configuration property specifies a sheet for the class we're looking
at
-0, introduce a new space for this config is not nice IMHO. Put this in let
say XWiki.defaultSheetBindingConfig
Does not this also solve the oldcore issue we have discussed, if you accept
the idea of providing this default binding with the XE xar ?(Should the old
core contains a minimal default one during empty data state ?)
Return the computed list if not empty.
Without duplicates ?
(4) If the passed document is a class (holds a class definition) then
return a reference to the default class sheet (XWiki.ClassSheet) if it
supports the passed action.
+0, why not getting this from the default binding above ?
Otherwise return an empty list.
I'd like you to vote on each of the steps of the algorithm. Are there
steps you think I should drop?
Yes definitely, but removing the need to link data with the sheet using
includes is really a big improvement.
Great job,
I'm obviously +1 for each of the steps.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO