April 2012 - xwiki-devs@xwiki.org

[xwiki-devs] [VOTE] Changing our deprecation strategy (TAKE2)
by Vincent Massol 26 Apr '12

26 Apr '12

Hi devs, I had started a first VOTE: http://markmail.org/thread/56v5thsj6wv7tpno But since that first VOTE transformed into a brainstorming I'm starting a new VOTE below with the result of our brainstorming: * Distribute without legacy modules by default * Document how users can add legacy modules and make that visible from the download page somewhere. * Move deprecated APIs to legacy modules as soon as our code is clean and stops using the newly deprecated APIs * Never remove APIs from the legacy modules by default but when we really need to do so (for some technical reason for example), do it on a case by case basis and send a VOTE to do so This ensures that: * New users quickly use the newest APIs (they won't even see the old APIs by default). * Older users are not broken since they can add the legacy modules * When someone upgrades he can easily try using the new distribution without legacy and if it breaks some of his code he can either fix his code or add the legacy modules Here's my +1 Thanks -Vincent

4 5

[xwiki-devs] Simple Mobile Skin
by Ludovic Dubost 26 Apr '12

26 Apr '12

Hi, I've been working a while ago on a Mobile Skin which principle is the following: 1/ Light UI adapted to mobile devices, both phones and tablet (with a particular attention to tablets), giving most of the screen real estate to the page content 2/ Support all Javascript normally supported in the XWiki skin in order for any code inside pages that would use this Javascript to still work 3/ Automatic detection of mobile devices to make them switch to the mobile skin 4/ Ability to switch from mobile to normal skin 5/ compatibility with color themes I believe this approach is the right one, as XWiki instances do have significant Javascript and in order to make sure these pages work, we need to be able to accept this javascript. Of course some other improvements could be done, for example to have a mobile friendly dashboard or livetable. Now this work has had a few iterations with particularly some relooking work from Caty. The work is published here: http://extensions.xwiki.org/xwiki/bin/view/Extension/SimpleMobileSkin And the code is available here in both XAR and File-System version (for XEM): https://github.com/ldubost/xwiki-mobileskin The skin can be tested on the incubator (although there is not the automated switch) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/34Proposal?skin=XW… I've also worked on integrating this in the platform. The commit is available in a fork on github: https://github.com/ldubost/xwiki-platform/commit/064baeb017b35e08a526029381… I'd like some comments and discussion so that we can bring this into the platform. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

3 7

[xwiki-devs] [Proposal] Changes to Page Creation needed for Application Within Minutes
by Marius Dumitru Florea 24 Apr '12

24 Apr '12

Hi devs, For the upcoming Application Within Minutes I need to enhance the XWiki platform with the ability to generate the page name automatically when creating a new wiki page. For some applications it doesn't make sense to have two creation steps: (1) specify the wiki page name (i.e. the location) and then (2) edit the new wiki page with the specified name. Let me give you two examples: * It would be cool to be able to create a new blog post in a single step. The blog post name could be generated from the blog post title specified in the edit form. * An application that manages holiday requests doesn't need meaningful page names (i.e. free text, like a blog post would have) but something like Request_XYZ, where XYZ is a unique counter/identifier. These applications should be able to create new wiki pages with automatically generated names without writing their custom create forms. Since 3.2RC1 was planed for today and these changes are in the 3.2 roadmap, here's a proposal that I think I can implement quickly and safely: (1) Introduce two new components: // Used to generate a document name that doesn't have to be unique (e.g. by cleaning the document title). DocumentReferenceGenerator#generate(DocumentModelBridge):DocumentReference // Used to make a document name unique (by suffixing an unique counter/identifier) DocumentReferenceDifferentiator#differentiate(DocumentReference):DocumentReference (2) Modify editinline.vm to store "documentReferenceGenerator" and "documentReferenceDifferentiator" request parameters in two hidden input fields so that they are passed to the save action. Obviously, these are component hints. (3) Modify editactions.vm to replace "Save & View" + "Save & Continue" with "Create" when "documentReferenceGenerator" or "documentReferenceDifferentiator" (or both) request parameters are set. (4) Modify SaveAction to take into account these two request parameters (only if they are specified). Something along these lines: generateDocumentReference(doc) synchronize(lock) { doc.copyDocument(differentiate(generatedDocumentReference)).save(); } I'm not sure where to place the two components from (1) though. WDYT? Thanks, Marius

8 14

[xwiki-devs] How to call rendering component ?
by jerem 23 Apr '12

