xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

Re: [xwiki-devs] [xwiki-notifications] r11992 - in platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/store: hibernate/query jcr/query query

by Vincent Massol

On Aug 23, 2008, at 1:07 AM, amelentev (SVN) wrote: > Author: amelentev > Date: 2008-08-23 01:07:59 +0200 (Sat, 23 Aug 2008) > New Revision: 11992 > > Added: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/store/ > query/QueryException.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/store/ > query/QueryExecutor.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/store/ > query/QueryImpl.java I really don't like to have Impl in class names. I'd really like that we define it as a rule not to use them. All or classes are implementations anywyay... I think it's also important it ends with Query since all queries should do that. I can propose: - DefaultQuery - BasicQuery - BaseQuery Thanks -Vincent PS: Haven't reviewed the commit, just this that jumped in front of my eyes. If we're ok with it I'll put it in our best practices guide on dev.xwiki.org [snip}

16 years, 5 months

[xwiki-devs] [New Rendering] Macro syntax

by Vincent Massol

Hi, Right now wikimodel implements the following syntax for xwiki macros: 1) {{macro param1="value1" param2="value2"}}content{{/macro}} {{macro param1=value1 param2=value2}}content{{/macro}} This is different from the original proposal of: 2) {{macro:param1="value1"|param2="value2"}}content{{/macro}} Notes: * I think 1) is cleaner and easier to read * There's no default param in 1) so you don't write something like: {{include:Main.WebHome}}. You have to write: {{include document=Main.WebHome}} * 2) is the same as the current syntax Which do we want? I don't have any particular preference. Thanks -Vincent

16 years, 5 months

Re: [xwiki-devs] [New Rendering] Automatic new lines?

by Joshua Marks

Regarding extra lines with multiple enter/carriage returns: +1 you bet- WYS should be WYG. If I put in 32 returns while typing, I want 32 empty lines on output. Joshua Marks CTO Curriki: The Global Education and Learning Community jmarks(a)curriki.org www.curriki.org ****************************

16 years, 5 months

[xwiki-devs] [New Rendering] Link rendering when no alias

by Vincent Massol

Hi, In the current rendering a link like [Space.MyPage] is displayed as "My Page" (camelcase rendering + removal of space prefix) when no alias is specified. We need to decide what to do with the new rendering. There are several options: * MyPage * Space.MyPage * My Page * wiki:Space.MyPage * (the page title) I propose to default to the page name without space nor wiki name (i.e. "MyPage" in our example). We could also make it configurable with variables like %w (wiki name), %s (space name), %p (page name), %P (camel cased page name, i.e. "My Page") and %t (page title). The default would be %p but users could change it to %s.%p or %w:%s.%p or whatever else they want. WDYT? Thanks -Vincent

16 years, 5 months

[xwiki-devs] XWIKI - Getting Space Rights.

by Prathap Pandian

HI, I have link [Panels>Panels.WebHome] in the *"Main"* Space. And i want to display this only for the user who having admin rights for the *"Panels"* Space. I tried with this one *$hasAdmin* but it getting the rights for the current space. Any other way to do this...? -- Prathap

16 years, 5 months

[xwiki-devs] [GSoC][officeimporter]the interface of office converter

by Wang Ning

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

16 years, 5 months

[xwiki-devs] Exporting/Importing pages

by gerem44＠free.fr

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

16 years, 5 months

[xwiki-devs] Watch Lucene integration: XWATCH-116

by Anca Paula Luca

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

16 years, 5 months

Re: [xwiki-devs] Questions regarding A,B,C,D .. Views on spaces.

by Ludovic Dubost

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

16 years, 5 months

[xwiki-devs] [Proposal] Move the new WYSIWYG into the platform

by Marius Dumitru Florea

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

16 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs