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

[xwiki-devs] Should email invitation code be an application? How should it be put in sandbox?

by Caleb James DeLisle

I have a reasonably clean revision of the code for inviting friends to join the wiki. Should it be a separate application with it's own jira project? It's not very large but may grow. I can't imagine what other application it should be filed under. I'd like to put it in the sandbox so it can be subject to review and discussion but I don't know how that should be done. I guess that depends on whether it is going to be it's own application. Any thoughts? Caleb

15 years, 5 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r26074 - in platform/core/trunk/xwiki-core/src: main/java/com/xpn/xwiki/doc test/java/com/xpn/xwiki/doc

by Caleb James DeLisle

(resending, meant to send to the dev list.) Sorry to drag up old commits but I have a couple of questions. vmassol (SVN) wrote: > Author: vmassol > Date: 2010-01-07 23:02:51 +0100 (Thu, 07 Jan 2010) > New Revision: 26074 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java > platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/doc/XWikiDocumentTest.java > Log: > XWIKI-4677: Introduce new Model module > > * Fixed infinite cycle (revert some previous change). We need to find a solution. > * Refactored existing code to prevent manual parsing > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java 2010-01-07 16:55:03 UTC (rev 26073) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java 2010-01-07 22:02:51 UTC (rev 26074) > @@ -80,6 +80,7 @@ > import org.xwiki.context.ExecutionContextManager; > import org.xwiki.model.reference.DocumentReferenceResolver; > import org.xwiki.model.reference.EntityReferenceSerializer; > +import org.xwiki.model.reference.WikiReference; > import org.xwiki.rendering.block.Block; > import org.xwiki.rendering.block.HeaderBlock; > import org.xwiki.rendering.block.LinkBlock; > @@ -359,8 +360,10 @@ > /** > * Used to create proper {@link Syntax} objects. > */ > - SyntaxFactory syntaxFactory = Utils.getComponent(SyntaxFactory.class); > + private SyntaxFactory syntaxFactory = Utils.getComponent(SyntaxFactory.class); > Why are we holding a hard reference on the Execution which was present when the document was first loaded or created? Is this not a memory leak? Cache holds Document holds Execution holds ExecutionContext holds XWikiContext holds DocumentArchive? > + private Execution execution = Utils.getComponent(Execution.class); > + > /** > * @since 2.2M1 > */ > @@ -375,7 +378,9 @@ > @Deprecated > public XWikiDocument() > { > - this(Utils.getComponent(DocumentReferenceResolver.class).resolve("")); > + // TODO: Replace this with the following when we find a way to not generate a cycle: > + // this(Utils.getComponent(DocumentReferenceResolver.class).resolve("")); > + this(new DocumentReference("xwiki", "Main", "WebHome")); > } > > /** > @@ -397,25 +402,18 @@ > * > * @param wiki The wiki this document belongs to. > * @param space The space this document belongs to. > - * @param name The name of the document. > + * @param name The name of the document (can contain either the page name or the space and page name) > * @deprecated since 2.2M1 use {@link #XWikiDocument(org.xwiki.model.reference.DocumentReference)} instead > */ > @Deprecated > public XWikiDocument(String wiki, String space, String name) > { > - String normalizedPage; > - String normalizedSpace; > - int i1 = name.indexOf("."); > - if (i1 == -1) { > - normalizedPage = name; > - normalizedSpace = space; > - } else { > - normalizedSpace = name.substring(0, i1); > - normalizedPage = name.substring(i1 + 1); > - } > - > - init(Utils.getComponent(DocumentReferenceResolver.class, "current/reference").resolve( > - new DocumentReference(wiki, normalizedSpace, normalizedPage))); > + // We allow to specify the space in the name (eg name = "space.page"). In this case the passed space is > + // ignored. > + DocumentReference reference = resolveReference(name, new DocumentReference(wiki, space, null)); > + // Replace the resolved wiki by the passed wiki > + reference.setWikiReference(new WikiReference(wiki)); > + init(reference); > } > > public XWikiStoreInterface getStore(XWikiContext context) > @@ -5846,4 +5844,21 @@ > > return syntaxId; > } > + > + private DocumentReference resolveReference(String referenceAsString, DocumentReference defaultReference) > + { > + XWikiContext xcontext = getXWikiContext(); > + XWikiDocument originalCurentDocument = xcontext.getDoc(); > + try { > + xcontext.setDoc(new XWikiDocument(defaultReference)); > + return this.currentDocumentReferenceResolver.resolve(referenceAsString); > + } finally { > + xcontext.setDoc(originalCurentDocument); > + } > + } > + How is this different from XWikiDocument#getContext() introduced in 23506? Is the only difference that the context is the one from when the document was created/loaded rather than the current context? If so this probably ought to be commented since it is a major trap for anyone who expects getXWikiContext().getUser() to yield the current user (for example). > + private XWikiContext getXWikiContext() > + { > + return (XWikiContext) this.execution.getContext().getProperty("xwikicontext"); > + } > } > > Modified: platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/doc/XWikiDocumentTest.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/doc/XWikiDocumentTest.java 2010-01-07 16:55:03 UTC (rev 26073) > +++ platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/doc/XWikiDocumentTest.java 2010-01-07 22:02:51 UTC (rev 26074) > @@ -155,6 +155,29 @@ > this.mockXWikiStoreInterface.stubs().method("search").will(returnValue(new ArrayList<XWikiDocument>())); > } > > + public void testConstructor() > + { > + XWikiDocument doc = new XWikiDocument("notused", "space.page"); > + assertEquals("space", doc.getSpaceName()); > + assertEquals("page", doc.getPageName()); > + assertEquals("xwiki", doc.getWikiName()); > + > + doc = new XWikiDocument("space", "page"); > + assertEquals("space", doc.getSpaceName()); > + assertEquals("page", doc.getPageName()); > + assertEquals("xwiki", doc.getWikiName()); > + > + doc = new XWikiDocument("wiki", "space", "page"); > + assertEquals("space", doc.getSpaceName()); > + assertEquals("page", doc.getPageName()); > + assertEquals("wiki", doc.getWikiName()); > + > + doc = new XWikiDocument("wiki", "notused", "notused:space.page"); > + assertEquals("space", doc.getSpaceName()); > + assertEquals("page", doc.getPageName()); > + assertEquals("wiki", doc.getWikiName()); > + } > + > public void testGetDisplayTitleWhenNoTitleAndNoContent() > { > this.document.setContent("Some content"); > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications >

15 years, 5 months

3
4
0 0

[xwiki-devs] [proposal] Fix XWIKI-4265 by changing the way the previous version of a document is found.

by Caleb James DeLisle

Currently, api.Document.getPreviousVersion() calls doc.XWikiDocument.getPreviousVersion() which calls doc.XWikiDocument.getDocumentArchive() which will return null if the document archive is not currently loaded. doc.XWikiDocument.getPreviousVersion() is inherently dangerous and should be deprecated then removed. doc.XWikiDocument.getDocumentArchive() sometimes returns null and should be deprecated then made private. everywhere doc.XWikiDocument.getDocumentArchive() is used it should be replaced with doc.XWikiDocument.getDocumentArchive(XWikiContext) which calls loadDocumentArchive first. What I propose we do now (for 2.3) #1 Change api.Document.getPreviousVersion() to call getDocumentArchive(getXWikiContext()) and move the logic from doc.XWikiDocument.getPreviousVersion() into api.Document.getPreviousVersion() #2 change doc.XWikiDocument.copyDocument(DocumentReference newDocumentReference, XWikiContext context) to call getDocumentArchive(XWikiContext) instead of getDocumentArchive() #3 Add warnings in javadoc for: clone(XWikiDocument document) cloneInternal(DocumentReference newDocumentReference, boolean keepsIdentity) to say that they may not copy the archive since they use getDocumentArchive() #4 mark doc.XWikiDocument.getPreviousVersion() and doc.XWikiDocument.getDocumentArchive() as depricated and explain why in a comment. WDYT? Caleb

15 years, 5 months

3
7
0 0

[xwiki-devs] [ANN] XWiki Enterprise and XWiki Enterprise Manager 2.2.5 Released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 2.2.5. This is a bug fix release for the 2.2 branches. Improvement * [XSCOLIBRI-206] - Use isInPortletMode and isInServletMode velocity variables instead of querying context mode * [XWIKI-5095] - Introduce isInPortletMode and isInServletMode velocity variables and use them instead of querying context mode * [XWIKI-5096] - Prevent ActionFilter from being called recursively and map it only to the action servlet * [XWIKI-5097] - Make sure SavedRequestRestorerFilter is not applied recursively * [XWIKI-5114] - Allow controlling the depth of headers to look for when generating titles from document's content Important Bugs fixed * [XSCOLIBRI-207] - Printing problems with displaying content and comments * [XPMAIL-24] - If there is an exception while sending mail which has no message (NPE) another exception is thrown hiding the real one. * [XWIKI-5076] - Fail to parse content with macro containing only a newline * [XWIKI-5085] - OfficeImporter does not set title of imported documents * [XWIKI-5086] - OfficeImporter is generating absolute links when performing splitting operations * [XWIKI-5087] - Paging History is broken * [XWIKI-5093] - Cancel edit JavaScript handler doesn't check if the URL fragment is present before appending the query string * [XWIKI-5094] - Administration rights editor cannot be used in portlet mode * [XWIKI-5107] - URLs are not escaped in link labels if link meta data is missing * [XWIKI-5109] - The application/x-www-form-urlencoded reader for objects and properties is broken * [XWIKI-5116] - NPE during resolution of XClassReference * [XWIKI-5119] - In a subwiki, a global user cannot save global documents * [XE-634] - RecentChanges fails to display with some mysql versions For more information see the Releases notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise225 and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM225 Thanks -The XWiki dev team

15 years, 5 months

1
0
0 0

[xwiki-devs] [Proposal] Computed title depth configuration option

by Vincent Massol

Hi, We've had a user request (Ludovic as a user ;)) to have a config option to decide the header level to consider for a title. Right now we consider only levels 1 and 2 when computing a title from the doc content. Thus I'm going to add a config option named xwiki.title.headerdepth and with a default value of 2 (to have the same behavior as now) and use it in XWikiDocument.getRenderedContentTitle(). Note that this is only for the 2.0 syntax (since it's too hard to do for syntax 1.0 and we're not supposed to bring changes to the 1.0 syntax). Please shout quickly if you're against this. Thanks -Vincent

15 years, 5 months

5
8
0 0

[xwiki-devs] [VOTE] Add the DatePicker application to the contrib repository

by Jean-Vincent Drean

Hi, I'd like to use the date picker application [1] as a dependency in one of my project. It has already been 'released' and AFAIK it is successfully used in production, I'd like to commit it to contrib/projects/xwiki-application-datepicker and perform a maven release (1.0) from the current code. Here's my +1. [1] http://code.xwiki.org/xwiki/bin/view/Applications/DatePickerApplication Thanks, JV.

15 years, 5 months

5
8
0 0

[xwiki-devs] [Proposal] Preparing for the Extension Manager

by Vincent Massol

Hi devs, I've been researching what it would take to be able to support the Extension Manager use case regarding components isolation and dependency versioning. I won't go over the details of all I've researched (you can ask questions for that). I'm just proposing a series of steps and a vision of the future for our component model. If you're interested in the topic I would recommend that you read the Weld tutorial on CDI: docs.jboss.org/weld/reference/1.0.0/en-US/html_single/ Here are the steps I'm willing to work on and implement. Step 1: timeframe from now: 1 month * Use JSR330 annotations Step 2: timeframe from now: 1 month * Do a POC of integrating xwiki-component with OSGi (as a xwiki-component-osgi module). - No versioning management yet. - Need to use a maven osgi plugin to generate Manifest files from the POMs * Revise further steps based on result from Step 2. Step 3: timeframe from now: 2 months * If step 2 is successful add what's needed to the XWiki Component API to perform generic lookup: CM.lookup(Class, Properties) where Properties is a set of properties registered with the component. It would contain the role hint and the version for example. Also add annotations for specifying dependency version ranges. Note: After step 3 we have the prereqs for the Extension Manager done. The other steps below are improvements and steps to put us in the standards direction. Step 4: timeframe from now: 6 months-2 years * When CDI (JSR299) has taken over the world (ie several DI frameworks migrate to it, it becomes a JavaSE de facto standard at least), migrate to it. We need 2 features not in the spec right now: - support for dynamic bean registration - ability to implement CDI over OSGi * Work with the Weld dev team to add support for those 2 items above. They're interested to implement it if we help them and if these 2 items get done relatively quickly we could migrate to CDI earlier than the timeframe above * In the meantime we can monitor it carefully to see its progress and we could start migrating to it slowly. Some ideas: - use the CDI annotations instead of the xwiki-specific ones for the binding part - introduce new concepts that comes from CDI: decorators, interceptors, producers - refactor our observation module to use the CDI event model Step 5: timeframe for now: 2-4 years * When JSR294 is approved and final (will require at least JDK 7, so XWiki needs to be on JDK7 at least for this, so that's a few years in the future...) migrate to CDI over JSR294 over (Jigsaw, OSGi). The good part is that since we would be using CDI we won't need to change much in our code to do that. WDYT? Thanks -Vincent Links: - Weld/JSR299: docs.jboss.org/weld/reference/1.0.0/en-US/html_single/ - Jigsaw: openjdk.java.net/projects/jigsaw/ - JSR330: atinject.googlecode.com/svn/trunk/javadoc/javax/inject/package-summary.html - JSR294: See description on openjdk.java.net/projects/jigsaw/

15 years, 5 months

3
3
0 0

[xwiki-devs] [Proposal] Add SuppressionCommentFilter (CHECKSTYLE:OFF and CHECKSTYLE:ON) to checkstyle.xml

by Caleb James DeLisle

I would like to propose changing checkstyle.xml to allow checkstyle to be enabled and disabled using inline comments. I propose this with some reservation because this can be a slippery slope but I would rather see the problems isolated in the file than the file excluded. Also I think this can be used to enforce checkstyle on changes made to code in big files in the old core. WDYT? Caleb

15 years, 5 months

5
6
0 0

[xwiki-devs] [VOTE] Release XE/XEM 2.2.5

by Thomas Mortagne

Hi devs, There is some important fix in 2.2.5 so i would like to release it ASAP. See http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=p… WDYT ? Here is my +1 -- Thomas Mortagne

15 years, 5 months

6
5
0 0

[xwiki-devs] [ANN] XWiki Enterprise 2.3 Release Candidate 1 Released

by Jean-Vincent Drean

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.3 Release Candidate 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download Changes from XWiki Enterprise 2.3 Milestone 2: * Annotations can now be activated by default from the wiki administration * Email addresses can now be modified from the user profile * Upgrade to Pygments 1.3.1 * Upgrade to Groovy 1.7.2 For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise23RC1 Thanks -The XWiki dev team

15 years, 5 months

1
0
0 0

[xwiki-devs] Question about hibernate transaction handling in XWiki

by Asiri Rathnayake

Hi Devs, While working on a client project I came across an issue where an exception is thrown with a message that reads something like: "Caused by: org.hibernate.HibernateException: Failed to commit or rollback transaction. Root cause []" Upon further digging I found the following code in XWikiHibernateBaseStore: <code> /** * Ends a transaction * * @param context * @param commit should we commit or not */ public void endTransaction(XWikiContext context, boolean commit) { endTransaction(context, commit, false); } /** * Ends a transaction * * @param context * @param commit should we commit or not * @param withTransaction * @throws HibernateException */ public void endTransaction(XWikiContext context, boolean commit, boolean withTransaction) throws HibernateException { Session session = null; try { session = getSession(context); Transaction transaction = getTransaction(context); setSession(null, context); setTransaction(null, context); if (transaction != null) { // We need to clean up our connection map first because the connection will // be aggressively closed by hibernate 3.1 and more preCloseSession(session); if (log.isDebugEnabled()) { log.debug("Releasing hibernate transaction " + transaction); } if (commit) { transaction.commit(); } else { transaction.rollback(); } } } catch (HibernateException e) { // Ensure the original cause will get printed. throw new HibernateException("Failed to commit or rollback transaction. Root cause [" + getExceptionMessage(e) + "]", e); } finally { closeSession(session); } } </code> The problem i see in this code is that if preCloseSession(session) or transaction.commit() throws an exception, there is no attempt made to rollback the transaction. Normally a transaction rollback attempt should be made within the catch block. If I understand the basics of transaction handling, this code is wrong. I want to discuss this with you (other developers) because I'm not an expert in this subject :) Thanks. - Asiri

15 years, 5 months

2
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r28305 - platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/representations/objects

by Sergiu Dumitriu

On 04/14/2010 04:27 PM, fmancinelli (SVN) wrote: > Author: fmancinelli > Date: 2010-04-14 16:27:12 +0200 (Wed, 14 Apr 2010) > New Revision: 28305 > > Modified: > platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/representations/objects/FormUrlEncodedObjectReader.java > platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/representations/objects/FormUrlEncodedPropertyReader.java > Log: > XWIKI-5109 The application/x-www-form-urlencoded reader for objects and properties is broken. > > Modified the readers in order to implement the correct behavior. > > > Modified: platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/representations/objects/FormUrlEncodedObjectReader.java > =================================================================== > --- platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/representations/objects/FormUrlEncodedObjectReader.java 2010-04-14 13:42:32 UTC (rev 28304) > +++ platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/representations/objects/FormUrlEncodedObjectReader.java 2010-04-14 14:27:12 UTC (rev 28305) > @@ -99,7 +99,7 @@ > if (name.startsWith(PROPERTY_PREFIX)) { > Property property = objectFactory.createProperty(); > property.setName(name.replace(PROPERTY_PREFIX, "")); > - property.setValue(httpServletRequest.getParameter(name)); > + property.setValue(form.getFirstValue(name)); > object.getProperties().add(property); > } > } > > Modified: platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/representations/objects/FormUrlEncodedPropertyReader.java > =================================================================== > --- platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/representations/objects/FormUrlEncodedPropertyReader.java 2010-04-14 13:42:32 UTC (rev 28304) > +++ platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/representations/objects/FormUrlEncodedPropertyReader.java 2010-04-14 14:27:12 UTC (rev 28305) > @@ -81,7 +81,7 @@ > while (names.hasMoreElements()) { > String name = (String) names.nextElement(); > if (name.startsWith(PROPERTY_PREFIX)) { > - property.setName(name); > + property.setName(name.replace(PROPERTY_PREFIX, "")); replace is not a good method, since it replaces from everywhere in the string. You should use StringUtils.removeStart(name, PROPERTY_PREFIX) > property.setValue(httpServletRequest.getParameter(name)); > break; > } > @@ -89,8 +89,8 @@ > } else { > for (String name : form.getNames()) > if (name.startsWith(PROPERTY_PREFIX)) { > - property.setName(name); > - property.setValue(httpServletRequest.getParameter(name)); > + property.setName(name.replace(PROPERTY_PREFIX, "")); > + property.setValue(form.getFirstValue(name)); > break; > } > } -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 5 months

1
0
0 0

[xwiki-devs] Problem with "Edit Attachment" feature

by Vincent Massol

Hi devs, It's been reported to me that this feature isn't working. Here are issues I know about it: - the pencil icon doesn't appear on Chrome - foxwiki is in version 1.0b and not even a final 1.0 version - when you try to install the FF extension it says it's not compatible with FF 3.6.3 (it doesn't work with other FF 3.6 versions either) - it's a built in feature and it's not working so it's misleading - doesn't work in IE either See also xwiki.markmail.org/thread/ychoon432tugvlbm The main problem is that FoxWiki is not supported by our dev team. Apart from this it's a very nice to have feature. Thus we have 2 choices: - someone volunteers to work on it and make FoxWiki work with FF and IE relatively quickly since the feature is currently broken - we move foxwiki to contrib/ and remove that feature (ie. we could make it active only if the extension is installed for ex) WDYT? Thanks -Vincent

15 years, 5 months

4
4
0 0

Re: [xwiki-devs] [xwiki-users] FoxWiki & "Edit attachments" feature

by Asiri Rathnayake

Hi Eugen, On Thu, Apr 15, 2010 at 2:17 PM, Colesnicov Eugen <ecolesnicov(a)gmail.com>wrote: > > Hi developers! > > According discussion about this FoxWiki & "Edit attachments" feature at > XWiki-Dev subforum. I want to write my opinion for developers. > > Current situation: > - In IE this feature working good without any additional jobs (I tested > 2.2.4). > - In FF - need to use FoxWiki extension (download manualy xpi-file, and > edit > max-version property). > - In Chrome - "Edit attachments" - doesn't work. > > I have proposal about using this feature in FF. FoxWiki working, but I > don't > like that users MANUALY everytime should add file extention and application > path in FoxWiki. From other side, exists some other extentions for FF (for > example http://openwebfolder.mozdev.org/). As I understand, this extention > adds to FF functionality of windows WebFolder WebDAV client - same as IE. > But now, I cannot use (or try) this extention with XWiki, because XWiki > programming code obviously use ONLY FoxWiki at FF. As I understand, If we > will try to use openwebfolder extention - no any special code needs for > XWiki - programming code can be same as a IE part. > > Other collaborative suits software also use openwebfolder extention for FF > (see for example > > http://help.collab.net/index.jsp?topic=/teamforge530/action/connecttowebdav… > ). > Openwebfolder has the following description: "*openwebfolder* itself does *not* contain any platform-independant WebDAV related code. It just adds hooks so that Microsoft's "Webfolder" WebDAV client can be invoked in a similar way like in IE." So this is a windows only solution. May be we should have some logic like: if (IE) { // Use native webdav support in IE. } else if (FF && Win32) { // Use openwebfolder. } else if (FF) { // Use FoXWiki. } But first someone has to evaluate if openwebfolder + FF on Win32 is better than FoXWiki + FF on the same. Anyway, I'm not sure if above logic can be implemented or if it is the best approach, someone has to digg a little deep. Just my opinion :) - Asiri > > For this reason, alternative proposal: no use any special extention for > WebDav - use standart openwebfolder extention (this extention is better > because not need to manualy add file extentions and application paths). > According this - need to change XWiki programming code for WebDav using in > Firefox. > > I am not a specialist with XWiki programming, for this reason - sorry, if I > write something stupid ... What do you think about my variant? > > -- > Best Regards > Eugen Colesnicov > > > -- > View this message in context: > http://n2.nabble.com/FoxWiki-Edit-attachments-feature-tp4906288p4906288.html > Sent from the XWiki- Users mailing list archive at Nabble.com. > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users >

15 years, 5 months

1
0
0 0

[xwiki-devs] Live Table with specific class

by Marine JULIAN

Good morning, I wanted to create a kind of bibliographic data base. To do that I create a "Document" class which have some properties (title, autor, year...) and each of its page "objects" would have an attachment (for instance, a pdf of an scientific article) which correspond to the document. Then, I use the Live Table to display all my class objects but I have some problems I can't resolve... I put the code of my Live Table at the bottom of the mail. So, obsiously, I have a template attached to my class which contains an object of it. My problem is when I display in my Live Table all my "Document" class pages (with the option : "className":"Biblio.DocumentClass"), the template is also display. I would like it doesn't. Is there a way to do that ? Secondly, I have a column in my Live Table to display attachment (with "_attachments") but i don't find how to link to the download link. Indeed, i'm not sur it's possible !! I try to put the option "link" : "view" and "link" : "field" but the first link to the document page and the second doesn't work. Finally, it's about the class creation. I create a date property but I don't want to have a default today date. I notice the field "Empty is today". But whenever I put 0 or 1 or nothing, there always is the default today date in the form creation... Thank you. Marine My Live Table code ("TitleDoc", "Autor", "Year are properties of my Biblio.DocumentClass) : > #set($columns = ["TitleDoc", "Autor", "Year", "_attachments", "doc.date", > "doc.author", "_actions"]) > #set($columnsProperties = { > "TitleDoc" : { "type" : "text", "link" : "view"}, > "Autor" : { "type" : "text", "link" : "view"}, > "Year" : { "type" : "number", "link" : "view"}, > "_attachments" : { "type" : "none", "sortable" : "false", "link" : > "view"}, > "doc.date" : { "type" : "text", "link" : "view"}, > "doc.auth" : { "type" : "text", "link" : "field"}, > "_actions" : { "actions": ["delete","rename"]} > }) > #set($options = { > "className":"Biblio.DocumentClass", > "rowCount": 10 > }) > #livetable("BDbiblio" $columns $columnsProperties $options) >

15 years, 5 months

2
1
0 0

Re: [xwiki-devs] [xwiki-users] XWiki Logo Challenge, Round 2

by [Ricardo Rodriguez] eBioTIC.

Hi, I've done fast test with some people here (10 users, 7 no-XWiki users, 3 XWiki users): 2. 1/10 has read *XNiki* in option A and *XWiki* in option B; she was no-XWiki user. 3. 1/10 has read *lambda wiki* in option A and *XWiki* in option B; she was no-XWiki user. 3. Some no-XWiki users, 5/10 have had some problems to identify the X both in option A and B. 4. All users consider that *wiki* is clearer in option B. 5. XWiki users read XWiki in both A and B. Please, consider that no experimental design is under the scene! :-) Cheers, Ricardo Raluca Stavro wrote: > Hi all, > > How about this alternative: > http://dev.xwiki.org/xwiki/bin/download/Community/LogoChallengeRound2/16-va…. > I think that the W is readable now. > > Raluca. > > On Wed, Apr 14, 2010 at 11:06 AM, Valdis Vītoliņš > <valdis.vitolins(a)odo.lv> wrote: > >> Readability is better, but for me upper right backgoing "serif" for w >> seems unnecessary. >> In place of (ascii art): >> \// \ >> /\\/\/iki >> >> only in this way: >> \/ >> /\\/\/iki >> >> Then X can be bigger and w can be aligned with k. >> What do you think? >> >> Valdis >> >> >>> I completely agree with Marius, I would also add that since this is a >>> Community project, it should have a Community logo ! >>> Since 16 has receive many votes now, and that I also agree with >>> Vincent, >>> Ludovic and others, it is not readable enough, I have made an >>> alternative >>> design: W-angle. My feeling was that the W is difficult to read, so my >>> proposal try to keep the style and reworked it. There is also small >>> changes >>> in spacing, and a different powered by button. >>> >>> Here is almost all that was requested in a proposal with this >>> variable: >>> http://dev.xwiki.org/xwiki/bin/download/Community/LogoChallengeRound2/16%2D… >>> >>> I really hope that if the logo 16 is chosen, my proposal could help in >>> mitigating the disappointment of those that really find it >>> unacceptable. >>> >>> WDYT ? >>> >>> Denis >>> >> _______________________________________________ >> users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users >> >> > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Ricardo Rodríguez CTO eBiotic. Life Sciences, Data Modeling and Information Management Systems

15 years, 5 months

1
0
0 0

Re: [xwiki-devs] [xwiki-users] XWiki Logo Challenge, Round 2

by Sergiu Dumitriu

On 04/12/2010 04:30 PM, Thibaut Camberlin wrote: > My corrected vote is +1 for 12A. 12A has been retired and is no longer a valid option. Please choose another one. -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 5 months

8
11
0 0

[xwiki-devs] [ANN] Core / Web / Enterprise 2.3 branches created

by Jean-Vincent Drean

Hi devs, Note that the 2.3 branches have been created. Don't forget to merge your fixes in those branches and fixes for blocker bugs in: trunk/2.2/2.3. XE 2.3 RC1 will be released as soon as tests succeed on the continuous build. Thanks, JV.

15 years, 5 months

1
0
0 0

[xwiki-devs] Check out my photos on Facebook

by Apurv Gupta

Hi XWiki, I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Apurv To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=100000353486453&k=Z6E3Y5T5VZVA2GGJPB63QTRZT… Already have an account? Add this email address to your account http://www.facebook.com/n/?merge_accounts.php&e=devs%40xwiki.org&c=cb0124cc… was invited to join Facebook by Apurv Gupta. If you do not wish to receive this type of email from Facebook in the future, please click on the link below to unsubscribe. http://www.facebook.com/o.php?k=06b8b2&u=100000397435867&mid=22e712bG5af328… Facebook's offices are located at 1601 S. California Ave., Palo Alto, CA 94304.

15 years, 5 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r28239 - platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/usersandgroups

by Vincent Massol

On Apr 12, 2010, at 12:05 PM, jvelociter (SVN) wrote: > Author: jvelociter > Date: 2010-04-12 12:05:45 +0200 (Mon, 12 Apr 2010) > New Revision: 28239 > > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/usersandgroups/usersandgroups.js > Log: > XWIKI-5094 Administration rights editor cannot be used in portlet mode > > Merged from branch 2.2 > > > Modified: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/usersandgroups/usersandgroups.js > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/usersandgroups/usersandgroups.js 2010-04-12 10:04:39 UTC (rev 28238) > +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/usersandgroups/usersandgroups.js 2010-04-12 10:05:45 UTC (rev 28239) > @@ -367,8 +367,9 @@ > var uorg = table.json.uorg; > var allows = row.allows; > var denys = row.denys; > - var saveUrl = "?xpage=saverights&clsname=" + table.json.clsname + "&fullname=" + row.fullname + "&uorg=" + uorg; > > + var saveUrl = window.docviewurl + "?xpage=saverights&clsname=" + table.json.clsname + "&fullname=" + row.fullname + "&uorg=" + uorg; > + BTW can we guarantee that table.json.clsname, row.fullname and uorg don't contain any character that would need to be URL-encoded? Thanks -Vincent PS: We need a URL factory on the JS side to create valid URLs with proper encoding. [snip]

15 years, 5 months

1
0
0 0

[xwiki-devs] Groovy Blog: the End (for now)

by Andreas Schaefer

Hi After using my Groovy based XWiki Blog I decided that I am not going to pursue this any further because of these issues: - Groovy applications still have more limitations than Velocity making it very difficult to use as an alternative - It is very difficult to deploy my own Groovy blog application because I have to go over several hoops to install it (content, plugins, plugin configurations) - Most of the issues where related to Groovy based Panels which seems not to be possible - No interest in it Even though I think that Groovy would be a much better way to script applications like the Blog XWiki seems not to be ready to embrace it. From my point of view the entrenched usage of Velocity makes it very difficult to go beyond a simple page script in another scripting language. Cheers Andreas Schaefer CEO of Madplanet.com Inc. Email: andreas.schaefer(a)madplanet.com schaefera(a)me.com Twitter; andy_mpc AIM: schaefera(a)me.com

15 years, 5 months

2
2
0 0

[xwiki-devs] [Proposal] Migration to JSR330 for our component model

by Vincent Massol

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

15 years, 5 months

5
11
0 0

[xwiki-devs] Short Urls - configuration

by Andreas Hahn

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

15 years, 5 months

1
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r28225 - platform/web/trunk/standard/src/main/webapp/templates

by Sergiu Dumitriu

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/

15 years, 5 months

1
0
0 0

[xwiki-devs] [Proposal] XWiki.org Community Page

by Ecaterina Valica

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

15 years, 5 months

5
7
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs