22 Jul
2012
22 Jul
'12
10:31 p.m.
I have a very basic additional request: please make sure the context through which a
displayer is executed contains sufficient information so that each displayed bit is
cacheable by:
- storing cache around each rendered piece of content
- allow each displayer code to register a set of "params" (the cache keys) and
consult an "if-modified-since" and stop displaying if it can estimate that its
display would not change
And a more elaborate request: Also, as a long term future, I would love the rendering of a
page element to be called individually by something such as JS call: e.g. so that JS can
replace the object that just got clicked by its "edit" equivalent, or because
that value has changed and needs update.
Are these two things doable with this proposal?
The second is probably very hard.
I find the first very important to be the default so that XWiki is a better citizen of the
web, playing well with the caches at any stage.
paul
Le 22 juil. 2012 à 17:00, Vincent Massol a écrit :
Hi devs,
I've been thinking about Displayer architecture today and here are my thoughts on how
I see them implemented (without entering low-level details):
Basics
======
* Everything in XWiki should be a Component and should be able to be implemented in Java
and optionally extended in wiki pages (wiki components notion)
* Have a Displayer component Role (ie a java interface for displayers)
* Have default implementations in the display module for all basic types we want to
support (textareas, date, string, number, etc). Basically this means rewriting the current
displayers as components.
* Allow to register Displayers defined in wiki pages by using wiki components (same
mechanism as wiki macros).
* Since a lot of Displayers are better written in wiki pages (javascript, css), create a
UI submodule of the current display module which contains displayers we want bundled by
default in XE (for ex for Dates and Users/Groups)
* Extend the current {{display}} macro to support displaying Objects and Object
Properties (it already supports passing an EntityType parameter but it's not used
ATM).
* The {{display}} macro will use the CM to get an instance of a displayer for the Object
property type. It'll do by finding the XClass and getting the type from the XClass and
then do a getInstance
* Add an optional parameter to the {{display}} macro to support passing a displayer hint
(by default it would use the "default" displayer for the property type). This
will allow some pages to decide which displayer to use to render their content without
being forced to use the default displayer.
Advanced
=========
In order to make it easy for a given class or a given object to decide how to display
itself we could also define some special DisplayerBinding XObjects (one per property
type). It could work like this:
* If the {{display}} macro has the displayer hint specified as parameter then use it
* If the {{display}} macro doesn't have the displayer hint specified then check if
the xclass document has a DisplayerBinding XObject defined and if so use the displayer
pointed to by the binding
* If the {{display}} macro doesn't have the displayer hint specified and the xclass
document doesn't have a DisplayerBinding XObject defined then check if the object to
display have such an XObject and if so use it
* Deprecate the notion of "custom displayer" that we have in our XClass since
it wouldn't be needed anymore
WDYT?
I know we're not there yet but it would be cool to make progress on the direction
we'd like to take.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs