[xwiki-devs] [Proposal] Displayer Architecture for the future
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
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
Vincent, I like the general direction for conditional displayers and alternate displays. In Curriki/XClams, there are presently two factors that affect the default display. A page is displayed as a learning resource IF it has an AssetClass AND it resides in a spaces starting with "Coll_" (For resource collection space.) Now we have often talked about changing the view based on the role or type of the user, (Student, vs. Teacher vs. Parent, etc.) So how does that factor in? There is certainly room for improvement over the current mish-mash of xpage= and viewer= parameters. Joshua Marks CTO Curriki: The Global Education and Learning Community [email protected] www.curriki.org -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Vincent Massol Sent: Sunday, July 22, 2012 8:00 AM To: XWiki Developers Subject: [xwiki-devs] [Proposal] Displayer Architecture for the future 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
2012/7/22 Vincent Massol <[email protected]>:
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
Currently custom displayers are activate on a per property basis, not by field type, so the binding should be per property. Knowing this it's a bit bizarre to have that binding not being a field of the property of the XClass. It should generally complicated to use bindings instead of just setting a field. There is another need (which I'm working on in the hackathon) to have default custom displayers for ALL property of a specific type for ALL classes. So if we go the component way we should make sure this is also possible. This means a binding at the wiki or multi wiki level for instance. Finally it's also important to have the same displayer system to be supported by calls to $doc.display(). Not everything can be done through macros, so we also need the API to support the same system of displayers In general it's a progress to be able to register new displayers like that as components, but it's important to make it simple to configure. If there are too many indirections it might be hard to actually understand where the configuration actually is. Ludovic
* 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 [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
participants (5)
-
Joshua Marks -
Ludovic Dubost -
Paul Libbrecht -
Thomas Mortagne -
Vincent Massol