March 2009 - xwiki-users@xwiki.org

[xwiki-users] Inline forms in XWiki Syntax 2.0
by Lewis Denizen 20 Mar '09

20 Mar '09

Hi xwiki-users, When attempting to include an inline form in XWiki Syntax 2.0, the resulting page always gets wrapped in a {pre} tag. It says this was to prevent further rendering of the form, but this doesn't work too well with the 2.0 syntax since {pre} is not a valid tag (just renders it as a literal string). I just created a custom form (using the {{html}} tag), but what is the preferred way of creating inline forms using the 2.0 syntax? Is this ( http://jira.xwiki.org/jira/browse/XWIKI-2891) the JIRA that tracks this issue? Also, I'm not 100% certain, but it also seems that a "#includeForm(" needs to exist in order for the default "edit" mode to enter inline editing (I think viewheader.vm is used to render the top panel... and there's a check [#if($doc.content.indexOf("includeForm(")!=-1)], which probably detects this) - again, will this still hold true in the 2.0 syntax? Thanks in advance! -- Lewis

2 2

Re: [xwiki-users] Why I chose Xwiki instead of other wikis
by Florin Ciubotaru 20 Mar '09

20 Mar '09

Ari Oinas wrote: >> Thanks for your feedback. I would be glad to know a bit more about what you >> were looking for, which wikis you tried and what made you choose XWiki >> rather than another system. This would help us understand better what makes >> XWiki stand out and what it lacks compared with other platforms. >> If you've got a little time, do you think you could tell us a bit about >> that? >> Many thanks in advance, >> Guillaume >> > > Ok, here's a small list of reasons why I chose Xwiki and not some other > wiki. > Before I begun searching for suitable wiki, I gathered a list of > requirements that a wiki must have. > Wikis that I tested or studied were: MediaWiki, TikiWiki, Xwiki and > Confluence. Maybe some others too, but I don't remember ;) > > Here is that list and how different wikis fulfill those requirements: > > Requirement 1: Ability to transclude pages and sections of pages in other > pages > MediaWiki: Yes, support page transcluding natively and section transcluding > can be added with plugin > Xwiki: Supports page transcluding. Section macro was easy to do, and I got > to do it just the way I like it :) > Confluence: I think it supports transcluding. Not tested it though. > > Requirement 2: Support for hierarchical information ( tree-like ) > MediaWiki: Very bad. Can be achieved using categories, but because Category > is a namespace, category names must be unique which was unacceptable in > mycase. > Xwiki: Very flexible. Namespaces ( Spaces in Xwiki ) are easy to create and > pages can be ordered hierarchically using page's parent -field. > > Requirement 3: Support for content localization/translation > Mediawiki: None. AFAIK every language needs it's own Wiki. > Xwiki: Built-in. Creating translated content is easy. Functions to retrieve > translations still needs work, but are good enough to get the job done. > > Requirement 4: Flexible, easy to maintain user rights > Mediawiki: User right management very restricted. Better with plugins but > still poor. > Xwiki: Superb! Very easy, yet powerful way to handle user rights. I really > liked that user right has 3 options: allow, deny, neutral. This combined > with user groups and spaces makes user rights management very enjoyable. > TikiWiki: Frustratingly detailed. Has some very powerful features, but list > of about 100 different user right parameters is very frustrating. (This > opinion is based on very quick tests) > > Requirement 5: Ability make offline HTML dumps of wiki content > MediaWiki: Possible (maybe with a plug-in, I don't remember) > Xwiki: Supported natively. Yet, I decided to make my own XML Dump program > which fetches content through XML/RPC interface. > > > And now a list of pros and cons for every wiki I tested: > > Mediawiki: > + Widely used, lots of help available > + lots of plugins > - hierarchical information support very bad > - user right management limited and hard to comprehend > > TikiWiki: > + Lots of features > - User interface looks clumsy and is difficult to use ( maybe because I > tested Xwiki just before this ;) > - User rights management is overwhelming > > Confluence: ( not tested, opinions based on what I read about it) > + seems finalized > + used widely in enterprises and universities > + XML/RPC interface > - PRICE > > Xwiki: > + Very slick UI > + Macros / Programming capabilities > + XML/RPC interface > + User rights management > + customer support > - Seems in many ways incomplete/work in progress > - Documention is scattered across the internets / help is very hard to find > using Google. Most searches end up in Xwiki JIRA-pages. > - Xwiki documentation pages seem disorientating. Even if I know theres some > useful info there, it takes me 15mins to find it. (DevGuide, dev.xwiki.org, > xwiki.org/Features) > - Example: > http://xoffice.xwiki.org/xwiki/bin/view/CodeBase/XmlRpcProxy and > http://platform.xwiki.org/xwiki/bin/view/Features/XMLRPC, so similar, yet in > totally different places > The XmpRpcProxy page was created after you sent your first mail. I published that page, as a result of your mail, so that it potentially helps you. As you can see the notes in the page, it is only a draft. When completed(fully maps the xml-rpc model&api) it will be linked/added to the platform page. > - Scandinavian characters in pageIds don't seem to work > > > I hope these lists are helpful to you. Despite some criticism I presented > here, you have developed an amazing wiki. I think you should focus a little > more on making documentation easy to find and read even for someone who is > just starting to code or otherwise noob (such as me ;). Now it gives an > impression that you have to be Linux-expert/super-coder/uber-nerd to be able > to set up wiki and program it (which you don't need to be, it's actually > quite simple). > > Best regards, > > Ari > > > > > > > > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > >

2 1

Re: [xwiki-users] Why I chose Xwiki instead of other wikis
by Guillaume Lerouge 20 Mar '09

20 Mar '09

Hi Ari, On Fri, Mar 20, 2009 at 10:00 AM, Ari Oinas <ari.oinas(a)jidea.fi> wrote: > > >Thanks for your feedback. I would be glad to know a bit more about what > you > >were looking for, which wikis you tried and what made you choose XWiki > >rather than another system. This would help us understand better what > makes > >XWiki stand out and what it lacks compared with other platforms. > >If you've got a little time, do you think you could tell us a bit about > >that? > >Many thanks in advance, > >Guillaume > > Ok, here's a small list of reasons why I chose Xwiki and not some other > wiki. > Before I begun searching for suitable wiki, I gathered a list of > requirements that a wiki must have. > Wikis that I tested or studied were: MediaWiki, TikiWiki, Xwiki and > Confluence. Maybe some others too, but I don't remember ;) > > Here is that list and how different wikis fulfill those requirements: > > Requirement 1: Ability to transclude pages and sections of pages in other > pages > MediaWiki: Yes, support page transcluding natively and section transcluding > can be added with plugin > Xwiki: Supports page transcluding. Section macro was easy to do, and I got > to do it just the way I like it :) > Confluence: I think it supports transcluding. Not tested it though. > > Requirement 2: Support for hierarchical information ( tree-like ) > MediaWiki: Very bad. Can be achieved using categories, but because Category > is a namespace, category names must be unique which was unacceptable in > mycase. > Xwiki: Very flexible. Namespaces ( Spaces in Xwiki ) are easy to create and > pages can be ordered hierarchically using page's parent -field. > > Requirement 3: Support for content localization/translation > Mediawiki: None. AFAIK every language needs it's own Wiki. > Xwiki: Built-in. Creating translated content is easy. Functions to retrieve > translations still needs work, but are good enough to get the job done. > > Requirement 4: Flexible, easy to maintain user rights > Mediawiki: User right management very restricted. Better with plugins but > still poor. > Xwiki: Superb! Very easy, yet powerful way to handle user rights. I really > liked that user right has 3 options: allow, deny, neutral. This combined > with user groups and spaces makes user rights management very enjoyable. > TikiWiki: Frustratingly detailed. Has some very powerful features, but list > of about 100 different user right parameters is very frustrating. (This > opinion is based on very quick tests) > > Requirement 5: Ability make offline HTML dumps of wiki content > MediaWiki: Possible (maybe with a plug-in, I don't remember) > Xwiki: Supported natively. Yet, I decided to make my own XML Dump program > which fetches content through XML/RPC interface. > > > And now a list of pros and cons for every wiki I tested: > > Mediawiki: > + Widely used, lots of help available > + lots of plugins > - hierarchical information support very bad > - user right management limited and hard to comprehend > > TikiWiki: > + Lots of features > - User interface looks clumsy and is difficult to use ( maybe because I > tested Xwiki just before this ;) > - User rights management is overwhelming > > Confluence: ( not tested, opinions based on what I read about it) > + seems finalized > + used widely in enterprises and universities > + XML/RPC interface > - PRICE > > Xwiki: > + Very slick UI > + Macros / Programming capabilities > + XML/RPC interface > + User rights management > + customer support > - Seems in many ways incomplete/work in progress > - Documention is scattered across the internets / help is very hard to find > using Google. Most searches end up in Xwiki JIRA-pages. > - Xwiki documentation pages seem disorientating. Even if I know theres some > useful info there, it takes me 15mins to find it. (DevGuide, dev.xwiki.org > , > xwiki.org/Features) > - Example: > http://xoffice.xwiki.org/xwiki/bin/view/CodeBase/XmlRpcProxy and > http://platform.xwiki.org/xwiki/bin/view/Features/XMLRPC, so similar, yet > in > totally different places > - Scandinavian characters in pageIds don't seem to work > Thanks a lot for the feedback :-) > I hope these lists are helpful to you. Despite some criticism I presented > here, you have developed an amazing wiki. I think you should focus a little > more on making documentation easy to find and read even for someone who is > just starting to code or otherwise noob (such as me ;). Now it gives an > impression that you have to be Linux-expert/super-coder/uber-nerd to be > able > to set up wiki and program it (which you don't need to be, it's actually > quite simple). > We're aware our documentation can be improved. We wanted to work on improving XWiki.org, but it got delayed with the release of XWiki Enterprise 1.8 taking most of our time. If you've got a little time, we'd be very happy to have you contribute the program you wrote on http://code.xwiki.org/ and improve the documentation in places where you found it confusing (adding details / links where needed). All you need to do this is an account on xwiki.org and then, well, it's a wiki ;-) Guillaume Best regards, > > Ari > > > > > > > > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/

1 0

Re: [xwiki-users] Translations cannot be fetched using XML/RPC interface
by Guillaume Lerouge 20 Mar '09

20 Mar '09

Hi Ari, On Thu, Mar 19, 2009 at 12:48 PM, Ari Oinas <ari.oinas(a)jidea.fi> wrote: > Some other improvements also came to mind: > - Search -method should also have ability to set language > - It would be nice if search -method could also search rendered contents. > For example if I have a macro on one page, which trancludes text from > another page, page containing the macro doesn't show in search results. I > think that this feature is very hard to implement very efficiently. And > theres definitely should be possibility to turn it on or off. Maybe it > would > require a "copy" of renderedContent to be stored on the database and thus > increases database size. > - Util class should contain function to strip HTML-tags from string. > > There is much of small things that need to be fixed in Xwiki to make it > "perfect", but it's a pretty good and flexible already. > I evaluated about 5 different wiki-systems before I decided to go with > Xwiki. Every wiki had some constraints which rendered them useless for my > needs, but Xwiki was the most flexible system. Thanks for your feedback. I would be glad to know a bit more about what you were looking for, which wikis you tried and what made you choose XWiki rather than another system. This would help us understand better what makes XWiki stand out and what it lacks compared with other platforms. If you've got a little time, do you think you could tell us a bit about that? Many thanks in advance, Guillaume > > > Keep up the good work! > > Cheers, > > Ari > > > -----Original Message----- > From: users-bounces(a)xwiki.org [mailto:[email protected]] On Behalf > Of > Fabio Mancinelli > Sent: 19. maaliskuuta 2009 13:09 > To: XWiki Users > Subject: Re: [xwiki-users] Translations cannot be fetched using XML/RPC > interface > > > On Mar 19, 2009, at 8:48 AM, Ari Oinas wrote: > > > Hi, > > > > And thanks for your efforts regarding this issue. I found the > > problem which > > caused my translations not to work. > > > > > Happy that you solved your problem. > > > Still, some things to consider: > > > > - should renderContent function also handle pageId so that language > > could be > > embedded in the end of pageId? Same way as getPage handles pageId. > > > > - getPages function returns PageSummaries with default language > > pageTitles. > > It would be convenient to call this function with language id, so that > > pagetitles would be in correct language. Now I have to loop through > > every > > pagesummary and get page title to get correct pageTitles to show on > > navigation tree. > > > Thank you for spotting these improvements. > I will open Jira issues in order to add these feature in the next > release. > > > Thanks for superb customer support! > > > You are welcome. > > Cheers, > Fabio > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/

