November 2008 - xwiki-devs@xwiki.org

[xwiki-devs] [Rendering] Error handling
by Vincent Massol 17 Nov '08

17 Nov '08

Hi, Just to let you know that I have started implementing error handling in the new rendering. Right now my idea is to wrap macro errors (macro not found, macro execution error) in an ErrorBlock so that renderers can decide to display them as they want. Something like the following (note: I think I need to add another  comment for putting error description (like the staktrace) in addition to the short error message. .#----------------------------------------------------- .input|xwiki/2.0 .# Verify behavior when macro doesn't exist .#----------------------------------------------------- Unknown {{unknown/}} macro .#----------------------------------------------------- .expect|event .#----------------------------------------------------- beginDocument beginParagraph onWord [Unknown] onSpace beginError: [Unknown macro: unknown] onMacroInline [unknown] [] [] endError: [Unknown macro: unknown] onSpace onWord [macro] endParagraph endDocument .#----------------------------------------------------- .expect|xhtml .#----------------------------------------------------- <p>Unknown  macro</p> .#----------------------------------------------------- .expect|xwiki .#----------------------------------------------------- Unknown {{unknown/}} macro .#----------------------------------------------------- .input|xhtml/1.0 .#----------------------------------------------------- <html><p>Unknown  macro</p></ html> I still haven't decided if MacroTransformation should still raise exceptions or not. I'm also investigating how to handle other rendering errors but my idea is also to wrap them in error blocks. Let me know what you think and respond quickly if you don't agree with this since I'm progressing fast on it. Thanks -Vincent

2 2

[xwiki-devs] [New WYSIWYG] Handling empty macros
by Vincent Massol 17 Nov '08

17 Nov '08

Hi, We need to decide how we display macro that do not generate any content in the WYSIWYG editor so that the user can edit them or delete them for example. We can have a visual placeholder that would be displayed whether the macro content is empty or not, just before the macro or just above the macro if we have enough vertical space. Something with "Macro" printed inside and the macro name as the tooltip. Clicking on it could select the macro block. WDYT? In any case I'm raising this so that design proposal for Macro handling in the new wysiwyg editor takes this into account. Thanks -Vincent

2 1

Re: [xwiki-devs] [Issue] Closed: (XWIKI-2796) Non semantic spaces/new lines present in XHTML content should not be reflected in generated xwiki 2.0 syntax code.
by Asiri Rathnayake 17 Nov '08

17 Nov '08

Hi Vincent, On Fri, Nov 14, 2008 at 8:20 PM, Vincent Massol (JIRA) <jira(a)xwiki.org>wrote: > > [ > http://jira.xwiki.org/jira/browse/XWIKI-2796?page=com.atlassian.jira.plugin…] > > Vincent Massol closed XWIKI-2796. > --------------------------------- > > Resolution: Fixed > Great! I'm testing office-importer with this fix in place now. Also I'm setting up the test server, which got bit delayed :( Thanks. - Asiri

1 0

[xwiki-devs] parametrized HQL example?
by Paul Libbrecht 16 Nov '08

16 Nov '08

Hello XWikiers, is there an example usage of xwiki.searchDocuments(java.lang.String parametrizedSqlClause, java.util.List parameterValues) The page: http://platform.xwiki.org/xwiki/bin/view/DevGuide/velocityHqlExamples did not contain this. today I would like to search for a list of documents modified since a given date. thanks in advance paul

2 2

Re: [xwiki-devs] [xwiki-notifications] r14215 - in platform/core/trunk/xwiki-core/src: main/java/com/xpn/xwiki test/java/com/xpn/xwiki
by Sergiu Dumitriu 16 Nov '08

16 Nov '08

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-11-14 15:41:52 +0100 (Fri, 14 Nov 2008) > New Revision: 14215 > > Added: > platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/XWikiContextTest.java > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWikiContext.java > Log: > XWIKI-2837: Class Cache in context is not database aware > Applied patch from Denis Gervalle (just added the base class's wiki if exists) > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWikiContext.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWikiContext.java 2008-11-14 14:41:34 UTC (rev 14214) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWikiContext.java 2008-11-14 14:41:52 UTC (rev 14215) > @@ -407,16 +407,47 @@ > put("mainxwiki", str); > } > > - // Used to avoid recursive loading of documents if there are recursives usage of classes > + /** > + * Used to avoid recurrent loading of documents if there are recurrent usage of classes. > + * > + * @param bclass the class to cache. > + */ > public void addBaseClass(BaseClass bclass) > { > - this.classCache.put(bclass.getName(), bclass); > + String className = bclass.getName(); > + if (bclass.getWiki() != null) { > + StringBuffer sb = new StringBuffer(bclass.getWiki()); > + sb.append(":"); > + sb.append(className); > + className = sb.toString(); > + } else if (getDatabase() != null) { > + StringBuffer sb = new StringBuffer(getDatabase()); > + sb.append(":"); > + sb.append(className); > + className = sb.toString(); > + } > + > + this.classCache.put(className, bclass); > } > > - // Used to avoid recursive loading of documents if there are recursives usage of classes > + /** > + * Used to avoid recurrent loading of documents if there are recurrent usage of classes. > + * > + * @param name the local name (without the wiki identifier) of the xclass. The wiki identifier is taken from > + * {@link #getDatabase()}. > + * @return the cached xclass or null if the cache does not contains any xclass. > + */ > public BaseClass getBaseClass(String name) > { > - return this.classCache.get(name); > + String classname = name; > + if (getDatabase() != null) { > + StringBuffer sb = new StringBuffer(getDatabase()); > + sb.append(":"); > + sb.append(name); > + classname = sb.toString(); > + } > + > + return this.classCache.get(classname); > } > > // Used to avoid recursive loading of documents if there are recursives usage of classes > Unfortunately this has a bad side effect: org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session: [com.xpn.xwiki.doc.XWikiDocument#-34276813] Lots of errors were displayed when starting the server, caused by http://jira.xwiki.org/jira/browse/XWIKI-2842 and the fact that although the class cache sees XWiki.Tags and xwiki:XWiki.Tags as different entities, in Hibernate they represent the same entity. -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 2

[xwiki-devs] [proposal] Add countDocuments API method, add 'hidden' document property
by Sergiu Dumitriu 16 Nov '08

16 Nov '08

Hi devs, The first proposal is about introducing two $xwiki.countDocuments methods, one that accepts a simple hql query, and one that accepts a parametrized query and a list of parameter values. These work like searchDocuments, but instead of prefixing the query fragment with 'select doc.fullName from XWikiDocument as doc', it will prefix it with 'select count(*) from XWikiDOcument as doc'. This will allow to count documents without using a programming-protected query, and without retrieving all the documents and count the results. Such a method is needed for paging results, for example. The second proposal is a temporary hack for hiding documents. The idea is to add a new field in the XWikiDocument class, 'hidden', which will be automatically used in searchDocuments and countDocuments to filter out special documents. This is a workaround until we will be able to tag special documents or spaces, and will allow to create special documents needed for an application inside the main application's space, instead of the generic XWiki space. Such hidden pages won't appear in normal search results, the index page or the navigation panel. To show these documents (for admins, for example) we could add another searchDocuments method which accepts a boolean parameter that enables or disables the filter on the 'hidden' property. -- Sergiu Dumitriu http://purl.org/net/sergiu/

6 19

[xwiki-devs] updating a wiki... yet another reason for source-as-source!
by Paul Libbrecht 15 Nov '08

15 Nov '08

Hello XWikiers, I am trying to sketch a best scenario for the update of our curriki derivative. As is common in most xwiki-based sites, i2geo is based on a distribution that builds from a multi-module source-directory into a web-archive and an xwiki-archive. What's in the xwiki archive and in the web-archive is tuned by installers. These tunes need to be brought back to source: for webapp changes it's often easy, for wiki-pages changes it is a matter of xar export and expansion in principle. Now comes the time to update because curriki has released anew. How can I do it? Ideally simply run svn update on the source which has been brought back of all changes and rebuild and redeploy. Generally there will be conflicts and they should be address individually. For the xwiki documents this is highly uncomfortable and this speaks again in favour of detached source-files in xwiki sources: the svn update should update the source code of documents as a source and conflicts should be solved there. Any advance in this direction? paul

1 0

[xwiki-devs] WebDAV integration: status and next steps
by Sergiu Dumitriu 14 Nov '08

14 Nov '08

Hi devs, Asiri, I finally found the time to apply Asiri's patch to integrate the WebDAV module in the default XE, and here are some comments/ideas: - I like this new feature, combined with KDE. I was able to start Konqueror, point it to localhost, and start editing wiki files in my favorite editor, Kate. - It seems to be much faster than the web view, which suggests that indeed most of the time is spent on rendering. - I wasn't able to create new wiki documents. Is there something special I should do? Is it not supported yet? Is Konqueror alone guilty? - Also, the error I get doesn't seem right (File already exists), since the file I want to create definitely doesn't exist. - Since it uses Basic authentication, we should advertise that authentication is not secure, thus it should only be used inside trusted intranets, over VLANs or over SSL. Code related: - Looking a bit over the code, I noticed that we're using only a bit from the jackrabit-jcr-server library, and I was wondering if it would be possible to refactor all the code that needs it to use something else, so that we have one dependency in minus. - Also, I noticed that you're using slf4j as the logging framework, which doesn't fit with the rest of the XWiki code, since we're using commons-logging. Still, this is also the framework used by jackrabbit, so we can't get rid of it completely. Asiri, could you update the code to use commons-logging? - Although there are integration tests, some unit tests would be great. I know it's hard for the moment to do proper unit testing, since most of the code works closely with the old core, which doesn't contribute to a good testing scenario. Congratulations for the good work, Asiri! -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 2

Re: [xwiki-devs] [Issue] Closed: (XWIKI-2771) Integrate xwiki-webdav into XE
by Asiri Rathnayake 14 Nov '08

14 Nov '08

On Fri, Nov 14, 2008 at 6:46 AM, Sergiu Dumitriu (JIRA) <jira(a)xwiki.org>wrote: > > [ > http://jira.xwiki.org/jira/browse/XWIKI-2771?page=com.atlassian.jira.plugin…] > > Sergiu Dumitriu closed XWIKI-2771. > ---------------------------------- > > Tests: [Integration] > Fix Version/s: 1.7 M3 > Resolution: Fixed > > Done. Thanks for the good work, Asiri. > You are welcome. And many thanks for reviewing the patch. I have another patch for webdav xwiki-ui integration, need to dig it up now ;) - Asiri

1 0

[xwiki-devs] [vote] Encoding for filesystem resources
by Sergiu Dumitriu 13 Nov '08

13 Nov '08

Hi devs, Until now, filesystem resources were not forced to a specific encoding (except ResourceBundle translation resources, which are forced by the spec to contain only ISO-8859-1 characters and unicode escapes). And the number of files not being ASCII was kept to 0, thus a policy wasn't needed. However, it is better to set a rule, in case third party developers need to place non-ascii characters in source files, such as JavaScript or CSS extensions and skin files. So, here are some proposed rules we should make public on our dev site, and follow ourselves. 1. All Java source files must contain only ASCII chars, unicode escapes inside strings when needed, and xml entities in javadocs. Since we don't use @author tags, this should not be a problem. 2. All translation files contain only ASCII chars and unicode escapes (stronger than the spec). 3. All wiki documents sources must be stored in UTF-8. 4. Other XML files should always specify their encoding in the <?xml header, and it should be as often as possible UTF-8. 5. All other textual resources must be stored in UTF-8, minimizing the use of non-ASCII chars. The changes are that: 1: This is the practice we were already using, but we didn't have a written rule on this. 2: This is the practice we were already using, but we didn't have a written rule on this, except in the "Contributing" page. 3: Wiki sources are currently in ISO-8859-1 because our default package ships with that encoding, and XML exports are usually done from the default package. This is not really a problem, since the XML reader can detect and use the encoding specified inside the document itself. 4: Not a strong requirement, but a suggestion only. Most of our XMLs are currently using ISO-8859-1, but since they only contain ASCII chars, it doesn't really make a difference. 5: There was no rule on this, and the resources were always read using the system encoding, which means that our package is not 100% portable now, unless we force people to set a specific JVM encoding. I'd like to force UTF-8 as the encoding for this kind of resources since it is hard to represent all the characters in 8bit encodings. WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

5 7