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

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

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