2 1

[xwiki-users] Moving from AD LDAP to Kerberos
by Samuel Lee 19 Mar '09

19 Mar '09

How do I allow Kerberos authentication for just one of my XWiki's in the xwiki farm? I had an AD LDAP authentication setup, but we're moving to a Kerberos structure for just the one xwiki. -Do I need to comment out all the LDAP parameters? -How do I pass the Kerberos Authentications to just one XWiki in the farm? -In your documentation you mention ":Place the authkerb.jar jar in the WEB-INF/lib directory of Xwiki in Apache Tomcat." Where is the authkerb.jar file? Sam

1 0

[xwiki-users] Hibernate exception when trying to delete attachment
by Stefan Woehrer 19 Mar '09

19 Mar '09

Hi, we are running XWiki 1.7.1 on Tomcat 6 with MS-SQL. When deleting attachments, in general, everything works fine. But on some files we get a hibernate exception. We can't figure out why this error appers with some attachments. Here's the exception: A problem occured while trying to service your request. Please contact the support if this happens again. Detailed information: Error number 0 in 3: Exception while hibernate execute Wrapped Exception: The database returned no natively generated identity value com.xpn.xwiki.XWikiException: Error number 0 in 3: Exception while hibernate execute Wrapped Exception: The database returned no natively generated identity value at com.xpn.xwiki.store.XWikiHibernateBaseStore.execute(XWikiHibernateBaseStore.java:1052) at com.xpn.xwiki.store.XWikiHibernateBaseStore.executeWrite(XWikiHibernateBaseStore.java:1098) at com.xpn.xwiki.store.hibernate.HibernateAttachmentRecycleBinStore.saveToRecycleBin(HibernateAttachmentRecycleBinStore.java:83) at com.xpn.xwiki.doc.XWikiDocument.deleteAttachment(XWikiDocument.java:2799) at com.xpn.xwiki.doc.XWikiDocument.deleteAttachment(XWikiDocument.java:2782) at com.xpn.xwiki.web.DeleteAttachmentAction.action(DeleteAttachmentAction.java:72) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:215) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:135) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Unknown Source) Wrapped Exception: org.hibernate.HibernateException: The database returned no natively generated identity value at org.hibernate.id.IdentifierGeneratorFactory.getGeneratedIdentity(IdentifierGeneratorFactory.java:67) at org.hibernate.id.IdentityGenerator$GetGeneratedKeysDelegate.executeAndExtract(IdentityGenerator.java:77) at org.hibernate.id.insert.AbstractReturningDelegate.performInsert(AbstractReturningDelegate.java:33) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2163) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2643) at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentityInsertAction.java:51) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:298) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:181) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:107) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:187) at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:33) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:172) at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:27) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70) at org.hibernate.impl.SessionImpl.fireSave(SessionImpl.java:535) at org.hibernate.impl.SessionImpl.save(SessionImpl.java:523) at org.hibernate.impl.SessionImpl.save(SessionImpl.java:519) at com.xpn.xwiki.store.hibernate.HibernateAttachmentRecycleBinStore$1.doInHibernate(HibernateAttachmentRecycleBinStore.java:87) at com.xpn.xwiki.store.XWikiHibernateBaseStore.execute(XWikiHibernateBaseStore.java:1046) at com.xpn.xwiki.store.XWikiHibernateBaseStore.executeWrite(XWikiHibernateBaseStore.java:1098) at com.xpn.xwiki.store.hibernate.HibernateAttachmentRecycleBinStore.saveToRecycleBin(HibernateAttachmentRecycleBinStore.java:83) at com.xpn.xwiki.doc.XWikiDocument.deleteAttachment(XWikiDocument.java:2799) at com.xpn.xwiki.doc.XWikiDocument.deleteAttachment(XWikiDocument.java:2782) at com.xpn.xwiki.web.DeleteAttachmentAction.action(DeleteAttachmentAction.java:72) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:215) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:135) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Unknown Source) Does anybody know how we can figure out why this happens and how we can solve this issue? THX, Steve -- View this message in context: http://n2.nabble.com/Hibernate-exception-when-trying-to-delete-attachment-t… Sent from the XWiki- Users mailing list archive at Nabble.com.

3 3

Re: [xwiki-users] Translations cannot be fetched using XML/RPC interface
by Sergiu Dumitriu 19 Mar '09

19 Mar '09

Ari Oinas wrote: > - It would be nice if search -method could also search rendered contents. > For example if I have a macro on one page, which trancludes text from > another page, page containing the macro doesn't show in search results. I > think that this feature is very hard to implement very efficiently. And > theres definitely should be possibility to turn it on or off. Maybe it would > require a "copy" of renderedContent to be stored on the database and thus > increases database size. This could be done using Lucene, once we start refactoring our lucene-based search. -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

Re: [xwiki-users] Translations cannot be fetched using XML/RPC interface
by Fabio Mancinelli 19 Mar '09

19 Mar '09

On Mar 19, 2009, at 8:48 AM, Ari Oinas wrote: > Hi, > > And thanks for your efforts regarding this issue. I found the > problem which > caused my translations not to work. > > Happy that you solved your problem. > Still, some things to consider: > > - should renderContent function also handle pageId so that language > could be > embedded in the end of pageId? Same way as getPage handles pageId. > > - getPages function returns PageSummaries with default language > pageTitles. > It would be convenient to call this function with language id, so that > pagetitles would be in correct language. Now I have to loop through > every > pagesummary and get page title to get correct pageTitles to show on > navigation tree. > Thank you for spotting these improvements. I will open Jira issues in order to add these feature in the next release. > Thanks for superb customer support! > You are welcome. Cheers, Fabio

2 1

[xwiki-users] Using session inside a class
by Jan Cerny 19 Mar '09

19 Mar '09

Hi, I'm trying to access session from a Groovy class, but I'm not successful. When I have a simple script: <% session = request.getSession(true); counter = session.getValue("counter") %> - everything is OK. But when I have a class: class User { def counter = 0; void setUser() { session = request.getSession(true); counter = session.getValue("counter") } String showCounter() { return this.counter; } } The Error message is No such property: request for class: User. So how should I access session from the class? Thanks, Zik

2 1

[xwiki-users] class database list property should be empty when creating document
by Sebastian Kannengiesser 19 Mar '09

19 Mar '09

Hi guys, I created a few days ago some documents based on my own class which has databse list properties. In the respective template fields, there was no entry selected when creating the document which is the behaviour I need. When I now create a document based on the same class the first entry is selected a priori and there is no way to deselect, i.e. have nothing selected, it. The old documents still have the ability to deselect the entry in inline editing mode. Can you guys please tell me, what might have happened here or could it be a bug? I dont't understand this apparently undeterministic behaviour. Many thanx in advance. BTW, this is in XWiki 1.7.2. Cheers Sebastian

5 21