27 Jan
2011
27 Jan
'11
9:57 a.m.
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
<mariusdumitru.florea(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs