xwiki-devs April 2008

xwiki-devs@xwiki.org

55 participants
180 discussions

[xwiki-devs] [ANN] XWiki Workspaces 1.0 RC 1 Released

by Jerome Velociter

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

16 years, 8 months

[xwiki-devs] XMLRPC

by Fabio Mancinelli

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

16 years, 8 months

[xwiki-devs] [proposal] change current behaviour of PropertyChangedRule to implement it correctly

by ancapaula.luca＠xwiki.com

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

16 years, 8 months

[xwiki-devs] [proposal] Extending the PluginInterface with beginParsing and endParsing

by Sergiu Dumitriu

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/

16 years, 8 months

[xwiki-devs] parent version for spacemanager and and activitystream plugin incorrect

by Sachin Mittal

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.

16 years, 8 months

[xwiki-devs] Name for disabled AttachmentVersioning

by Artem Melentyev

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

16 years, 8 months

Re: [xwiki-devs] [xwiki-notifications] r9125 - trunks

by Sergiu Dumitriu

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/

16 years, 8 months

[xwiki-devs] Question on modifying XWikiLogin

by rgbohner＠rockwellcollins.com

Hello, I would like to make a small modification to the XWikiLogin page on a local xwiki instance xwiki v 1.3 to better understand the different layers of configuration available for xwiki. There is an error occurring on this login page when xwiki is configured for LDAP authentication. When a user enters incorrect credentials, the login page does not provide any indication of an error while the LDAP.LDAPAuthServiceImpl class returns "LDAP Bind failed with Exception Invalid Credentials". What is the best route for adding error notification into the XWikiLogin page in the event of an invalid LDAP credentials error is propagated from LDAP.LDAPAuthServiceImpl? Thank you Ross

16 years, 8 months

[xwiki-devs] [ANN] XWiki Enterprise Manager 1.2 Milestone 1 released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise Manager 1.2 Milestone 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This release follow XWiki Enterprise 1.4 Milestone 1 release to maintain XEM synchronised with XE. Changes from 1.1: The main change is XWiki Enterprise upgrade from 1.3 to 1.4M1. Wiki Manager also fix a bug in translations page and is now able to create a wiki with the name of one that just been deleted. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM12M1 Thanks -The XWiki dev team

16 years, 8 months

[xwiki-devs] [VOTE] Release XEM 1.2 M1

by Thomas Mortagne

Hi comitters, As XE 1.4M1 has been released and to follow its releases I would like to release XEM 1.2M1. Modification since XE 1.1 : - XE 1.3 to XE 1.4M1 modifications. - XAWM-63: Broken translations in wikis descritors sheet page - XAWM-62: Can't recreate a wiki which just been deleted Thanks, -- Thomas Mortagne

16 years, 8 months

← Newer
1
...
8
9
10
11
12
13
14
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs April 2008