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 <!--
errordescription:(description)--> 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 <!--starterror:Unknown macro: unknown--><!--
startmacro:unknown|-||-|--><!--stopmacro--><!--stoperror--> macro</p>
.#-----------------------------------------------------
.expect|xwiki
.#-----------------------------------------------------
Unknown {{unknown/}} macro
.#-----------------------------------------------------
.input|xhtml/1.0
.#-----------------------------------------------------
<html><p>Unknown <!--starterror:Unknown macro: unknown--><!--
startmacro:unknown|-||-|--><!--stopmacro--><!--stoperror--> 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
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
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
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
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/
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/
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
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/
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
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/