10 Feb
2011
10 Feb
'11
9:57 a.m.
Hi Vincent,
On 02/10/2011 10:21 AM, Vincent Massol wrote:
In the case of gallery macro the width and height parameters are used to
limit the size of the displayed images (CSS max-width and max-height).
It may be possible to determine the width and height from the container
but it was easier for me to take them from the macro parameters. I'll
see if I can change the gallery CSS so that it doesn't have to know the
width and height.
The gallery macro won't depend on the box macro. I just gave the box
macro as an example of a macro that accepts any wiki content. Images
will be extracted on the client side using JavaScript and the the rest
of the macro content will be hidden through CSS.
Note that I can't filter images on the server side (i.e. look for image
blocks in the macro content) because I want to support:
{{gallery}}
{{html}}
HTML content with images
{{/html}}
{{/gallery}}
Thanks,
Marius
Hi Marius,
On Feb 10, 2011, at 9:10 AM, Marius Dumitru Florea wrote:
Hi devs,
I'd like to add a gallery macro that will be used like this:
{{gallery}}
any wiki content
{{/gallery}}
and which is equivalent to:
{{velocity output="false"}}
$xwiki.jsfx.use('uicomponents/widgets/gallery/gallery.js')
$xwiki.ssfx.use('uicomponents/widgets/gallery/gallery.css')
Should these be standard resources? I think it's
ok for now but we need to think about how to do that in an extension way for the future,
in order to be able to use the extension manager to add such feature to an installed XE.
There was this discussion
http://lists.xwiki.org/pipermail/devs/2010-December/021304.html started
by Anca and in the end she decided to use standard resources because
they are easier to overwrite. I agree that at some point we need to move
them inside the macro jar but before we need to find a way to overwrite
the resources while keeping their request-on-demand nature.
{{/velocity}}
(% class="gallery" %)
(((
any wiki content
)))
Some technical details:
* it won't support in-line mode
WDYM? Will it break when viewed in inline mode?
Yes. Do you have any valid use case when the gallery should work
in-line? I view the gallery as a block so I don't see why you would use
it inside the text like this:
before {{gallery}}image:one.jpg image:two.jpg{{/gallery}} after
* it will have two optional parameters: width and
height, both expressed
in pixel units (i.e. both are positive integers)
Have we decided on a strategy for this? More specifically do we want all our visible
macros to have style params or do we want users to have to surround them with the
container macro to add styling (borders, sizes, etc)?
From the POV of users it's probably easier to have params for all visible macros.
From a logical/reuse POV it's better to wrap any macro with the container macro when
you need to add styling.
WDYT? * it will handle its content as box macro does
(using a
MacroContentParser without running transformations)
BTW I think Box Macro needs to be removed now (merged with the container macro).
Or the Container macro should only care about layout and not styling and let the Box
macro do the styling...
* it will be
placed in xwiki-rendering-macros/xwiki-rendering-macro-gallery/
ok for now. I think we need to start moving non technical macros out. I'll make a
proposal at some point (probably in 3.1)
* images will be displayed as in
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/OfficePresentation…
Nice
Further more, I will change the office importer
module to generate:
{{gallery}}
image:presentation-slide1.jpg
image:presentation-slide2.jpg
...
image:presentation-slideN.jpg
{{/gallery}}
when importing an office presentation file. As a consequence the office
viewer macro will use the gallery macro behind the curtains (i.e.
{{office attachment="presentation.odp"/}} will display the presentation
slides using the gallery macro).
+1
WDYT?
Note that the gallery macro could be based on a generic macro that:
* wraps the content with a GroupBlock and adds a CSS class name
* uses the SkinExtension component to import some JS/CSS resources
but there is no such macro right now. Another thing to note is that I
can't make gallery macro a wiki macro because the office importer module
will depend on it.
Good point.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs