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

[xwiki-devs] parameters for embedded docs don't work...

by Pascal Voitot

Hello again, I write something like: (% style="somestyle" %) ((( my embedded wikipage ))) the style is not applied to the <div> surrounding the embedded wikipage. Is it normal or is it a bug? Pascal

16 years, 3 months

4
14
0 0

[xwiki-devs] A GWT space/page XWiki Selection tool

by Pascal Voitot

Hello all, I have developped a little XWiki selection tool because I needed it for own purpose. It provides a way to hook the xwikiexplorer provided within the Wysiwyg editor to an existing form and when you select a space and page, the result is put into the form. This is a standalone gwt client module with no server part based mainly on the wysiwyg code. It doesn't require the wysiwyg to compile (lots of code comes directly from wysiwyg but not all the code from wysiwyg was needed) It can be deployed outside XWiki and uses an existing XWiki instance in the same domain. It also provides a way to login/logout to the existing XWiki instance. I wondered whether it would be of any interest to someone... The idea is described here in details and there is a demo site it also... http://www.mandubian.org/magnoliaPublic/mandubian-org/opensource-playground… Don't hesitate to comment... this is a draft... regards Pascal

16 years, 3 months

3
3
0 0

[xwiki-devs] [PROPOSAL] Create a column macro

by Dan Miron

Hi, Regarding the http://jira.xwiki.org/jira/browse/XWIKI-2963 issue, this is how I propose the macro to look like: {{columnedtext}} {{column with="40%"}} My first text {{/column}} {{column with="60%"}} My second text {{/column}} {{/columnedtext}} This way, depending on how many {{column}} blocks it finds, the macro transformer has a complete overview over the text to be arranged in columns. What do you say? Tnx. Dan

16 years, 3 months

3
7
0 0

[xwiki-devs] [VOTE] Make ComponentManager a component

by Vincent Massol

Hi, I'd like to remove the usage of Composable and instead inject directly the ComponentManager. Implementation note: I'll create a component manager component wrapping ComponentManager (thus using Composable internally). Here's my +1 Thanks -Vincent

16 years, 3 months

8
8
0 0

[xwiki-devs] OfficeImporter interface enhancements: space & page input

by Asiri Rathnayake

Hi devs, I have been working on two small enhancements for officeimporter interface: 1. Use a drop-down list for target space input field. This list contains all existing spaces + an option to create a new space. 2. Suggest the target page name based on the input file name. To implement these two features I used bit of javascript which I embedded in the XWiki.OfficeImporter page (inside <script> tags). I didn't bother using JSX because this javascript fragment is really small. Is this ok? In the first feature, the user can select one of existing spaces. If he selects the [New Space] option, a javascript un-hides a text field into which the user can type in the new space name. Question; should I worry about browsers with javascript disabled? Any hints about how to handle such a scenario? :) The second feature calculates the target page name based on the input file name and updates the "Target page" text field. If the user does not like the auto-generated page name, he can adjust the value in "Target page" text field manually. For an example, if the input file name is "My Word Document.doc" the target page name will be "My Word Document". This calculation + update is also done in javascript. Please let me know what you think, I didn't commit these features because I am not sure if my approach is ok. Thanks. - Asiri

16 years, 4 months

3
7
0 0

[xwiki-devs] Sorry but I give up

by Andreas Schaefer

I tried for a few weeks to make XWiki work for me and even though it worked out well in the beginning I will not go into production with it. These are the issues I had to deal with it: 1) Renaming Pages and Spaces leave the wiki somewhat in limbo because the references are not working anymore. Copying around the pages seems to do the trick but I leaves a lingering bad feeling. For Example I can rename the Web Home of a Space but then the Space because empty (? at the end). I cannot rename the WebHome because the new Space already has that Document and then I need to manually copy each document one by one. 2) Upgrade to a new minor release is a nightmare. Even though the WAR file can be easily replaced and seems to work fine the upgrading of documents is a blind flight because there is no list that tells me what should be imported and not. XWiki should now which documents where edited and so should be able to give a hint if they were changes before importing them. I would also like a way to create a diff of the existing file and the one I like to import. 3) I cannot make XWiki work on JBoss without messing around with Classloader settings. This is a no-go because I cannot afford to make existing applications fail. 4) I cannot build the current XWiki code (from SVN) because the XWikiDocument in the Core is messed up. I also have no idea how I can get the code of an existing release (no docu). This means I cannot figure out if I try to fix the classloading. This is the compiler error: /Users/schaefa/Development/xwiki/trunks/core/xwiki-core/src/main/java/ com/xpn/xwiki/doc/XWikiDocument.java:[3273,15] cannot find symbol symbol : method getRenderedContent(java.lang.String,com.xpn.xwiki.XWikiContext) location: class com.xpn.xwiki.doc.XWikiDocument UPDATE: as of tonight I fail now building the WYSIWYG component (Mac OS X 10.5.7, JDK 1.6, Maven 2.0.10): INFO] ------------------------------------------------------------------------ [INFO] Building XWiki Platform - Web - WYSIWYG [INFO] task-segment: [package] [INFO] ------------------------------------------------------------------------ [INFO] [enforcer:enforce {execution: default}] [INFO] [remote-resources:process {execution: xwiki-license-resources}] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [dependency:unpack {execution: unzip-gwt-libs}] [INFO] Configured Artifact: com.google.gwt:gwt-dev:mac-libs:1.5.3:zip [INFO] gwt-dev-1.5.3-mac-libs.zip already unpacked. [INFO] [gwt:compile {execution: generate-javascript}] [INFO] establishing classpath list (buildClaspathList - scope = COMPILE) [INFO] google.webtoolkit.home (gwtHome) *not* set, using project POM for GWT dependencies Removing units with errors [ERROR] Errors in 'file:/Users/schaefa/Development/xwiki/trunks/ web/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/util/ Attachment.java' [ERROR] Line 27: No source code is available for type com.xpn.xwiki.gwt.api.client.Attachment; did you forget to inherit a required module? [ERROR] Errors in 'file:/Users/schaefa/Development/xwiki/trunks/ web/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/ WysiwygService.java' [ERROR] Line 136: No source code is available for type com.xpn.xwiki.gwt.api.client.XWikiGWTException; did you forget to inherit a required module? [ERROR] Errors in 'file:/Users/schaefa/Development/xwiki/trunks/ web/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/Wysiwyg.java' [ERROR] Line 49: No source code is available for type com.xpn.xwiki.gwt.api.client.app.XWikiGWTDefaultApp; did you forget to inherit a required module? [ERROR] Line 67: No source code is available for type com.xpn.xwiki.gwt.api.client.app.XWikiAsyncCallback; did you forget to inherit a required module? [ERROR] Errors in 'file:/Users/schaefa/Development/xwiki/trunks/ web/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/client/plugin/sync/ SyncPlugin.java' [ERROR] Line 438: No source code is available for type com.xpn.xwiki.gwt.api.client.dialog.MessageDialog; did you forget to inherit a required module? [ERROR] Line 438: No source code is available for type com.xpn.xwiki.gwt.api.client.dialog.Dialog; did you forget to inherit a required module? [ERROR] Line 452: No source code is available for type com.xpn.xwiki.gwt.api.client.XWikiGWTException; did you forget to inherit a required module? 4b) In the same direction I was not able to check out the source of my current released version. 5) Handling of images is cumbersome. If I have a lot of images to be added to a page like a walkthrough then uploading the images is a hercules task. I would expect that I could add x number of files or mark a number of file before hitting upload or delete. This works in the JSPWiki. I also saw that with JIRA I can add an image directly from the clipboard into the web page. I am not a Web Expert and so I don't know how difficult that is. 6) I tried to keep the images in one document and reference them in the pages containing the text. But I can only use get the reference in the WYSIWYG editor when the images are in the same page. I expect that I can at least list all the image names from the entire space or from another document. Sometimes I need to reuse the images or I want to reuse the page without having to reupload all the images. 7) The Trail is broken in my installation bringing up an error page even though the page is available. This is because I copied some pages around and the trail is now pointing to the old defunct space. 8) How can I delete a space 9) In case I want to clean up my somewhat messy wiki and only export a given Space so that I can recreate the Wiki and then import only that given Space. Currently it seems I can only export everything and then only select the space I want to be imported. I would prefer to do it the other way around. 10) I see really strange reaction from the system when a Space name (maybe even regular documents) contain a dot at the end. If that is an issue why is the application no displaying a warning or error when that happens (see my issue with the Trail). I think that is bugging me the most right now. I still like XWiki the most so far and would be disappointed if I could not use it. I also would be willing to help dealing with the JBoss classloading issue if I can get the build to compile. 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

