January 2009 - xwiki-devs@xwiki.org

[xwiki-devs] [Proposal] xwiki-web-standard reorganization cleanup
by Jean-Vincent Drean 28 Jan '09

28 Jan '09

Hi, I'm about to commit silk icons so that we bundle them with our webapp. I want to commit them under xwiki-web-standard but we don't have any standard place where to put this kind of common resources. We currently have common resources (js and icons) under the root of our webapp (yui,xwiki.js,etc) and in the albatross skin (most of them). Those resources are independant from a particular skin and thus shouldn't be placed in one of them (at least imho). I suggest that we move javascript and icon files out of albatross and that we introduce a new rule: don't put javascript in our skins. Note that I'm not suggesting to deprecate our baseskin mechanism since being able to use inheritance between skins is a good thing (it allows to customize only part of the styles). Proposal 1 ======== Tree: xwiki/ -- resources/ ---- icons/ ------ tango/ ------ silk/ ---- javascript/ ------ lib/ (we could minimize files in this folder at build time with rhino) -------- prototype/ -------- scriptaculous/ -------- yui/ ------ xwiki/ (files get from this directory would be parsed since almost xwiki js files contains velocity calls) -- skins/ ---- toucan/ -- templates/ -- META-INF/ -- WEB-INF/ Getter methods: Util.getJavascriptResource(String filename) Util.getIconResource(String filename) The resources directory would be held by xwiki-web-standard. Note that this way of getting resources would prevent overloading of icons and javascript from the skin (unlike xwiki.getSkinFile). Proposal 2 ======== Tree: xwiki/ -- skins/ ---- commons/ ------ icons/ -------- tango/ -------- silk/ ------ javascript/ -------- lib/ (we could minimize files in this folder at build time with rhino) ---------- prototype/ ---------- scriptaculous/ ---------- tinymce/ ---------- yui/ -------- xwiki/ (files get from this directory would be parsed since almost xwiki js files contains velocity calls) ---- toucan/ -- templates/ -- META-INF/ -- WEB-INF/ Getter methods: Modify getSkinFile to look into commons after looking into skin and baseskin (toucan then albatross in our distrib). The skins/commons/ directory would be held by xwiki-web-standard. I'd also like to take advantage of this refactoring to remove some files from the root of our webapp if we all agree: - JSTrim* - freemind (unused) - s5 (moved out of XE 2 years ago IIRW) WDYT ? Thanks, JV.

5 6

[xwiki-devs] blogs in XE 1.8
by Vivian Richard 27 Jan '09

27 Jan '09

Hi how can I make my xwiki EP 1.8 work like WS? I need all my users to have their own blogs. Regards....

2 1

Re: [xwiki-devs] [xwiki-notifications] r15759 - in platform: core/trunk/xwiki-core/src/main/resources xwiki-applications/trunk/administration/src/main/resources/XWiki
by Vincent Massol 27 Jan '09

27 Jan '09

On Jan 27, 2009, at 12:30 PM, jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-01-27 12:30:04 +0100 (Tue, 27 Jan 2009) > New Revision: 15759 > > Modified: > platform/core/trunk/xwiki-core/src/main/resources/ > ApplicationResources.properties > platform/xwiki-applications/trunk/administration/src/main/ > resources/XWiki/AdminGeneralSheet.xml > Log: > XAADMINISTRATION-17 : Display date format option in the general > section of the administration > > Implemented. > > Modified: platform/core/trunk/xwiki-core/src/main/resources/ > ApplicationResources.properties > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/resources/ > ApplicationResources.properties 2009-01-27 11:28:16 UTC (rev 15758) > +++ platform/core/trunk/xwiki-core/src/main/resources/ > ApplicationResources.properties 2009-01-27 11:30:04 UTC (rev 15759) > @@ -158,6 +158,7 @@ > registration=Registration > multilingual=Multi Lingual > default_language=Default Language > +dateformat=<a href="http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration#HDateform… > ">Date format</a> hmm... do we want this? Are we already linking from the source to external documentation? The risk is that it's going to be very easy to break the link when we reorganize documentation and that it requires internet connection. The alternative could be to have a tooltip with the format defined in there. WDYT? Thanks -Vincent > > authenticate_view=Prevent unregistered users from viewing pages, > regardless of the page or space rights > authenticate_edit=Prevent unregistered users from editing pages, > regardless of the page or space rights > baseskin=Base Skin > > Modified: platform/xwiki-applications/trunk/administration/src/main/ > resources/XWiki/AdminGeneralSheet.xml > =================================================================== > --- platform/xwiki-applications/trunk/administration/src/main/ > resources/XWiki/AdminGeneralSheet.xml 2009-01-27 11:28:16 UTC (rev > 15758) > +++ platform/xwiki-applications/trunk/administration/src/main/ > resources/XWiki/AdminGeneralSheet.xml 2009-01-27 11:30:04 UTC (rev > 15759) > @@ -58,7 +58,7 @@ > <content>### Administrate general wiki preferences, at global level > #set($legend = ["language", "editor", "admin", "server"]) > #set($params = $util.hashMap) > -#set($params.language = ["multilingual", "languages" , > "default_language"]) > +#set($params.language = ["multilingual", "languages" , > "default_language", "dateformat"]) > #set($params.editor = ["editor"]) > #set($params.admin = ["admin_email"]) > #set($params.server = ["smtp_server"])

