Hi devs,
Currently when we import an office presentation the office importer
module generates an image for each slide and inserts it into the wiki
syntax:
image:myPresentation-slide0.jpg
...
image:myPresentation-slideN.jpg
Some users have complained that:
* when the presentation has many slides (e.g. 100) the page is heavy
because all the slide images are requested at page load time.
* there's no way to switch slides using an user friendly UI. See
http://jira.xwiki.org/jira/browse/XWIKI-5785 .
One simple way to fix this is to group the images and to add a class
name to the group. Then it will be easy to integrate an image gallery
that replaces the group (found by its class name).
I made a simple image gallery to demonstrate this. Please check
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/OfficePresentation…
.
The class name used by the office importer module should be configurable
and should have a default value (e.g. "gallery"). The office viewer
macro can then be changed to have an optional cssClass parameter.
It would be nice if the office importer/viewer would also use a default
image gallery, i.e. request on demand the JavaScript code and the CSS
for the default image gallery when the class name (e.g. cssClass
parameter) is not specified.
WDYT?
Thanks,
Marius
Hi devs,
I wanted to create a component to define the interface for the skin
extension mechanism:
@ComponentRole
public interface SkinExtension {
public void use(String resource);
public void use(String resource, Map<String, Object> parameters);
}
in a module in platform/core called xwiki-skinx-api or
xwiki-skinx-bridge-api
and then implement it with ssx, jsx, ssfx, jsfx, ssrx, jsrx hints in the
skinx plugin. Basically the implementation will do nothing else but grab
the XWikiContext from the Execution, grab XWiki from there, get the
plugin api and call the use function on it.
This will be useful to write code that needs the skin extensions but
doesn't want to depend on the core (macros, for example) and it will
serve as a bridge towards the future implementation of the skinx plugin
as a component.
My +1 for the proposed interface in xwiki-skinx-api and the
implementation in the plugin.
WDYT?
Thanks,
Anca
Hello!
I'm migrating my Xwiki site from 2.1.1.25889 to 2.7.33656
and I cant catch why only Xwiki 1.0 syntax is allowed.
On editing Page Syntax combo box shows only Xwiki 1.0
and rendering also looks bit wrong. E.g. some pages show {pre} tags.
I tried to change ../WEB-INF/xwiki.cfg file without any success.
Can anybody provide some hints?
Thanks!
Valdis
Hi devs,
This is a bit technical but after brainstorming with Thomas we came to the conclusion that in order to implement "generic marker" support the best solution would be to add the notion of original blocks to the Block interface itself.
This will results in 2 things:
* adding new begin/endOriginalBlocks events (in Listener.java)
* adding a CollectionBlock that is a non content block used simply to group together one or several blocks. We'll need it in the following use case: when a single block is replaced with several blocks, we'll need to wrap the several blocks in a CollectionBlock that has an originalBlocks field set to the previous single block. It's also needed in some other use cases, for example when a block is replaced by a leaf block (non father block), we need a wrapper block to group together begin/endOriginal blocks and the new block events.
In summary the idea is to not require a new generic marker block and instead set the notion of original block in the Block interface itself.
WDYT?
Thanks
-Vincent
Hello fellow developers,
I can't reach http://www.xwiki.org/xwiki/bin/view/Main/WebHome while www.xwiki.org redirects properly (so the xwiki is down, not the apache).
Something must be hanging wrong somewhere.
That makes it that I can't commit it seems.
Skol seems to be "working" since quite a while (more than an hour?).
paul