Hi Marius,
very nice, +1 for the {{gallery}} macro.
Guillaume
On Thu, Feb 10, 2011 at 09:57, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
Hi Vincent,
On 02/10/2011 10:21 AM, Vincent Massol wrote:
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?
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.
* 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...
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
> * 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs