August 2008 - xwiki-devs@xwiki.org

[xwiki-devs] [GSoC][officeimporter]the interface of office converter
by Wang Ning 23 Aug '08

23 Aug '08

Hi Vincent, I think OutputStream convert(InputStream inputStream, OfficeDocumentType inputDocumentType, OfficeDocumentType outputDocumentType) is not appropriate. The OutputStream is a place to write data to. I just can't get the data from the OutputStream. I think the OutputStream should be a special outputStream the user provide, so I have these to proposals for this interface: 1. ByteArrayOutputStream convert(InputStream inputStream, OfficeDocumentType inputDocumentType, OfficeDocumentType outputDocumentType) return type change to ByteArrayOutputStream. Then client can use ByteArrayOutputStream.toByteArray() to get the contents in OutputStream. 2. void convert(InputStream inputStream, OfficeDocumentType inputDocumentType, OutputStream outputStream, OfficeDocumentType outputDocumentType) Client provide a output Target to store the contents. Example: ByteArrayOutputStream outputStream = new ByteArrayOutputStream(); convert(inputStream, inputDocumentType, outputStream, outputDocumentType) WDYT? -- Thanks Wang Ning

2 2

[xwiki-devs] Exporting/Importing pages
by gerem44＠free.fr 23 Aug '08

23 Aug '08

Hi, Everytime i try to export pages in .XAR, and when i try to open it, i get a corrupted archive, i tried with 2 different XWiki installation. Actually i try to see the XWwiki page format to match with the pages i created. If nobody has an idea about XAR problem, maybe someone could tell me what to put in the XAR archive to be able to import it into XWiki. The package.xml format and the page format or extension. I dont know if its possible to send me as an attached file, A wokring XAR archive. Best Regards, Gerem

3 4

[xwiki-devs] Watch Lucene integration: XWATCH-116
by Anca Paula Luca 22 Aug '08

22 Aug '08

