xwiki-devs June 2012

xwiki-devs@xwiki.org

35 participants
107 discussions

[xwiki-devs] append html node to wysiwyg

by liujinlong5788

Hello , I have sent a similar email yesterday which said I can't append html button to wysiwyg in js. Just now I have tried in plugin with gwt. It doesn't work eithor. For example I define a string varirable String button= "<input type='button' value='xx' />" and use execute(button) ,and it will add a button to wysiwyg editor ,but it does nothing to the source ,so ,the things I have done can't be saved.Of course ,execute(rta.getDocument().createButtonInputElement()) doesn't work eithor. I see the RichTextArea which is implemented by xwiki and extended from the RichTextArea of the gwt has a method setHtml() .And it doesn't work just like execute(). At first ,I think this should be a very easy thing .but I have been defeat by it - -! Pleanse ,help me . Thank you .

13 years

[xwiki-devs] Two problems about wysiwyg

by liujinlong5788

Hello , I an sorry it's also simple problems about wysiwyg. The first one .can I use component in wysiwyg plugin. (The component is to get and save data in database which is not the table created by XWIKI, and not mapped by hibernate )I hava used it ,but it can't run .So , I wander it is the problem in my code or XWIKI doesn't support it (I thinke there is something wront with the grammer .I don't know how to say it correctly ,but I think you can understand it). The second one is when I use js to operate the wysiwyg, I use editor.getRichTextArea().contentWindow.document.body to get the document ,but all the operate to the html do nothing to the source , and {{html}} tag which I think will work also take no effect. So ,If I append html child to the document ,The change can't be saved .Is there method to make it or the method to operate the source .I don't think getSourceText can achieve it .. Thank you!

13 years

[xwiki-devs] [Proposal] Add and Copy CLIRR explanations to release notes when releasing

by Vincent Massol

Hi devs, I'd like to propose that we: 1) always add explanations in our pom.xml files when we add CLIRR excludes (since we should have any based on our deprecation/legacy rule) 2) copy them in our release notes. As an example I've just done that for http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… The advantage: * Users get an explanation as to why we have broken some APIs * We need the explanation in our pom.xml for ourselves to understand why we're excluding some files and since we have that explanation we might as well copy it to the release notes… WDYT? Thanks -Vincent

13 years

[xwiki-devs] [Proposal] XWiki Configuration and Data directories

by Vincent Massol

Hi devs, This proposal is a restart of the thread I've sent, entitled "[Proposal] XWiki's Permanent Directory Strategy for Installations" in which I wasn't clear. Executive Summary ================ Define 2 XWiki directories; one for holding configuration data and one for holding (permanent) data and allow various configurations for our distributions. * Config dir is where xwiki configuration files is located. Examples: xwiki.cfg, xwiki.properties, hibernate.cfg.xml * Data dir is where xwiki writes permanent data. Examples: database/, extension/ lucene/, jetty log files Rationale ======== This proposal below tries to answer the following general use cases: * Ability to easily backup an XWiki install * Ability to easily upgrade an XWiki install * Ability to install XWiki on various OSes, including OSes like Windows 7 which require a total separation of readonly binaries and generated data * Ability to have several instances of XWiki on the same machine Note that I'm sending this email since I'm currently working on making our installer work on Windows 7 and I need an agreement on this before I can continue since I'm currently blocked. Use Cases ========= The proposal below should allow the following use cases easily: UC1: use the standalone zip distribution UC2: upgrade a standalone zip distribution install UC3: Use the WAR production distribution UC4: Upgrade an existing WAR distribution Short Term Proposal ================= * Add 2 system property variables: xwiki.config.dir and xwiki.data.dir * Use the following algorithm for resolving the Config dir (in Environment Module): ** Check if system property xwiki.config.dir is set, if so, use it ** Otherwise default to the WEB-INF directory (same as now) * Use the following algorithm for resolving the Data dir (in Environment Module): ** Check if system property xwiki.data.dir is set, if so, use it ** Otherwise use value of environment.permanentDirectory in xwiki.properties (same as now) ** If no environment.permanentDirectory exists, then use the temporary directory (same as now) * Don't provide a default value for environment.permanentDirectory in xwiki.properties * Note that we probably need to modify a bit Environment module to add support for a Configuration directory (not sure yet about this need). Use Cases Walkthrough =================== UC1: * user unzips, that's all * in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config and xwiki.data.dir=[homedir]/data * environment.permanentDirectory is not defined in xwiki.properties UC2: * user unzips new version in another directory and copy the old data and config directories over * Note that this use case is not really a valid one since the standalone zip is not meant to be a production zip at the moment UC3: * user deploys war in container's webapps dir and edits WEB-INF/xwiki.properties to set environment.permanentDirectory (same as now) * however the recommendation is for the user to put it's XWiki config dir and data dir somewhere on his system and use the xwiki.config.dir and xwiki.data.dir system properties in his startup/stop scripts, thus making it easy for UC4 UC4: * users replaces the older WAR with the new WAR and if he has applied the recommendation from UC3 that's all he has to do. Otherwise he needs to edit the xwiki.properties file to set environment.permanentDirectory WDYT? Thanks -Vincent

13 years

[xwiki-devs] context.language having wild values?

by Paul Libbrecht

Hello developers, We had some (rare) users that had a very bad issue because we told their browser to load the lang_xx.js of their language. And their language was... wild! See: http://jira.xwiki.org/browse/CURRIKI-5694 for a sample of the things that got submitted to us. Sure, we'll now protect against these bizarre languages, still, there might be other things broken. Is there some guarantee on the set of possible languages provided by $context.language? I was expect the possible values of ISO-623-1 but that was clearly not sufficient! paul

13 years

[xwiki-devs] [VOTE] Remove the notion of sending messages from the activity macro

by Eduard Moraru

Hi devs, We have recently extracted the functionality of sending messages from the activity macro into a new messageSender macro [1][2]. However, for backwards compatibility reasons, the activity macro still uses by default (unless the parameter messageSender='false' is specified) the messageSender macro so the users still see the ability to send messages as a feature of the activity macro. The proposal is that, for 4.1, we follow the original jira [2] issue idea (as seen in the issue's images) and: - Completely remove the messageSender macro call from activity macro (including the recently introduced messageSender=true/false parameter) - Providing instead a "Send Message" gadget for the main Dashboard that will use the new messageSender macro This way we have 2 clear macros, no more mixing: - messageSender for sending messages - activity for displaying messages (and other events) Additionally, it makes it easier for users to remove the ability to send messages from the homepage by editing the Dahsboard and removing the "Send Message" gadget. Here's my +1. Thanks, Eduard ---------- [1] http://xwiki.markmail.org/thread/mxpkpqfplbznfgbd [2] http://jira.xwiki.org/browse/XWIKI-7679

13 years

[xwiki-devs] deadly bug on MoveItM: temporary fix

by Paul Libbrecht

Hello Smalalers, Thanks to Marc, we just realized that MoveItM broke since quite a while, since shortly after 1.1. I rolled back to the version 1.1 on prod so that http://sail-m.de/smala/act/de.ph-ludwigsburg.MZimmermann-Modul1.2.MoveItM_S… kind of works whereas: http://dev.sail-m.de/smala/act/de.ph-ludwigsburg.MZimmermann-Modul1.2.MoveI… shows the bug. I've opened: http://youtrack.i2geo.net/youtrack/issue/LABB-16 do you know of anyone else intending to use MoveItM? It is not very clear if the logging will work on the URL that works... paul

13 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs June 2012