April 2010 - xwiki-devs@xwiki.org

[xwiki-devs] [Proposal] Migration to JSR330 for our component model
by Vincent Massol 11 Apr '10

11 Apr '10

Hi devs, Since the JSR330 is now accepted as final and thus as a standard, I'd like to propose that we modify our component annotations to use it. Rationale ======== The advantages of using it are: * Be standard, ie: ** Our components will be able to be re-used by injectors other than ours (Guice for example) ** Since IDEs will support JSR330 they'll be able to offer features for our code (auto complete, graph, etc), for ex http://blogs.jetbrains.com/idea/tag/dependency-injection/ Proposed Changes =============== Note: JSR330 doesn't specify how components should be bound, hence the need to keep xwiki-specific metadata for the bindings. * @Component and @ComponentRole stay unchanged * Deprecate @Requirement, replaced by @Inject * Use @Named or application-specific annotations (based on @Qualifier) instead of hints specified in the @Requirement annotation * Add new @Role(Class) to specify a dependency role in the case of collections (since generics are not available using reflection in Java) * Deprecate @InstantiationStrategy, replaced by @Singleton. We don't need to introduce any other scope annotations for now. * Note that the default scope in the JSR330 spec is "per lookup". Since our default is singleton, we'll need to add @Singleton annotations everywhere we used to not have anything. Example before: @Component("html") public class HTMLMacro extends AbstractMacro<HTMLMacroParameters> { ... @Requirement private HTMLCleaner htmlCleaner; ... @Requirement("xhtmlmacro/1.0") private PrintRendererFactory xhtmlRendererFactory; ... Same example after the change: @Component("html") public class HTMLMacro extends AbstractMacro<HTMLMacroParameters> { ... @Inject private HTMLCleaner htmlCleaner; ... @Inject @Named("xhtmlmacro/1.0") private PrintRendererFactory xhtmlRendererFactory; ... WDYT? Thanks -Vincent

5 11

[xwiki-devs] Short Urls - configuration
by Andreas Hahn 11 Apr '10

11 Apr '10

Hi, yesterday I'v set up a new wiki (with the new Milestone 2). I've followed the instructions to set up short urls: http://platform.xwiki.org/xwiki/bin/view/Main/ShortURLs with one difference. Instead of using mod_redirect for the Apache HTTPD I'm using mod_proxy and mod_rewrite so that an url www.mydomain.com/docs -> (internal-ip) 192.168.1.n/appContext The effect is that from the internet only the new naming schema is visible and not the default 'long' url resolution. This works fine so far, except for one issue: In all cases where xwiki generates redirection urls like this example for "Logout" /docs/logout/XWiki/XWikiLogout?xredirect=http://www.mydomain.com/appContext/docs/XWik/aha What's wrong IMHO is "appContext" - part of the ?xredirect - this exposes the internal webapppath back to the caller. I have configured the xwiki.cfg to not using the appPath: xwiki.webapppath=/ but this setting is not used, instead the deployment webappPath is used for ?xredirect. In all other cases (except the ?xredirect) the configured webapppath seems to be used correctly. This is my configuration: in xwiki.cfg: xwiki.webapppath=/ (because this is handled by mod_rewrite) xwiki.defaultservletpath=docs/ (use "docs" instead of "bin") xwik.showviewaction=0 in web.xml param-value of "redirectHomeServlet" to http://www.mydomain.com/docs/Main and added a <servlet-mapping> pattern for "action" to /docs/* for completeness here's the mod_rewrite <VirtualHost> configuration (Ubuntu) <VirtualHost *> ServerName www.mydomain.com ServerAdmin wiki(a)mydomain.com RewriteEngine On RewriteLog /var/log/wiki_rewrite.log RewriteLogLevel 2 CustomLog /var/log/wiki_custom.log common ErrorLog /var/log/wiki_error.log # use [P] for Proxy and NOT [R] for redirect ! RewriteRule ^/(.*) http://www.mydomain.com/appContext/$1 [L,P,E=proxy_ok:1] ProxyPreserveHost On </VirtualHost> and this is the mod_proxy <IfModule mod_proxy.c> #turning ProxyRequests on and allowing proxying from all may allow #spammers to use your proxy to send email. ProxyRequests Off <Proxy *> AddDefaultCharset off Order deny,allow Deny from all # Proxies just in case Proxy_ok is set Allow from env=proxy_ok </Proxy> # Not sure whether we need this ... # Enable/disable the handling of HTTP/1.1 "Via:" headers. # ("Full" adds the server version; "Block" removes all outgoing Via: headers) # Set to one of: Off | On | Full | Block ProxyVia On </IfModule> thanks for your support Andreas

