On Mon, Oct 22, 2012 at 11:33 AM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
On Mon, Oct 22, 2012 at 12:15 PM, Thomas
Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Mon, Oct 22, 2012 at 10:36 AM, Marius Dumitru
Florea
<mariusdumitru.florea(a)xwiki.com> 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.
I don't have any breaking change in mind except that
obviously a 2.0
document is not going to be parsed properly with XWiki version that
only knows 1.0.
Anyway the point is not if it's going to fully work with XWiki 1.0.
I don't see any reason to break anything here and it's not even like
either of my suggestions was introducing any important complexity in
your proposal.