Hi devs, my research about Lucene querying for Watch (http://jira.xwiki.org/jira/browse/XWATCH-116) from the past weeks brought me to the following results: First of all, as I already mentioned, since Lucene is a fulltext indexing engine and Watch data is, even if wiki data, quite structured data (and so are its queries), something feels not right in trying to do this. But the query speed improvements are / should be significant so we could try to workaround -- XWiki Lucene plugin indexes object properties in documents as fields so basically, a structured search is plausible (with the right type of Lucene fields, etc). Even like this, not all Watch SQL queries are fully translatable to Lucene queries without having Watch specific Lucene querying code and / or Watch specific Lucene indexing. Second, there is a problem with the Lucene reliability and "response time", as mentioned in the jira issue comments: * there is a delay between the moment a document is created / modified and the moment the change is retrievable through Lucene queries, because first it needs to be indexed by Lucene. This fuzzyness, although acceptable in some situations (for example, retrieving the list of articles to show to the user) it is not desired in situations like article properties updates (star, read, trash) or feed adding / deleting -- "caching" these changes until they are retrievable through Lucene querying is not at all an option. * XWiki Lucene plugin seems quite buggy / unstable: a lot of exceptions (server restart seems to be fatal due to some hanged file lock), duplicate documents in results sometimes, missing results some time, all explainable and acceptable in the "fuzzy" situation of a fulltext search engine, but not when trying to use it for structured search. Despite all these, I devised some code to help me test Lucene and compare it to SQL in the real-watch situation, for the article list retrieval. The results for the time spent on the server (I assumed that the time taken to transport documents and print them in the Reader is the same regardless of the querying technique), for a mysql server with ~60000 articles in ~200 feeds, are: * for the initial loading of the articles, in a newly started server, SQL can take up to 30-40 seconds, Lucene takes "only" up to 20 (15-16) * for the initial load of the interface, in a non-newly started server, it takes ~15 seconds for SQL and ~4-5 on average (but can go up to 10) for Lucene * for a click on the All group, which it's basically the same query as for the initial load of the article list, it can go under a second for Lucene and around 7-8-9 seconds for SQL * for a click on a feed with 1023 articles (therefore loading the list of articles in a specific feed), SQL goes to 3 seconds while Lucene can take from under a second to a couple of seconds, depending on the time took to load the actual documents corresponding to the search results * for pagination navigation, Lucene takes a second on average and SQL 2-3 seconds. Note that Lucene retrieval still uses the database and SQL access because its results are LuceneDocuments (that hold names of XWikiDocuments), not XWikiDocuments. All the tests above were made with a server running on my computer with a 5.0.51a mysql version, a 1.6-SNAPSHOT XWiki version , java 1.5.0_15 version, AMD Turion64 x 2 TL-56, 1.8 GB RAM, but with other applications running too. I feel that, overall, Lucene querying improvements are not so spectacular, especially because it cannot solve all situations and we would still need SQL querying in some cases, and because of its relative instability (which we could think about fixing, though). The other option for performance improvements in Watch would be to have a Watch specialized server (as we've already discussed) which would allow, amongst other things, to use Watch specific SQL queries (as opposed to now when we use generic queries since we have to go through the XWiki GWT API) and optimize as much as possible at that level. I haven't tested yet the amount of improvement but, since I think we might be able to drop some tables from some of the SQL joins we're doing right now, it should be better. Of course, this kind of approach requires heavy refactor, and potentially complete rewriting and rearchitecturing of some pieces. Despite the coding challenge, I'd go for the second approach, WDYT? Happy coding, Anca Luca

4 6

Re: [xwiki-devs] Questions regarding A,B,C,D .. Views on spaces.
by Ludovic Dubost 22 Aug '08

22 Aug '08

Hi Asiri, You are perfectly right that we have a coherence problem with these virtual views. Maybe one way to solve it would be to show the last 20 pages directly in the Space view. This way if you create a new page it will show up in the space view refresh. We are kind of stuck between a view system that is not perfect (the A, B, C, D) and one that will cause performance issue (normal flat view). I think users will have to live with the caveats of the A, B, C, D system. So I propose to implement A, B, C, D + the last 20 recent pages. Maybe Guillaume can give his point of view ? WDYT ? Ludovic Asiri Rathnayake wrote: > Hi Ludovic, > > I've been thinking of implementing A,B,C,D view for spaces but i came > across few obstacles. > > Currently we have SpacesView->Space->Page kind of a hierarchy and > there, both Space & Page are domain objects. But if we change the > hierarchy to categorize pages by first letter, the situation changes a > bit. > > Then the hierarchy would be like, > SpacesView->Space->PagesByFirstLetter->Page. Here the Space is no > longer a domain object but kind of a view and adding pages to it poses > problems. I mean if we add a page to an space, we would have to move > it immediately to the correct category (by first letter). And this is > not that good. > > One solution is to restrict the user's ability to add pages / spaces > (these are what complicates the issues). But this might not look that > pretty. > > I have the following hierarchy in my mind but i'm not quite sure about > it : > > XWikiDocumentsDavView->XWikiDocumentBySpaceNameDavView->XWikiDocumentsByFirstLettersDavView->XWikiDavPage > > This way it looks pretty much alike attachments view. But again, > adding pages to a space seems to pose the same problem. > > I think these problems are mainly due to the fact that XWiki domain > does not directly map into a directory hierarchy. > > Please let me know how should i proceed. > > Thanks. > > - Asiri -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

2 1

[xwiki-devs] [Proposal] Move the new WYSIWYG into the platform
by Marius Dumitru Florea 22 Aug '08

22 Aug '08

Hi devs, I propose to move the new WYSIWYG editor into the platform in order to have it as an experimental feature for 1.6M1. The following steps should be taken: * Create a platform/web/wysiwyg module to host the code currently resided in sandbox/wysiwyg * Change templates/edit.vm, templates/editpanels.vm and create templates/editwysiwygnew.vm to make XE aware of the new editor. This way our users will be able to experiment the new WYSIWYG editor on any page, by having editor=wysiwygnew in the edit URL. * Change platform/web/pom/xml and enterprise/web/pom.xml Here's my +1 Marius

13 28

[xwiki-devs] [GSoC][officeimporter]finish code clean for office converter and status update
by Wang Ning 22 Aug '08

22 Aug '08

Hi Vincent & all devs, I finished the code clean and document for the current version of office converter. If you want to see the detail, please visit http://dev.xwiki.org/xwiki/bin/view/Design/OfficeConverter This project is dependence on the XE 1.6 which is not released yet. So if you want to try the newest version of this project, you need build the latest version of xwiki from the svn and download the officeconverter for XE 1.6 and follow the README. Important change: 1. add the support for ppt and odt 2. encapsulate the convert2xwiki to the Util So the todo list is * improve the xhtmlparser in the xwiki-core-rendering and wikimodel * improve the xwiki-core-xml 's HTMLCleaner -- Thanks Wang Ning

2 2

[xwiki-devs] XWIKI - Problem In Getting The Rights.
by Prathap Pandian 22 Aug '08

22 Aug '08

Hi, I had some problem in the rights, i have created a user and assigned admin for that user in the XWiki space. Now in the Main Space i had the following code #if ($xwiki.hasAdminRights()) You have admin rights for this space. #else You don't have admin rights for this space. #end Now login as newly created user and go to the Main space. It showing "You have admin rights for this space". Actually it has to display "You don't have admin rights for this space." since i have assigned admin rights for the XWiki Space. -- Prathap

1 0

[xwiki-devs] strange behavior for XWikiGlobalRights and register
by Pascal Voitot 21 Aug '08

21 Aug '08

Hello, I deny(or just keep blank) Register right for XWikiAllGroup<http://www.mandubian.org/xwiki/bin/view/XWiki/XWikiAllGroup> Then I deny "register" right for "unregistered users" aka XWiki.XWikiGuest I logout It appears that anyone is able to register!!!!!!!!! Then, I allow register right for XWikiAllGroup while keeping it denied for XWikiGuest. The register menu disappears by default! Apparently, the right management requires the right to be defined at least for XWikiAllGroup to take XWikiGuest into account. is it normal? best regards Pascal

1 0

[xwiki-devs] [GSoC][officeimporter]code clean and javedoc almost done
by Wang Ning 21 Aug '08

21 Aug '08

Hi Vincent, Just FYI, I almost finish the code clean and javadoc from my current code(two class left). I think I can finish it tomorrow morning. And we can submit it to the code.xwiki.org soon. -- Thanks Wang Ning

1 0

Re: [xwiki-devs] XWiki wysiwyg editor
by Marius Dumitru Florea 21 Aug '08

21 Aug '08

Hi Darren, I'm currently moving the new WYSIWYG from the sandbox into the platform. Next Monday we are going to release XWiki Enterprise 1.6M1 including the new editor as an experimental feature. Experimental because, for the moment, it doesn't have all the features of the TinyMCE. We hope it will have them by the end of September. Also the new editor depends on the new rendering module, made by Vincent, which is very complex and requires an tremendous effort. So you can wait for the 1.6M1 release and then try to extend the new editor to fit your needs. On our side, it will take a few months till the current editor will be replaced. Thanks for your interest in the XWiki platform! Marius > Hello Marius, > > I was wondering if you had made any progress with > http://jira.xwiki.org/jira/browse/XWIKI-2497. > > I am new to XWiki and the only real stopper from us using it more widely > is the problems with the wysiwyg editor. We are very keen on getting the > new version you are developing. Is it in a state that we can start using > it, and if so can you tell me where to get it and how to integrate it. > If it helps we could help you test it. > > Thank you for your time and keep up the good work, > > Darren > > >> Darren Owens >> E-Strategy Senior Web Developer >> Simplyhealth > t: 01264 353211 x2850 > m: 07595 393651 > e: darren.owens(a)simplyhealth.co.uk > > ----------------------------------------------------------------------------------------------- > This email, and the contents contained within, are private > and confidential between the sender and the individual(s) > to whom it is addressed. > The contents do not necessarily represent the views of Simplyhealth Group > Limited. > > In the event of misdirection, the recipient is prohibited from > using, copying or disseminating it or any information contained in it. > If you have received this email in error please notify Simplyhealth > immediately by telephone on 0845 075 2020, or by email to > network.administrator(a)simplyhealth.co.uk > > Simplyhealth Group Limited is registered and incorporated in England and > Wales > as a company limited by guarantee. Its registered office is at Hambleden > House, > Waterloo Court, Andover, Hampshire, SP10 1LQ, registered no. 5445654. We > may record or monitor telephone calls to help improve our service and > protect our > members. > ----------------------------------------------------------------------------------------------- >

1 0