23 Apr '12

Hello, In velocity I was using : $services.rendering.parse(...) $services.rendering.render(...) My question is : how can I inject the component to do that from a java component, specifying the parser/syntax ? I just had a quick look to the tests but they use the componentManager while I preferred to use annotations until now, so I'm a bit lost ... :) Thanks Jeremie -- View this message in context: http://xwiki.475771.n2.nabble.com/How-to-call-rendering-component-tp7487904… Sent from the XWiki- Dev mailing list archive at Nabble.com.

2 6

[xwiki-devs] New XWiki Commons Groovy Module
by Vincent Massol 23 Apr '12

23 Apr '12

Hi devs, I'd like to add a Groovy Module in XWiki Commons. We need this module to provide customization for the Groovy JSR223 implementation to support Groovy Compilation Customizers, see http://groovy.codehaus.org/Groovy+1.8+release+notes#Groovy18releasenotes-Co… See also: * http://jira.xwiki.org/browse/XCOMMONS-153 * http://jira.xwiki.org/browse/XWIKI-7755 I'm going to add it in my next commits. Please should if you think it's not a good idea. Thanks -Vincent

1 1

[xwiki-devs] Create Page button redirected to localhost
by du du 21 Apr '12

21 Apr '12

Hi, all, I logged in as an administrator, I like to create a new page under jQuery with this URL: http://mydomain/xwikim/bin/create/jQuery/WebHome when I click the Create button, it always redirected me to localhost as following: http://localhost/xwikim/bin/edit/jQuery/jQueryUICustom?template=&parent=jQu… which caused error message: Unable to connect, I tried to create from Main space, also the same problem and redirected me to: http://localhost/xwikim/bin/edit/Main/jQueryUICustom?template=&parent=Main.… when this happens, I have to replace the localhost with mydomain on browser address and press enter to bring up the page, this happened to me many times when I need to do edit action, when it is view action, it works perfectly, I have httpd apache webserver in front of tomcat, in apache config file, my setup is: ProxyPass /xwikim http://localhost:8082/xwikim ProxyPassReverse /xwikim http://localhost:8082/xwikim In tomcat server.xml file, the setup is: <Connector port="*8082*" maxThreads="*150*" minSpareThreads="*25*"maxSpareThreads ="*75*" enableLookups="*false*" acceptCount="*100*" connectionTimeout="* 20000*" proxyPort="*80*" disableUploadTimeout="*true*" /> I feel this setup should be ok, since it works all the time except sometimes it does not work for edit action or login. Does anybody have ideas about what happened and how to fix? Thanks very much in advance. Dave

1 0

[xwiki-devs] [PROPOSAL] Determine that it's a new or out of sync instance
by Thomas Mortagne 19 Apr '12

19 Apr '12