16 years, 4 months

6
9
0 0

Re: [xwiki-devs] [xwiki-notifications] r20420 - in platform/core/trunk: xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/test/java/org/xwiki/rendering xwiki-shared-tests xwiki-shared-tests/src/main/java/org/xwiki/test

by Sergiu Dumitriu

vmassol (SVN) wrote: > Author: vmassol > Date: 2009-05-25 16:00:26 +0200 (Mon, 25 May 2009) > New Revision: 20420 > Modified: platform/core/trunk/xwiki-shared-tests/src/main/java/org/xwiki/test/AbstractXWikiComponentTestCase.java > =================================================================== > --- platform/core/trunk/xwiki-shared-tests/src/main/java/org/xwiki/test/AbstractXWikiComponentTestCase.java 2009-05-25 13:59:40 UTC (rev 20419) > +++ platform/core/trunk/xwiki-shared-tests/src/main/java/org/xwiki/test/AbstractXWikiComponentTestCase.java 2009-05-25 14:00:26 UTC (rev 20420) > @@ -16,7 +16,6 @@ > * 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.test; > > @@ -25,7 +24,7 @@ > > /** > * Tests which needs to have XWiki Components set up should extend this class which makes the Component Manager > - * available. > + * available. Use this class for JUnit 3.x tests. For Junit 4.x tests use {@link AbstractComponentTestCase What's this character? > � instead. > */ > public abstract class AbstractXWikiComponentTestCase extends MockObjectTestCase > { -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 4 months

1
0
0 0

[xwiki-devs] Building from source

by ms123

Hello When i building for example 1.8.4 then i checkout svn co http://svn.xwiki.org/svnroot/xwiki/platform/core/tags/xwiki-core-1.8.4/ core But what is the right tag for xwiki-tools,xwiki-plugins ... Thanks Manfred -- View this message in context: http://n2.nabble.com/Building-from-source-tp2970636p2970636.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

16 years, 4 months

2
7
0 0

[xwiki-devs] any xwiki code to fetch and filter a HTML document?

by Niels Mayer

Any suggestions on xwiki/velociy code/calls to use to 1. fetch a document by URL and create a DOM representation "in memory" (on the server). e.g. #set( $domstruct = $xwiki.pluginwanted.url2DOM("http://......") )## (i realize there's existing code that first turns it into a wiki document, which means storing it in the database). 2. search for a particular document section by id/name and/or tag e.g. #set( $domsubstruct = $xwiki.pluginwanted.findDOM($domstruct, "main-content", "<div>") )## 3. pass that DOM-subsection to an additional velocity call to output it as HTML for presentation on the client's web-browser: $xwiki.pluginwanted.outputDOM($domsubstruct) Also, has anybody developed a "thumbnail view" for xwiki documents? I guess I could just iframe an existing xwiki doc with xpage=plain and shrink/size it appropriately, ala http://www.dynamicdrive.com/forums/archive/index.php/t-2668.html . Niels http://nielsmayer.com

16 years, 4 months

1
0
0 0

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

by Jean-Vincent Drean

The XWiki development team is pleased to announce the release of XWiki Enterprise 1.9 Release Candidate 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download First release candidate of the XWiki Enterprise 1.9 version. Main changes: * The default syntax is now 'xwiki/2.0' which means that new documents will be created with this syntax. Note that XWiki Enterprise documents (user profile, recent changes, etc) are still using the "xwiki/1.0" syntax, they will be migrated during the 2.0 release cycle. * WYSIWYG Improvements ** Ability to insert level 6 headings ** Allow adding and editing lists in table cells ** Allow adding complex content inside list items * Important Bugs fixed ** Many WYSIWYG bugs fixed ** Many 2.0 syntax bugs fixed ** Many 1.0 to 2.0 conversion bugs fixed For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise19RC1 Note that general goals for XWiki Enterprise 1.9 are: * Finish/stabilize/document new rendering * Finish/stabilize/document new wysiwyg editor * Finish/stabilize/document office importer + doc splitter/management * Finish/stabilize/document webdav * Finish/stabilize/document REST support * Usability improvements Thanks, The XWiki dev team

16 years, 4 months

2
1
0 0

[xwiki-devs] [VOTE] Switch to using the Embedded Container Manager for our tests

by Vincent Massol

Hi, I'd like to switch to using the Embedded Container Manager for our tests. The main reason is that I want to introduce the ability to register dynamic mocks from our tests rather having to create static stubs (the MockDocumentAccessBridge classes and co). Note that our functional tests would still use plexus as the CM thus ensuring that Plexus is correctly initialized. Here's my +1 Thanks -Vincent

16 years, 4 months

4
4
0 0

[xwiki-devs] [VOTE] Allow sandbox access for the GSoC students

by Sergiu Dumitriu

Hi devs, Since, in the GSoC timeline, the coding period starts soon (Saturday), I'd like to propose to grant commit rights to the sandbox to the following students: - Alexandru Cismaru - Anamaria Stoica - Arun Reddy - Chathura Prabuddha - Cristina Scheau - Teofil Achirei - Tharindu Madushanka - Venkatesh Nandakumar -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 4 months

7
7
0 0

Re: [xwiki-devs] [xwiki-notifications] r20329 - in platform/core/trunk/xwiki-rendering/xwiki-rendering-xwiki/src/main: java/org/xwiki/rendering/internal/renderer resources resources/META-INF

by Sergiu Dumitriu

vmassol (SVN) wrote: > Author: vmassol > Date: 2009-05-23 17:08:55 +0200 (Sat, 23 May 2009) > New Revision: 20329 > > Added: > platform/core/trunk/xwiki-rendering/xwiki-rendering-xwiki/src/main/java/org/xwiki/rendering/internal/renderer/XWikiLinkLabelGenerator.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-xwiki/src/main/resources/META-INF/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-xwiki/src/main/resources/META-INF/component-overrides.txt > Log: > XWIKI-3892: Make XWiki Rendering usable standalone as a library independent of XWiki Core/XWiki Enterprise > > * Added leftovers > > Added: platform/core/trunk/xwiki-rendering/xwiki-rendering-xwiki/src/main/java/org/xwiki/rendering/internal/renderer/XWikiLinkLabelGenerator.java > =================================================================== Missing svn:keywords > + * @version $Id: DefaultLinkLabelGenerator.java 19713 2009-05-11 21:36:01Z sdumitriu $ Wrong @since > + * @since 1.6M1 -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 4 months

2
3
0 0

[xwiki-devs] Setting up a annotation prototype enabled wiki

by lucien.pereira＠xwiki.com

Hi all, Since annotation prototype seems to be stable enough, I'm proposing you to add it to myxwiki.org in order to test it and to get feed back about bugs and UI improvements. *Annotation location retrieval system* We chose to use a typographic alteration system in order to map a selection from html document to the xwiki source which had generated it. So, each non alphanumeric character is deleted whereas others becomes uppercase. After matching the altered selection in the altered source, we are enable to deduce real ''offsets'' from ''altered'' offsets (having previously filled a hash map). *Rendering* In order to produce an annotated html code we inject in the document xwiki source marks and render it. Then we replace marks by span markups. In order to avoid ''tag crossing'' (<c><d></c></d>) annotation zone can be splited in several span tags. *Architecture and Installation* This feature implementation can be divided in three modules : http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-plugin-annotation/ This plugin provide the logic side of the feature: - determining annotation location - adding annotation to the document - rendering and injection of span it require a standard plugin installation process. http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-rest-annotation/ This module provide a rest interface in order to communication with plugin. Communication is done using this rest resource : http://{host}/xwiki/rest/wikis/xwiki/spaces/{space}/pages{page}/annotation A GET request returns generated and annotated html and the set of annotations in the page. A PUT request aims to add an annotation to resource. To install it, web.xml must be modified:  <servlet> <servlet-name>RestletServlet</servlet-name> <servlet-class> org.xwiki.rest.XWikiRestletServlet </servlet-class> <init-param> <param-name>resources</param-name> <param-value> ... com.xpn.xwiki.rest.annotation.AnnotationService; </param-value> </init-param> ... http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-application-annotation/ This is the client side of the feature, it use rest interface in order to request an annotation, retrieve html annotated content and put in the DOM. it's a xar package which must be imported. *Prototype usage* Just select a non dynamique data in page content, an annotation edition box should appear, fill it and validate. To display annotation just click on Annotations > Show annotations menu item. Lucien Pereira.

16 years, 4 months

5
10
0 0

[xwiki-devs] [ANN] XWiki Enterprise 1.8.4 and XWiki Enterprise Manager 1.6.4 Released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise 1.8.4 and XWiki Enterprise Manager 1.6.4. This release contains 55 bugfixes and enhancements. Most of the modifications are targeting the general replacement of old 1.0 code and content by 2.0 syntax and architecture and the stabilization of XWiki. Summary of changes since XWiki Enterprise 1.8.3 : * Many WYSIWYG bugs fixed and improvements * Many 2.0 syntax bugs fixed * Many 1.0 to 2.0 conversion bugs fixed * Several PDF export bugs fixed and improvements * Improvements for the Office Importer * A few bug fixes in many other places For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise184 and http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM164 Thanks -The XWiki dev team

16 years, 4 months

5
4
0 0

[xwiki-devs] [Ideas/Proposal] Thoughts on the Wiki Import feature for GSOC

by Vincent Massol

Hi (Arun), I've thought a bit and here are some ideas: 1) Have a xwiki-importer module in platform/core/ Note that later on we could move the XAR importer as a submodule in there too. This module will contain all the java code to perform input parsing + import into wiki pages. 2) Have a xwiki-importer application in platform/applications/ This application would provide an "Import" icon in the Admin page. When you click on that icon you would get to a second page with several icons: - Import Application (that's the current XAR import) - Import from Confluence - Import from Mediawiki ... 3) Each "Import from ..." will have its own UI since the import methods differ from wiki to wiki Arun, you need to look at all wikis for which we want to offer an importer for (MediaWiki and Confluence to start with) and see what options they offer: - could be an export in the form of XML files in a zip - could be accessing them through a REST/XMLRPC/other api online For a first version I think we should offer only 1 way of importing and I'd suggest the zip containing XML if that's supported by the wiki. 4) (this is a second step) Write Link parsers for the different wiki syntaxes (since right now we only have XWiki 2.0 link parser). We'll need 1 for mediawiki and 1 for confluence. 5) (this is a third step) Deal with macros. For example confluence offers lots of macros which when imported will not work. We can convert them to XWiki macros that do something similar. We'll need to identify simple macros that we don't have to add them. Of course for macros that we don't have, they wouldn't be converted. 6) We need a Roadmap/planning * Do this in the sandbox for now * Prepare a planning with milestones. * Each milestone shouldn't be longer than 2 weeks. * Make sure you don't slip dates * Always have something that work. This means that after the first milestone you *MUST* have something that can be demonstrated and that is working (even if it's not doing much) * Corollary: always start by doing the integration work first so that you can have a working chain. More specifically, after your first milestone, I should be able to drop the xwiki-import JAR in my xwiki's WEB-INF/lib + import the xwiki- import XAR and be able to click on "Import from Mediawiki" and be able to have the pages imported in xwiki 2.0 syntax (no options for the first version). The first milestone could be 3 weeks since you need to set up the plumbery. Let me know what you think. All: let us know also what you think about this. Guillaume: Let us know if you're ok with the UI ideas above. Thanks -Vincent

16 years, 4 months

2
3
0 0

[xwiki-devs] XE 1.9 RC1 postponed to Monday 25

by Vincent Massol

Hi, Since it's a bank holiday tomorrow and our release manager is on holidays till Sunday night we're postponing the 1.9RC1 release to next Monday. This means committers can still commit non risky *bug fixes* on the 1.9 branch for the coming few days and thus progress on the work that needs to be done for 1.9RC2. 1.9RC2 release date is maintained to 1st of June. Note that 1.9RC2 == 1.9 final. Thanks -Vincent

16 years, 4 months

1
0
0 0

[xwiki-devs] [VOTE] Enable XWiki syntax 2.0 by default in 1.9 final

by Vincent Massol

Hi, I'd like to propose that we enable by default the 2.0 syntax in 1.9 final (i.e do this in RC2). Here's my +1 Thanks -Vincent

16 years, 4 months

10
11
0 0

[xwiki-devs] [Proposal] Choosing a new format for serializing a document's name

by Vincent Massol

Hi, We need to choose a new format for serializing a document name for several reasons: - the current format is ambiguous and doesn't allow too many characters to be entered - it doesn't support nested spaces I'd like to propose the following format: a URL. <wiki>://<space1>/<space2>/.../<spaceN>/<page>?<params>#anchor Examples: * Page * Space/Page * mywiki://Space/Page * mywiki://some/nested/Space/Page * Page?param=value * Page#anchor + the ability to escape chars. For example if the user wants to have the "/" char in a page name he would have: Special~/Page (we can decide what escape char to use) Of course, it'll be the role of the serializer to escape chars as required. Pros of using a URL format: * easy to code since we can reuse the JDK's URL class * URL friendly. It's easy to copy paste the URL of a document into a link. No more needing to translate "." into "/" * it's JCR friendly since JCR also uses "/" for the path to a Node * it's a well known format and users are used to it WDYT? Thanks -Vincent