1 2

Re: [xwiki-devs] [xwiki-notifications] r28225 - platform/web/trunk/standard/src/main/webapp/templates
by Sergiu Dumitriu 10 Apr '10

10 Apr '10

On 04/10/2010 09:50 PM, jvelociter (SVN) wrote: > Author: jvelociter > Date: 2010-04-10 21:50:05 +0200 (Sat, 10 Apr 2010) > New Revision: 28225 > > Modified: > platform/web/trunk/standard/src/main/webapp/templates/macros.vm > Log: > [minor] removed inline style when using hidden livetable columns > > > Modified: platform/web/trunk/standard/src/main/webapp/templates/macros.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/macros.vm 2010-04-10 19:42:49 UTC (rev 28224) > +++ platform/web/trunk/standard/src/main/webapp/templates/macros.vm 2010-04-10 19:50:05 UTC (rev 28225) > @@ -1613,7 +1613,7 @@ > #set($displayName = $colname) > #end > #if($colname != '_actions' || $hasAdmin) > -<th class="xwiki-livetable-display-header-text #if($isSortable)sortable #if($colname == $selectedColumn)selected $defaultOrder#else asc#end#end" #if("$!colprop.type"=="hidden")style="display: none"#end scope="col"> > +<th class="xwiki-livetable-display-header-text #if($isSortable)sortable #if($colname == $selectedColumn)selected $defaultOrder#else asc#end#end" #if("$!colprop.type"=="hidden")class="hidden"#end scope="col"> Invalid, now you have two class attributes. > #if($isSortable)<a rel="${colname}">#end > #if($isFilterable&& ("$!colprop.type"=="text"||"$!colprop.type"=="number"))<label for="xwiki-livetable-${divid}-filter-${velocityCount}">#end > $displayName -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

[xwiki-devs] [Proposal] XWiki.org Community Page
by Ecaterina Valica 09 Apr '10

09 Apr '10

Hi, *Community Home Page Proposal: * http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2C… Thanks, Caty

5 7

[xwiki-devs] Ending macro syntax as macro content
by Thomas Mortagne 09 Apr '10

09 Apr '10

Hi devs, We have a limitation in the xwiki/2.0 parser related to the way macros are parsed: impossible to have the ending syntax of a macro as content of this macro. Here is the related jira issue: http://jira.xwiki.org/jira/browse/XWIKI-5077 A good example is: i want to have "{{/code}}" alone as the content of a code macro. That's impossible. The only way to have {{/code}} in the content is with: {{code}} {{code}} {{/code}} {{/code}} or {{code}} ~{{/code}} {{/code}} but in the first case you get "{{code}}" you did not want and in the second you get "~" you did not want. Only solution i can see is to specifically handle escaping of ending macro syntax inside macros of the same name. Here is some examples: 1) {{code}} ~{{/code}} {{/code}} would give code macro containing "{{/code}}" 2) {{code}} ~{{/somemacro}} {{/code}} would give code macro containing "~{{/somemacro}}" 3) {{code}} ~~{{/code}} {{/code}} would give code macro containing "~" followed by the text "{{/code}}" 4) {{code}} ~~~{{/code}} {{/code}} would give code macro containing "~{{/code}}" 5) Then double escaping for each level to escape: {{box}} {{box}} ~~~{{/box}} {{/box}} {{/box}} would give box macro containing a box macro containing the text "{{/box}}": the first pass change "~~~{{/box}}" into "~{{/box}}" like in example 4) and the second pass escape "{{/box}}" like in example 1). So WDYT ? Here is my +1 -- Thomas Mortagne

3 7

[xwiki-devs] [Proposal] Stop using XWiki.Admin for contentAuthor in pages in platform/applications and enterprise/wiki unless PR is needed.
by Caleb James DeLisle 08 Apr '10

08 Apr '10

Currently everything is saved with the content author set to XWiki.Admin. This means that in a default system, every single page has programming access and any bug which allows for arbitrary velocity to be evaluated or even allows arbitrary xwiki syntax to be rendered in that page will be a PR leak. We can either (A) begin making pages with contentAuthor = XWiki.XWikiGuest or (B) we could create a new default username which has no PR. I'm +1 for A because of it's simplicity and adding default usernames seems ugly to me. Caleb Another though, should we change the values of "creator" and "author" at the same time?