Hi dev, To get a proper setup of installed extensions we want to make sure everything is installed trough Extension Manager instead of being imported as a plain xar. So the idea come up to finally start the long awaited installer/upgrader UI. First step is to find how to know when to display this UI so here is a proposal (ref http://dev.xwiki.org/xwiki/bin/view/Design/Installerandupgrader) = The new informations * deprecate version.properties for a more complete distribution.properties that would contains at least the following ** version of the distribution ** top extension id of the distribution (to display general informations about the distribution). For example in XE it would be distribution.id=xwiki-enterprise ** name of the distribution (I'm not 100% sure for this one since we can find it with the id using Extension Manager but I think it's safer in case we don't have access to any repository to display something nicer than a technical id). For example for XE it would be distribution.name=XWiki Enterprise (who would have guessed :)). ** war extension id of the distribution (generate a default id like <product-id>-web when none is provided). For example in XE it would be distribution.web.id=xwiki-enterprise-web ** ui extension id of the distribution (generate a default id like <product-id>-ui when none is provided). For example in XE it would be distribution.ui.id=xwiki-enterprise-ui ** then come custom properties specific to the distribution. For example in XE I think we could add commons.version, rendering.version, etc. = The current informations * store all that in a table of the DB to compare the current with what comes with the war. If the DB does not contain anything its a new install, if the DB contain something different it's an upgrade (note that this also support downgrade or moving from one distribution to another like XE -> XEM the same way). The idea is that we store theses informations only when the installer/upgrader is fully passed or that the user explicitly indicated tat he does not want to install or upgrade anything so that if you only did part of it before restoring you can come back and continue the install/upgrade process. = The manager * introduce a xwiki-platform-distribution to manipulate all that = Some questions 1) "distribution" or "product" ? 2) reuse the same table where we currently store the DB version ? I don't want to talk about the installed/upgrader UI itself for now, it will be the subject of another mail. I would like to concentrate of one step at a time since that's going to be pretty important system. WDYT ? The may goal that started this proposal is the installer/upgrader UI but those as also very useful for different use case. Some lib could want to know the version of platform or commons to choose what to do, we will be able to add the id of the distribution itself and the war extension as core extension to allow some extension to put it as dependency, we will finally display a proper footer without putting the distribution name in the XWikiPreferences. Here is my +1. 1) my +1 goes to "distribution" 2) my +1 goes to another table to not mix different subjects Thanks, -- Thomas Mortagne

5 8

[xwiki-devs] An edit problem
by jinlong liu 18 Apr '12

18 Apr '12

I use the xwiki 3.5.When I edit a long text(longer than one screen) with the wysiwyg, Every time I press t he enter button or insert a heading,it will jump t.o the head of the page which I am editing.Is there any solution to it or it is just a problem only I met

2 1

Re: [xwiki-devs] [xwiki-users] xwiki:dom:loaded event callback function never got called
by du du 18 Apr '12

18 Apr '12

I tried to use wiki="false", or remove //<![CDATA[ and //]]>, still the event callback function never get called, any other reason? Thanks for your response, please help. Dave On Wed, Apr 18, 2012 at 5:33 AM, Marius Dumitru Florea < mariusdumitru.florea(a)xwiki.com> wrote: > Hi Dave, > > On Wed, Apr 18, 2012 at 6:43 AM, du du <dddu88(a)gmail.com> wrote: > > Hi all, > > > > I have the following velocity code in xwiki page, I can see the fid and > > fname values when I retrieve entryobj from the server side, so I want to > > use javascript to add the fid and fname to image link node as parameters > of > > the href url. the problem is the javascript loaded event function never > got > > called, why? > > > > Thanks very much. > > > > Dave > > > > {{velocity filter="none"}} > > {{html clean="false" wiki="true"}} > > <script type="text/javascript"> > > > //<![CDATA[ > > wiki="true" causes // to generate an EM HTML tag. Just look at the > page HTML source (all browsers have this option) and you'll see that > your SCRIPT tag is messed up. > > My advice is to: > > * use a JavaScript extension ( > > http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial#HM… > ) instead of in-line SCRIPT tag > * try to avoid HTML macro with wiki="true" or, if it's not possible, > try to reduce as much as possible its content, i.e. wrap only the code > that really needs it. > > Hope this helps, > Marius > > > document.observe("xwiki:dom:loaded", function(){ > > var imageNode = document.getElementById('tmViewImages'); > > var url = imageNode.href; > > var index = url.indexOf("?"); > > if(index!=-1) > > url = url.substring(0,index-1); > > url=url+"?FID=$!fid&FName=$!fname"; > > imageNode.href=url; > > > > //]]> > > </script> > > > > #getEntryItemObject($doc $entryObj) > > > > #if("$!entryObj" == '') > > #warning($msg.get('xe.blog.sheet.notpost')) > > ## Keep testing the inline action for backward compatibility with older > > blog posts. > > #elseif($xcontext.action != 'edit' && $xcontext.action != 'inline') > > ## View mode > > > > #set($fid=$entryObj.getProperty('FID').value) > > #set($fname=$entryObj.getProperty('FName').value) > > fid view: $fid > > fname view: $fname > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users >

1 0

[xwiki-devs] Approach for extensions with multiple dependencies ?
by jerem 18 Apr '12

18 Apr '12

Hi all, Developping the mail archive, I realize that this app (that will consist of extension .xar + component .jar) will have many dependencies on other extensions. To cite only some, there will be : mktree, tabs, livetable export to excel, ratings, ... When possible I try to make these dependencies optional : if you want the related feature, install the extension and check the option (for ex. livetable export to excel). But some dependencies will be mandatory anyway. To prepare things correctly in advance, what is the best approach in this case ? Do I only need to list the dependencies, and prevent users that to install my app, they need to install the other extensions as prerequisites ? Can it be managed automatically by the extension manager during install of my app (it would install the others before) ? Or should I package all these inside my own app for sake of simplicity ? (but it's ugly) Thanks, Jeremie -- View this message in context: http://xwiki.475771.n2.nabble.com/Approach-for-extensions-with-multiple-dep… Sent from the XWiki- Dev mailing list archive at Nabble.com.

2 1