Hi
Because of all the issues I have trying to convert XWiki Blog to 2.0 I was wondering if it wouldn't be better to rewrite it in Groovy than trying to convert it?
Any feedback is welcomed.
Thanks - Andy Schaefer
Hi
When I try to convert BlogCode (at least that is what I think) I get this strange error:
Caused by: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'searchDocuments' in class com.xpn.xwiki.api.XWiki threw exception com.xpn.xwiki.XWikiException: Error number 3223 in 3: Exception while searching documents with SQL [select distinct doc.space, doc.name, doc.name and isPublished.value = 1 and hidden.value <> 1 and isPublished.value = 0 order by publishDate.value from XWikiDocument as doc , BaseObject obj where (doc.hidden <> true or doc.hidden is null) and obj.name = doc.fullName and obj.className = 'Blog.CategoryClass' order by doc.name and isPublished.value = 1 and hidden.value <> 1 and isPublished.value = 0 order by publishDate.value desc]
Wrapped Exception: unexpected token: from near line 1, column 148 [select distinct doc.space, doc.name, doc.name and isPublished.value = 1 and hidden.value <> 1 and isPublished.value = 0 order by publishDate.value from com.xpn.xwiki.doc.XWikiDocument as doc , com.xpn.xwiki.objects.BaseObject obj where (doc.hidden <> true or doc.hidden is null) and obj.name = doc.fullName and obj.className = 'Blog.CategoryClass' order by doc.name and isPublished.value = 1 and hidden.value <> 1 and isPublished.value = 0 order by publishDate.value desc] at Blog.Test 2b[line 4, column 35]
It seems for whatever reason XWiki is mixing up some SQL statements. Any ideas how I can figure out where this happens (the stacktrace is not helpful) and then what is going wrong.
I personally think that somehow the velocity template is messed up but I could be completely wrong.
Thank you - Andy Schaefer
Currently I am working on converting the Blog application to XWiki Syntax 2.0. After having spent quite some time trying to figure out how everything works together I figured out that the automatic conversion tools makes many mistakes with Velocity code (BlogCode, CreatePost).
To resolve that I have to copy away the old code, convert to 2.0, take the new code and run a diff on it to figure out what has changed and then undo some of the changes. Because I will not be the only one trying to do that I was wondering if there is a tool out that that could automate this process:
- Save the old code
- Convert to 2.0
- Display a diff where the user can do final adjustments
What do you think?
-Andy Schaefer
Hello,
I have upgraded XE from 1.8 to 1.9 and i'm facing this problem:
- the documents added as attachments are not usable anymore (images can't be
viewed anymore as well as .ppt presentations).
Is there a fix available for this problem?
--
View this message in context: http://n2.nabble.com/Upgrade-from-XE-1.8-to-1.9-problems-tp3174142p3174142.…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi,
On Thu, Jul 2, 2009 at 2:50 PM, Anca Paula Luca
<ancapaula.luca(a)xwiki.com>wrote:
>
> alexmaru (SVN) wrote:
> > Author: alexmaru
> > Date: 2009-07-01 18:16:45 +0200 (Wed, 01 Jul 2009)
> > New Revision: 21750
> >
> > Added:
> > sandbox/gsoc/widgets/src/main/XWikiFox/
> > sandbox/gsoc/widgets/src/main/XWikiFox/XWikiFox.xpi
>
> This is not needed. Redundant is bad because it takes up unneeded space,
> brings
> unneeded complexity to the sources tree, and it can cause unsynchronized
> sources
> with packed versions. You should have a maven build create this pack for
> you.
>
> > sandbox/gsoc/widgets/src/main/XWikiFox/chrome.manifest
> > sandbox/gsoc/widgets/src/main/XWikiFox/chrome/
> > sandbox/gsoc/widgets/src/main/XWikiFox/chrome/XWikiFox.jar
>
> Neither is this, same, you can have a maven build create it for you. Or,
> for the
> start, use just the sources, it's not mandatory to pack them in a .jar.
>
Have a look at
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-tools/trunk/foxwiki/
specially:
http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-tools/trunk/foxwiki/distr…
I created a maven assembly to bundle foxwiki.xpi (with help from vincent)
long time ago. you just have to use it.
Thanks.
- Asiri
Hello Devs,
This is about implementing support for creating rendering macros by editing
wiki pages! The corresponding JIRA issue is
http://jira.xwiki.org/jira/browse/XWIKI-3213.
Introduction
------------
There are two main xwiki classes involved: XWiki.WikiMacro &
XWiki.WikiMacroParameter. Fields of these classes are as below:
XWiki.WikiMacro
|
|-> name (Name of the macro)
|
|-> description (Short description about the macro - for display purposes)
|
|-> content (Macro content, this is what will be executed when the macro is
invoked, can be any xwiki/2.0 content)
XWiki.WikiMacroParameter
|
|-> name (Name of the parameter)
|
|-> macro (Name of the macro to which this parameter applies to)
|
|-> description (Description of this macro parameter - for display purposes)
|
|-> mandatory (boolean value indicating if this parameter is mandatory)
So the basic idea is, when a user saves (or updates) a page containing an
Object of XWiki.WikiMacro type, we will dynamically register (or
re-register) a macro as defined by that object.
Question:
1. What about macro name conflicts? Should we ask macro name to be unique?
(This can be done if we introduce a document sheet and a template for
creating macros)
Implementation steps
--------------------
1. The original idea was to create XWiki.WikiMacro &
XWiki.WikiMacroParameter classes upon XE startup (if those classes are not
present). But I would like to start a little different here, we create
xwiki-application-wikimacro application to host these two documents and
later remove this app and add the initialization code. This will allow me to
focus on other more important tasks upfront and meanwhile i can make any
changes easily to these wiki pages if they are kept inside an application.
2. Document update / save event listening & Macro registration can be
implemented using the ObservationManager and dynamic component registration
mechanisms.
- Currently ObservationManager can only send general document save / update
events. We can either use these events and filter only those we are
interested (ones where an XWiki.WikiMacro object is saved / updated) OR we
can introduce a new event like ObjectChangedEvent (which would be
constructed given a class name) that is fired by xwiki-core appropriately.
- This document event listening & dynamic macro component registration code
will be put inside xwiki-rendering/xwiki-rendering-macro-wikibridge
3. Finally DefaultMacroManager needs to be updated so that it listens to
ComponentManager events and filters out those events corresponding to Macro
component registrations and updates the internal macro cache.
So, above is the approach I have in mind for implementing the wiki-macro
bridge. If you have any comments, please let me know.
Thanks.
- Asiri
I seem to recall some discussion about automatic plugin startup being planned. One of the really nice things about confluence is that you can add plugins with just a jar file and don't have to edit .xml configuration files. This also makes upgrades of either the plugin or wiki easier as everything is in the jar.
Was anything like this added for 2.0 or possibly planned in the near future?
--
Glenn