On Tue, Dec 16, 2008 at 4:36 AM, Sergiu Dumitriu <[email protected]> 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?

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:

I'll make the same votes : +1 for 5, with a +0 for 4 and -1 for the rest. Since you're worried by the number of JIRA projects implied by 5) I'd be curious to see a list of let's say 10 ICs you have in mind. May be we could bundle ICs that are related in single modules. JV.

+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.

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:

Going further, since there are no objections, I propose the following structure: - platform - skins - albatross - toucan - components (pom id = xwiki-skin-components) - attachments (pom id = xwiki-skin-attachments) - jump - suggest The packaging for components is XAR, and they are declared as dependencies in products (enterprise/wiki/pom.xml). -- Sergiu Dumitriu http://purl.org/net/sergiu/

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