2 3

[xwiki-devs] OfficeImporter-Wysiwyg-FileUpload
by Asiri Rathnayake 27 Jan '09

27 Jan '09

Devs, I've been brainstorming about implementing office importer functionality in wysiwyg where the user will be able to upload a document and have it's content imported into the current page being edited (i.e into the wysiwyg editor). Note that we already have the copy/paste functionality implemented. The first problem I see is that GWT doesn't have a way to upload a file with a usual RPC call. Given the parameters, following is one possible way out of this problem, 1. Define an OfficeImporterServlet which mapps to /xwiki/officeimporter 2. Let the office importer wysiwyg plugin make a POST request to this servlet with a FileUpload widget ( http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/use… ). 3. The servlet will import the document into xhtml and write back the result as the response. 4. Office importer wysiwyg plugin in turn takes the result and put it into the wysiwyg editor. And the second problem arises when there are non-textual content (ex. images) in the document submitted. In this case, office importer servlet must attach these files into the wiki page which is being edited. Now, if the user decides to cancel the whole edit operation just after the import operation, there must be a way to remove those attachments. How can we do this? (For the moment I don't know how to handle this case) Please let me know if you have any comments :) Thanks. - Asiri

4 8

[xwiki-devs] [Proposal] JIRA and SVN reorganization cleanup
by Vincent Massol 27 Jan '09

27 Jan '09

Hi, In order to better organize our SVN/JIRA I propose to implement the following refactoring: 1) Release all platform modules simultaneously. Rationale: make it easy to release and to ensure all versions work together. 2) Remove notion of core. Keep only notion of platform. It's up the products/projects to hand pick whatever components they need from the platform. 3) Move in SVN platform/core/* to platform/components/ except for platform/core/xwiki-core which is moved to platform/xwiki-core/ (while waiting to be split into components) 4) in JIRA create a new category named "XWiki Platform Components" and have one jira project for each top level module in platform/ components/. Move the "XWiki Core" jira project from the "XWiki Core & Products" category to the "XWiki Platform Components" category. 5) In JIRA rename "XWiki Core & Products" to "XWiki Top Level Projects" 6) Create some tools on dev.xwiki.org to help with releases (using swizzle jira). Namely: - a tool to automatically add a version to a set of jira projects (we'll need to do that to manipulate all jira projects in "XWiki Platform Components" all together). Same to release a version WDYT? Note that I've tried imagining keeping all platform modules under the same jira project but I've ruled it out since that doesn't work well for several reasons: * there's no notion of sub-components in jira which would mean creating hundreds of jira components... * we already have some modules in separate jira projects * it may happen that we may want to occasionally release a module separately in the future for some reason Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

2 1

[xwiki-devs] [Proposal] Want to play a game with our build system and Hudson?
by Vincent Massol 26 Jan '09

26 Jan '09

Hi devs, Just found this plugin which sounds pretty promising: http://hudson.gotdns.com/wiki/display/HUDSON/The+Continuous+Integration+Gam… I think our build is failing a bit too frequently and we're not always paying enough attention to checkstyle rules(me included) and the like so maybe this game idea could help us in this direction. WDYT? Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

9 9

Re: [xwiki-devs] [xwiki-notifications] r15733 - platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/plugin/importer
by Vincent Massol 26 Jan '09

26 Jan '09

On Jan 26, 2009, at 11:12 AM, asiri (SVN) wrote: > Author: asiri > Date: 2009-01-26 11:12:27 +0100 (Mon, 26 Jan 2009) > New Revision: 15733 > > Modified: > platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ > client/plugin/importer/ImporterPlugin.java > Log: > Addressing review comments: Checkstyle fix. > > Modified: platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/ > wysiwyg/client/plugin/importer/ImporterPlugin.java > =================================================================== > --- platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ > client/plugin/importer/ImporterPlugin.java 2009-01-26 09:07:00 UTC > (rev 15732) > +++ platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/ > client/plugin/importer/ImporterPlugin.java 2009-01-26 10:12:27 UTC > (rev 15733) > @@ -132,7 +132,8 @@ > if (importerDialog.isFilterStyles()) { > params.put("filterStyles", "strict"); > } > - params.put("namespacesAware", "false"); // For Office2007 > + // For Office2007 I think explaining why it is needed for office 2007 would help. > > + params.put("namespacesAware", "false"); > > WysiwygService.Singleton.getInstance().cleanOfficeHTML(inputHtml, > "wysiwyg", params, this); > } > } Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

2 1

[xwiki-devs] alphanumeric sorting
by Vivian Richard 25 Jan '09

25 Jan '09

Hi devs, column sorting (as shown in table generated by "xwiki.result") does only string sort. Is there any way to do alphanumeric sort? for example sorting does something like this: a1, a10, a11, a2, a21, a3,a4 ..... , a9, ...... I would like to get something like this: a1, a2, a3, a4, ... a9.... a10, a11, a21, ...... Also is there a way just to do the numeric sort? Regards......

3 2

[xwiki-devs] Social Networking via OpenID support in Xwiki?
by Niels Mayer 23 Jan '09

23 Jan '09

Seems like there's a number of interesting social networking "protocols" that may be interesting to support in Xwiki. Any plans to support any of these: http://www.google.com/friendconnect/ http://developers.facebook.com/connect.php http://developer.myspace.com/Community/blogs/devteam/archive/2008/12/09/int… Of these, google's friendconnect looks most interesting: http://www.youtube.com/v/N94s7ix0JPo&hl=en&autoplay=1 With Google Friend Connect, visitors to your site or blog can: - Sign in with their Google, Yahoo, AIM or OpenID account. - Interact with other visitors by making friends, sharing media, posting comments, playing games, and more. - Invite friends from other social networks and contact lists to join your site or blog. [image: Sign in - Post reviews, share media, and more - Invite friends] Niels http://nielsmayer.com

1 0

[xwiki-devs] Fwd: [ossgtp] Groovy 1.6-RC-2 is out!
by Vincent Massol 22 Jan '09

22 Jan '09

Groovy 1.6RC2 is out. We could upgrade. Thanks -Vincent Begin forwarded message: > From: Guillaume Laforge <glaforge(a)gmail.com> > Date: January 22, 2009 10:25:26 PM CEST > To: Groovy User <user(a)groovy.codehaus.org>, Grails Users <user(a)grails.codehaus.org > >, GroovyDev <dev(a)groovy.codehaus.org>, announce(a)groovy.codehaus.org > Subject: [ossgtp] Groovy 1.6-RC-2 is out! > Reply-To: ossgtp(a)yahoogroups.com > > Hi all, > > The Groovy development team and SpringSource are pleased to announce > the second candidate for Groovy 1.6. > This release is a bug fix release, and as you can see by looking at > the JIRA issues closed -- almost a hundred, a lot of work has been > done to ensure that our next major release is of great quality, and > various improvements have been introduced -- check for instance the > much nicer and thourough output of GroovyDoc! > > This version obviously also contain all the performance improvements > and features of the latest betas and RC. You can read more about > them by reading the previous announcements: > Groovy 1.6-beta-1 > Groovy 1.6-beta-2 > Groovy 1.6-RC-1 > You can download Groovy 1.6-RC-2 at the usual place: http://groovy.codehaus.org/Download > > And now, we need your help to test drive this release candidate! We > need you to find possible critical bugs or regressions, so please > make sure you try 1.6-RC-2 with your project, to be able to upgrade > as soon as possible to the latest and greatest Groovy. > > We're looking forward to your feedback. > > Thank you all for your hard work and your contributions. > > > -- > Guillaume Laforge > Groovy Project Manager > Head of Groovy Development at SpringSource > http://www.springsource.com/g2one

1 0