November 2009 - xwiki-devs@xwiki.org

[xwiki-devs] OfficeImporter API changes - Take 2
by Asiri Rathnayake 18 Dec '09

18 Dec '09

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

5 8

[xwiki-devs] [Proposal] Wiki macros improvement ideas
by Vincent Massol 09 Dec '09

09 Dec '09

Hi, Wiki macros currently require programming rights and thus are limited and in addition cannot be created in subwikis by the majority of users. Since I've now almost finished implementing component isolation I'd like to agree on what we want for wiki macros. Proposal: * Modify the wiki macro class to add a "Visibility" field with 2 values: - visible only in the current wiki - visible to everyone * Visible to everyone will require admin rights * Make the macro available to a user only if that user has view rights to the wiki macro page. This is to allow making a wiki macro private (when testing for example). It also allows making a macro visible only to a given group of users. Note: I considered having a "visible only to the current user" value for the Visibility field but I don't think it means much since if someone else edit the page and saves it, then suddenly the macro becomes visible only to that person... WDYT? Thanks -Vincent

2 5

[xwiki-devs] Dodo and Finch skins location?
by Vincent Massol 02 Dec '09

02 Dec '09

Hi, What should we do with the Dodo and Finch skins? Right now they sit in the platform as any other skin. However they're not in a working state. I've just tried Finch and the home doesn't display nicely in it. We have 2 options I can think of: 1) we leave old/non-working modules in platform (as they are now) 2) we move them to a retired location. In this case we could move them to the contrib repo in retired/. This leaves the door open to anyone interested to resurrect them (even if it's a bit hidden, but we could make that more visible). The only small issue (maybe it's not one) is that name "contrib". Another option would be to create an "attic" top level project for retried projects. I can also think of some plugins that could go there (alexa, adwords, etc) - We'd need to verify that they don't work since otherwise they probably don't need to be moved. We could also define a rule to move stuff to the attic: - the feature is not working anymore - there's been no commit for one year Obviously anyone interested in reviving the retired code could do so and move it back to the platform at any time. Any idea on this? Thanks -Vincent

5 7

[xwiki-devs] What does "import translation file" mean? It doesn't work.
by Zhaolin Feng 02 Dec '09

02 Dec '09

I'm trying to translate the XE Simplified Chinese but have a question. On this page: http://l10n.xwiki.org/xwiki/bin/view/XE/XWikiCoreResources, there is a link "Import/reimport default language file". And after each specific language, there is also an "import" link. What it means? I guess it will pull the resource file from the svn trunk, extract all (variable names, English text) pairs, so that someone can start providing more translations. I'm I right? But the import functionality seems broken. When I click "confirm import" it says, "Error number 4001 in 4: Error while parsing velocity page XE.XWikiCoreResources Wrapped Exception: Failed to evaluate content with id XWiki Core Resources" -- -- Currahee! We stand alone together!

2 3

[xwiki-devs] XOO
by Cristina Scheau 01 Dec '09

01 Dec '09

Hi all! How are you? I apologize that I wasn't so active recently. I spent all my time with tasks from my job and my Master. Now I have a little bit more free time (in the evenings and weekends) and I would like to continue the XOO project. I'm not clear what should I exactly do next and maybe you can help me with your feedback and ideas. I'd really like to contribute again to the XWiki software . Although I was not so happy with the API from OpenOffice, last summer was a really interesting experience for me. Thank you, Cristina S.

2 1

[xwiki-devs] [Discussion] Annotations improvements (wider annotations target) and roadmap update
by Anca Luca 30 Nov '09

30 Nov '09

Hi devs, following a discussion with Fabio about the second desired feature for the annotations, namely the ability to add annotations on any document, no matter how its content is generated, we came up with the solution described at http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature#HSolution1stor… , the main idea being that annotations would be defined by their selected text and a context (as opposed to offsets) and would be identified to be rendered in a document on a serialization of the transformed XDOM of the document, this way taking into account any macro rendering, document inclusion, etc. WDYT about this solution? Also, because the implementation of this, though relatively localized, comes together with refactor and cleanup of the annotations module (update everything so that annotations don't store and use offsets anymore, remove classes & functions which are not needed in this simplified process), I propose to include this improvement in version 1.0 of the annotations module (so that we don't cleanup and release what we know for sure we'll delete) and push the 1.0 version further to mid to end December. here's my +1 for this, WDYT? Happy coding, Anca

7 16

[xwiki-devs] [WCAG][CSS] opacity exception
by Ecaterina Valica 30 Nov '09

30 Nov '09

Hi, One of the WCAG requirements is to have all our CSS Level 2.1 valid. I saw we have exceptions on the elements we cover in our validation and I would like to know your opinion about: *opacity* CSS propriety. *Opacity* is a CSS 3 valid property, but not a CSS 2.1. The main components (that I know) that can be affected by not having * opacity* are: modalPopup.css (for Ctrl+G "Go To" feature) and lightbox.css (for the boxes in Administation: Users, Groups). Without *opacity* they look disconnected from XWiki. *Opacity* used to be used in Panel Wizard, but got removed because of the WCAG and because it didn't changed much on an aspect level. It can be used in lots of places like tooltips, use to be in WYSIWYG disabled buttons etc. The main problem about *opacity* is that if we are gonna make it an exception, because of IE6, we are gonna need to make other proprieties exceptions (*filter, zoom*). IE’s CSS uses *filter* instead of *opacity* and also needs (for some elements) *zoom* propriety in order to apply it correctly. I need to know your opinion in order to complete our CSS files validation. Thanks, Caty

3 2

[xwiki-devs] [VOTE] Move xwiki-plexus to the contrib repository
by Vincent Massol 30 Nov '09

30 Nov '09

Hi, I'd like to move the xwiki-plexus module to the contrib repository. The rationale is: - plexus is going EOL (Jason Van Zyl has clearly mentioned it was dead and he's favoring Guice) - in the future we're interested in moving towards Guice/OSGi - it's too much effort to maintain several implementations in the core development branch - with the component isolation refactoring I'm doing I'd need to implement that for Plexus which isn't trivial and I'd rather not spend time on it - if users are interested in using XWiki with Plexus they'd be able to use that contrib module to get started Here's my +1 Thanks -Vincent

6 5

[xwiki-devs] [VOTE] New committer Caleb James DeLisle
by Vincent Massol 30 Nov '09

30 Nov '09

Hi committers, I'd like to propose a new committer on XWiki core: Caleb. - Caleb has been regularly posting good patches in JIRA. - He's also been courageous enough to tackle complex issues (changing core stuff is always complex ;)). - Even though Caleb has been active only since August 2009, the quality of his work justifies that we make him a committer. - Caleb has the right attitude: asking on the list, respectful Some stats: - Mails sent by Caleb (36): http://xwiki.markmail.org/search/?q=from%3ACaleb - Patches from Caleb that have been applied (5): http://xwiki.markmail.org/search/?q=%22Patch+from+Caleb%22 - Total patches from Caleb (9): http://xwiki.markmail.org/search/?q=calebjamesdelisle+keywords+patch - Mails mentioning Caleb (114): http://xwiki.markmail.org/search/?q=Caleb - Patches not applied yet (4): - http://jira.xwiki.org/jira/browse/XWIKI-4367 - http://jira.xwiki.org/jira/browse/XWIKI-4287 - http://jira.xwiki.org/jira/browse/XWIKI-1716 - http://jira.xwiki.org/jira/browse/XWIKI-3355 - http://jira.xwiki.org/jira/browse/XSKINX-9 - http://jira.xwiki.org/jira/browse/XWIKI-4326 In addition I know Caleb will not commit something he's not sure about. I'm +1 to make Caleb a committer. Committers, please vote. Thanks -Vincent

8 10

[xwiki-devs] Writing a Macro in XWiki 1.3
by Roberto Perez Santamaria 30 Nov '09

30 Nov '09

Hello, I want to include this code in a macro in a 1.3 version...but I don´t find any example of how to do this... Could you help me and tell me if there is any way to do this?? The URL will be the parameter of the macro... <% try { URL timelineURL = new URL("http://ws.geonames.org/search?name_equals=den&fcode=airp&style=full"); def connection = timelineURL.openConnection(); def xml = connection.content.text def geonames = new XmlSlurper().parseText(xml) def result = [:] result.name = geonames.geoname.name as String result.lat = geonames.geoname.lat as String result.state = geonames.geoname.adminCode1 as String result.lng = geonames.geoname.lng as String result.country = geonames.geoname.countryName as String //print ("Nombre: " + "\n") //print result.name + "\n" //print ("\n") //print ("Latitud: " + "\n") //print result.lat + "\n" //print ("\n") //print ("Longitud: " + "\n") //print result.lng + "\n" //print ("\n") //print ("Estado: " + "\n") //print result.country + "\n" print ("{" + "code}\n") print xml + "\n" print ("{" + "code}\n") print ("{" + "table}\n") print "Nombre" + "|" + "Latitud" + "|" + "Longitud" + "|" + "Estado" print ("\n") print result.name + "|" + result.lat + "|" + result.lng + "|" + result.country print ("{" + "table}\n") } catch(Exception e) {print e.message} %> Thank you. ------------------------------------------------------------------ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informacion confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente pueden estar protegidos por secreto profesional. Si usted recibe este correo electronico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos Origin no se hace responsable por su contenido. Su contenido no constituye ningun compromiso para el grupo Atos Origin, salvo ratificacion escrita por ambas partes. Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no sera responsable de cualesquiera danos que puedan resultar de una transmision de virus. ------------------------------------------------------------------

1 0