Vincent Massol wrote: > How much duplication do you reckon there is between the 2 classes? > > Might be worth refactoring and have a common ancestor to share code?
Hi, There already is a common ancestor... It just happens that these 2 extensions use a similar xclass, yet different enough not to justify a common method. At least not one common between these two, but maybe we can have a common ensureClassDocumentIsProperlyDefined method used by all the code that creates a class dynamically. I had a discussion with Jerome about the skin extensions plugin(s), the main point being: Should there be only one plugin that offers both Javascript and CSS extensions? I said yes, as SkinExtensions isn't really a plugin, but a concept, or a meta-plugin, currently implemented in JavaScript and Style extensions, but that can be further explored. For example, another idea was to have LinkExtensions, which offer the ability for a page to "advertise" some links: - a Project Description application could publish links to DOAP profiles for every project page - a Social Networking application could publish FOAF documents for each user - a slideshow application could publish first/prev/next/last/index links which would appear nicely in the navigation bar in Opera and in Firefox with the Site Navigation Bar extension; this is applicable for any structured multi-document information - link to a custom RSS feed - link to a RDF/OWL description of the document This is pretty different from Jsx and Ssx, because there's no need for xobjects. Still, the same principle is used: the content pulls in links. The format of the links is quite different, though, so having one class that generates 5 types of links (jsx, static js file, ssx, static css file, user-defined link) is not clean enough. And maybe sometime later we'll come with another type of skin extension, with a different way of working. And I think that by now we've learned that trying to make one class that should do more things is not a good idea, as otherwise we'll end up with huge classes, so it is not extensible enough to just add new methods and new if-then-else blocks whenever we want to add a new type of extensions. I'd say that the current model is good enough, as it provides a common framework and allows each extension type to define its own rules, keeping them separate (each extension type can be enabled or disabled in xwiki.cfg) Yep, just had another idea of skin extensions for the future, XBL extensions; but that is for much later, when we'll be able to use XBL files. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
