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

[xwiki-devs] I'm updating from 2.1M1 to 2.1 Final release, and encountered an error.

by Zhaolin Feng

Hi: I'm updating from 2.1M1 to 2.1 Final release, and encountered an error. Please someone help me out. Many thanks. I did the following things. 1. Export everything from 2.1M1 to backup.xar 2. Import backup.xar to 2.1Final 3. Import official XE XAR, effectively overwrite the things in backup.xar, with the exception of XWiki.XWikiPreference and ***.WebPreference. 4. So far so fine. But after restarting the server, I encounter the following error: HTTP ERROR 500 Problem accessing /xwiki/bin/view/Main/. Reason: Error number 3 in 0: Could not initialize main XWiki context Wrapped Exception: Error number 3001 in 3: Cannot load class com.xpn.xwiki.store.migration.hibernate.XWikiHibernateMigrationManager from param xwiki.store.migration.manager.class Wrapped Exception: Error number 0 in 3: Exception while hibernate execute Wrapped Exception: Could not create a DBCP pool. There is an error in the hibernate configuration file, please review it. -- -- Zhaolin Feng -- www.mapbar.com -- Currahee! We stand alone together!

15 years, 9 months

2
4
0 0

Re: [xwiki-devs] [xwiki-users] XWiki + Glassfish 2.1.1 + cglib

by Sergiu Dumitriu

On 12/18/2009 01:36 PM, Reto Hotz wrote: > Hi, > > FYI: We have experienced problems running XWiki 2.1 on Glassfish 2.1.1 > (see stacktrace at the end). > Our final solution was to replace the bundled cglib-2.1_3.jar with the > newest cglib-2.2.jar So the solution is to also update it in the default distribution, right? -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 9 months

2
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r25854 - in platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter: . internal

by Thomas Mortagne

On Sun, Dec 20, 2009 at 16:44, asiri <platform-notifications(a)xwiki.org> wrote: > Author: asiri > Date: 2009-12-20 16:44:32 +0100 (Sun, 20 Dec 2009) > New Revision: 25854 > > Added: > platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/OfficeImporterVelocityBridge.java > Removed: > platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/internal/OfficeImporterVelocityBridge.java > Modified: > platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/internal/OfficeImporterVelocityContextInitializer.java > Log: > [misc] improving officeimporter code - step 1 > > * Moved OfficeImporterVelocityBridge class out from org.xwiki.officeimporter.internal package into org.xwiki.officeimporter package since a velocity bridge represents a public API. > > Added: platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/OfficeImporterVelocityBridge.java > =================================================================== > --- platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/OfficeImporterVelocityBridge.java (rev 0) > +++ platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/OfficeImporterVelocityBridge.java 2009-12-20 15:44:32 UTC (rev 25854) > @@ -0,0 +1,172 @@ > +/* > + * See the NOTICE file distributed with this work for additional > + * information regarding copyright ownership. > + * > + * This is free software; you can redistribute it and/or modify it > + * under the terms of the GNU Lesser General Public License as > + * published by the Free Software Foundation; either version 2.1 of > + * the License, or (at your option) any later version. > + * > + * This software is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this software; if not, write to the Free > + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA, or see the FSF site: http://www.fsf.org. > + */ > +package org.xwiki.officeimporter; > + > +import java.io.ByteArrayInputStream; > +import java.util.Map; > + > +import org.xwiki.bridge.DocumentAccessBridge; > +import org.xwiki.component.logging.Logger; > +import org.xwiki.component.manager.ComponentManager; > +import org.xwiki.context.Execution; > +import org.xwiki.model.DocumentNameFactory; > + > +/** > + * A bridge between velocity and office importer. > + * > + * @version $Id: OfficeImporterVelocityBridge.java 24508 2009-10-15 10:05:22Z asiri $ > + * @since 1.8M1 > + */ > +public class OfficeImporterVelocityBridge > +{ > + /** > + * The key used to place any error messages while importing office documents. > + */ > + public static final String OFFICE_IMPORTER_ERROR = "OFFICE_IMPORTER_ERROR"; > + > + /** > + * The {@link Execution} component. > + */ > + private Execution execution; > + > + /** > + * Internal {@link OfficeImporter} component. > + */ > + private OfficeImporter importer; > + > + /** > + * The {@link DocumentAccessBridge} component. > + */ > + private DocumentAccessBridge docBridge; > + > + /** > + * Used for converting string document names to {@link DocumentName} instances. > + */ > + private DocumentNameFactory nameFactory; > + > + /** > + * The {@link Logger} instance. > + */ > + private Logger logger; > + > + /** > + * Default constructor. > + * > + * @param componentManager used to lookup for other necessary components. > + * @param logger logger. > + */ > + public OfficeImporterVelocityBridge(ComponentManager componentManager, Logger logger) > + { > + this.logger = logger; > + try { > + this.execution = componentManager.lookup(Execution.class); > + this.importer = componentManager.lookup(OfficeImporter.class); > + this.docBridge = componentManager.lookup(DocumentAccessBridge.class); > + this.nameFactory = componentManager.lookup(DocumentNameFactory.class); > + } catch (Exception ex) { > + logger.error("Error while initializing office importer velocity bridge.", ex); Shouldn't it be an exception instead of a log ? Since this class depends on this component you should not be able to created it if one of these is missing like when you create a component. > + } > + } > + > + /** > + * Imports the passed Office document into the target wiki page. > + * > + * @param fileContent the binary content of the input document. > + * @param fileName the name of the source document (should have a valid extension since the extension is used to > + * find out the office document's format). > + * @param targetDocument the name of the resulting wiki page. > + * @param options the optional parameters for the conversion. > + * @return true if the operation was a success. > + */ > + public boolean importDocument(byte[] fileContent, String fileName, String targetDocument, > + Map<String, String> options) > + { > + boolean success = false; > + try { > + validateRequest(targetDocument, options); > + importer.importStream(new ByteArrayInputStream(fileContent), fileName, targetDocument, options); > + success = true; > + } catch (OfficeImporterException ex) { > + logger.error(ex.getMessage(), ex); > + execution.getContext().setProperty(OFFICE_IMPORTER_ERROR, ex.getMessage()); > + } catch (Exception ex) { > + logger.error(ex.getMessage(), ex); > + setErrorMessage("Internal error while finalizing the target document."); > + } > + return success; > + } > + > + /** > + * @return an error message set inside current execution (during import process) or null. > + */ > + public String getErrorMessage() > + { > + return (String) execution.getContext().getProperty(OFFICE_IMPORTER_ERROR); > + } > + > + /** > + * Utility method for setting an error message inside current execution. > + * > + * @param message error message. > + */ > + private void setErrorMessage(String message) > + { > + execution.getContext().setProperty(OFFICE_IMPORTER_ERROR, message); > + } > + > + /** > + * @return any error messages thrown while importing. > + * @deprecated use {@link #getErrorMessage()} instead since 2.2M1. > + */ > + @Deprecated > + public String getLastErrorMessage() > + { > + return getErrorMessage(); > + } > + > + /** > + * Checks if this request is valid. For a request to be valid, the target document should be editable by the current > + * user. And if this is not an append request, the target document should not exist. > + * > + * @param targetDocument the target document. > + * @param options additional parameters passed in for the import operation. > + * @throws OfficeImporterException if the request is invalid. > + */ > + private void validateRequest(String targetDocument, Map<String, String> options) throws OfficeImporterException > + { > + if (!docBridge.isDocumentEditable(nameFactory.createDocumentName(targetDocument))) { > + throw new OfficeImporterException("Inadequate privileges."); > + } else if (docBridge.exists(targetDocument) && !isAppendRequest(options)) { > + throw new OfficeImporterException("The target document " + targetDocument + " already exists."); > + } > + } > + > + /** > + * Utility method for checking if a request is made to append the importer result to an existing page. > + * > + * @param options additional parameters passed in for the import operation. > + * @return true if the params indicate that this is an append request. > + */ > + private boolean isAppendRequest(Map<String, String> options) > + { > + String appendParam = options.get("appendContent"); > + return (appendParam != null) ? appendParam.equals("true") : false; > + } > +} > > Deleted: platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/internal/OfficeImporterVelocityBridge.java > =================================================================== > --- platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/internal/OfficeImporterVelocityBridge.java 2009-12-20 02:37:05 UTC (rev 25853) > +++ platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/internal/OfficeImporterVelocityBridge.java 2009-12-20 15:44:32 UTC (rev 25854) > @@ -1,147 +0,0 @@ > -/* > - * See the NOTICE file distributed with this work for additional > - * information regarding copyright ownership. > - * > - * This is free software; you can redistribute it and/or modify it > - * under the terms of the GNU Lesser General Public License as > - * published by the Free Software Foundation; either version 2.1 of > - * the License, or (at your option) any later version. > - * > - * This software is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > - * Lesser General Public License for more details. > - * > - * You should have received a copy of the GNU Lesser General Public > - * License along with this software; if not, write to the Free > - * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > - * 02110-1301 USA, or see the FSF site: http://www.fsf.org. > - */ > -package org.xwiki.officeimporter.internal; > - > -import java.io.ByteArrayInputStream; > -import java.util.Map; > - > -import org.xwiki.bridge.DocumentAccessBridge; > -import org.xwiki.component.logging.Logger; > -import org.xwiki.context.Execution; > -import org.xwiki.officeimporter.OfficeImporter; > -import org.xwiki.officeimporter.OfficeImporterException; > - > -/** > - * A bridge between velocity and office importer. > - * > - * @version $Id$ > - * @since 1.8M1 > - */ > -public class OfficeImporterVelocityBridge > -{ > - /** > - * The key used to place any error messages while importing office documents. > - */ > - public static final String OFFICE_IMPORTER_ERROR = "OFFICE_IMPORTER_ERROR"; > - > - /** > - * The {@link Execution} component. > - */ > - private Execution execution; > - > - /** > - * Internal {@link OfficeImporter} component. > - */ > - private OfficeImporter importer; > - > - /** > - * The {@link DocumentAccessBridge} component. > - */ > - private DocumentAccessBridge docBridge; > - > - /** > - * The {@link Logger} instance. > - */ > - private Logger logger; > - > - /** > - * Default constructor. > - * > - * @param execution current execution. > - * @param importer internal office importer component. > - * @param docBridge document access bridge. > - * @param logger logger. > - */ > - public OfficeImporterVelocityBridge(Execution execution, OfficeImporter importer, DocumentAccessBridge docBridge, > - Logger logger) > - { > - this.execution = execution; > - this.importer = importer; > - this.docBridge = docBridge; > - this.logger = logger; > - } > - > - /** > - * Imports the passed Office document into the target wiki page. > - * > - * @param fileContent the binary content of the input document. > - * @param fileName the name of the source document (should have a valid extension since the extension is used to > - * find out the office document's format). > - * @param targetDocument the name of the resulting wiki page. > - * @param options the optional parameters for the conversion. > - * @return true if the operation was a success. > - */ > - public boolean importDocument(byte[] fileContent, String fileName, String targetDocument, > - Map<String, String> options) > - { > - boolean success = false; > - try { > - validateRequest(targetDocument, options); > - importer.importStream(new ByteArrayInputStream(fileContent), fileName, targetDocument, options); > - success = true; > - } catch (OfficeImporterException ex) { > - logger.error(ex.getMessage(), ex); > - execution.getContext().setProperty(OFFICE_IMPORTER_ERROR, ex.getMessage()); > - } catch (Exception ex) { > - logger.error(ex.getMessage(), ex); > - execution.getContext().setProperty(OFFICE_IMPORTER_ERROR, > - "Internal error while finalizing the target document."); > - } > - return success; > - } > - > - /** > - * Checks if this request is valid. For a request to be valid, the target document should be editable by the current > - * user. And if this is not an append request, the target document should not exist. > - * > - * @param targetDocument the target document. > - * @param options additional parameters passed in for the import operation. > - * @throws OfficeImporterException if the request is invalid. > - */ > - private void validateRequest(String targetDocument, Map<String, String> options) throws OfficeImporterException > - { > - if (!docBridge.isDocumentEditable(targetDocument)) { > - throw new OfficeImporterException("Inadequate privileges."); > - } else if (docBridge.exists(targetDocument) && !isAppendRequest(options)) { > - throw new OfficeImporterException("The target document " + targetDocument + " already exists."); > - } > - } > - > - /** > - * Utility method for checking if a request is made to append the importer result to an existing page. > - * > - * @param options additional parameters passed in for the import operation. > - * @return true if the params indicate that this is an append request. > - */ > - private boolean isAppendRequest(Map<String, String> options) > - { > - String appendParam = options.get("appendContent"); > - return (appendParam != null) ? appendParam.equals("true") : false; > - } > - > - /** > - * @return any error messages thrown while importing. > - */ > - public String getLastErrorMessage() > - { > - Object error = execution.getContext().getProperty(OFFICE_IMPORTER_ERROR); > - return (error != null) ? (String) error : null; > - } > -} > > Modified: platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/internal/OfficeImporterVelocityContextInitializer.java > =================================================================== > --- platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/internal/OfficeImporterVelocityContextInitializer.java 2009-12-20 02:37:05 UTC (rev 25853) > +++ platform/core/trunk/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/internal/OfficeImporterVelocityContextInitializer.java 2009-12-20 15:44:32 UTC (rev 25854) > @@ -20,12 +20,11 @@ > package org.xwiki.officeimporter.internal; > > import org.apache.velocity.VelocityContext; > -import org.xwiki.bridge.DocumentAccessBridge; > import org.xwiki.component.annotation.Component; > import org.xwiki.component.annotation.Requirement; > import org.xwiki.component.logging.AbstractLogEnabled; > -import org.xwiki.context.Execution; > -import org.xwiki.officeimporter.OfficeImporter; > +import org.xwiki.component.manager.ComponentManager; > +import org.xwiki.officeimporter.OfficeImporterVelocityBridge; > import org.xwiki.velocity.VelocityContextInitializer; > > /** > @@ -43,29 +42,16 @@ > public static final String VELOCITY_CONTEXT_KEY = "officeimporter"; > > /** > - * The {@link Execution} component. > + * Used to lookup other components. > */ > @Requirement > - private Execution execution; > + private ComponentManager componentManager; > > /** > - * The {@link OfficeImporter} component. > - */ > - @Requirement > - private OfficeImporter officeImporter; > - > - /** > - * The {@link DocumentAccessBridge}. > - */ > - @Requirement > - private DocumentAccessBridge docBridge; > - > - /** > * {@inheritDoc} > */ > public void initialize(VelocityContext context) > { > - context.put(VELOCITY_CONTEXT_KEY, new OfficeImporterVelocityBridge(execution, officeImporter, docBridge, > - getLogger())); > + context.put(VELOCITY_CONTEXT_KEY, new OfficeImporterVelocityBridge(componentManager, getLogger())); > } > } > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications > -- Thomas Mortagne

15 years, 9 months

2
1
0 0

[xwiki-devs] [Discussion] extract out an xwiki-openoffice module from xwiki-officeimporter module ?

by Asiri Rathnayake

Hello Devs, Currently xwiki-officeimporter contains logic for mainly two different tasks: 1. Manage the back-end openoffice process (and provide document conversion facilities). 2. Perform the actual transformation from office documents to wiki pages. (depends on point 1) xwiki-officeimporter module's code might appear a bit complex because of this mix up. Also I believe openoffice related code might have to be reused once we introduce an office-exporter module. I was wondering if it would be beneficial (in the long run) to extract out openoffice related code into a separate module (xwiki-openoffice). The main concern I have is that currently openoffice related code is inside org.xwiki.officeimporter.openoffice package which have to be changed to org.xwiki.openoffice if we are to extract out a xwiki-openoffice module, this could break a few things in public API. Even if we decide to do so, I don't think any of us (devs) would be able to do this within 2.2M1 time period. But I thought it's better to discuss about it a little now. Let me know what you think. Thanks. - Asiri

15 years, 9 months

4
5
0 0

[xwiki-devs] mimic relational database one to many relations

by Helenc

Hi All, I would really like to be able to mimic one to many relations through classes somehow? I noticed there have been a few posts about how one might go about such a thing using dblists, it's not clear yet to me how I could implement such a thing? I'm wondering if any demo application exist that might give me more of a clue? Let's say I want to set up a simple one to many relationship between information about a company and then individuals who worked for that company. How would I go about such a thing? Do I setup a companyclass and a personsclass and then link them somehow with the dblist? What's the best user interface setup for this too so it's easy for users to enter company and people data? Are there any examples of HQL queries about how one would then search to display individuals details along with elements of their companies details? Referencing the relationship? Or is there another way to do this? Any pointers would be very much appreciated? Thanks Helen -- View this message in context: http://n2.nabble.com/mimic-relational-database-one-to-many-relations-tp4185… Sent from the XWiki- Dev mailing list archive at Nabble.com.

15 years, 9 months

3
4
0 0

[xwiki-devs] Are velocity bridges part of public API?

by Asiri Rathnayake

Hi Devs, I just realized that I've been having a velocity bridge class inside an *.internal package for sometime. I think this is wrong because velocity bridges are part of our public API (?). Moving this bridge to a non-internal package would not harm because it would not break any existing velocity scripts. WDYT? - Asiri

15 years, 9 months

1
0
0 0

[xwiki-devs] Add currentPage to the XWiki object in javascript

by Anca Luca

Hi devs, right now we have 2 ways to get (some) information about the current document in javascript: * the meta tags (which store the page, the space, the wiki, version, etc) -- set in htmlheader.vm * the XWiki object set in xwiki.js and filled in with info in javascript.vm which contains currentWiki, mainWiki, currentSpace, action, etc, but *not* the currentPage. Between the two, I propose to use the second as the 'recommended' way to get information about XWiki in some javascript in a document (the action, the wiki, the space, etc) and, to make it complete, to add a currentPage to it. WDYT? Thanks, Anca

15 years, 9 months

5
10
0 0

[xwiki-devs] [Suggestion] separate interface language and page content language settings

by Zhaolin Feng

Hi, everyone: As discussed in XE-552 <http://jira.xwiki.org/jira/browse/XE-552>, Thomas Mortagne and I agreed that interface language and page content language are two unrelated dimensions. With the new Colibri skin in XE2.1, I think we are in a good position to seperate them. 1. Move the content language switcher from the site title bar to the page title bar. 2. In register page and personal profile page, add a "preferred language" setting. It's the interface language as well as the default content language. WDYT? I've created a suggestion in JIRA: http://jira.xwiki.org/jira/browse/XSCOLIBRI-169 -- -- Zhaolin Feng -- www.mapbar.com -- Currahee! We stand alone together!

15 years, 9 months

2
1
0 0

[xwiki-devs] [Proposal] Gadgets Integration

by Anamaria Stoica

Hi devs, I'd like to start working on Gadgets Integration. (this is a new feature) I've been working on the specs with Guillaume, and you can see the Design page here: http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration The aim of the gadget integration is to provide XWiki users with a dashboard-like page that will display a list of gadgets. These gadgets can be either internal gadgets (similar to XWiki panels) or external gadgets (coming from the Google Gadget repository for instance). Users can select which gadgets to display on their dashboard from a gadget directory located on the wiki. I've also created a few Mockups here http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GadgetsIntegration for the Dashboard, Gadget Windows and Gadgets Directory. List of features: Dashboard - Dashboard for each user with drag&drop for Gadget Windows - Display both Google Gadgets and XWiki Gadgets (Panels) Directory - An internal directory with Gadgets in the wiki divided in 3 parts: * XWiki Gadgets defined in the wiki / in the farm (current Panels) * Google Gadgets selected out of the global Google Directory by wiki admins * If allowed by wiki admins: full Google Gadgets Directory I'd like to include all of the above with basic functionalities into 2.2M1. One thing is not clear at this point >> The relationship between XWiki Gadgets and current Panels: They are basically the same thing (same content), but they will have different containers (drag&drop window with edit settings on Dashboard and present containers for the side menu Panels). Will all Panels make sense as XWiki Gadgets? If no, when a new Panel is created, how do you know it's meant to be only a side menu Panel and not also a XWikiGadget? (this applies for current Panels as well) Also, very important: where should the interface for the Gadgets Directory be placed? Appended to Panels.WebHome or new directory Gadgets.WebHome? In my opinion it needs a different interface from the Panel Wizard Interface. The Panel Wizard is in the Wiki Preferences (administration space) open only to Admins, but the Directory will have to be available to all users (even browsable by everyone). An admin interface for picking Google Gadgets from iGoogle Directory and/or XWiki Panels for the Gadgets Directory might be needed. How should I treat the 2 of them (XWiki Gadgets vs side menu Panels)? Thanks, Anamaria

15 years, 9 months

7
18
0 0

[xwiki-devs] Authentication with Active Directory

by Fabio Puglisi

Hi, I'm trying to configure my xwiki installation to authenticate users using Microsoft Active Directory. If I try to login the result is a continuous reload of the login page without error message. No error message in log files too. Our login standard use dot between First name and Last name (eg: fabio.puglisi), could be this a problem? Anyone can help me? Thanks Here my wiki.cfg #----------------------------------------------------------------------- -------------- # LDAP #----------------------------------------------------------------------- -------------- #-# new LDAP authentication service xwiki.authentication.authclass=com.xpn.xwiki.user.impl.LDAP.XWikiLDAPAut hServiceImpl #-# Turn LDAP authentication on - otherwise only XWiki authentication xwiki.authentication.ldap=1 #-# LDAP Server (Active Directory, eDirectory, OpenLDAP, etc.) xwiki.authentication.ldap.server=10.239.1.169 xwiki.authentication.ldap.port=389 #-# LDAP login, empty = anonymous access, otherwise specify full dn #-# {0} is replaced with the username, {1} with the password xwiki.authentication.ldap.bind_DN=ldaptest\\administrator xwiki.authentication.ldap.bind_pass=Password #-# Force to check password after LDAP connection #-# 0: disable #-# 1: enable xwiki.authentication.ldap.validate_password=0 #-# only members of the following group will be verified in the LDAP #-# otherwise only users that are found after searching starting from the base_DN xwiki.authentication.ldap.user_group=cn=Users #-# [Since 1.5RC1, XWikiLDAPAuthServiceImpl] #-# only users not member of the following group can autheticate # xwiki.authentication.ldap.exclude_group=cn=admin,ou=groups,o=MegaNova,c= US #-# base DN for searches xwiki.authentication.ldap.base_DN=dc=ldaptest,dc=semplatest,dc=local #-# Specifies the LDAP attribute containing the identifier to be used as the XWiki name (default=cn) xwiki.authentication.ldap.UID_attr=sAMAccountName #-# [Since 1.5M1, XWikiLDAPAuthServiceImpl] #-# Specifies the LDAP attribute containing the password to be used "when xwiki.authentication.ldap.validate_password" is set to 1 xwiki.authentication.ldap.password_field=userPassword #-# [Since 1.5M1, XWikiLDAPAuthServiceImpl] #-# The potential LDAP groups classes. Separated by commas. # xwiki.authentication.ldap.group_classes=group,groupOfNames,groupOfUnique Names,dynamicGroup,dynamicGroupAux,groupWiseDistributionList #-# [Since 1.5M1, XWikiLDAPAuthServiceImpl] #-# The potential names of the LDAP groups fields containings the members. Separated by commas. xwiki.authentication.ldap.group_memberfields=member,uniqueMember #-# retrieve the following fields from LDAP and store them in the XWiki user object (xwiki-attribute=ldap-attribute) xwiki.authentication.ldap.fields_mapping=name=sAMAccountName,last_name=s n,first_name=givenName,fullname=displayName,email=mail,ldap_dn=dn #-# [Since 1.3M2, XWikiLDAPAuthServiceImpl] #-# on every login update the mapped attributes from LDAP to XWiki otherwise this happens only once when the XWiki account is created. xwiki.authentication.ldap.update_user=1 #-# [Since 1.3M2, XWikiLDAPAuthServiceImpl] #-# mapps XWiki groups to LDAP groups, separator is "|" xwiki.authentication.ldap.group_mapping=XWiki.XWikiAdminGroup=cn=Adminis trators #-# [Since 1.3M2, XWikiLDAPAuthServiceImpl] #-# time in s after which the list of members in a group is refreshed from LDAP (default=3600*6) # xwiki.authentication.ldap.groupcache_expiration=21800 #-# [Since 1.3M2, XWikiLDAPAuthServiceImpl] #-# - create : synchronize group membership only when the user is first created #-# - always: synchronize on every login xwiki.authentication.ldap.mode_group_sync=always #-# [Since 1.3M2, XWikiLDAPAuthServiceImpl] #-# if ldap authentication fails for any reason, try XWiki DB authentication with the same credentials xwiki.authentication.ldap.trylocal=0 #-# [Since 1.3M2, XWikiLDAPAuthServiceImpl] #-# SSL connection to LDAP server #-# 0: normal #-# 1: SSL xwiki.authentication.ldap.ssl=0 #-# [Since 1.3M2, XWikiLDAPAuthServiceImpl] #-# The keystore file to use in SSL connection # xwiki.authentication.ldap.ssl.keystore= #-# [Since 1.5M1, XWikiLDAPAuthServiceImpl] #-# The java secure provider used in SSL connection # xwiki.authentication.ldap.ssl.secure_provider=com.sun.net.ssl.internal.s sl.Provider Le informazioni contenute in questo messaggio sono riservate e confidenziali ed e vietata le diffusione in qualunque modo eseguita. Qualora Lei non fosse la persona a cui il presente messaggio e destinato, La invitiamo ad eliminarlo e a non leggerlo, dandocene gentilmente comunicazione. Per qualsiasi informazione si prega di contattare (informazioni(a)sempla.it). Rif. D.L. 196/2003 This e-mail (including attachments) is intended only for the recipient(s) named above. It may contain confidential or privileged information and should not be read, copied or otherwise used by any other person. If you are not the named recipient, please contact (informazioni(a)sempla.it) and delete the e-mail from your system. Rif. D.L. 196/2003.

15 years, 9 months

2
1
0 0

[xwiki-devs] OfficeImporter API changes - Take 2

by Asiri Rathnayake

Hello Devs, After few discussions I have revised the new officeimporter API to take into account the use of DocumentName instead of plain strings for representing document names. I'll repeat the details of the previous proposal with the new changes applied: Currently we have the following officeimporter API: <code> OfficeImporter::importStream(InputStream is, String documentFormat, String targetDocumentName, Map params):void OfficeImporter::importAttachment(String documentName, String attachmentName, Map params):String </code> Problems with this API: * Loosely typed (params, document names) * Both of the above methods perform almost the same task. * Customizing the import process is implemented in a hackish way. (not visisble on the API) The new API proposed looks like below: <code> OfficeImporter::officeToXHTML(byte[] officeFileData, DocumentName referenceDocument, boolean filterStyles):XHTMLOfficeDocument OfficeImporter::xhtmlToXDOM(XHTMLOfficeDocument xhtmlOfficeDocument):XDOMOfficeDocument OfficeImporter::officeToXDOM(byte[] officeFileData, DocumentName referenceDocument, boolean filterStyles):XDOMOfficeDocument OfficeImporter::buildPresentation(byte[] officeFileData):XDOMOfficeDocument OfficeImporter::splitImport(XDOMOfficeDocument xdomOfficeDocument, int[] headingLevelsToSplit, NamingCriterion namingCriterion, DocumentName baseDocumentName):Map<TargetPageDescriptor, XDOMOfficeDocument> </code> As you can see, these methods are more granular and the responsibilities are well defined. Customizing the import process can be done from the client code. For an example: 1. Make the initial import from office to XHTMLOfficeDocument - OfficeImporter::officeToXHTML() 2. Perform customizations on the XHTMLOfficeDocument - w3c DOM manipulations. 3. Import the XHTMLOfficeDocument into XDOMOfficeDocument - OfficeImporter::xhtmlToXDOM() 4. Perform customizations on the XDOMOfficeDocument (XDOM) - XDOM manipulations. 5. Split the XDOMOfficeDocument into multiple XDOMOfficeDocument instances - OfficeImporter::splitImport() 6. Perform customizations on these child XDOMOfficeDocument instances - XDOM manipulations. 7. Render the XDOMOfficeDocument instances & save them into wiki pages - XWiki rendering operations. I think this interface will make it easy to extend & maintain officeimporter functionality in the future. Along with this, I would also like to refactor the xwiki-refactoring module a bit to get rid of string based document names from it. This whole refactoring operation would take approximately one day to complete. And since this operation is not adding any new features, I think it can be committed on both trunk and 2.0 branch. Here's my +1 to all of above. Thanks. - Asiri

15 years, 9 months

5
8
0 0

[xwiki-devs] [Proposal] Resource vs Item vs ItemResource vs Model & Name vs Path vs Reference

by Vincent Massol

Hi devs, We need to decide if we want to keep the current: ResourceName, DocumentName, SpaceName, WikiName, AttachmentName or instead use a variation. There are 2 things to decide: - The prefix for the base object (Resource, Item, Model, etc) - The suffix (Name, Path, Reference, etc) Proposal ======= I'd like to propose ModelReference for the base object and then DocumentReference, SpaceReference, WikiReference, AttachmentReference. Note: This is different from Identity which is unique (a UUID). References do not point to unique objects. Reference makes sense to me since it means what it means... :) For example the API: Document getDocument(DocumentReference) is pretty clear IMO. Path is too physical to me. In JCR it's called getPath() but it returns a string with a path, for ex "/wiki/space1/space2/document". This is not our case. IMO our Reference would transform into a path when serialized only. Name isn't too bad, it would be my second choice. But it doesn't show the fact that it's a ... reference... ;) WDYT? Thanks -Vincent

15 years, 9 months

7
21
0 0

[xwiki-devs] [Proposal][Model] ResourceName refactoring

by Vincent Massol

Hi, I'd like to propose a refactoring for org.xwiki.model.DocumentName/ AttachmentName. There are currently 2 problems with the current implementation: - DocumentName doesn't support nested spaces (we need that for the future) - We need to generalize the concept of resource names so that we can use the generic concept in the Model in some APIs Thus I'd like to propose: enum ResourceType - WIKI, DOCUMENT, SPACE, ATTACHMENT ResourceName - ResourceName(String name, ResourceName parent) - get/setName() - get/setParent(ResourceName) - get/setType(ResourceType) DocumentName extends ResourceName - DocumentName(String pageName, SpaceName parent) AttachmentName extends ResourceName - AttachmentName(String fileName, DocumentName parent) WikiName extends ResourceName - WikiName(String wikiName) SpaceName extends ResourceName - SpaceName(String spaceName, SpaceName parent) - SpaceName(String spaceName, WikiName parent) Open questions and comments ======================== - Should we replace "Name" by "Reference", i.e. DocumentReference instead of DocumentName, WikiReference instead of WikiName? - Note: A name (or reference) isn't resistant to change. Resources (Document, Space, Wiki, etc) must also have an Identifier (unique id) to uniquely identify them. For example a Document can be moved from one space to another (the DocumentName changes in this case). - The scheme above allows to map this easily to the JCR API - Do we want helper methods for locating the wiki in which a DocumentName is? That would mean adding: WikiName DocumentName.getWiki() (algo: getParent() till getType == WIKI or null) Same question for getting the last Space or Wiki from AttachmentName - Do we want a helper constructor to make it easier to create a DocumentName? With the proposal above it means: new DocumentName("page", new SpaceName("space", new WikiName("wiki"))); A helper constructor could be: DocumentName(String page, String space, String wiki). Problems: a) we would need another constructor to support a list of spaces and b) if there are fields other than the name to set on ResourceNames later on, it's not going to work as smoothly) Factory and Serializer ================= This is a big question I haven't yet solved. We have 2 options: 1) have specialized Factory/Serializer. For ex: DocumentNameFactory, DocumentNameSerializer 2) have generic ones: ResourceNameFactory/ResourceNameSerializer 2) seems nicer initially but the problem with 2) is that we need a global String representation of any resource in the system. There are 2 problems with that: - we may not want that. For example when the user is asked to enter a document name in a field, we may not need/want to parse this as a general resource that could for example point to an attachment (and btw as a consequence allow entering "@" which is our separator for attachments) - it's very hard to add new Resource types later on (since we'd need more special characters to separate them and this means these chars wouldn't be allowed in names for pages for ex) The other option is to have 2) but with the type passed as parameter: ResourceName ResourceNameFactory.create(String stringRepresentation, ResourceType) However this simply means that ResourceNameFactory would be a factory for actual factories (DocumentNameFactory, AttachmentNameFactory, etc) so I don't really see the added value in our component-based world (we can look up the right factory directly). Thus IMO we want 1). WDYT? Thanks -Vincent

15 years, 9 months

3
12
0 0

Re: [xwiki-devs] [xwiki-notifications] r25832 - in platform: core/trunk/xwiki-core/src/main/resources xwiki-applications/trunk/panels/src/main/resources/Panels

by Jean-Vincent Drean

The fact that it uses translations with the panels.* prefix is wrong, we need to use a core.search.* (or platform.search.* ?) prefix for the text in the header. About the label itself having a voice reader reading "search query" to describe the input is better than "search", WDYT ? Any other opinions about this ? I'll commit the fixes when we'll find an agreement. Thanks, JV. On Thu, Dec 17, 2009 at 11:39 AM, Ecaterina Valica <valicac(a)gmail.com> wrote: > The Search label in the global.vm uses panels.search.inputLabel > > <label class="hidden" > for="headerglobalsearchinput">$msg.get('panels.search.inputLabel')</label> > > > On Thu, Dec 17, 2009 at 12:08, jvdrean <platform-notifications(a)xwiki.org> > wrote: >> >> Author: jvdrean >> Date: 2009-12-17 11:08:18 +0100 (Thu, 17 Dec 2009) >> New Revision: 25832 >> >> Modified: >> >> platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties >> >> platform/xwiki-applications/trunk/panels/src/main/resources/Panels/Search.xml >> Log: >> XAPANELS-106 : Missing label for search input field in Panels.Search >> >> + removed tag object >> >> Modified: >> platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties >> =================================================================== >> --- >> platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties >> 2009-12-17 09:58:26 UTC (rev 25831) >> +++ >> platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties >> 2009-12-17 10:08:18 UTC (rev 25832) >> @@ -919,6 +919,7 @@ >> panels.translation.existingTranslations=Existing translations: >> >> panels.search.title=Search >> +panels.search.query=Search query >> panels.search.inputLabel=Search >> panels.search.inputText=search... >> panels.search.submit=Go >> >> Modified: >> platform/xwiki-applications/trunk/panels/src/main/resources/Panels/Search.xml >> =================================================================== >> --- >> platform/xwiki-applications/trunk/panels/src/main/resources/Panels/Search.xml >> 2009-12-17 09:58:26 UTC (rev 25831) >> +++ >> platform/xwiki-applications/trunk/panels/src/main/resources/Panels/Search.xml >> 2009-12-17 10:08:18 UTC (rev 25832) >> @@ -22,39 +22,6 @@ >> <comment></comment> >> <object> >> <class> >> -<name>XWiki.TagClass</name> >> -<customClass></customClass> >> -<customMapping></customMapping> >> -<defaultViewSheet></defaultViewSheet> >> -<defaultEditSheet></defaultEditSheet> >> -<defaultWeb></defaultWeb> >> -<nameField></nameField> >> -<validationScript></validationScript> >> -<tags> >> -<name>tags</name> >> -<prettyName>Tags</prettyName> >> -<unmodifiable>0</unmodifiable> >> -<relationalStorage>1</relationalStorage> >> -<displayType>input</displayType> >> -<multiSelect>1</multiSelect> >> -<size>30</size> >> -<separator> </separator> >> -<cache>0</cache> >> -<separators> ,|</separators> >> -<values></values> >> -<number>1</number> >> -<classType>com.xpn.xwiki.objects.classes.StaticListClass</classType> >> -</tags> >> -</class> >> -<name>Panels.Search</name> >> -<number>0</number> >> -<className>XWiki.TagClass</className> >> -<property> >> -<tags/> >> -</property> >> -</object> >> -<object> >> -<class> >> <name>Panels.PanelClass</name> >> <customClass></customClass> >> <customMapping></customMapping> >> @@ -138,7 +105,8 @@ >> <content>#panelhiddenheader($msg.get("panels.search.title")) >> <form action="$xwiki.getURL('Main.WebSearch')"> >> <div class="globalsearch"> >> - <input class="globalsearchinput" type="text" name="text" >> value="$msg.get('panels.search.inputText')" size="15" onfocus="if >> (this.value == '$msg.get('panels.search.inputText')') value=''; >> this.select();" onblur="if (this.value == '') >> value='$msg.get('panels.search.inputText')'; this.blur()"/> >> + <label for="globalsearchinput" >> class="hidden">$msg.get('panels.search.query')</label> >> + <input id="globalsearchinput" class="globalsearchinput" >> type="text" name="text" value="$msg.get('panels.search.inputText')" >> size="15" onfocus="if (this.value == '$msg.get('panels.search.inputText')') >> value=''; this.select();" onblur="if (this.value == '') >> value='$msg.get('panels.search.inputText')'; this.blur()"/> >> &nbsp; >> <input class="button" value="$msg.get('panels.search.submit')" >> type="image" src="$xwiki.getSkinFile('go.png')" >> alt="$msg.get('panels.search.submit')"/> >> </div> >> >> _______________________________________________ >> notifications mailing list >> notifications(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/notifications > > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications > >

15 years, 9 months

1
0
0 0

[xwiki-devs] Update XWiki Hall Of Fame

by Marius Dumitru Florea

Hi devs, I just looked at the XWiki Hall of Fame ( http://dev.xwiki.org/xwiki/bin/view/Community/HallOfFame ) and I think it is a bit outdated. 1) I think we should make Artem Melentev and Stéphane Laurière emeritus committers since they haven't been active for a long time now. 2) I was surprised to see that Eduard is not listed among the XEclipse committers. 3) I think we should add Caty to http://dev.xwiki.org/xwiki/bin/view/Community/HallOfFame#HOthers ("Others" sounds bad though; we should find a better name for this category of special contributors). Caty has worked on improving the UI and UX of XWiki Enterprise. She also helped improving the XWatch UI one year ago when she participated in the GSoC program. 4) I think we should add to the list of Contributors: Oana Tabaranu * http://code.xwiki.org/xwiki/bin/view/Macros/Video20Macro * http://code.xwiki.org/xwiki/bin/view/Applications/BulletinBoardApplication * http://code.xwiki.org/xwiki/bin/view/Applications/LightboxApplication * http://code.xwiki.org/xwiki/bin/view/Applications/WatchListLayoutApplication Thibaut Deveraux for his participation to the UI/UX related discussions on the XWiki mailing lists and Raluca Stavro for her contribution to XWiki Workspaces, Rating Application (on sandbox right now) and, recently, Colibri skin. Thanks, Marius

15 years, 9 months

2
1
0 0

[xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor

by Marius Dumitru Florea

Hi devs, Currently we have this behavior: * simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result: ----- <details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened: * The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. ----- </details> ----- Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become: * simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit I'm +1 for Alt key. WDYT? Thanks, Marius

15 years, 9 months

5
13
0 0

Re: [xwiki-devs] [xwiki-notifications] r25823 - platform/xwiki-applications/trunk/blog/src/main/resources/Blog

by Sergiu Dumitriu

On 12/16/2009 05:23 PM, jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-12-16 17:23:10 +0100 (Wed, 16 Dec 2009) > New Revision: 25823 > > Modified: > platform/xwiki-applications/trunk/blog/src/main/resources/Blog/BlogStyle.xml > platform/xwiki-applications/trunk/blog/src/main/resources/Blog/CreatePost.xml > Log: > XABLOG-98 : Accessibility for Blog.CreatePost > > Modified: platform/xwiki-applications/trunk/blog/src/main/resources/Blog/BlogStyle.xml > =================================================================== > --- platform/xwiki-applications/trunk/blog/src/main/resources/Blog/BlogStyle.xml 2009-12-16 16:09:58 UTC (rev 25822) > +++ platform/xwiki-applications/trunk/blog/src/main/resources/Blog/BlogStyle.xml 2009-12-16 16:23:10 UTC (rev 25823) > @@ -232,6 +232,12 @@ > font-size: 140%; > width: 100%; > font-weight: bold; > +} > +.createPost { Wrong, use getSkinFile: > + background: transparent url(/xwiki/resources/icons/silk/add.gif) no-repeat scroll left center; > + font-size: 80%; > + font-weight: bold; > + padding-left: 18px; > }</code> > </property> > <property> -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 9 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r25823 - platform/xwiki-applications/trunk/blog/src/main/resources/Blog

by Vincent Massol

On Dec 16, 2009, at 5:23 PM, jvdrean (SVN) wrote: > Author: jvdrean > Date: 2009-12-16 17:23:10 +0100 (Wed, 16 Dec 2009) > New Revision: 25823 > > Modified: > platform/xwiki-applications/trunk/blog/src/main/resources/Blog/ > BlogStyle.xml > platform/xwiki-applications/trunk/blog/src/main/resources/Blog/ > CreatePost.xml > Log: > XABLOG-98 : Accessibility for Blog.CreatePost It's missing the "Patch from Ecaterina Valica". http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HApplyin… Thanks -Vincent [snip]

15 years, 9 months

1
0
0 0

[xwiki-devs] [VOTE] XWiki.org: Don't delete important pages

by Vincent Massol

Hi, Another proposal: don't remove important pages that are moved. For example imagine that we refactor the RSSFeeds page into a Notifications page. I propose that we don't delete the RSSFeeds page but instead add a redirect to the new page. Example: {{velocity}} $response.sendRedirect($xwiki.getURL("Features.Notifications")) {{/velocity}} I propose we do this till we get this feature automatically in the XWiki core. The rationale is that users will save links and when they navigate to them later on these links will be broken. Here's my +1 Thanks -Vincent

15 years, 9 months

10
11
0 0

[xwiki-devs] [Proposal] XWiki.org documentation rule for Versions and Skins

by Vincent Massol

Hi, We need to decide how we want to document xwiki.org with regards to project versions and skins. For example the screenshot and features described can depend on 2 factors: - the project version (XE version for ex) - the skin used Project versions ============= We have several choices: 1) We make the doc only for the latest version and in this case we should probably export the pages at release time and make it available as a zipped HTML export so that people using the older version can refer to them. 2) We make the doc work the last 2 releases. That would be either 2.1 and 2.0.5 or 2.2M1 and 2.1 depending on how we view it and depending on whether we want to document on xwiki.org before we release or not. Personally I think I prefer option 1 with a little addition: - whenever something that is new to the last release is documented, we should add a little "New" logo (possibly with the version value, "New in 2.2" for example). This could be done with a wiki macro. If option 1 is chosen then we need to add a step to the release process. Skins ==== Again we have several choices: 1) Document only for the latest skin 2) Document for all supported skins. Right now that would be Toucan + Colibri (not sure about Albatross, I don't think we've officially said it wasn't supported). If we were to do 2) then this that for example this page http://code.xwiki.org/xwiki/bin/view/Applications/WatchlistApplication would need to contain screenshots for all supported skins *OR* there should be different screenshots only when the skins have different features. This is the case here since the location of menus and actions are quite different. I'm hesitating more for this one... 1) is definitely easier for us so I'm tempted to propose 1) but with the proviso that we make it clear in the text when a feature is available only for a given skin (for ex: the Show Code menu action is avail in Colibri but not in Toucan). WDYT? When we agree we should put the result on dev.xwiki.org in a new page describing how xwiki.org is documented. Thanks -Vincent

15 years, 9 months

8
7
0 0

Re: [xwiki-devs] [xwiki-notifications] r25768 - in contrib/sandbox/xwiki-model: . src src/main src/main/java/org/xwiki/model

by Thomas Mortagne

On Sat, Dec 12, 2009 at 16:02, vmassol <contrib-notifications(a)xwiki.org> wrote: > Author: vmassol > Date: 2009-12-12 16:02:21 +0100 (Sat, 12 Dec 2009) > New Revision: 25768 > > Added: > contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Persistable.java > Removed: > contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/internal/ > contrib/sandbox/xwiki-model/src/main/resources/ > contrib/sandbox/xwiki-model/src/test/ > Modified: > contrib/sandbox/xwiki-model/ > contrib/sandbox/xwiki-model/pom.xml > contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Attachment.java > contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Document.java > contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Object.java > contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ObjectDefinition.java > contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ObjectDefinitionProperty.java > contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Server.java > contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Space.java > contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Wiki.java > Log: > Continuing work on the new Model. The idea is to do step1, which is about designing the interfaces and implementing them with the old model FTM. > > * Remove dependencies on JCR since we now want to create interfaces for the new model that are independent of JCR (for a start). I'm still unsure whether we should base these interfaces on JCR or not but it seems easier not to for the moment. > * Several questions asked in comments > [...] > Modified: contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Attachment.java > =================================================================== > --- contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Attachment.java 2009-12-11 17:03:01 UTC (rev 25767) > +++ contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Attachment.java 2009-12-12 15:02:21 UTC (rev 25768) > @@ -1,8 +1,6 @@ > package org.xwiki.model; > > -import javax.jcr.Node; > - > -public interface Attachment extends Node > +public interface Attachment extends Persistable > { > > } > > Modified: contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Document.java > =================================================================== > --- contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Document.java 2009-12-11 17:03:01 UTC (rev 25767) > +++ contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Document.java 2009-12-12 15:02:21 UTC (rev 25768) > @@ -1,10 +1,12 @@ > package org.xwiki.model; > > +import org.xwiki.bridge.DocumentName; > +import org.xwiki.rendering.block.XDOM; > + > import java.util.List; > +import java.util.Locale; > > -import javax.jcr.Node; > - > -public interface Document extends Node > +public interface Document extends Persistable > { > /** > * @return the list of object definitions defined inside this document > @@ -14,6 +16,24 @@ > List<Object> getObjects(); > > List<Attachment> getAttachments(); > - > - String setContent(String content); > + > + void setParent(Document document); > + > + Document getParent(); > + > + // Note: In order to make modifications to the document's content, modify the returned XDOM > + // Default language > + XDOM getContent(); > + XDOM getContent(Locale locale); > + > + // get/setSyntax(Syntax syntax) > + > + // Q: Should we have this or should we force users to use a Parser for a given syntax, ie make Document > + // independent of the Syntax? Sounds nicer to only work with XDOM but what does it mean for the storage ? Is the way to store the document content (a string in some syntax, directly in the database with each block type having its own table, etc...) become an implementation details (good idea IMO) ? > + //String setContent(String content); > + > + boolean hasObject(String objectName); > + > + // Q: Is this ok? > + DocumentName getDocumentName(); > } > > Modified: contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Object.java > =================================================================== > --- contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Object.java 2009-12-11 17:03:01 UTC (rev 25767) > +++ contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Object.java 2009-12-12 15:02:21 UTC (rev 25768) > @@ -1,8 +1,6 @@ > package org.xwiki.model; > > -import javax.jcr.Node; > - > -public interface Object extends Node > +public interface Object extends Persistable > { > > } > > Modified: contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ObjectDefinition.java > =================================================================== > --- contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ObjectDefinition.java 2009-12-11 17:03:01 UTC (rev 25767) > +++ contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ObjectDefinition.java 2009-12-12 15:02:21 UTC (rev 25768) > @@ -1,8 +1,6 @@ > package org.xwiki.model; > > -import javax.jcr.Node; > - > -public interface ObjectDefinition extends Node > +public interface ObjectDefinition extends Persistable > { > > } > > Modified: contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ObjectDefinitionProperty.java > =================================================================== > --- contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ObjectDefinitionProperty.java 2009-12-11 17:03:01 UTC (rev 25767) > +++ contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ObjectDefinitionProperty.java 2009-12-12 15:02:21 UTC (rev 25768) > @@ -1,12 +1,6 @@ > package org.xwiki.model; > > -import javax.jcr.Node; > - > -/** > - * Note: we cannot map an Object Definition Property to a JCR property since it has several properties such as > - * validation script, edit sheet, etc. > - */ > -public interface ObjectDefinitionProperty extends Node > +public interface ObjectDefinitionProperty extends Persistable > { > > } > > Added: contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Persistable.java > =================================================================== > --- contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Persistable.java (rev 0) > +++ contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Persistable.java 2009-12-12 15:02:21 UTC (rev 25768) > @@ -0,0 +1,9 @@ > +package org.xwiki.model; > + > +public interface Persistable > +{ > + // Note: All the other methods don't save. Need to call save() to save. For ex this allows to add several docs > + // at once before saving them all at once. This allows for optimizations. > + // Q: Should we use a more generic API? Like pass a Map<String, String>? I don't think is really needed, we can always add support for a Map<String, String> latter. > + void save(String comment, boolean isMinorEdit); > +} > > Modified: contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Server.java > =================================================================== > --- contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Server.java 2009-12-11 17:03:01 UTC (rev 25767) > +++ contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Server.java 2009-12-12 15:02:21 UTC (rev 25768) > @@ -1,16 +1,14 @@ > package org.xwiki.model; > > +import org.xwiki.bridge.DocumentName; > + > import java.util.List; > > -import javax.jcr.Repository; > - > -import org.xwiki.model.Wiki; > - > /** > * An XWiki Server is made of one or several {@link org.xwiki.model.Wiki}s. This is the top most > * object of the XWiki Model. > */ > -public interface Server extends Repository > +public interface Server extends Persistable > { > /** > * @return the list of all wiki names inside this Server > @@ -24,4 +22,17 @@ > void addWiki(Wiki wiki); > > void removeWiki(String wikiName); > + > + boolean hasWiki(String wikiName); > + > + // Q: Should the methods below be moved into some other class, such as a DocumentQuery component which would > + // be less generic than using the Query Manager? Yes it's looks too much like a helper for something that should be in some generic query api to me. Or having something more generic, see at the end of the mail. > + > + // Q: Is this ok? > + Document getDocument(DocumentName documentName); > + > + // Should we also have getSpace(SpaceName spaceName)? > + > + // Q: Is this ok? > + boolean hasDocument(DocumentName documentName); > } > > Modified: contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Space.java > =================================================================== > --- contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Space.java 2009-12-11 17:03:01 UTC (rev 25767) > +++ contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Space.java 2009-12-12 15:02:21 UTC (rev 25768) > @@ -2,12 +2,11 @@ > > import java.util.List; > > -import javax.jcr.Node; > - > -public interface Space extends Node > +public interface Space extends Persistable > { > /** > * @return the space's description > + * @todo Should not be implemented with the old model > */ > String getDescription(); > > @@ -16,13 +15,38 @@ > */ > List<Space> getSpaces(); > > + /** > + * @param spaceName the name of the nested space to look for > + * @return the nested space whose name is passed as parameter > + */ > + Space getSpace(String spaceName); > + > + /** > + * @todo Should not be implemented with the old model > + */ > void addSpace(String spaceName); > - > + > + /** > + * @todo Should not be implemented with the old model > + */ > + Space createSpace(String spaceName); > + > + /** > + * @todo Should not be implemented with the old model > + */ > void removeSpace(String spaceName); > > + List<Document> getDocuments(); > + > + boolean hasSpace(String spaceName); > + > + boolean hasDocument(String shortDocumentName); > + > + Document getDocument(String shortDocumentName); > + > void addDocument(Document document); > > - void removeDocument(String documentName); > - > - Document createDocument(String documentName); > + void removeDocument(String shortDocumentName); > + > + Document createDocument(String shortDocumentName); > } > > Modified: contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Wiki.java > =================================================================== > --- contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Wiki.java 2009-12-11 17:03:01 UTC (rev 25767) > +++ contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Wiki.java 2009-12-12 15:02:21 UTC (rev 25768) > @@ -2,17 +2,17 @@ > > import java.util.List; > > -import javax.jcr.Workspace; > - > -import org.xwiki.model.Space; > - > -public interface Wiki extends Workspace > +public interface Wiki extends Persistable > { > /** > - * @return the list of all space names of this wiki including nested spaces > + * @return the list of all space names in this wiki including nested spaces > */ > List<String> getSpaceNames(); > > + /** > + * @param spaceName the name of the space > + * @return the object representing the space whose name is passed in parameter > + */ > Space getSpace(String spaceName); > > Space createSpace(String spaceName); > @@ -20,4 +20,6 @@ > void addSpace(Space space); > > void removeSpace(String spaceName); > + > + boolean hasSpace(String spaceName); > } > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications > Some quick comments about the model: * I think we should have something more generic that DocumentName that support anything from Wiki to objet or class property. Some WikiResourceName that target anything in XWiki and that you can use with the query api. Then we can provide different parser/serializer for WikiResourceName (URIParser/serializer used in REST, WikiSyntaxParser/Serialize commonly used in the document content as link/attachment/image reference, etc...). * Persistable should maybe also contains something like copy() or clone(), we generally know what we are copying but having in at Persistable make sure this is posible for anything in the model tree -- Thomas Mortagne

15 years, 9 months

2
4
0 0

[xwiki-devs] XWiki & MSSQL

by hel-o

If you notifiy me of DB-changes in new releases i will test & fix the mssql mapping if necessary. hel. ----- semantic-web.hel.at hel(a)hel.at -- View this message in context: http://n2.nabble.com/XWiki-MSSQL-tp4168841p4168841.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

15 years, 9 months

