April 2009 - xwiki-devs@xwiki.org

[xwiki-devs] Practices for Front-end Development
by Jerome Velociter 21 Apr '09

21 Apr '09

Hi Guys, I've refactored a little http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices to introduce practices for Front-End development. Right now it's only a set of practices for JavaScript development (rules about external libraries, namespacing and backward compatibility/deprecation), but I'd like that in the future we add practices for Design (UI consistency, UX guidelines, etc.) and CSS development. Since the rules I've added for JS have not all been voted (none except the deprecation strategy has been voted in fact), they are of course open to discussion. Tell me what you think, Regards, Jerome.

1 1

Re: [xwiki-devs] [xwiki-notifications] r18877 - in platform/web/trunk/standard: . src/main/webapp/resources/js/xwiki/actionbuttons
by Vincent Massol 21 Apr '09

21 Apr '09

Hi Sergiu, On Apr 21, 2009, at 12:27 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-04-21 00:27:36 +0200 (Tue, 21 Apr 2009) > New Revision: 18877 > > Modified: > platform/web/trunk/standard/pom.xml > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/ > actionbuttons/actionButtons.js > Log: > [misc] Velocity code inside JS breaks the minimization process > > > Modified: platform/web/trunk/standard/pom.xml > =================================================================== > --- platform/web/trunk/standard/pom.xml 2009-04-20 21:32:42 UTC (rev > 18876) > +++ platform/web/trunk/standard/pom.xml 2009-04-20 22:27:36 UTC (rev > 18877) > @@ -139,6 +139,7 @@ > <artifactId>maven-dependency-plugin</artifactId> > <executions> > <execution> > + <id>unpack-dependencies</id> >  > <phase>test</phase> > @@ -264,8 +265,9 @@ > </includes> >  > <excludes> > - <exclude>**/*-min.js</exclude> > + <exclude>**/*-min.js</exclude> > <exclude>**/*-debug.js</exclude> > + <exclude>**/actionButtons.js</exclude> Would be great to have a comment here to explain why this is execluded maybe? (I wonder if we'll remember in a few months/year). Especially since the comment 'exclude already minified files"' doesn't match. Thanks -Vincent

2 1

Re: [xwiki-devs] [xwiki-notifications] r18869 - in platform/web/trunk/standard/src/main/webapp: resources/icons resources/icons/xwiki resources/js/xwiki resources/js/xwiki/actionbuttons templates
by Jerome Velociter 21 Apr '09

21 Apr '09

Hi, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-04-20 22:25:52 +0200 (Mon, 20 Apr 2009) > New Revision: 18869 > > Added: > platform/web/trunk/standard/src/main/webapp/resources/icons/xwiki/ > platform/web/trunk/standard/src/main/webapp/resources/icons/xwiki/ajax-loader-large.gif > platform/web/trunk/standard/src/main/webapp/resources/icons/xwiki/ajax-loader-white.gif > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/actionbuttons/ > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/actionbuttons/actionButtons.js > Modified: > platform/web/trunk/standard/src/main/webapp/templates/edit.vm > platform/web/trunk/standard/src/main/webapp/templates/editactions.vm > platform/web/trunk/standard/src/main/webapp/templates/inline.vm > platform/web/trunk/standard/src/main/webapp/templates/macros.vm > platform/web/trunk/standard/src/main/webapp/templates/preview.vm > platform/web/trunk/standard/src/main/webapp/templates/previewactions.vm > Log: > XWIKI-3654: Improve editor and preview buttons > XWIKI-2597: Hitting 'Back to edit' after previewing an in-line form does not return to inline editing > XWIKI-3653: Edit comment and Minor edit settings lost when going to the preview and back to edit > Done. > > [snip] > > Added: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/actionbuttons/actionButtons.js > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/actionbuttons/actionButtons.js (rev 0) > +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/actionbuttons/actionButtons.js 2009-04-20 20:25:52 UTC (rev 18869) > @@ -0,0 +1,218 @@ > +// ====================================== > +// Form buttons: shortcuts, AJAX improvements and form validation > +// To be completed. > +if (typeof(XWiki) == 'undefined') { > + XWiki = new Object(); > +} > +if (typeof(XWiki.actionButtons) == 'undefined') { > + XWiki.actionButtons = new Object(); > +} > + > +XWiki.actionButtons.EditActions = Class.create({ Why do you make this a class and not an object ? It looks like it will never be instanciated more than once > + initialize : function() { > + this.addListeners(); > + this.addShortcuts(); > + this.saveAndContinueListener = new XWiki.actionButtons.EditActions.AjaxSaveAndContinue(this); > + }, > [snip] > + onCancel : function(evt) { > + evt.stop(); > + var location = evt.element().form.action; > + if (location.indexOf('?' == -1)) { > + location += '?'; > + } > + window.location = location + 'action_cancel=true'; > + }, > + onPreview : function(evt) { > + if (!this.validateForm(evt.element().form)) { > + evt.stop(); > + } > + }, > + onSaveAndView : function(evt) { > + if (!this.validateForm(evt.element().form)) { > + evt.stop(); > + } > + } > +}); Maybe we could fire custom events here for code that want to listen to cancel/preview/save clicks. I faced the case several times, and ended up using some wicked CSS selectors to find the buttons to observe. We could do something like : onSaveAndView : function(evt) { if (!this.validateForm(evt.element().form)) { evt.stop(); } else { document.fire("xwiki:actions:save:before"); } } Jerome. > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

2 1

[xwiki-devs] Integration of XWiki with Magnolia CMS
by Pascal Voitot 20 Apr '09

20 Apr '09

Hello guys, I'm back after some months away... I wanted to create my small website looking like a website (and not like a blog) where I could express myself (even if I don't think it is very interesting ) and where I could test some technologies at the same time... my live public laboratory... I have been working with some CMS for some time now and also with wikis... Beyond the common discussions about the differences between CMS and Wiki I can find everywhere, I still think both approaches are compatible and complementary... Personnally, I prefer writing, formatting with Wiki syntaxes but I also like skinning and authoring/publishing mechanisms in CMS... I have decided to make an experimentation by designing my website using Wiki+CMS... I have chosen: - Magnolia CMS since it's designed around a Java lightweight architecture, fully implementing a JCR storage (this was one of my interests also), it provides publishing workflow between a private and public instances and it provides a nice skinning and authoring mechanism... There are lots of defaults and poor docs in it but this is not the question here. - XWiki for the wiki because as George says:"What else????"... I also decided to use only XWiki/2.0 syntax to test it deeply... I wanted: - to use the CMS as the content aggregator and XWiki as one content provider - to use XWiki remotely and enable content retrieval from several XWikis for example - to integrate XWiki pages as paragraphs into a magnolia page containing other contents - to allow remote XWiki edition using a "simplified" XWiki editor So I have developped: - a Magnolia module which manages the creation/edition/insertion of XWiki paragraphs into Magnolia. The XWiki pages are retrieved remotely from one XWiki server using the XMLRPC API for the time being... - a "light" XWiki editor based on velocity templates from the basic XWiki skin. You can see the resulting website in this site: http://www.mandubian.org It's a draft site so please don't look too much at the quantity of content (and the quality also ;) ) I will build progressively the website, deliver, document and improve the XWiki/Magnolia module also and bring new ideas also... This is a private server so don't be surprised when it is not very quick! regards Pascal Voitot