16 years, 4 months

4
4
0 0

[xwiki-devs] XWikiAllGroup implicit behavior

by Ludovic Dubost

Hi, As part of the Curriki development, since Curriki is growing big (more than 60000 users), the XWiki.XWikiAllGroup is not scalable and this can lead to bad things. I've proposed a patch to make XWiki.XWikiAllGroup implicit. We have tested it and this seems to work well (see http://jira.xwiki.org/jira/browse/CURRIKI-738 for the patch). The only issue I see is the fact that once you have activated this, the counter of number of users for the group all group in the administration and the ability to edit the group makes no sense. Finally the adding the the AllGroup in registration has not yet been deactivated which would be necessary to make the registration not be impacted by the number of users. The Curriki team would like to see this patch make it in the XWiki Core. WDYT ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

16 years, 4 months

5
4
0 0

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

by Vincent Massol

On May 19, 2009, at 7:52 PM, fmancinelli (SVN) wrote: > Author: fmancinelli > Date: 2009-05-19 19:52:09 +0200 (Tue, 19 May 2009) > New Revision: 20119 > > Modified: > platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/ > ComponentsObjectFactory.java > Log: > [Minor] Use component descriptors in order to check whether a > component has a PER_LOOKUP instantiation strategy. > > Modified: platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/ > rest/ComponentsObjectFactory.java > =================================================================== > --- platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/ > ComponentsObjectFactory.java 2009-05-19 17:47:18 UTC (rev 20118) > +++ platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/ > ComponentsObjectFactory.java 2009-05-19 17:52:09 UTC (rev 20119) > @@ -25,6 +25,7 @@ > import org.restlet.ext.jaxrs.InstantiateException; > import org.restlet.ext.jaxrs.ObjectFactory; > import org.xwiki.component.annotation.InstantiationStrategy; > +import org.xwiki.component.descriptor.ComponentDescriptor; > import org.xwiki.component.descriptor.ComponentInstantiationStrategy; > import org.xwiki.component.manager.ComponentLookupException; > import org.xwiki.component.manager.ComponentManager; > @@ -65,6 +66,8 @@ > XWikiRestComponent component = > (XWikiRestComponent) > componentManager.lookup(XWikiRestComponent.class, clazz.getName()); > > + ComponentDescriptor componentDescriptor = > componentManager.getComponentDescriptor(XWikiRestComponent.class, > clazz.getName()); > + > /* > * Retrieve the releasable component list from the > context. This is used to store component instances that > * need to be released later. > @@ -79,11 +82,8 @@ > } > > /* Only add components that have a per-lookup > instantiation stategy. */ > - InstantiationStrategy is = > component.getClass().getAnnotation(InstantiationStrategy.class); > - if (is != null) { > - if > (is.value().equals(ComponentInstantiationStrategy.PER_LOOKUP)) { > - releasableComponentReferences.add(component); > - } > + > if > (componentDescriptor > .getInstantiationStrategy > ().equals(ComponentInstantiationStrategy.PER_LOOKUP)) { you could write: if (componentDescriptor.getInstantiationStrategy() == ComponentInstantiationStrategy.PER_LOOKUP) -Vincent > > + releasableComponentReferences.add(component); > } > > /*

16 years, 4 months

2
1
0 0

[xwiki-devs] [Discussion] Officeimporter remote OpenOffice server

by Asiri Rathnayake

Hi Devs, Currently OfficeImporter requires an OpenOffice server to be present in the same computer as XE. I have been searching about adding support for a remote OpenOffice server but the results are not very promising: http://groups.google.com/group/jodconverter/browse_thread/thread/f4f0e8328d… Even though this is the case, I think we can settle on a compromise with the following approach: * We develop a stand-alone servlet (probably under xwiki-tools just like the root-web-app) * The purpose of this servlet is to: 1. Accept incoming office documents 2. Convert them into html (results in multiple files) 3. Zip the results together 4. Stream the zipped content back to the client * And the client would be any xwiki instance that is configured to consume this converter-servlet. This way, multiple XWiki instances would be able to share a central OpenOffice server via the converter-servlet. The downside of this approach is that there has to be a servlet container on the remote computer which is hosting the OpenOffice server. Please let me know what you think about this idea. Thanks. - Asiri

16 years, 4 months

2
2
0 0

[xwiki-devs] [VOTE] What do we do about Object.get() Document.get() "api change"

by Thomas Mortagne

Hi devs, For 2.0 syntax we make XWikiDocument.display() enclose the result in {{html}}{{/html}} since it's supposed to generate html and that we should not have to use {{html}}{{/html}} in the syntax when we call $doc.display("somefield"). Now the issue is that public api Object and Document get() methods does not return the value but call display. But users (and us) used to access string value using $object.somefield instead of $object.getProperty("somefield").getValue() which is the correct form to access an object field value. Because of this wrong use of display() we have a big change in the api form user point so the question is what do we do ? I can see the following solution: 1) it's not a real change in the API, user should use the right way. It's ok like that. 2) we "optimize" XWikiDocument.display() by generating {{html}}{{/html}} only when it's necessary (if the result really is html) 2.a) if it contains "<" or ">" 2.b) when it's not a BaseStringProperty/NumberProperty/DateProperty since theses properties does not really need to produce HTML 3) we clean the display result in Object/Document.get by removing the {{html}}{{/html}} when the result does not really contains html (more or less the same way to find it than 2)) WDYT ? I'm +1 for 2.a) (I don't like b, i think the generic way is better) since i don't think we can "change" the API even if it's not a real change and this solution is not that much a hack, it makes display() return cleaner anyway. 3) as the advantage of fixing only the problematic API but it's really too crappy IMO

16 years, 4 months

5
8
0 0

[xwiki-devs] [VOTE] Start migrating our XE XAR to 2.0 syntax for 1.9 final

by Vincent Massol

Hi, Following the mail vote for enabling the 2.0 syntax in 1.9 final we need to decide on our strategy for the XE XAR. I propose that we only support 1 XAR (since I don't think we have the manpower to support 2) and that this XAR is in 2.0 syntax. For 1.9 we would only convert a few pages (listed in http://jira.xwiki.org/jira/browse/XWIKI-3605) and in 2.0 we will continue till we have a full 2.0 syntax XAR. We would also add a warning in the release notes for 1.9 listing the pages that have been converted to 2.0 syntax. Here's my +1 Thanks -Vincent

16 years, 4 months

8
7
0 0

[xwiki-devs] [ANN] XWiki Office 1.0 Milestone 3 released!

by Florin Ciubotaru

The XWiki development team is pleased to announce the release of XWiki Office 1.0 Milestone 3. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiOffice !** XWiki Office is a XWiki.org project that provides integration between Microsoft Office and XWiki servers. For more information about XOffice go at: - http://xoffice.xwiki.org/xwiki/bin/view/Main/ Main changes from version 1.0 Milestone 2: - Basic XML-RPC support - Opening, editing & publishing pages(XHTML content only) - Downloading, opening, editing & uploading attachments - Viewing the wiki in the Wiki Explorer - Support for multiple encodings - Improved wiki explorer - Inhibited unnecessary Word messages & dialogs - Better sync between Word instances - Better & cleaner output All active XWord M2 clients and snapshot instances will be automatically updated to the latest version. For details about this release see the Release Notes at: - http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXOffice10M3 You can also view the roadmap here: - http://xoffice.xwiki.org/xwiki/bin/view/Main/Roadmap#HVersion10Milestone3 Thanks -The XWiki dev team

16 years, 4 months

1
0
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