- xwiki-devs@xwiki.org - lists.xwiki.org

[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

[xwiki-devs] A Problem about Debug Wysiwyg Editor
by Leon Wang 06 Apr '10

06 Apr '10

Hi Marius, hi XWiki Developers, Thank you for your reply and add instructions to http://dev.xwiki.org/xwiki/bin/view/Community/Debugging#HDebuggingtheWYSIWY…<http://www.google.com/url?q=http%3A%2F%2Fdev.xwiki.org%2Fxwiki%2Fbin%2Fview…> Really appreciated! After I executed the start_xwiki.sh and start_wysiwyg_noserver_debug.sh, it gives me new errors. It says: "[WARN] Unable to process 'file:/home/freeleons/XWiki_Enterprise_2.1.1/war/WEB-INF/web.xml' for servlet validation javax.servlet.UnavailableException: Configuration problem at org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:298) at org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:222) at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:68) at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:51) at com.google.gwt.dev.HostedMode.doStartup(HostedMode.java:344) at com.google.gwt.dev.HostedModeBase.startUp(HostedModeBase.java:585) at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:397) at com.google.gwt.dev.HostedMode.main(HostedMode.java:232)" also it gives me a hint: "[ERROR] Hint: Check that the type name 'com.xpn.xwiki.wysiwyg.client.Wysiwyg' is really what you meant" Here is the visual: http://picasaweb.google.com/lh/photo/arGtksR3nPM9-b-GbNOmsg?feat=directlink When I made the change to the script (start_wysiwyg_noserver_debug.sh), from: "com.google.gwt.dev.HostedMode \ -logLevel WARN \ -style DETAILED \ -noserver \ -port 8080 \ -startupUrl xwiki/$WYSIWYG_PATH/Wysiwyg.html \ com.xpn.xwiki.wysiwyg.Wysiwyg" to "com.google.gwt.dev.HostedMode \ -logLevel WARN \ -style DETAILED \ -noserver \ -port 8080 \ -startupUrl xwiki/$WYSIWYG_PATH/Wysiwyg.html \ com.xpn.xwiki.wysiwyg.client.Wysiwyg" It will give me the error: "[ERROR] Unable to find 'com/xpn/xwiki/wysiwyg/client/Wysiwyg.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source?" Here is the screenshot of hierarchy of the XWiki Enterprise folder, http://picasaweb.google.com/lh/photo/arGtksR3nPM9-b-GbNOmsg?feat=directlink Could you please give me some suggestions? Thank you! Sincerely, Jue Wang

2 2

[xwiki-devs] A Problem about Debug Wysiwyg Editor
by Leon Wang 05 Apr '10

05 Apr '10

Hi Marius, hi XWiki Developers, Thank you for your reply and add instructions to http://dev.xwiki.org/xwiki/bin/view/Community/Debugging#HDebuggingtheWYSIWY… appreciated! In case you might miss the email which I replied. I sent this again. After I executed the start_xwiki.sh and start_wysiwyg_noserver_debug.sh, it gives me new errors. It says: "[WARN] Unable to process 'file:/home/freeleons/XWiki_Enterprise_2.1.1/war/WEB-INF/web.xml' for servlet validation javax.servlet.UnavailableException: Configuration problem at org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:298) at org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:222) at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:68) at com.google.gwt.dev.ServletValidator.create(ServletValidator.java:51) at com.google.gwt.dev.HostedMode.doStartup(HostedMode.java:344) at com.google.gwt.dev.HostedModeBase.startUp(HostedModeBase.java:585) at com.google.gwt.dev.HostedModeBase.run(HostedModeBase.java:397) at com.google.gwt.dev.HostedMode.main(HostedMode.java:232)" also it gives me a hint: "[ERROR] Hint: Check that the type name 'com.xpn.xwiki.wysiwyg.client.Wysiwyg' is really what you meant" Here is the visual: http://picasaweb.google.com/lh/photo/arGtksR3nPM9-b-GbNOmsg?feat=directlink When I made the change to the script (start_wysiwyg_noserver_debug.sh), from: "com.google.gwt.dev.HostedMode \ -logLevel WARN \ -style DETAILED \ -noserver \ -port 8080 \ -startupUrl xwiki/$WYSIWYG_PATH/Wysiwyg.html \ com.xpn.xwiki.wysiwyg.Wysiwyg" to "com.google.gwt.dev.HostedMode \ -logLevel WARN \ -style DETAILED \ -noserver \ -port 8080 \ -startupUrl xwiki/$WYSIWYG_PATH/Wysiwyg.html \ com.xpn.xwiki.wysiwyg.client.Wysiwyg" It will give me the error: "[ERROR] Unable to find 'com/xpn/xwiki/wysiwyg/client/Wysiwyg.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source?" Here is the screenshot of hierarchy of the XWiki Enterprise folder, http://picasaweb.google.com/lh/photo/arGtksR3nPM9-b-GbNOmsg?feat=directlink Could you please give me some suggestions? Thank you! Could you please also tell me what "com.xpn.xwiki.wysiwyg.client.Wysiwyg" for in the script below: -logLevel WARN \ -style DETAILED \ -noserver \ -port 8080 \ -startupUrl xwiki/$WYSIWYG_PATH/Wysiwyg.html \ com.xpn.xwiki.wysiwyg.client.Wysiwyg Sincerely, Jue Wang

2 1

[xwiki-devs] [Discussion] What direction to take the administration application.
by Caleb James DeLisle 05 Apr '10

05 Apr '10

When I was trying to figure out how to cleanly configure the registration page, I wrote a piece of code to handle it. The code is at XWiki.ConfigurableClass and it displays configuration for applications which contain objects of the same class. Documentation is here: http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication… In adding this I made a few assumptions which may not be the direction which the community wants to go. #1 I added a document called XWiki.RegistrationHelp to the default XE package which explains how to configure the registration page. In the Registration section of the administration interface, I made the labels for the input fields into links to the relevant sections of the help page (I like links :) ) Vincent has suggested that instead of links we were to use popups or tooltips because they would not allow the user to leave the administration interface. The currently existing links could have click handlers added to show a popup and block the click so that they still work for users without Javascript. The other and more major issue in my mind is that I can't think of a way to show only information for the item clicked on while keeping the help page a single unit which can be read (and edited) easily. Another option would be to remove the help page and links but I found myself reading code to figure out what some of the parameters meant so I don't think that is a realistic option. I am in favor of continuing with the method which I started because I feel that popups are an attack on my browser and I see no way to keep tooltips centralized for reading beginning to end and for easily updating when things change. #2 When I added configuration for the registration page, I did not want to add it to XWikiPreferences. This is not only because I want to keep my code modular but I want to put myself in the position of an application developer so I can see the API from their point of view. This has lead to configuration for XWiki.Registration residing in XWiki.RegistrationConfig. It has been pointed out to me that this will make upgrading more difficult and I agree but I don't think adding properties to XWikiPreferences class for each and every application is reasonable and since third party developers cannot do that I see this as a deficiency in our API. The options I can see are to add a "Document Type" which defines a particular document as a configuration document which should never be upgraded but I think this is wrong because even configuration needs to be upgraded, it is the values which need to remain. Also I am not a fan of separating configuration to a document different than the code because the code needs to handle the case where the configuration is unavailable and I think code making static references to a document name is an antipattern. My proposal is to create another class just like ConfigurableClass except it will be UpgradableClass. A document may have an object of UpgradableClass and that object can either A. Point to another object in the same class which should have it's values loaded in on upgrade or B. Add some code which should be run on upgrade. It is important to understand that the document can be changed but the upgradable objects will load the values from the old object and set them in the new object. #3 Because the configuration for the registration page is seperate, it cannot be saved along with XWikiPreferences in a single save operation and because there is configuration for the registration page in XWikiPreferences and in RegistrationConfig, they are both specified to be displayed in the "Registration" section of the administration interface. XWiki.ConfigurableClass handles this situation by creating two forms with two save buttons and a heading in the middle saying "Configure XWiki.RegistrationConfig" It would be easy to override this with another message and it would be possible to make a single button for users who have Javascript enabled but it introduces the question do we want third party applications to anonymously add parameters to a section of the administration interface. I suppose the best answer would be to separate all of the parameters having to do with registration from XWikiPreferences (and stop referring to them in the core). I can think of no better solutions to this at the moment. #4 (No hasty changes here, just a proposal) The administration application uses the "admin" struts action which calls the AdminAction class. From my looking at AdminAction class I think it can be removed entirely and struts can be redirected to the InlineClass (Unproven claim). This brings up a point about permissions: admin permission must be had in order to use the admin action but only edit access to XWikiPreferences is required to do the things offered by the administration action. see: https://localhost:8443/xwikiTrunk/bin/edit/XWiki/XWikiPreferences?editor=ob… In fact admin action is not even necessary to use the Administration Application see: https://localhost:8443/xwikiTrunk/bin/inline/XWiki/XWikiPreferences?xpage=a… I think the myth that admin access is necessary to do the administrative functions is dangerous for administrators who may leave security holes as a result. My proposal is that we try removing AdminAction to sandbox and redirect /admin/ in struts to InlineAction. I also think we ought to redefine admin access perhaps as the combination of view, edit, and delete which cannot be denied at a lower level (so a space admin can delete a page even if it denies them access.) I have made XWiki.ConfigurableClass with the idea that it should be able to do all of the functions of the administration application (meaning XWikiPreferences would have a ConfigurableClass object for each section in the administration application). I am always happy to hear when somebody wants to use ConfigurableClass but I don't think porting XWikiPreferences over is a good idea until ConfigurationClass has had some time in the field and we are sure that we don't want to change any of it's behavior. Sorry for the long email, I had a lot to discuss and didn't want to spam the list with 4 emails about the administration application. Caleb

2 6

[xwiki-devs] [Proposal] XWiki.org Logo Challenge - Round 2
by Sergiu Dumitriu 02 Apr '10

02 Apr '10

Hi devs, Votes are now closed for the new XWiki.org logo, and, according to http://spreadsheets.google.com/ccc?key=0Ah6DqXzfHT2vdHV5Ty1LX3lKU3U5V3M4YmN… , they seem pretty tight for: 12A, 12E, 15, 16B and proposals 4A and 19 were also mentioned by a significant number of voters (feel free to double-check the spreadsheet, at least for your own votes if not for the whole thread, to make sure I entered the right values). So, I propose to organize a second round of votes, from Thursday April 8th until Sunday April 11th. The voters will be asked to choose only ONE logo proposal (no more fuzzy votes this time) between 4A, 12A, 12E, 15, 16B and 19. Before the new round of votes starts, the authors of these 6 proposals are kindly asked to do the following by Wednesday, if not already done for round 1: * correct any inaccuracies that might have appeared in the name * try to integrate any constructive feedback that came with the votes (I tried to gather this feedback from the emails on http://dev.xwiki.org/xwiki/bin/view/Community/LogoChallengeRound2 ) * polish the design (if they consider it necessary) * provide the requested variations for .org, enterprise and office * provide samples for light and dark background * provide a black&white version * provide a 16X16 icon containing the logo or a representative part of the logo * provide a nice "Powered by XWiki" button that goes with the logo * provide a mockup/screenshot with the logo used in the current skin, colibri The _final_ versions should be uploaded here: http://dev.xwiki.org/xwiki/bin/view/Community/LogoChallengeRound2 . Unless updated, the versions that participated in round 1 will also be used for round 2, and voters will have to use their imagination in case any of the required use cases is missing. Please let me know if there are any objections regarding the finalists, the timeline or the requirements for round 2. Some commiters disagree with including in the final vote proposals 12A, 12E and 15, because of their similarity with the XWiki.com and Atlassian Confluence logos respectively. Since it seems that not everybody sees these resemblances, I tried to do the most impartial thing I could think of: I included these 3 proposals on the finalist page, with a visible warning that those who agree there is a similarity should definitely not vote for them in round 2, even if they like them very much (the goal being to have a new, original logo, not a variation of the old one or the logo of a competitor). My hope is that the community will properly decide whether these logos are suitable and meet the uniqueness requirement. Note that this is not the e-mail for _starting_ the second round, but rather for _agreeing on_ the second round. Thanks in advance for the cooperation. -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0