1 0

Re: [xwiki-devs] [xwiki-notifications] r28168 - platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode
by Sergiu Dumitriu 07 Apr '10

07 Apr '10

On 04/07/2010 03:15 PM, lucaa (SVN) wrote: > Author: lucaa > Date: 2010-04-07 15:15:44 +0200 (Wed, 07 Apr 2010) > New Revision: 28168 > > Modified: > platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/CreateForm.xml > platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Macros.xml > platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Script.xml > Log: > XAANNOTATIONS-13: URL Decode annotation target before using it in AnnotationService > * Fixed encoding across all annotations js and velocity scripts > > > Modified: platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/CreateForm.xml > =================================================================== > --- platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/CreateForm.xml 2010-04-07 08:56:02 UTC (rev 28167) > +++ platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/CreateForm.xml 2010-04-07 13:15:44 UTC (rev 28168) > @@ -12,8 +12,8 @@ > <customClass></customClass> > <contentAuthor>XWiki.Admin</contentAuthor> > <creationDate>1265236156000</creationDate> > -<date>1266926719000</date> > -<contentUpdateDate>1266926719000</contentUpdateDate> > +<date>1270643626000</date> > +<contentUpdateDate>1270643626000</contentUpdateDate> > <version>1.1</version> > <title></title> > <template></template> > @@ -37,9 +37,9 @@ > {{html}} > ## get create a hashmap with request data about the selection > #set($annData = $util.hashMap) > -#set($dispose = $annData.put("selection", $util.decodeURI($!request.selection))) > -#set($dispose = $annData.put("selectionContext", $util.decodeURI($!request.selectionContext))) > -#set($dispose = $annData.put("selectionOffset", $util.decodeURI($!request.selectionOffset))) > +#set($dispose = $annData.put("selection", $!request.selection)) > +#set($dispose = $annData.put("selectionContext", $!request.selectionContext)) > +#set($dispose = $annData.put("selectionOffset", $!request.selectionOffset)) > ## pretend that annotation author is current user, and annotation date is now > ##Even if they get sent to the server, the server will overwrite with anything's logged in in there anyway > #set($dispose = $annData.put("author", $context.user)) > > Modified: platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Macros.xml > =================================================================== > --- platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Macros.xml 2010-04-07 08:56:02 UTC (rev 28167) > +++ platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Macros.xml 2010-04-07 13:15:44 UTC (rev 28168) > @@ -12,8 +12,8 @@ > <customClass></customClass> > <contentAuthor>XWiki.Admin</contentAuthor> > <creationDate>1264959390000</creationDate> > -<date>1267569743000</date> > -<contentUpdateDate>1267569743000</contentUpdateDate> > +<date>1270643964000</date> > +<contentUpdateDate>1270643964000</contentUpdateDate> > <version>1.1</version> > <title></title> > <template></template> > @@ -47,7 +47,7 @@ > *# > #macro(displayCreateBox $docWiki $docSpace $docPage $annData) > <div class="annotation-box annotation-box-create"> > -<form method="POST" action="/xwiki/rest/wikis/${docWiki}/spaces/${docSpace}/pages/${docPage}/annotations?media=json"> > +<form method="POST" action="/xwiki/rest/wikis/${util.encodeURI($docWiki)}/spaces/${util.encodeURI($docSpace)}/pages/${util.encodeURI($docPage)}/annotations?media=json"> > <div class="hidden"> > #foreach($field in $annData.keySet()) > <input type="hidden" name="${field}" value="$!{annData.get(${field})}"/> > @@ -73,7 +73,7 @@ > <div class="annotation-box annotation-box-edit"> > #if($ann) > ## TODO: fix this url to be generated less hardcoded > - #set($editURL = "/xwiki/rest/wikis/" + $docWiki + "/spaces/" + $docSpace + "/pages/" + $docPage + "/annotation/" + $util.encodeURI($ann.id) + "?method=PUT&media=json") > + #set($editURL = "/xwiki/rest/wikis/" + $$util.encodeURI($docWiki) + "/spaces/" + $util.encodeURI($docSpace) + "/pages/" + $util.encodeURI($docPage) + "/annotation/" + $util.encodeURI($ann.id) + "?method=PUT&media=json") > <form method='POST' action="${editURL}"> > #displayAnnotation($ann, 'edit') > #displayAnnotationBoxButtons('edit') > @@ -174,7 +174,7 @@ > #macro(displayAnnotationToolbox $ann $mode $docWiki $docSpace $docPage) > <span class="annotationTools"> > #if($mode != 'create'&& $annotations.canEditAnnotation($ann.id, $docWiki, $docSpace, $docPage)) > - #set($editURL = "/xwiki/rest/wikis/" + $docWiki + "/spaces/" + $docSpace + "/pages/" + $docPage + "/annotation/" + $util.encodeURI($ann.id) + "?method=PUT&media=json") Instead of $util.encodeURI you should use $escapetool.url > + #set($editURL = "/xwiki/rest/wikis/" + $util.encodeURI($docWiki) + "/spaces/" + $util.encodeURI($docSpace) + "/pages/" + $util.encodeURI($docPage) + "/annotation/" + $util.encodeURI($ann.id) + "?method=PUT&media=json") > #if ("$!{ann.state}" == 'UPDATED') > <span class="tool accept"><a class="validate" href="${editURL}" title="$msg.get('annotations.action.validate.tooltip')">$msg.get('annotations.action.validate.text')</a></span> > #end > @@ -183,7 +183,7 @@ > <span class="tool annotationEdit"><a class="edit" href="${editURL}" title="$msg.get('annotations.action.edit.tooltip')">$msg.get('annotations.action.edit.text')</a></span> > #end > ## TODO: fix this url to be generated less hardcoded > - #set($deleteURL = "/xwiki/rest/wikis/" + $docWiki + "/spaces/" + $docSpace + "/pages/" + $docPage + "/annotation/" + $util.encodeURI($ann.id) + "?method=DELETE&media=json") > + #set($deleteURL = "/xwiki/rest/wikis/" + $util.encodeURI($docWiki) + "/spaces/" + $util.encodeURI($docSpace) + "/pages/" + $util.encodeURI($docPage) + "/annotation/" + $util.encodeURI($ann.id) + "?method=DELETE&media=json") > <span class="tool delete"><a class="delete" href="${deleteURL}" title="$msg.get('annotations.action.delete.tooltip')">$msg.get('annotations.action.delete.text')</a></span> > #end > </span> > > Modified: platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Script.xml > =================================================================== > --- platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Script.xml 2010-04-07 08:56:02 UTC (rev 28167) > +++ platform/xwiki-applications/trunk/annotations/src/main/resources/AnnotationCode/Script.xml 2010-04-07 13:15:44 UTC (rev 28168) > @@ -12,8 +12,8 @@ > <customClass></customClass> > <contentAuthor>XWiki.Admin</contentAuthor> > <creationDate>1264860755000</creationDate> > -<date>1270590698000</date> > -<contentUpdateDate>1270590698000</contentUpdateDate> > +<date>1270643534000</date> > +<contentUpdateDate>1270643534000</contentUpdateDate> > <version>1.1</version> > <title></title> > <template></template> > @@ -847,7 +847,7 @@ > > fetchAnnotations : function(andShow) { > // TODO: fixme, get the URL in a less hardcoded way > - var getAnnotationsURL = '/xwiki/rest/wikis/' + XWiki.currentWiki + '/spaces/' + XWiki.currentSpace + '/pages/' + $$('meta[name=page]')[0].content + '/annotations?media=json'; > + var getAnnotationsURL = '/xwiki/rest/wikis/' + encodeURIComponent(XWiki.currentWiki) + '/spaces/' + encodeURIComponent(XWiki.currentSpace) + '/pages/' + encodeURIComponent($$('meta[name=page]')[0].content) + '/annotations?media=json'; > new Ajax.Request(getAnnotationsURL, {method: 'GET', > parameters: this.prepareRequestParameters(new Hash()), > onCreate: function() { > @@ -1037,9 +1037,9 @@ > new Ajax.Request('$xwiki.getURL("AnnotationCode.EditForm")', { > parameters: { > 'xpage' : 'plain', > - 'wiki' : encodeURIComponent(XWiki.currentWiki), > - 'space' : encodeURIComponent(XWiki.currentSpace), > - 'page' : encodeURIComponent($$('meta[name=page]')[0].content), > + 'wiki' : XWiki.currentWiki, > + 'space' : XWiki.currentSpace, $$ is really slow in IE, you should use something faster, like setting XWiki.currentDocumentName to this value first. > + 'page' : $$('meta[name=page]')[0].content, > 'id' : id > }, > onCreate : function() { > @@ -1124,9 +1124,9 @@ > parameters: { > 'id' : annotationId, > 'xpage' : 'plain', > - 'wiki' : encodeURIComponent(XWiki.currentWiki), > - 'space' : encodeURIComponent(XWiki.currentSpace), > - 'page' : encodeURIComponent($$('meta[name=page]')[0].content) > + 'wiki' : XWiki.currentWiki, > + 'space' : XWiki.currentSpace, > + 'page' : $$('meta[name=page]')[0].content > }, > onSuccess: function(response) { > // display the annotation creation form -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

[xwiki-devs] [ANN] XWiki Enterprise 2.3 Milestone 2 Released
by Jean-Vincent Drean 06 Apr '10

06 Apr '10

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.3 Milestone 2. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is second and last milestone of the XWiki Enterprise 2.3 version. Main changes from 2.3 Milestone 1: * New Annotations section in the Administration * New spanish translations for the WYSIWYG editor * Lots of bugs fixes For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise23M2 Thanks -The XWiki dev team

1 0

[xwiki-devs] [VOTE] Save dirty attachment content when saving documents
by Denis Gervalle 06 Apr '10

06 Apr '10

In XWiki(Hibernate|Jcr)Store#saveXWikiDoc(), the attachement list is persisted, but the attachement contents are not persisted. A) I would like to take care of also persisting attachment contents when these contents are loaded and marked dirty (XWikiAttachmentContent#isContentDirty() == true). Why I would like to change this ? 1) I see no use case that would have to persist reference to an attachment and drop its content at the same time, which create records with a size field set to n bytes, while the attachment is 0 or m bytes. 2) When for example an XWikiDocument#copy() is followed by an XWiki#saveDocument() (on the newly created document), without also calling XWikiDocument#saveAllAttachements(), the cache store contains the documents with all their attachments contents, while the DB has not really persisted these contents. 3) In XWikiHibernateAttachmentStore#saveAttachmentContent(), the default is to persist the document, this is not consistent with the document not doing the same in reverse. (I would have better understand that persisting attachment contents does not persist the document.) 4) isContentDirty is properly maintained, and currently it is nearly unused, making the false impression that attachments content are persisted properly 5) This issue is invisible in normal XWiki usage, since we take care of saving attachments contents to avoid it everywhere, for example in XWiki#copyDocument(), attachments contents are saved "manually". 6) As a application developer, using the internal API in groovy, my collegue has missed it, and we have loose production data, since during testing, the cache has always hide the issue. I really dislike API that could introduce inconsistencies in the DB and moreover when you loose large amount of data. B) This change has no real impact on any code that would take care of saving the attachments separatly, it will just be saved twice, isContentDirty() currently only prevent useless archiving. This could be optimized by not saving contents as well when it is not dirty, but I do not want a negative vote on the rest for just this. So please vote this as B) C) I also would like to optimize existing internal usage, removing useless call to saveAttachmentContent() in XWiki.copyDocument() for example. This could have an impact on a custom store that does not take care of saving attachments contents while saving documents. I doubt many user has such a store and release notes could mention this incompatibility. This is my +1 for A) B) and C) Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

