On Sun, Jul 22, 2012 at 5:00 PM, Vincent Massol <[email protected]> wrote: > 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?
Sounds good in general, that's pretty much the way I was seeing it since we introduced display macro. One thing is missing: how do you find the displayer from the property type ? Is it a role hint prefix ? You lookup all of them and call some method like getSupportedType to know which one is the right one ? You make it part of the role type as a generic parameter ? > > 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
