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
On 12/28/2010 01:22 PM, evalica (SVN) wrote:
> Author: evalica
> Date: 2010-12-28 13:22:42 +0100 (Tue, 28 Dec 2010)
> New Revision: 33714
>
> Modified:
> enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeClass.xml
> enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeSheet.xml
> enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeTemplate.xml
> enterprise/trunk/wiki/src/main/resources/ColorThemes/DefaultColorTheme.xml
> enterprise/trunk/wiki/src/main/resources/ColorThemes/WizardPropertyMapping.xml
> Log:
> XE-796: Customizable "Add" menu entry from the Color Theme Wizard
>
> Modified: enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeSheet.xml
> ===================================================================
> --- enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeSheet.xml 2010-12-28 12:18:23 UTC (rev 33713)
> +++ enterprise/trunk/wiki/src/main/resources/ColorThemes/ColorThemeSheet.xml 2010-12-28 12:22:42 UTC (rev 33714)
> @@ -1431,6 +1434,7 @@
> <div #elementMetaData('mainmenu')>
> <div>
> $msg.get('xe.themes.colors.wizard.mainMenu')
I think it would be better to use a different text for this one, since
it's supposed to be used only for the Add entry:
> +<span #elementMetaData('menuaddentry')>$msg.get('xe.themes.colors.wizard.menuEntry')#$msg.get('core.menu.create')</span>
> <span #elementMetaData('menuentry')>$msg.get('xe.themes.colors.wizard.menuEntry')#1</span>
> <span #elementMetaData('menuentry')>$msg.get('xe.themes.colors.wizard.menuEntry')#2</span>
> </div>
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
We have a general problem when upgrading XWiki which is to not forget to
exclude certain files from the import.
The manual exclusion is something that generates all sorts of problems
especially when done by less experienced users.
These files are:
- preferences
- all and admin group
- admin user
- invitation config file
- anotation config file
Either we make a FULL and an UPGRADE XAR or we make a CODE and CONFIG
xar (initial install would need both xars to be imported).
I'm more for the solution of one FULL and one UPGRADE xar.
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi devs,
I'd like to propose Raluca as a committer.
Raluca is one of the first employees of the of the Romanian branch of
XWiki SAS, with more than three years experience developing applications
on top of the XWiki platform. She didn't have time to contribute that
much code to the platform, but she's been active on the mailing lists,
she provided several patches, and she's the main developer behind the
new Activity reimplementation of the old Recent Changes feature.
I trust her to bring good value to the community, so here's my +1.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/