6 7

[xwiki-devs] [Proposal] Structure for extensions.xwiki.org
by Vincent Massol 06 Apr '10

06 Apr '10

Hi, I'm implementing the mail entitled "[Proposal] Rationalize our projects and SVN structure" and I need to start creating extensions.xwiki.org (a **first** version of it). Here's my current thinking re its structure: * An ExtensionClass - Description - icon (optional) - Download page (optional) - created by - contributor - bundled with (none, top level projects except contrib, extensions) - content (with template having Tested With + Requirements sections) - type (macro, snippet, application, plugin, skin, other) * A MacroClass - macro type * A SnippetClass - languages (multi choice list: script languages) Note: In the future we'll need to map these classes to the Extension Manager descriptor, with dependencies for example. * Have an ExtensionClassSheet that does basically the same thing as now * Have an ExtensionClassTemplate with predefined sections to guide the author: Usage, Installation & Requirements, Tested With (note: Installation & Requirements could also be put in the Download page, common to all versions) * Keep the Download classes too for now * On the home page, have a big livetable mapped to ExtensionClass for now. * Put all extensions in an Extensions space * Use a prefix of "Extension" * When an extension is made of different "types", then bundle it as a zip with type "other". For example the Watch extension is made of a XAR + 2 jars, it would be bundled as a zip and a type of "other". * Move Module References to platform.xwiki.org * Possibly write some scripts to help migrate current content on code.xwiki.org to extensions.xwiki.org WDYT? Thanks -Vincent

3 6