On 01/26/2011 04:58 PM, Jerome Velociter wrote:

Hi Marius,

Globally I like the idea, it sounds like a good feature, with a lot of use cases.

I have some concerns/questions :

* It will be somehow "magical" (kind of the same way aspects act for Java code). There will be a strong need for documentation and explanation so that users can understand why some imports are sometime triggered and sometime not.

We have the same magical level right now for style names like withTip. The difference is that the behaviour of withTip is included in all pages, even if it's not used. It's not a problem right now because the code behind it is small, but for style names with complex behaviour it's best to include the code on demand.

* In my opinion we cannot release this without a UI that at least lists all SkinExtensions.

I agree.

* Isn't there a risk the TX could be a bit costly for complex documents (big and deep XDOM) ?

Might be. In the end it's <<load unused code>> vs. <<spend time deciding what code is needed>>

* Since order matters for both JS and CSS, how do we chose which SX gets included in what order ? (I know this question already applies for our SX plugin - just raising it again now)

I haven't though about this. It's indeed a problem.

* This will lead to more and more segmentation in skin files/SX files (JS and CSS). We need to foresee the possibility that some sites want to pack some or all JS and CSS together in one file in production mode. This need to be somehow supported (configuration ?)

Indeed. But since the content editor is no longer hard-coding the path to the resource, he doesn't care how the JS/CSS are loaded (separately or packed). The skin extension plugin/component could be enhanced to pack all used resources and generate one single link/script element in the HTML head. Unfortunately my proposal has one big drawback: overwriting. It's easy for a normal used to overwrite the gallery behaviour for all the users. I think this is handled by wiki macros through the scope parameter. Thanks, Marius

Jerome.

On Mon, Jan 24, 2011 at 5:08 PM, Marius Dumitru Florea <[email protected]> wrote:

...

Hi devs,

I have this wiki syntax:

----------8<---------- {{velocity output="false"}} $xwiki.ssrx.use('uicomponents/widgets/gallery.css') $xwiki.jsrx.use('uicomponents/widgets/gallery.js') {{/velocity}} (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8----------

and I'd like to make the resource import automatic. I think we can achieve this in two steps.

(1) Add a way to group skin extensions. I'd like to be able to write this:

----------8<---------- {{velocity output="false"}} $xwiki.gsx.use('gallery') {{/velocity}} (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8----------

(2) Write a rendering transformation that looks for style names (CSS classes) in the content and imports the skin extension group with the same name. This way I'd be able to write just:

----------8<---------- (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8----------

Let's consider the technical details now:

(1) I propose we add two XWiki classes:

XWiki.SkinExtension * type (StaticList): jsrx * resource (String): uicomponents/widgets/gallery.js

XWiki.SkinExtensionRole * role (String): gallery

which will be used by a new SkinExtension plugin and component (hint=gsx). The XWiki.SkinExtensionRole objects will be joined with XWiki.SkinExtension objects by document id. In other words, in order to create a skin extension group you have to add a XWiki.SkinExtensionRole object and multiple XWiki.SkinExtension objects to a document.

To make group creation easier for StyleSheetExtension and JavaScriptExtension the new skin extension plugin will include them automatically in the group defined by the XWiki.SkinExtensionRole. In other words if you want to group a JSX and a SSX that are on the same document you just have to add a XWiki.SkinExtensionRole object to that document.

(2) The rendering transformation that will automatically import the skin extension groups based on style names will use the skin extension component defined at step (1). This transformation should be the last one executed.

WDYT? I'd like to implement this ASAP as it doesn't seem to be very complicated.

Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Wed, Jan 26, 2011 at 7:16 PM, Vincent Massol <[email protected]> wrote:

Hi Marius,

While this is technically interesting isn't this adding too much complexity for the gain it brings?

For ex: * the transformation will run always on all pages for all content, thus adding some small performance lag * it's a little bit too magical maybe

I feel your example doesn't clearly show the advantage: * the grouping is saving 1 line of code in the example * the automatic import is saving 4 lines at the expense of clarity

Personally I think i'd *much* prefer to hide all this behind a gallery macro:

{{gallery}} image:first.png ... image:last.png {{/gallery}}

That macro would automatically add the SSX/JSX + class, thus hiding all complexity and implementation details from users.

WDYT?

There are use case where the approach Marius proposes is interesting, over specialized macros. I have in mind for example the behavioral "maximizable" CSS class name (See http://platform.xwiki.org/xwiki/bin/view/DevGuide/SpecialCSSClasses#HB2.Beha... ) Right now one have to explicitly write down the SSX/JSX imports. Of course we could as well write a {{maximizable}} macro that takes care of that. But I'm not sure we want to offer specialized macros for each behavioral CSS class name we want to support and that requires JS and/or CSS. I understand your remark about the added complexity though. Jerome.

Thanks -Vincent

On Jan 24, 2011, at 5:08 PM, Marius Dumitru Florea wrote:

...

Hi devs,

I have this wiki syntax:

----------8<---------- {{velocity output="false"}} $xwiki.ssrx.use('uicomponents/widgets/gallery.css') $xwiki.jsrx.use('uicomponents/widgets/gallery.js') {{/velocity}} (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8----------

and I'd like to make the resource import automatic. I think we can achieve this in two steps.

(1) Add a way to group skin extensions. I'd like to be able to write this:

----------8<---------- {{velocity output="false"}} $xwiki.gsx.use('gallery') {{/velocity}} (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8----------

(2) Write a rendering transformation that looks for style names (CSS classes) in the content and imports the skin extension group with the same name. This way I'd be able to write just:

----------8<---------- (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8----------

Let's consider the technical details now:

(1) I propose we add two XWiki classes:

XWiki.SkinExtension * type (StaticList): jsrx * resource (String): uicomponents/widgets/gallery.js

XWiki.SkinExtensionRole * role (String): gallery

which will be used by a new SkinExtension plugin and component (hint=gsx). The XWiki.SkinExtensionRole objects will be joined with XWiki.SkinExtension objects by document id. In other words, in order to create a skin extension group you have to add a XWiki.SkinExtensionRole object and multiple XWiki.SkinExtension objects to a document.

To make group creation easier for StyleSheetExtension and JavaScriptExtension the new skin extension plugin will include them automatically in the group defined by the XWiki.SkinExtensionRole. In other words if you want to group a JSX and a SSX that are on the same document you just have to add a XWiki.SkinExtensionRole object to that document.

(2) The rendering transformation that will automatically import the skin extension groups based on style names will use the skin extension component defined at step (1). This transformation should be the last one executed.

WDYT? I'd like to implement this ASAP as it doesn't seem to be very complicated.

Thanks, Marius

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Jan 27, 2011, at 10:05 AM, Marius Dumitru Florea wrote:

On 01/26/2011 08:16 PM, Vincent Massol wrote:

...

Hi Marius,

While this is technically interesting isn't this adding too much complexity for the gain it brings?

For ex: * the transformation will run always on all pages for all content, thus adding some small performance lag * it's a little bit too magical maybe

I feel your example doesn't clearly show the advantage: * the grouping is saving 1 line of code in the example * the automatic import is saving 4 lines at the expense of clarity

Personally I think i'd *much* prefer to hide all this behind a gallery macro:

{{gallery}} image:first.png ... image:last.png {{/gallery}}

That macro would automatically add the SSX/JSX + class, thus hiding all complexity and implementation details from users.

WDYT?

Indeed, this will do for my purpose (office presentation viewer). But, as Jerome said, sometimes using style names is more convenient.

Yes but in that case we allow it (as you've shown in your example below) even if not 100% convenient (it's not that bad) :) I think it's good to direct users to package more complex things into macros, especially since it's easy to package as a wiki macro. It has several advantages, one of them being that it makes the "snippet" reusable. Thanks -Vincent

...

On Jan 24, 2011, at 5:08 PM, Marius Dumitru Florea wrote:

...

Hi devs,

I have this wiki syntax:

----------8<---------- {{velocity output="false"}} $xwiki.ssrx.use('uicomponents/widgets/gallery.css') $xwiki.jsrx.use('uicomponents/widgets/gallery.js') {{/velocity}} (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8----------

and I'd like to make the resource import automatic. I think we can achieve this in two steps.

(1) Add a way to group skin extensions. I'd like to be able to write this:

----------8<---------- {{velocity output="false"}} $xwiki.gsx.use('gallery') {{/velocity}} (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8----------

(2) Write a rendering transformation that looks for style names (CSS classes) in the content and imports the skin extension group with the same name. This way I'd be able to write just:

----------8<---------- (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8----------

Let's consider the technical details now:

(1) I propose we add two XWiki classes:

XWiki.SkinExtension * type (StaticList): jsrx * resource (String): uicomponents/widgets/gallery.js

XWiki.SkinExtensionRole * role (String): gallery

which will be used by a new SkinExtension plugin and component (hint=gsx). The XWiki.SkinExtensionRole objects will be joined with XWiki.SkinExtension objects by document id. In other words, in order to create a skin extension group you have to add a XWiki.SkinExtensionRole object and multiple XWiki.SkinExtension objects to a document.

To make group creation easier for StyleSheetExtension and JavaScriptExtension the new skin extension plugin will include them automatically in the group defined by the XWiki.SkinExtensionRole. In other words if you want to group a JSX and a SSX that are on the same document you just have to add a XWiki.SkinExtensionRole object to that document.

(2) The rendering transformation that will automatically import the skin extension groups based on style names will use the skin extension component defined at step (1). This transformation should be the last one executed.

WDYT? I'd like to implement this ASAP as it doesn't seem to be very complicated.

Thanks, Marius

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Jan 27, 2011, at 12:59 PM, Marius Dumitru Florea wrote:

On 01/27/2011 01:41 PM, Vincent Massol wrote:

...

On Jan 27, 2011, at 10:05 AM, Marius Dumitru Florea wrote:

...

On 01/26/2011 08:16 PM, Vincent Massol wrote:

...

Hi Marius,

While this is technically interesting isn't this adding too much complexity for the gain it brings?

For ex: * the transformation will run always on all pages for all content, thus adding some small performance lag * it's a little bit too magical maybe

I feel your example doesn't clearly show the advantage: * the grouping is saving 1 line of code in the example * the automatic import is saving 4 lines at the expense of clarity

Personally I think i'd *much* prefer to hide all this behind a gallery macro:

{{gallery}} image:first.png ... image:last.png {{/gallery}}

That macro would automatically add the SSX/JSX + class, thus hiding all complexity and implementation details from users.

WDYT?

Indeed, this will do for my purpose (office presentation viewer). But, as Jerome said, sometimes using style names is more convenient.

Yes but in that case we allow it (as you've shown in your example below) even if not 100% convenient (it's not that bad) :)

...

I think it's good to direct users to package more complex things into macros, especially since it's easy to package as a wiki macro. It has several advantages, one of them being that it makes the "snippet" reusable.

One issue we have is that wiki macros that import JS/CSS can't be used inside velocity code.

what's the problem? Thanks -Vincent

Thanks, Marius

...

Thanks -Vincent

...

...

On Jan 24, 2011, at 5:08 PM, Marius Dumitru Florea wrote:

...

Hi devs,

I have this wiki syntax:

----------8<---------- {{velocity output="false"}} $xwiki.ssrx.use('uicomponents/widgets/gallery.css') $xwiki.jsrx.use('uicomponents/widgets/gallery.js') {{/velocity}} (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8----------

and I'd like to make the resource import automatic. I think we can achieve this in two steps.

(1) Add a way to group skin extensions. I'd like to be able to write this:

----------8<---------- {{velocity output="false"}} $xwiki.gsx.use('gallery') {{/velocity}} (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8----------

(2) Write a rendering transformation that looks for style names (CSS classes) in the content and imports the skin extension group with the same name. This way I'd be able to write just:

----------8<---------- (% class="gallery" %)((( image:first.png ... image:last.png ))) ---------->8----------

Let's consider the technical details now:

(1) I propose we add two XWiki classes:

XWiki.SkinExtension * type (StaticList): jsrx * resource (String): uicomponents/widgets/gallery.js

XWiki.SkinExtensionRole * role (String): gallery

which will be used by a new SkinExtension plugin and component (hint=gsx). The XWiki.SkinExtensionRole objects will be joined with XWiki.SkinExtension objects by document id. In other words, in order to create a skin extension group you have to add a XWiki.SkinExtensionRole object and multiple XWiki.SkinExtension objects to a document.

To make group creation easier for StyleSheetExtension and JavaScriptExtension the new skin extension plugin will include them automatically in the group defined by the XWiki.SkinExtensionRole. In other words if you want to group a JSX and a SSX that are on the same document you just have to add a XWiki.SkinExtensionRole object to that document.

(2) The rendering transformation that will automatically import the skin extension groups based on style names will use the skin extension component defined at step (1). This transformation should be the last one executed.

WDYT? I'd like to implement this ASAP as it doesn't seem to be very complicated.

Thanks, Marius

On Thu, Jan 27, 2011 at 13:54, Marius Dumitru Florea <[email protected]> wrote:

On 01/27/2011 02:37 PM, Vincent Massol wrote:

...

On Jan 27, 2011, at 12:59 PM, Marius Dumitru Florea wrote:

...

On 01/27/2011 01:41 PM, Vincent Massol wrote:

...

On Jan 27, 2011, at 10:05 AM, Marius Dumitru Florea wrote:

...

On 01/26/2011 08:16 PM, Vincent Massol wrote:

...

Hi Marius,

While this is technically interesting isn't this adding too much complexity for the gain it brings?

For ex: * the transformation will run always on all pages for all content, thus adding some small performance lag * it's a little bit too magical maybe

I feel your example doesn't clearly show the advantage: * the grouping is saving 1 line of code in the example * the automatic import is saving 4 lines at the expense of clarity

Personally I think i'd *much* prefer to hide all this behind a gallery macro:

{{gallery}} image:first.png ... image:last.png {{/gallery}}

That macro would automatically add the SSX/JSX + class, thus hiding all complexity and implementation details from users.

WDYT?

Indeed, this will do for my purpose (office presentation viewer). But, as Jerome said, sometimes using style names is more convenient.

Yes but in that case we allow it (as you've shown in your example below) even if not 100% convenient (it's not that bad) :)

...

I think it's good to direct users to package more complex things into macros, especially since it's easy to package as a wiki macro. It has several advantages, one of them being that it makes the "snippet" reusable.

One issue we have is that wiki macros that import JS/CSS can't be used inside velocity code.

...

what's the problem?

Nested script macros. We should introduce a:

Wiki macros are supposed to break nested script protection like include macro and i'm pretty sure there is tests for it so I don't see what's the issue here.

{{use type="jsx" resource="Space.Page"/}}

to overcome this issue.

Thanks, Marius

...

Thanks -Vincent

...

Thanks, Marius

...

Thanks -Vincent

...

...

On Jan 24, 2011, at 5:08 PM, Marius Dumitru Florea wrote:

> Hi devs, > > I have this wiki syntax: > > ----------8<---------- > {{velocity output="false"}} > $xwiki.ssrx.use('uicomponents/widgets/gallery.css') > $xwiki.jsrx.use('uicomponents/widgets/gallery.js') > {{/velocity}} > (% class="gallery" %)((( > image:first.png > ... > image:last.png > ))) > ---------->8---------- > > and I'd like to make the resource import automatic. I think we can > achieve this in two steps. > > (1) Add a way to group skin extensions. I'd like to be able to write this: > > ----------8<---------- > {{velocity output="false"}} > $xwiki.gsx.use('gallery') > {{/velocity}} > (% class="gallery" %)((( > image:first.png > ... > image:last.png > ))) > ---------->8---------- > > (2) Write a rendering transformation that looks for style names (CSS > classes) in the content and imports the skin extension group with the > same name. This way I'd be able to write just: > > ----------8<---------- > (% class="gallery" %)((( > image:first.png > ... > image:last.png > ))) > ---------->8---------- > > Let's consider the technical details now: > > (1) I propose we add two XWiki classes: > > XWiki.SkinExtension > * type (StaticList): jsrx > * resource (String): uicomponents/widgets/gallery.js > > XWiki.SkinExtensionRole > * role (String): gallery > > which will be used by a new SkinExtension plugin and component > (hint=gsx). The XWiki.SkinExtensionRole objects will be joined with > XWiki.SkinExtension objects by document id. In other words, in order to > create a skin extension group you have to add a XWiki.SkinExtensionRole > object and multiple XWiki.SkinExtension objects to a document. > > To make group creation easier for StyleSheetExtension and > JavaScriptExtension the new skin extension plugin will include them > automatically in the group defined by the XWiki.SkinExtensionRole. In > other words if you want to group a JSX and a SSX that are on the same > document you just have to add a XWiki.SkinExtensionRole object to that > document. > > (2) The rendering transformation that will automatically import the skin > extension groups based on style names will use the skin extension > component defined at step (1). This transformation should be the last > one executed. > > WDYT? I'd like to implement this ASAP as it doesn't seem to be very > complicated. > > Thanks, > Marius

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne