April 2010 - xwiki-devs@xwiki.org

[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

[xwiki-devs] [VOTE] Add 6 new methods to com.xpn.xwiki.api for loading and saving documents as the content author of the script calling the method.
by Caleb James DeLisle 01 Apr '10

01 Apr '10

Hello all, I'd like to make this change: Add to xwiki.api.Document saveAsAuthor() saveAsAuthor(String comment) saveAsAuthor(String connent, String isMinorEdit) deleteAsAuthor() Add to xwiki.api.XWiki getDocumentAsAuthor(DocumentReference reference) getDocumentAsAuthor(String fullName) They save, load or delete the document if the script's contentAuthor has the necessary permission, the user in context is switched so the contentAuthor is listed as having done the operation. Though they say *AsAuthor the action will take place in the name of the contentAuthor of the document this is mainly because *AsContentAuthor is long and confusing. This is already partially available if the script has programming access but I think it is an important enough feature that it should not be limited to scripts with programming access. Use case: allowing users to submit information without letting them see or modify what other users had submitted. This is my +1 Caleb

5 9

[xwiki-devs] [Proposal] Rationalize our projects and SVN structure
by Vincent Massol 01 Apr '10

01 Apr '10

Hi devs, Jean-Vincent, Thomas and I (hope I didn't forget anyone) would like to propose the reorganization described below: = Projects = In 2007 we decided to start multiple projects based on the XWiki platform, namely: manager, workspaces and watch. The objective was to provide multiple products based on the XWiki platform with the same expectations in terms of quality; all those projects were top level projects to reflect that. A year later we decided to put all our development effort in XWiki Enterprise, since then all the projects except Enterprise and Office have been left aside. == XWiki Watch == * Last significant jira issue fixed on 12/Jun/2009 * Last release 1.1M1 (based on XE 1.5.1) - 11/Sep/08 While watch code is compatible with recent XE versions its distribution is not maintained. The proposal is to move watch code somewhere else in the SVN (see below) and to drop the distribution modules (database, distribution, installers). Watch documentation (including installation guides) would be placed on code.xwiki.org and watch.xwiki.org pages would redirect to this new location. Watch JIRA would be made read only and move to the retired category. All new issues should use the existing Watch application JIRA. == XWiki Workspaces == * Last significant jira issue fixed on 19/Oct/2008 * Last release 1.2M1 (based on XE 1.5.2) - 19/Sep/08 Workspaces is no longer maintened and it doesn't work with XE > 1.5.2. The proposal is to move it to contrib/retired and to display a banner on workspaces.xwiki.org saying that this product is retired (see http://beehive.apache.org/ for an example). Workspaces JIRA would be made read-only. == XWiki Eclipse == * Last significant jira issue fixed on 06/Jan/09 * Last release 2.2 - 11/Jan/09 XEclipse is no longer maintained and it doesn't handle the xwiki/2.0 syntax. The proposal is to move it to contrib/retired and to display a banner on xeclipse.xwiki.org saying that this product is retired. XEclipse JIRA would be made read-only. Note that we hope the project will be brought back from the dead in the future. == XWiki Manager == * Last significant jira issue fixed on 11/Apr/09 (XEM jira project) * Last release 2.2 (based on XE 2.2) - 16/Feb/10 The Manager case is different, it's released often and isn't lagging behind XE. The problem is that we only release it labeled as stable, based on XE stable versions, which is bad since it's not properly tested before that. Manager is not a product per-se, all the code that allows to run a wiki farm is located in the xwiki platform, which means that having a different life-cycle for its distribution doesn't make sense and doesn't serve the product (less testing). Manager is a set of 2 plugins making easier to run a wiki farm. We should emphasize on this, make people understand that the virtual feature is a core feature and that they can take advantage of it on any XE release by using the correct plugins and apps. This way we could get feedback from people doing staged deployment. We wouldn't mislead people by releasing a distribution directly in a stable version. = SVN Organization = If we agree on the proposal above we need to refactor the SVN according to it. Possible implementation: {{code language="none"}} /svnroot/xwiki/ |_ contrib/ |_ people/ |_ projects/ |_ retired/ |_ photoalbum/ |_ s5/ |_ workspaces/ |_ xeclipse |_ enterprise/ |_ extensions/ |_ administration |_ application-manager/ |_ plugin/ |_ application/ |_ blog |_ calendar |_ ircbot |_ officeimporter |_ panels |_ scheduler/ |_ plugin/ |_ application/ |_ selenium/ |_ skins/ |_ colibri/ |_ statistics/ |_ plugin/ |_ application/ |_ tag/ |_ plugin/ |_ application/ |_ watchlist/ |_ plugin/ |_ application/ |_ webdav/ |_ wiki-macro-bridge/ |_ wiki-manager/ |_ watch |_ application/ |_ component/ |_ gwt/ |_ gwt-client/ |_ gwt-server/ |_ workstream/ |_ platform/ |_ components/ |_ components-all/ |_ xwiki-component/ |_ xwiki-rendering/ |_ ... |_ gwt |_ xwiki-gwt-api/ |_ xwiki-gwt-dom/ |_ xwiki-gwt-user/ |_ xwiki-gwt-wysiwyg-client/ |_ xwiki-gwt-wysiwyg-server/ |_ web |_ tools/ |_ xoffice {{/code}} Modifications summary: * 4 projects moved to retired: photoalbum, s5, workspaces, xeclipse * platform/web/standard content (templates and resources) moved to platform/core/web (packaging: zip) * platform/web/ gwt modules moved to platform/core/gwt (packaging: zip) * new plaform/distribution module (packaging: war) it replaces the previous platform/web-standard minimal webapp * new extensions top level project gathering plugins and applications, rationale: ** applications made of a plugin and an application will now be released in one place ** with the future extension-manager all the extensions (plugins, document sets, skins) should be released as a XAR ** coherent with extensions.xwiki.org = XWiki.org Website Organization = {{code language="none"}} |_ www.xwiki.org |_ dev.xwiki.org |_ enterprise.xwiki.org |_ extensions.xwiki.org (was: code.xwiki.org) |_ l10n.xwiki.org |_ platform.xwiki.org |_ xoffice.xwiki.org {{/code}} wdyt? Thanks -Vincent

4 4

[xwiki-devs] [VOTE] Escaping for document references in xwiki syntax links
by Vincent Massol 01 Apr '10

01 Apr '10

Hi, I'm working on fixing http://jira.xwiki.org/jira/browse/XWIKI-4957 I'm proposing to use \ as the escape char since we're already using it for escaping chars in references. for ex: [[My\.Page\@\#\?]] here's my +1 Thanks -Vincent PS: for xwiki syntax 2.1, i'd like to propose that we use [[reference||anchor="..." queryString="..."]] but that'll be another vote

5 5