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

[xwiki-devs] [VOTE] Release XWS 1.0 RC 1
by Jerome Velociter 15 Apr '08

15 Apr '08

Dear devs, I would like to release the first release candidate of XWiki Workspaces 1.0, with the following bugs solved : http://jira.xwiki.org/jira/secure/ReleaseNote.jspa?version=10647&styleName=… As some bugs are remaining, we plan to do a second RC before releasing 1.0 final. (see http://jira.xwiki.org/jira/browse/XWS?report=com.atlassian.jira.plugin.syst…) Here is my +1 for releasing. Regards, Jerome

5 8

Re: [xwiki-devs] Integrating Java Swing components with Xwiki
by sachin mittal 15 Apr '08

15 Apr '08

> > > Message: 10 > Date: Mon, 14 Apr 2008 12:02:19 -0500 > From: "Kamna Jain" <kammy.scorpi(a)gmail.com> > Subject: [xwiki-devs] Integrating Java Swing components with Xwiki > To: devs(a)xwiki.org > Message-ID: > <fb681d280804141002k18a26459rdb4cc748d73d1b86(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hello Devs, > > This is regarding the capability to upload Multiple files at a time to > Xwiki. > I understand that currently the attach functionality is rendered using > HTML. > The HTML file upload control does not allow mutliple files to be > selected/uploaded at one time. > > Hence, I looked the JFileChooser component of Java Swing. I can write a > Class that brings up a JFileChooser object and allow multiple selections > at > once. > But, I am not sure how to integrate this functionality with Xwiki , Velocity is a scripting language to render web pages where as swing component is a desktop based application, unless swing components are embedded inside an applet > > especially with the Velocity templates (which are used to render the > pages). > Few Questions: > > 1) in order to achieve this, do I need to create a velocity template that > will render the fileChooser on the XWiki page ? > No I don't think velocity can render JFileChooser > 2) If yes, how do I accomplish this? create a new "action" and then write > the render and action methods for that? > > 3) If no, what are my other options to achieve this? > Try to look for ajax components which achieve the the same functionality as JFileChooser > > Please guide me. > Thanks > > > ------------------------------ > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > > > End of devs Digest, Vol 10, Issue 47 > ************************************ >

2 1

[xwiki-devs] Integrating Java Swing components with Xwiki
by Kamna Jain 14 Apr '08

14 Apr '08

Hello Devs, This is regarding the capability to upload Multiple files at a time to Xwiki. I understand that currently the attach functionality is rendered using HTML. The HTML file upload control does not allow mutliple files to be selected/uploaded at one time. Hence, I looked the JFileChooser component of Java Swing. I can write a Class that brings up a JFileChooser object and allow multiple selections at once. But, I am not sure how to integrate this functionality with Xwiki , especially with the Velocity templates (which are used to render the pages). Few Questions: 1) in order to achieve this, do I need to create a velocity template that will render the fileChooser on the XWiki page ? 2) If yes, how do I accomplish this? create a new "action" and then write the render and action methods for that? 3) If no, what are my other options to achieve this? Please guide me. Thanks

2 1

[xwiki-devs] [ANN] XWiki Workspaces 1.0 RC 1 Released
by Jerome Velociter 14 Apr '08

14 Apr '08

The XWiki development team is pleased to announce the release of XWiki Workspaces 1.0 RC 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the first release candidate for the 1.0 version of XWiki Workspaces. A second release candidate is planned for next monday, before hopefully being able to deliver the 1.0 final release. Bug fixed since 1.0 Milestone 2 : * XWS-17 - JavaScript error when uploading photos * XWS-29 - With IE6, selected users does not appear in the list when adding members to a space group * XWS-33 - On a private workspace, only admins can access content, not writers and readers * XWS-37 - Readers are not displayed in the directory of a space * XWS-38 - List numbers are not shown in the WYSIWYG & view mode * XWS-40 - Lightboxes are displayed real bad in IE6 * XWS-41 - Writers and readers rights are inverted in a workspace * XWS-42 - Impossible to set a category for a Wiki Page : the active field is automatically changed when we click on the categories Select * XWS-43 - A macro is not evaluated when comparing two versions * XWS-49 - The tooltips displayed when we are over the "My Profile" & "MyDashboard" buttons are not translated * XWS-50 - The dates are formated differently on the different pages * XWS-56 - Comments do not show up anymore in wiki pages, blog posts and photo albums * XWS-59 - Missing activitystream hibernate mapping in the war distribution * XWS-60 - Galleries with empty description generates two entries in gallery list For more information, see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesWorkspaces10RC1 Regards, The XWiki dev team

