April 2009 - xwiki-devs@xwiki.org

[xwiki-devs] [GSoC2009] eBay and Apache Shindig for OpenSocial
by Anamaria Stoica 09 Apr '09

09 Apr '09

eBay's new Selling Manager (beta) <http://developer.ebay.com/web20> uses Apache Shindig to integrate OpenSocial !! :) http://google-code-updates.blogspot.com/2009/04/ebays-farhang-kassaei-annou… Anamaria

1 0

[xwiki-devs] [VOTE] Introduce DocumentAccessBridge::setProperty() method
by Asiri Rathnayake 09 Apr '09

09 Apr '09

Hi devs, I need to add some tags into a document via officeimporter. For this I need to have above method implemented in DocumentAccessBridge. The most generic method signature would be: void setProperty(String documentName, String className, int objectNumber, String propertyName, Object value) throws Exception; But for my use case following would be enogh: void setProperty(String documentName, String className, String propertyName, Object value) throws Exception; I'm currently +1 for second signature. WDYT? Note: this method has been implemented in issue: http://jira.xwiki.org/jira/browse/XWIKI-2831 but this patch seems to have lot more other (unnecessary) methods. Thanks. - Asiri

2 2

Re: [xwiki-devs] [xwiki-notifications] r18354 - in platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest: . resources/attachments
by Sergiu Dumitriu 08 Apr '09

08 Apr '09

fmancinelli (SVN) wrote: > Author: fmancinelli > Date: 2009-04-08 23:58:20 +0200 (Wed, 08 Apr 2009) > New Revision: 18354 > > Modified: > platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/XWikiAuthentication.java > platform/core/trunk/xwiki-rest/src/main/java/org/xwiki/rest/resources/attachments/AttachmentsResource.java > Log: > XWIKI-3542: Allow attachment upload in REST API using multipart form data > + @POST > + @Consumes(MediaType.MULTIPART_FORM_DATA) > + public Response addAttachment(@PathParam("wikiName") String wikiName, @PathParam("spaceName") String spaceName, > + @PathParam("pageName") String pageName, Multipart multipart) throws MessagingException, IOException, > + XWikiException > + { Fabio, could you change this to support uploading several files in a single request? This would be very useful. -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

Re: [xwiki-devs] [xwiki-notifications] r18222 - in platform/core/trunk/xwiki-xml/src: main/java/org/xwiki/xml/internal/html/filter test/java/org/xwiki/xml/internal/html
by Sergiu Dumitriu 08 Apr '09

08 Apr '09

asiri (SVN) wrote: > Author: asiri > Date: 2009-04-03 10:43:01 +0200 (Fri, 03 Apr 2009) > New Revision: 18222 > > Modified: > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/html/filter/FontFilter.java > platform/core/trunk/xwiki-xml/src/test/java/org/xwiki/xml/internal/html/DefaultHTMLCleanerTest.java > Log: > XWIKI-3494: Font tag is not cleaned properly. > > * Fixed. > + public FontFilter() > + { > + fontSizeMap = new HashMap<String, String>(); > + fontSizeMap.put("1", "8"); > + fontSizeMap.put("2", "10"); > + fontSizeMap.put("3", "12"); > + fontSizeMap.put("4", "14"); > + fontSizeMap.put("5", "18"); > + fontSizeMap.put("6", "24"); > + fontSizeMap.put("7", "36"); > + } Asiri, using pt as font sizes is not good, because it will not fit well with custom skins. It is better to use relative font sizes, using either em or %, like: font size=1 => font-size: 0.6em; or: font-size: 60%; This way, fonts will be made larger or smaller compared to the current skin's normal font size. -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 1

[xwiki-devs] Thoughts about the attachment and image insert
by Ludovic Dubost 08 Apr '09

08 Apr '09

I'm having some thoughts about the attachments and image insert. I just tested the current work on attachment link insert. The more I think about it, the more I believe that images and attachments should be mainly attached to the CURRENT page. It is a nice to have to be able to use images or attachments for other pages (and even less upload to another page). However, when I look at the superbe tree UI, I have the feeling it will actually get in the way of the main usage, which is having the file attached to the current page. Therefore I believe we should have 2 different UIs. One simple and one advanced. The simple one would only manager files or images attached to the current page. The advanced would be the tree one. I understand this is more work, but if you ask me, if we should do only one, then it should be the one with file or images in the current page. WDYT ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

5 8

Re: [xwiki-devs] [xwiki-notifications] r18319 - platform/web/trunk/standard/src/main/webapp/templates
by Sergiu Dumitriu 08 Apr '09

08 Apr '09

vmassol (SVN) wrote: > Author: vmassol Look closely: > <div class="floatinginfobox"> > + ## We use an empty legend since the XHTML 1.0 strict XSD forces a legend to exist. > + <legend></legend> -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

[xwiki-devs] about lucene plugin
by Paul Libbrecht 08 Apr '09

08 Apr '09

Hello XWiki devs, I've been playing a bit to adapt the xwiki lucene plugin, actually the curriki lucene plugin which is very similar, to the tastes of Intergeo. One thing that surprised me is that most of the fields in the lucene plugin are stored fields. This sounds like a big overkill when you think that all the values of the fields of a document are loaded when you have this document as match. Not surprisingly, the curriki search result was almost only using fullname, using lucene directly is somewhat faster, I think it's good practice. Could this be configurable? (i.e. the names of the fields that are stored) One powerful way to make it configurable would to migrate to solr which bases on lucene but uses a schema that describes well type of the fields. Three other pluggeabilities I would wish: - the search-result class really would wish to be subclassable, the configuration could define a search-result-factory or something such which would help (a lot) as a cursor exploiting the hits list - I deem it very important to also have query expansion but maybe that can be inside the rest of the application - what is indexed how should also be subclasses (a pluggeable factory for ObjectData?) Finally, I wanted to use different analyzers per language, using the Snowball family of analyzers so that stemming really does happen. I kind of have it now but I would like to test it in unit tests and, well... how can I do that? Is there a way to get a "unit-test xwiki environment" (context, xwiki) where my unit tests would create a few documents then query them? Is there active work on this plugin? Which patch is most interesting for the others? paul

3 4

[xwiki-devs] Designing Refactoring module
by Asiri Rathnayake 07 Apr '09

07 Apr '09

Hi Devs, I have committed the initial xwiki-refactoring module which has support for splitting a document into multiple documents. The design of the DocumentSplitter component is somewhat like http://i39.tinypic.com/28k24w4.png (there are few minor changes). Anyway, we need to think of a proper desgin for the Refactoring module that will allow us to extend this module in future. I can see two approaches for this desgin: 1. We implement each refactoring operation as a single component - like currently it is done with DocumentSplitter. But this might not be a good idea because the refactoring module itself will not provide a well-defined API to users (it will be scattered into multiple component interfaces). 2. We define a single Refactoring plexus component interface that will include all the currently suppported refactoring operations (like a facade) - this way we have a high-level refactoring interface that can be easliy understood and used by users. I think the 2 approach is more usable than the first one. WDYT? may be there is a third approach? Thanks. - Asiri

4 8

[xwiki-devs] [VOTE] OSS Product Manager Role : Guillaume Lerouge
by Vincent Massol 07 Apr '09

07 Apr '09

Hi devs, Most of you already know Guillaume Lerouge since he's been active on these lists. Guillaume is interested and willing to act as our first OSS Product Manager. This is not a role that exists in many OSS projects. Actually I've never encountered it before but I can see value in it and I think we should recognize this role in the same manner that we recognize the role of Committer. See some rationale here: http://www.productbeautiful.com/2008/05/02/why-product-management-is-open-s… So I see Guillaume's role as: * Monitoring the lists for users requests/needs * Talking to people who implement XWiki out there in the wild, in companies and see what their needs are * Monitoring the enterprise wiki landscape for new features we should have * Comparing XWiki with other wiki engines out there Guillaume should provide us devs with visibility on the most wanted features and help us prepare our roadmaps. Regarding votes I propose that we has the same binding votes as Committers (obviously since Guillaume is not technical he probably won't vote on tech matters). Example of domain where he could vote on: UI decisions. This is what Guillaume has already started doing for some time but we've never really voted him in this role so I propose to fix this now and make this role official. Here's my +1 Thanks -Vincent PS: This doesn't mean that any of us shouldn't do this too. Quite the opposite. It just means that Guillaume is willing to spend a lot of his time working on this. PPS: Disclaimer: Guillaume is working for XWiki SAS. For more details on the XWiki project and XWiki SAS see http://massol.myxwiki.org/xwiki/bin/view/Blog/XWikiSASAndOpenSource

7 7

[xwiki-devs] [PROPOSAL] Integrate OfficeImporter document splitting into main source tree
by Asiri Rathnayake 07 Apr '09

07 Apr '09

Hi devs, I have completed implementing office importer document splitting functionality and I would like to commit this code in trunk. However the functionality of splitting a xwiki document into many sub documents does not belong to the officeimporter module. Rather it belongs to the more generic topic of refactoring existing wiki documents. There for, I propose to introduce a new core module: xwiki-core-refactoring and include the document splitting code into this module rather than having splitting code within the officeimporter code base. This will allow us to extend the refactoring module in future to include following possibilities: - Split an exiting document into multiple documents (first refactoring) - Merge documents to form a single document - Rename documents - Rename attachments - Replace words - More... Here's my +1 for introducing the xwiki-core-refactoring module and comitting document splitting code in it. Thanks. - Asiri

7 6