2 1

[xwiki-devs] Getting your feedback about different texts for XWiki.org
by Emilie Ogez 20 Apr '09

20 Apr '09

Hi, I'd like your feedback about these different texts that would be put online on XWiki.org. *You are about to download XWiki* This is a short text that would be put there: http://www.xwiki.org/xwiki/bin/view/Main/Download --> http://dev.xwiki.org/xwiki/bin/view/Drafts/TextDownload *Manifesto* This Manifesto is cited in the previous text. It would be put on XWiki.com and/or XWiki.org Its objective is to give a clear vision of XWiki SAS involvement and commitment towards XWiki software. --> http://dev.xwiki.org/xwiki/bin/view/Drafts/Manifesto *Satisfaction survey about XWiki software* This survey will be sent to the people who downloaded XWiki enterprise or one of its applications, with the purpose of getting feedback about our software in order to make it better. It would only be sent to the people who downloaded XWiki Enterprise at first. --> http://dev.xwiki.org/xwiki/bin/view/Drafts/SatisfactionSurveyProducts Thanks in advance for your help and your time. Emilie

2 1

Re: [xwiki-devs] [xwiki-notifications] r18827 - in platform/web/trunk/standard/src/main/webapp: resources/icons resources/icons/datamodel resources/js/xwiki resources/js/xwiki/dataeditors templates
by Jerome Velociter 20 Apr '09

