Re: [xwiki-devs] [Proposal] Define XClass property types using components

On Mon, Oct 22, 2012 at 12:15 PM, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com&gt; wrote: > > On Mon, Oct 22, 2012 at 10:36 AM, Marius Dumitru Florea > &lt;mariusdumitru.florea(a)xwiki.com&gt; wrote: >> >> Hi devs, >> >> Currently, the available XClass property types are hard-coded in >> MetaClass [1]. So in order to add a new property type you need to >> recompile the XWiki old core. I'd like to be able to create new >> property types using components so I created this branch [2] that >> includes the following important changes: >> >> (A) Use the value of the "classType" XML element from the XAR as a >> property type hint >> >> If you look at the XML export of an XClass you'll see that each >> property has a "classType" element whose content is the full name of >> the Java class used to implement that property type: >> >> <classType>com.xpn.xwiki.objects.classes.DBTreeListClass</classType> >> >> I think this is bad because: >> * it exposes an implementation detail >> * you cannot change the property type implementation without breaking >> backwards compatibility >> >> So I'm proposing to use the "classType" as a hint for the property >> type. Well, technically it will be a hint, but semantically it will >> specify the data type of the property value (e.g. String, Date, >> Number). For backwards compatibility, the existing property types will >> have hints that can be extracted from the value of the 'classType' >> (i.e. the full Java class name): >> >> String hint = >> StringUtils.removeEnd(StringUtils.substringAfterLast(classType, >> "."), "Class"); >> >> So both: >> >> <classType>com.xpn.xwiki.objects.classes.DBTreeListClass</classType> >> <classType>DBTreeList</classType> >> >> will point to the property type with hint "DBTreeList". Of course, >> when exporting an XClass with the new version of the core you'll only >> see the property type hint. >> >> The only issue with this approach is that XClasses exported with the >> new version will not work on an older version but this is acceptable >> IMO. > > I don't like breaking stuff too much especially when it's far from To be clear. This is not backwards compatibility. Are you sure that a XAR from 4.2 can be imported in XWiki 1.0 for instance? In other words, whenever we extended the XAR/XML format did we take care to keep the new XARs working on older versions of XWiki? If the answer is yes then I agree with your suggestions below. But for me it's enough to ensure that older XARs work with newer versions of XWiki, not the other way around.

Thanks, Marius > mandatory technically. We could either: > * keep theses old classType and have cleaner ones for new types. It's > not a big deal IMO, we are talking about oldcore API here and we will > have to introduce a new component API for this anyway with the new > model. > * or simply introduce a new field in the class which would fallback on > String hint = > StringUtils.removeEnd(StringUtils.substringAfterLast(classType, > "."), "Class"); when it's not defined > >> (B) Add a PropertyClassProvider [3] role to retrieve an instance of a >> property class and to access its meta class >> >> Currently, in order to define a new property type you need to create >> two Java classes: >> * one extending PropertyMetaClass, to define the list of meta >> properties of the new property type (e.g. displayType, dateFormat, >> multiSelect, etc.) >> * one extending ProperyClass, to define setters and getters for the >> meta properties and maybe some custom display. This is the property >> type itself. >> >> So I added a PropertyClassProvider role that has two methods: one to >> get the meta class and one to get a new instance of the property type >> (e.g. when adding a property to an XClass). As a quick implementation >> I transformed all meta classes into implementations of this role. >> Finally, I modified MetaClass to lookup property class providers >> instead of hard-coding the property types. >> >> WDYT? >> >> Note that I've not added any CLIRR excludes and I tested my changes >> with the default, unchanged, class editor and it works fine. >> >> Thanks, >> Marius >> >> [1] >> https://github.com/xwiki/xwiki-platform/blob/xwiki-platform-4.2/xwiki-platf… >> [2] >> https://github.com/xwiki/xwiki-platform/compare/feature-xclass-property-com… >> [3] >> https://github.com/xwiki/xwiki-platform/commit/fb9fcc7313ccb16f38c2d17dd7ed… >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > 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