Hin On Dec 16, 2008, at 4:36 AM, 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 Could you explain why it doesn't fit. My opinion is that everything should fit into applications and that a wiki is just an addition of 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. > I think it would help if you could describe what you're trying to do. > 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. +1 for either 3 (admin app if it's an admin feature but not enterprise- wiki since this is meant to only contain some home page in the end) or 5 but I'd like to know more what it's about to be able to decide. > 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. hmmm you seem to differentiate IC manager and App manager. Aren't they the same? I'd expect the app manager to handle all types of xwiki extensions (pages, jars, resources, skin extensions, interface extensions, etc). I don't like 5 if it's too small (because of the infra cost), in which case I'd prefer to find a generic name for grouping them together but not a technical name, rather a business name. For that we need to see what feature you're talking about and what business role it has. > 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. I'm still unsure what is an IC. From the description above, it's just a page with a JSX and SSX object attached right? I'm also getting confused between IX and IC (note: I haven't re-read the IX document). I'd love to see a diagram putting all of these next to each other and interacting together to form a page. Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
