+1 for 5
Sergiu Dumitriu wrote: > Hi devs, > > While working on a UI feature that makes use of skin extensions (both > script and style), I was faced with a difficult choice: where to put > these extensions? > > The difficulty comes from several factors: > - This is a small feature that doesn't deserve its own application > - Yet, it does not fit in any of the existing applications > - I don't want to put the js and css in Albatross, as it was done until now > - Resource-based extensions are not as flexible as document-based ones, > and I'd still need a .jar module to stick them to. > > Since this is just the first in a long series of such small extensions, > leading to a simpler and more modular skin mechanism, I think we should > take a decision. > > > A while back, when designing Interface eXtensions, I also proposed > Interface Components, which is exactly what I would like to do (as the > packaging, since the code is already structured like a component). See > http://dev.xwiki.org/xwiki/bin/view/Design/InterfaceExtensions#HAfterwards > > > So, the choices are: > > 1. Stick to the past and put the code in Albatross, registering it in > platform-web/javascript.vm and stylesheet.vm. > > 2. Put the files as resource skin extensions inside xwiki-core. > > 3. Force the documents into an existing application, for example > administration or enterprise-wiki. > > 4. Create a new application for holding Interface Components. > > 5. Create a new application for each IC. > > > Currently, my preference is +1 for 5, with a +0 for 4 and -1 for the > rest. Here's some of my motivations: > > 1. is dead wrong. This is what we've been doing until now, and we > managed to overwhelm the skin with resources, putting a hard requirement > on Albatross, registering no less than 14 global javascript files, most > of the times unneeded, but hard to remove since nobody knows where and > how they are used. If a bug is found, we need to redeploy the whole skin > and wait for the next XE release, although it only affects one small > part of the wiki. This also ties the platform to the skin. And it is > completely not modular. > > 2. is dead wrong too. What does the core have to do with CSS??! > > 3. is slightly better. Since the SX are documents, they should be in an > application. enterprise-wiki used to be the catch-all place to put > documents, but we all decided that it must be split into modular > applications. Plus, this is not XE specific, but it can be used in any > product. administration is not suited either, since this has nothing to > do with the wiki administration. The other existing apps are even less > suited. > > 4. is a good alternative. The problem with only one application is that > it is not modular enough. We must release the whole bunch when only one > component was changed, which leads to numerous releases, or delayed > releases until enough bugs have been found and fixed, which prevents > users from benefiting of already solved bugs. The advantage is that we > don't have to create numerous tiny projects in Jira. > > 5. is the best alternative when thinking of the future. With a good > Interface Components manager, and a good Application Manager, installing > and upgrading applications will be very easy. This solves the problems > of 4, since each app can be released as soon as its bugs are solved, and > auto-updated on all clients in no time. The problem is that we would > need a lot of tiny Jira projects, each with its own release cycle. This > is not a code problem, but a infrastructure one. In the future we should > drop Jira (which IMO is much too company-oriented than > umbrella-oriented), and replace it with our own infrastructure: > interface.xwiki.org, as a repository of interface components, where each > component has its own space, including our future agile project > management tool. > > > WDYT? Anything against option 5? If no, we'll need to decide some more > details, as to where to put ICs in the svn repo, where to list them in > the wiki, how to name them, etc. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
