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:

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.

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:

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.