20 Apr '09

Hi Sergiu, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-04-19 21:40:15 +0200 (Sun, 19 Apr 2009) > New Revision: 18827 > > Added: > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/ > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/boolean.png > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/calendar.png > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/database.png > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/groups.png > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/move.png > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/number.png > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/password.png > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/propertyType-Generic.png > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/rights.png > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/staticlist.png > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/string.png > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/textarea.png > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/tree.png > platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/users.png > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/dataeditors/ > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/dataeditors/dataeditors.css > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/dataeditors/dataeditors.js > Modified: > platform/web/trunk/standard/src/main/webapp/templates/editclass.vm > platform/web/trunk/standard/src/main/webapp/templates/editobject.vm > platform/web/trunk/standard/src/main/webapp/templates/editpanelsvars.vm > Log: > XWIKI-3635: Improve the object and class editors > Done. L10N will be done afterwards. > > [snip] > Property changes on: platform/web/trunk/standard/src/main/webapp/resources/icons/datamodel/rights.png > ___________________________________________________________________ > Name: svn:mime-type > + image/png > > This image is not very comprehensive. I had to look twice before getting it is key ring. [snip] > +XWiki.XPropertyOrdering = Class.create({ Shouldn't this be namespaced under the XWiki namespace ? For example "XWiki.dataeditor.XPropertyOrdering" If we do not make submodules in the XWiki objects, we'll make the same mistake we did with the window object, and we will end up with a large collection of properties and functions that have nothing to do one with each other. I'd rather keep the XWiki object for both holding modules and functions/classes/properties that have sense in all XWiki pages, not just in one module. Jerome. > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

2 1

Re: [xwiki-devs] [xwiki-notifications] r18760 - in platform: core/trunk/xwiki-core/src/main/resources xwiki-applications/trunk/tag/src/main/resources/XWiki
by Sergiu Dumitriu 18 Apr '09

18 Apr '09

jvelociter (SVN) wrote: > Author: jvelociter > Date: 2009-04-16 20:03:35 +0200 (Thu, 16 Apr 2009) > New Revision: 18760 > > Modified: > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources_fr.properties > platform/xwiki-applications/trunk/tag/src/main/resources/XWiki/TagCloud.xml > Log: > XE-430 In space dashboard, display tag cloud with tags of the space > > > Modified: platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties 2009-04-16 17:21:20 UTC (rev 18759) > +++ platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties 2009-04-16 18:03:35 UTC (rev 18760) > @@ -1117,6 +1117,7 @@ > # Tag application > xe.tag.tags=Tags > xe.tag.notags=No document has been tagged yet. Documents can be tagged from the information section (footer) or from the Document information panel available in edit mode. For more information on tagging please refer to the <a href="http://www.xwiki.org/xwiki/bin/view/UserGuide/">User Guide</a>. > +xe.tag.notagsforspace=No document has been tagged yet in space *{0}*. Documents can be tagged from the information section (footer) or from the Document information panel available in edit mode. For more information on tagging please refer to the <a href="http://www.xwiki.org/xwiki/bin/view/UserGuide/">User Guide</a>. I think we should rethink how/if to use wiki markup in localization resources. This would fail if used in a document with the 2.0 syntax, since the bold markup was changed. -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 1

[xwiki-devs] [VOTE] Add Rendering event begin/endGroup + remove (%%) + add params for macros
by Vincent Massol 18 Apr '09

18 Apr '09

Hi, * Thomas and I would like to split the current begin/endDocument() events by adding begin/endGroup(). We're currently reusing the same event for group usage (with the (((...))) syntax). * This will allow us to write things such as (%...%)(((....))) in order to add parameters for a group of standalone blocks * We also propose to remove the (%...%)...(%%) notation in favor of (%..%)(((...))) notation * (%..%) will always be applied only to the next element, even for inline content. * Add support for (%...%){{macro/}} Here's my +1 Thanks -Vincent

5 5

Re: [xwiki-devs] Group Members in Velocity
by bruno.amaro 17 Apr '09

17 Apr '09

Thanks! It works like a charm ;) You are looking for something like: #if($xwiki.getUser("XWiki.Admin").isUserInGroup("XWiki.XWikiAllGroup")) ... #end Check the API of your XWiki (http://platform.xwiki.org/xwiki/bin/download/DevGuide/API/xwiki-core-1.8.1-…) please. Here a snippet where the prefix "XWiki." is handled in Velocity. Only the user login name and group name has to be entered. Have fun, Rudi #if(($request.action) && ($request.action == 'CheckGroupMembership')) #set($group = "XWiki.${request.group}") #set($user = "XWiki.${request.user}") #if($xwiki.getUser($user).isUserInGroup($group)) User $user IS in group $group #else User $user IS NOT in group $group #end #end 1 Check Group Membership <form action="$doc.getURL("view")" method="post"> <input type="hidden" name="action" value="null" /> <table> <tr> <td>Group:</td> <td><input type="text" name="group" value="$!request.group" size="60" /><td> </tr> <tr> <td>User:</td> <td><input type="text" name="user" value="$!request.user" size="60" /></td> </tr> </table> <input type="submit" value="Check Group Membership" onclick="document.getElementById('bequiet').style.visibility='visible';this.form.action.value='CheckGroupMembership'" />  <div id="bequiet" style="visibility:hidden"> <h1>busy...</h1> </div> </form> Hi I`m trying to figure a way to check if a user is a member of one group. I`m looking for something like: a) retrieve the groups membership of an user in velocity or b) check if a user is a member of a specify group. Thanks in advance Regards, Bruno -- View this message in context: http://n2.nabble.com/Group-Members-in-Velocity-tp2641137p2652257.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

1 0

[xwiki-devs] [VOTE] HTML and Velocity macro NL/WS behaviors
by Vincent Massol 17 Apr '09

17 Apr '09

Hi devs, We need to come to a conclusion for handling New Lines(NL) and white spaces (WS) in HTML and Velocity Macro. If you remember from http://markmail.org/thread/mhqhxnz5twhev5se the current problem is that we cannot indent scripts since WS and NL are meaningful. I'd like to reiterate the proposal that was sent but not enough people voted on it (only Thomas did). A) For the HTML macro, we propose to make the following changes: - strip NL/WS between elements (elements that don't accept CDATA) - strip leading/trailing NL/WS for element content before passing them to the wiki syntax parser B) for the Velocity macro we have 2 choices I can think of: 1) strip all leading spaces for all lines (but keep NL) Note that this means that inside a velocity macro you wouldn't be able to have a line break with the new line starting with spaces without escaping the leading space with ~(space). Note also that this means we will not be able to add extra new lines to format the text nicely (since that would add new paragraphs) or split a single line into several lines for extra readability. This is the case today with the old syntax and it's a pain not to be able to aerate the text with empty lines. Ex: some text ~ next line #if (...) this goes on the same line #something(...) #end This is a new paragraph In this example notice that we need the velocity #if to be on the same line since NL are significant. 2) strip all leading spaces for all lines + remove all NL too. This means we need to ensure we still have one space remaining between "words" (same as HTML). The user would use something like $nl and $sp to explicitely enter new lines and spaces. The advantage is that you control completely the formatting (no magic anymore) at the cost of a little extra work (adding the $nl where required). Basically this means the same pros/cons as when you work with HTML where you need to explicitly add <br/> when you want new lines. Ex: some text $nl $sp next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end $nl $nl This a new paragraph Note: I've aerated the text by putting extra new lines around the velocity #if to show that it would work. 3) Same as 1) + strip 1 NL (i.e. line breaks) and only allow "forced" line breaks with "\\". The exact algorithm is: if there's 1 NL remove it, if there's more than 1 leave them. Ex: some text\\ ~ next line #if (...) this goes on the same line #something(...) <-- this is also on the same line #end This a new paragraph I'm +1 for A) For B) I think the most flexible is 2) but I'm wondering if it's too big a change for our users or not. If not 2) then 3). Thanks -Vincent

7 14