1
0
0 0

Re: [xwiki-devs] [VOTE] Rename xwiki-bridge in xwiki-model (NEW)

by Vincent Massol

Hi, New proposal: Create a new xwiki-model and move "clean" classes from xwiki-bridge into it. These are: - *AttachmentName* - *DocumentName* Here's my +1 Thanks -Vincent On Wed, Sep 2, 2009 at 1:12 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: > On Wed, Aug 26, 2009 at 18:00, Vincent Massol<vincent(a)massol.net> wrote: >> Hi, >> >> Since we have some final classes (final in the sense with a good >> architecture) in xwiki-bridge I'd like to rename it into xwiki-model >> so that we can start this model module. >> >> Note: We'd still have a org.xwiki.model.bridge package for the time >> being in that xwiki-model module. >> >> Here's my +1 > > I would prefer to create a new xwiki-model with only the clean apis > instead of having clean and bridge in the same project. > >> >> Thanks >> -Vincent

15 years, 9 months

9
21
0 0

Re: [xwiki-devs] [xwiki-notifications] r25793 - contrib/sandbox/xwiki-annotation-parent/xwiki-annotation-application/src/main/resources/Panels

by Jerome Velociter

On 12/14/09 6:38 PM, lucaa (SVN) wrote: > Author: lucaa > Date: 2009-12-14 18:38:53 +0100 (Mon, 14 Dec 2009) > New Revision: 25793 > > Modified: > contrib/sandbox/xwiki-annotation-parent/xwiki-annotation-application/src/main/resources/Panels/AnnotationManager.xml > Log: > Fixed js client to work in multiwiki mode. > > > Modified: contrib/sandbox/xwiki-annotation-parent/xwiki-annotation-application/src/main/resources/Panels/AnnotationManager.xml > =================================================================== > --- contrib/sandbox/xwiki-annotation-parent/xwiki-annotation-application/src/main/resources/Panels/AnnotationManager.xml 2009-12-14 17:27:26 UTC (rev 25792) > +++ contrib/sandbox/xwiki-annotation-parent/xwiki-annotation-application/src/main/resources/Panels/AnnotationManager.xml 2009-12-14 17:38:53 UTC (rev 25793) > @@ -12,8 +12,8 @@ > <customClass></customClass> > <contentAuthor>XWiki.Admin</contentAuthor> > <creationDate>1240502446000</creationDate> > -<date>1259676301000</date> > -<contentUpdateDate>1259676301000</contentUpdateDate> > +<date>1260811068000</date> > +<contentUpdateDate>1260811068000</contentUpdateDate> > <version>1.0</version> > <title></title> > <template></template> > @@ -277,6 +277,7 @@ > XWiki.Annotation.prototype = { > /* Utils */ > getDocumentInfos : function() { > + // TODO: get these from the XWiki object or meta tags > var space = ''; > var page = ''; > window.location.pathname.toString().scan(/\/[^\/]+/, function(match) { > @@ -295,6 +296,7 @@ > page = page.replace('/', ''); > return { > host : location.host, > + 'wiki' : XWiki.currentWiki, > 'space' : space, > 'page' : page > }; > @@ -463,11 +465,18 @@ > XWiki.Annotation.getInstance().updateAnnotationResumeAux(items); > return; > } > - var space = anno.author.split('.')[0]; > - var page = anno.author.split('.')[1]; > + var wiki = anno.author.split(':')[0]; > + var localAuthor = anno.author.split(':')[1]; > + // if there is no wiki in the username (user is already local), use XWiki.currentWiki for wiki and wiki for localAuthor > + if (!localAuthor) { > + localAuthor = wiki; > + wiki = XWiki.currentWiki; > + } > + var space = localAuthor.split('.')[0]; > + var page = localAuthor.split('.')[1]; > var url = 'http://' > + location.host > - + '/xwiki/rest/wikis/xwiki/spaces/' > + + '/xwiki/rest/wikis/' + wiki + '/spaces/' > + space > + '/pages/' > + page > @@ -537,7 +546,7 @@ > } > XWiki.Annotation.getInstance().annotatedDocumentFlag = 1; > var infos = XWiki.Annotation.getInstance().getDocumentInfos(); > - var url = 'http://' + infos.host + '/xwiki/rest/wikis/xwiki/spaces/' > + var url = 'http://' + infos.host + '/xwiki/rest/wikis/' + infos.wiki + '/spaces/' > + infos.space + '/pages/' + infos.page > + '/annotation?media=json'; > new Ajax.Request(url, { > @@ -549,7 +558,7 @@ > > removeAnnotation : function(id) { > var infos = XWiki.Annotation.getInstance().getDocumentInfos(); > - var url = 'http://' + infos.host + '/xwiki/rest/wikis/xwiki/spaces/' > + var url = 'http://' + infos.host + '/xwiki/rest/wikis/' + infos.wiki + '/spaces/' > To be on the safe side you should use XWiki.contextPath in place of "/xwiki". We really need to add some helper methods in the XWiki object, to create URLs... Jerome. > + infos.space + '/pages/' + infos.page + '/annotation/' + id > + '?method=DELETE&media=json'; > new Ajax.Request(url, { > @@ -561,7 +570,7 @@ > > addAnnotation : function() { > var infos = XWiki.Annotation.getInstance().getDocumentInfos(); > - var url = 'http://' + infos.host + '/xwiki/rest/wikis/xwiki/spaces/' > + var url = 'http://' + infos.host + '/xwiki/rest/wikis/' + infos.wiki + '/spaces/' > + infos.space + '/pages/' + infos.page > + '/annotation?method=PUT&media=json'; > new Ajax.Request(url, { > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications >

15 years, 9 months

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r25770 - contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model

by Vincent Massol

On Dec 13, 2009, at 9:11 AM, vmassol (SVN) wrote: > Author: vmassol > Date: 2009-12-13 09:11:05 +0100 (Sun, 13 Dec 2009) > New Revision: 25770 > > Modified: > contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ > Document.java > contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Space.java > Log: > Made the model more scaleable (ability to have lots of spaces, lots > of objects, lots of object definitions) > > Modified: contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ > Document.java > =================================================================== > --- contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ > Document.java 2009-12-12 15:37:00 UTC (rev 25769) > +++ contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ > Document.java 2009-12-13 08:11:05 UTC (rev 25770) > @@ -11,10 +11,14 @@ > /** > * @return the list of object definitions defined inside this > document > */ > - List<ObjectDefinition> getObjectDefinitions(); > + List<String> getObjectDefinitionNames(); > > - List<Object> getObjects(); > + ObjectDefinition getObjectDefinition(String > objectDefinitionName); > > + List<String> getObjectNames(); > + > + Object getObject(String objectName); > + Another solution would be to use iterators with this API: Iterator<Object> getObjects(); instead of List<String> getObjectNames(); Object getObject(String objectName); I think it could allow more fine-tuning on the requests we send to the DB (ie we can fetch elements N elements by N elements instead of 1 by 1). Thanks -Vincent > List<Attachment> getAttachments(); > > void setParent(Document document); > > Modified: contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ > Space.java > =================================================================== > --- contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ > Space.java 2009-12-12 15:37:00 UTC (rev 25769) > +++ contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ > Space.java 2009-12-13 08:11:05 UTC (rev 25770) > @@ -11,9 +11,9 @@ > String getDescription(); > > /** > - * @return the full list of all nested spaces > + * @return the names of all nested spaces > */ > - List<Space> getSpaces(); > + List<String> getSpaceNames(); > > /** > * @param spaceName the name of the nested space to look for > @@ -36,7 +36,7 @@ > */ > void removeSpace(String spaceName); > > - List<Document> getDocuments(); > + List<String> getDocumentNames(); > > boolean hasSpace(String spaceName);

15 years, 9 months

3
2
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