1 0

[xwiki-devs] XMLRPC
by Fabio Mancinelli 14 Apr '08

14 Apr '08

Dear all, I've sent a patch on the Jira for a first version of the new XMLRPC layer. (http://jira.xwiki.org/jira/browse/XWIKI-1560) This is a message just to let you know, since the Jira notification message might have been passed unnoticed. I don't have the rights to commit on the core so this patch should be reviewed and applied by some core committer. Following Sergiu's message about quality, I tried to keep a very high quality standard for the code (tests are provided as well). I'm getting back to XEclipse coding now since the XMLRPC API now has support for Object edition and other niceties (e.g., translations, attachments, revisions) Let me know if there are issues. Thanks. Cheers, Fabio

4 4

[xwiki-devs] [proposal] change current behaviour of PropertyChangedRule to implement it correctly
by ancapaula.luca＠xwiki.com 13 Apr '08

13 Apr '08

Dear developers, while fixing the PropertyChangedRule class (XWIKI-2293) I found that there is no way I can improve the code without breaking the current behaviour: right now, since the className parameter is ignored, upon adding a PropertyChangedRule with no className, the property change is checked on the object returned by XWikiDocument.getxWikiObject() (which is the first object of the class defined in the document). This behaviour makes no sense in the context of a correctly implemented PropertyChangedRule: there might be more than one object of that type so why check only on the first and not all of them, why use the class defined by this document as default in the first place and not test the specified property on all objects, etc. There are two choices: 1) break current behaviour and correctly implement the PropertyChangedRule 2) keep the current PropertyChangedRule class but deprecate it and add a new notification rule class that would correctly implement the property change rule. I prefer the first one, since we can consider the current behaviour to be buggy and this to be the fix, but the choice depends on actually how much this would impact existing code, how much code relies on the current behaviour to create PropertyChangedRules with unspecified classNames. In the core, the only place where PropertyChangedRule is used is to re-prepare plugins when the plugin preference is changed in XWiki.XWikiPreferences, but there might also be some code in products, xwiki applications, etc. Here's my +1 for 1), but I would like to get some opinions on this from the developers. Also, since the PropertyChangedRule behaviour on unspecified className or propertyName is ambiguous I propose to consider the rule as incompletely specified if one of the two is missing and therefore never send notifications from such a rule (though it wouldn't be consistent with DocObjectChangeRule who is currently checking all objects on null className). Here's my +1 for this one, too. WDYT? Happy coding, Anca

2 1

[xwiki-devs] [proposal] Extending the PluginInterface with beginParsing and endParsing
by Sergiu Dumitriu 13 Apr '08

13 Apr '08

Hi devs, There's a blocker issue preventing the finalization of the SkinExtensions implementation (http://dev.xwiki.org/xwiki/bin/view/Design/SkinExtensions) To explain a bit what the problem is: - skin extensions are javascript or css pseudo-files, which are included ("linked to") in generated XHTML pages - a skin extension is "requested" by some code using, for example, $xwiki.jsx.use("XWiki.RightsManagement"); while generating the content, the jsx plugin builds a list of used extensions - after the whole page is parsed, the generated content must also include the links to the needed extensions The problem is that these links must be placed in the head part of the HTML, which is generated before the body, where the extensions are actually pulled in. This means that sometime after the parsing is done, and before sending the response to the client, some code must insert those links in the response. My dilemma was where... One solution was to use the new notification mechanism to send some parsing events that would allow listeners to change the content when the parsing was done. Vincent opposed, so I dropped the idea. Another solution would have been to write a Filter that would intercept the response and insert the links, but the problem is that the filter is isolated, without access to the context, the xwiki object, or the jsx/ssx plugins. The component manager _could_ be a solution, but for the moment it still needs the context, which is not available. Another solution is to just modify Utils.parseTemplate, but this is not elegant. It is more like a patchy workaround that would increase the messiness of the code even more, so I'm against it. Another solution could have been the existing plugin.endRendering, but it is called many times during a request, and only when rendering with Radeox, not when parsing, so it would not be called for the whole template (so the html header would be left out). The best solution I could come so far is to add two methods to the PluginInterface, beginParsing and endParsing, called before and after parsing the resulting template. This is generic enough, as it can be used by other plugins, there's no code targeting exactly the jsx and ssx plugins, it is extensible enough to allow other type of extensions to be added (link extensions?), and except the StrutsActions which cannot be added dynamically (at least not yet) it allows the SkinExtensions implementation to be completely pluggable. So, beginParsing will be called in com.xpn.xwiki.web.Utils.parseTemplate before parsing the template that generates the response, and it allows plugins to initialize some per-request variables. endParsing will be called in the same method, right after generating the response, and will allow plugins to change the resulting response or cleanup resources. The signature of these methods would be: public void beginParsing(XWikiContext context) public String endParsing(String content, XWikiContext context) endParsing could also be used by the FileUploadPlugin to cleanup the resources (see http://fisheye2.cenqua.com/browse/xwiki/xwiki-platform/core/trunk/xwiki-cor… ). Now, the thing that I don't like is that this changes a public interface, used by many plugins. It is good that most plugins extend DefaultPlugin, as there is only one place where these methods must be implemented, so the impact on existing plugins should be minimal. I also don't like that the plugin interface contains so many methods, but that is an acknowledged problem and it will be solved when everything would be a component. Until then, these two methods seem to me like they should already be there, given the other rendering-related methods. Any other (better) solutions I didn't see? Objections to this change? Thanks, -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 1

[xwiki-devs] parent version for spacemanager and and activitystream plugin incorrect
by Sachin Mittal 13 Apr '08

13 Apr '08

Hi, build of xwiki-platform-plugins fails as the parent pom version in these two plugins is incorrect. same if changed to 7-SNAPSHOT works. eg: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.xpn.xwiki.platform.plugins</groupId> <artifactId>xwiki-plugins</artifactId> <version>7-SNAPSHOT</version> </parent> .... may be this needs to be checked in. Thanks Sachin ----- http://www.assembla.com/wiki/show/sachin_mittal about me: -- View this message in context: http://www.nabble.com/parent-version-for-spacemanager-and-and-activitystrea… Sent from the XWiki- Dev mailing list archive at Nabble.com.

1 0

[xwiki-devs] Name for disabled AttachmentVersioning
by Artem Melentyev 12 Apr '08

12 Apr '08

Hi, devs. How would you name a special "empty" store class used when some store feature is disabled? (see FakeAttachmentVersioningStore, XWIKI-2275) 1 Void 2 Empty 3 Disabled 4 Dummy 5 Mock 6 else? Vincent Massol wrote: > I'm not sure if "Fake" is the best word to use... > > I don't think it's a Fake one. It's an empty implementation that does > nothing. so I'd rather call it: VoidAttachmentVersioningStore or > EmptyAttachmentVersioningStore. > > Also I'd replace the comment like: > >> + public void deleteArchive(XWikiAttachment attachment, >> XWikiContext context, >> + boolean transaction) throws XWikiException >> + { >> + // not needed >> + } > > with: > > "// Don't do anything since it's a void implementation." > > WDYT? Ok. I'll replace. -- Artem Melentyev

2 1

Re: [xwiki-devs] [xwiki-notifications] r9125 - trunks
by Sergiu Dumitriu 12 Apr '08

12 Apr '08

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-04-11 23:28:49 +0200 (Fri, 11 Apr 2008) > New Revision: 9125 > > Modified: > trunks/pom.xml > Log: > [Release] Prepare next version > > Modified: trunks/pom.xml > =================================================================== > --- trunks/pom.xml 2008-04-11 21:28:28 UTC (rev 9124) > +++ trunks/pom.xml 2008-04-11 21:28:49 UTC (rev 9125) > @@ -63,10 +63,10 @@ > </activation> > <modules> > <module>xwiki-platform-core</module> > - <module>xwiki-platform-plugins</module> > - <module>xwiki-platform-skins</module> > +  > <module>xwiki-platform-web</module> > - <module>xwiki-platform-applications</module> > + > <module>xwiki-product-enterprise</module> > </modules> > </profile> > What's the purpose of this? -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 1