Re: [xwiki-devs] [VOTE] XWiki.org governance (take 2)
as a non committer, I agree with caleb: go on and let's manage incoming issues... seems ok Pascal On Tue, Mar 16, 2010 at 5:01 PM, Marius Dumitru Florea mariusdumitru.flo...@xwiki.com wrote: +1 Thanks, Marius Vincent Massol wrote: ok I've now reworked the page based on the feedback received so far. Please recast your votes if they have changed. Thanks -Vincent On Mar 16, 2010, at 10:22 AM, Vincent Massol wrote: Hi everyone, I'd like to move this topic forward. Thus I've now created a draft of the XWiki.org Governance that gathers what I had proposed at http://markmail.org/message/fxqvprtbb5vyog6g The Governance page is currently at: http://dev.xwiki.org/xwiki/bin/view/Drafts/Governance Please review it and vote. The idea is then to move it to http://dev.xwiki.org/xwiki/bin/view/Community/Governance in a few days. As usual, non committers don't have binding votes but are still very much encouraged to give their opinions. Their voice is especially more important on this topic since most committers are from XWiki SAS and thus I feel we need at least a general agreement from the community at large before doing anything. Thanks a lot -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] right problem when creating a new wiki with XEM 2.2.1
Ok I looked into the 2.2.2 XAR and I find backupPacktrue/backupPack So it is already set to true I tried to use Replace history but it keeps Guest rights... So i first import the XAR with guest rights in order to have the XWiki.Admin user! Then I login as admin and I re-import the XAR again using replace history and then everything is importer as Admin... Like this, it prevents from logging as superadmin that I don't really like! Anyway, there might be a light issue around there. Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] right problem when creating a new wiki with XEM 2.2.1
On Sat, Mar 6, 2010 at 2:24 PM, Thomas Mortagne
thomas.morta...@xwiki.comwrote:
On Fri, Mar 5, 2010 at 01:26, Pascal Voitot Dev
pascal.voitot@gmail.com wrote:
Hello,
I installed an XEM 2.2.1 on glassfish + mysql... OK
Then I imported xwiki-enterprise-manager-wiki-administrator-2.2.1.xar
into
the Wiki... it works and I get the XEM pages...
I login as XWiki.Admin
I try to create a new Wiki and I get this exception
[#|2010-03-05T01:16:21.719+0100|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=25;_ThreadName=Thread-1;|2010-03-05
01:16:21,718 [
http://MY_IP:8080/xwiki/bin/view/WikiManager/CreateNewWiki?wikiname=mywikiXWiki.XWikiServerClass_0_wikiprettyname=mywikiXWiki.XWikiServerClass_0_description=XWiki.XWikiServerClass_0_server=my-adress.infoXWiki.XWikiServerClass_0_owner=XWiki.AdminXWiki.XWikiServerClass_0_owner=wikitemplate=readersusers=xwiki%3AXWiki.Adminwritersusers=xwiki%3AXWiki.Adminadminsusers=xwiki%3AXWiki.Adminactioncreate=Create
]
ERROR kimanager.WikiManagerPluginApi - Wiki
[Main.WebHome,my-adress.info,XWiki.Admin]
creation failed
com.xpn.xwiki.plugin.wikimanager.WikiManagerException: Error number 9001
in
5: com.xpn.xwiki.plugin.wikimanager.WikiManagerPlugin: You dont have
right
to create wiki [{0}]
at
com.xpn.xwiki.plugin.wikimanager.WikiManagerPluginApi.createNewWiki(WikiManagerPluginApi.java:204)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:389)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:378)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:270)
at
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:252)
at
org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:493)
at
org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71)
at
org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142)
at
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
at
org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:191)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:156)
at
com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:116)
at
com.xpn.xwiki.render.XWikiVelocityRenderer.render(XWikiVelocityRenderer.java:93)
at
com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:272)
at
com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:202)
at
com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:170)
at
com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderDocument(DefaultXWikiRenderingEngine.java:159)
at
com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:741)
at
com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:758)
at
com.xpn.xwiki.api.Document.getRenderedContent(Document.java:492)
I've seen a closed/Won't fix bug in Jira
http://jira.xwiki.org/jira/browse/XAWM-115 but the given information
brings
no help...
I create a page in Wiki WikiManager as indicated in this bug:
{{velocity}}
#set($xwikicontext = $context.context)
#set($rightService = $xwikicontext.getWiki().getRightService())
* Is the wiki in virtual mode: $xwikicontext.getWiki().isVirtualMode()
* The user [$context.user] has admin rights:
$rightService.hasAdminRights($xwikicontext)
* The user [$context.user] has programming rights:
$rightService.hasProgrammingRights($xwikicontext)
{{/velocity}}
It gives:
Is the wiki in virtual mode: true
The user [XWiki.Admin] has admin rights: true
The user [XWiki.Admin] has programming rights: true
I tried with the template templatexe also but nothing better...
Has anyone encountered the same error as me or any idea?
You should make the the /WikiManager/CreateNewWiki page has been saved
with the proper user, if your XWiki.Admin has programming right edit
and save the page to make sure the page has programming right, maybe
for some
Re: [xwiki-devs] right problem when creating a new wiki with XEM 2.2.1
On Sat, Mar 6, 2010 at 6:13 PM, Thomas Mortagne
thomas.morta...@xwiki.comwrote:
On Sat, Mar 6, 2010 at 18:09, Thomas Mortagne thomas.morta...@xwiki.com
wrote:
On Sat, Mar 6, 2010 at 17:39, Thomas Mortagne thomas.morta...@xwiki.com
wrote:
On Sat, Mar 6, 2010 at 17:17, Pascal Voitot Dev
pascal.voitot@gmail.com wrote:
On Sat, Mar 6, 2010 at 2:24 PM, Thomas Mortagne
thomas.morta...@xwiki.comwrote:
On Fri, Mar 5, 2010 at 01:26, Pascal Voitot Dev
pascal.voitot@gmail.com wrote:
Hello,
I installed an XEM 2.2.1 on glassfish + mysql... OK
Then I imported
xwiki-enterprise-manager-wiki-administrator-2.2.1.xar
into
the Wiki... it works and I get the XEM pages...
I login as XWiki.Admin
I try to create a new Wiki and I get this exception
[#|2010-03-05T01:16:21.719+0100|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=25;_ThreadName=Thread-1;|2010-03-05
01:16:21,718 [
http://MY_IP:8080/xwiki/bin/view/WikiManager/CreateNewWiki?wikiname=mywikiXWiki.XWikiServerClass_0_wikiprettyname=mywikiXWiki.XWikiServerClass_0_description=XWiki.XWikiServerClass_0_server=my-adress.infoXWiki.XWikiServerClass_0_owner=XWiki.AdminXWiki.XWikiServerClass_0_owner=wikitemplate=readersusers=xwiki%3AXWiki.Adminwritersusers=xwiki%3AXWiki.Adminadminsusers=xwiki%3AXWiki.Adminactioncreate=Create
]
ERROR kimanager.WikiManagerPluginApi - Wiki
[Main.WebHome,my-adress.info,XWiki.Admin]
creation failed
com.xpn.xwiki.plugin.wikimanager.WikiManagerException: Error number
9001
in
5: com.xpn.xwiki.plugin.wikimanager.WikiManagerPlugin: You dont have
right
to create wiki [{0}]
at
com.xpn.xwiki.plugin.wikimanager.WikiManagerPluginApi.createNewWiki(WikiManagerPluginApi.java:204)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:389)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:378)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:270)
at
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:252)
at
org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:493)
at
org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71)
at
org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142)
at
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
at
org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:191)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:156)
at
com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:116)
at
com.xpn.xwiki.render.XWikiVelocityRenderer.render(XWikiVelocityRenderer.java:93)
at
com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:272)
at
com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:202)
at
com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:170)
at
com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderDocument(DefaultXWikiRenderingEngine.java:159)
at
com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:741)
at
com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:758)
at
com.xpn.xwiki.api.Document.getRenderedContent(Document.java:492)
I've seen a closed/Won't fix bug in Jira
http://jira.xwiki.org/jira/browse/XAWM-115 but the given
information
brings
no help...
I create a page in Wiki WikiManager as indicated in this bug:
{{velocity}}
#set($xwikicontext = $context.context)
#set($rightService = $xwikicontext.getWiki().getRightService())
* Is the wiki in virtual mode:
$xwikicontext.getWiki().isVirtualMode()
* The user [$context.user] has admin rights:
$rightService.hasAdminRights($xwikicontext)
* The user [$context.user] has programming rights:
$rightService.hasProgrammingRights($xwikicontext)
{{/velocity}}
It gives
[xwiki-devs] right problem when creating a new wiki with XEM 2.2.1
Hello,
I installed an XEM 2.2.1 on glassfish + mysql... OK
Then I imported xwiki-enterprise-manager-wiki-administrator-2.2.1.xar into
the Wiki... it works and I get the XEM pages...
I login as XWiki.Admin
I try to create a new Wiki and I get this exception
[#|2010-03-05T01:16:21.719+0100|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=25;_ThreadName=Thread-1;|2010-03-05
01:16:21,718 [
http://MY_IP:8080/xwiki/bin/view/WikiManager/CreateNewWiki?wikiname=mywikiXWiki.XWikiServerClass_0_wikiprettyname=mywikiXWiki.XWikiServerClass_0_description=XWiki.XWikiServerClass_0_server=my-adress.infoXWiki.XWikiServerClass_0_owner=XWiki.AdminXWiki.XWikiServerClass_0_owner=wikitemplate=readersusers=xwiki%3AXWiki.Adminwritersusers=xwiki%3AXWiki.Adminadminsusers=xwiki%3AXWiki.Adminactioncreate=Create]
ERROR kimanager.WikiManagerPluginApi - Wiki
[Main.WebHome,my-adress.info,XWiki.Admin]
creation failed
com.xpn.xwiki.plugin.wikimanager.WikiManagerException: Error number 9001 in
5: com.xpn.xwiki.plugin.wikimanager.WikiManagerPlugin: You dont have right
to create wiki [{0}]
at
com.xpn.xwiki.plugin.wikimanager.WikiManagerPluginApi.createNewWiki(WikiManagerPluginApi.java:204)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:389)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:378)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:270)
at
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:252)
at
org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:493)
at
org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71)
at
org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142)
at
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
at
org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87)
at
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:191)
at
org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:156)
at
com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:116)
at
com.xpn.xwiki.render.XWikiVelocityRenderer.render(XWikiVelocityRenderer.java:93)
at
com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:272)
at
com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:202)
at
com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:170)
at
com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderDocument(DefaultXWikiRenderingEngine.java:159)
at
com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:741)
at
com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:758)
at com.xpn.xwiki.api.Document.getRenderedContent(Document.java:492)
I've seen a closed/Won't fix bug in Jira
http://jira.xwiki.org/jira/browse/XAWM-115 but the given information brings
no help...
I create a page in Wiki WikiManager as indicated in this bug:
{{velocity}}
#set($xwikicontext = $context.context)
#set($rightService = $xwikicontext.getWiki().getRightService())
* Is the wiki in virtual mode: $xwikicontext.getWiki().isVirtualMode()
* The user [$context.user] has admin rights:
$rightService.hasAdminRights($xwikicontext)
* The user [$context.user] has programming rights:
$rightService.hasProgrammingRights($xwikicontext)
{{/velocity}}
It gives:
Is the wiki in virtual mode: true
The user [XWiki.Admin] has admin rights: true
The user [XWiki.Admin] has programming rights: true
I tried with the template templatexe also but nothing better...
Has anyone encountered the same error as me or any idea?
regards
Pascal
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [proposal][discussion]Object properties references
On Wed, Jan 13, 2010 at 1:42 PM, Anca Luca ancapaula.l...@xwiki.com wrote: Hi devs, Short story: 1/ add the CLASS, OBJECT, PROPERTY EntityTypes in the model +1 +1 : it would be interesting and it would be nice to allow class inheritance also (in order to inherit properties from another class for example) and to be able to refactor a class by removing properties (This is a feature I really miss... I had studied this but this feature has never appeared in your roadmap) 2/ serialization for referencing a property of an object a) wiki:Space.Page^className[objectNumber]#property b) wiki:Space.Page^className#objectNumber$property +0.75 for b) Long story: 1/ I would need to extend the EntityReference to be able to target a property in an object in a document. For this, I will need to add /** * Represents a Class Entity */ CLASS, /** * Represents an Object Entity. */ OBJECT, /** * Represents a Property Entity */ PROPERTY, in the EntityType. Although I would prefer an extensible framework that would allow to extend the possible entity types without changing an enum in the platform (for any API user to be able to define its own references), I think this is fairly extensible (these are key concepts in the xwiki model and I don't think they would be changed that soon, and their interpretation is flexible, they could be combined with any parent to generate either references to class definitions or instances). here's my +1 for this. I don't know the reference model so don't know if it's possible but it would be a nice feature 2/ I would also need a 'standard' string serialization for these. Now, there's also the option to do it in my own module (annotations) because only I need it ftm, but I prefer to have a platform wide approach. Opinions? There are 2 choices, with a potentially different combination of separators: a/ wiki:Space.Page^className[objectNumber]#property pros: it's a suggestive way to access objects by number ([] is the standard syntax for array indexed access and the objects are accessed by index), [] is supported by JCR so maybe we should support it too cons: [] is somewhat inconsistent with all other separators which are just one separator, to the left (right) of the entity, harder to implement the [] separators on the current framework b/ wiki:Space.Page^className#objectNumber$property pros: inline with the separator usage we already have (and easier to implement for this reason), could be easier refactored to contain an object name instead of the number cons: $ separator can collide with velocity syntax (can potentially cause trouble when used in velocity -- an alternative could be the pipe |), could be harder to drop the object number part of the reference to refer a property in a class (if wanted, in the future) I have no other argument between a) and b) but the implementation speed one, so I'd go for a b)-like approach, in the spirit of the current separators. WDYT? Thanks, Anca ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [VOTE] new APIs for XWikiDocument
does it mean all scripts using the older functions will need to be updated? Pascal On Sat, Jan 9, 2010 at 12:43 PM, Vincent Massol vinc...@massol.net wrote: Hi devs, As I mentioned already I'm modifying all APIs in XWikiDocument to use References (I'm adding new APIs and deprecating old ones). While doing this I'm also fixing names for new APIs. So far I'm modifying 3 things: - replace Vector by List - replace Object by XObject in API. For example: getxWikiObjects() -- getXObjects(), getObjects(String classname) -- getXObjects(DocumentReference classnameReference) - replace Class by XClass in API. For example: getxWikiClasses -- getXClasses() Note1: I wanted to use getObject and getClass but getClass is reserved already. Note2: in the new model we won't have this problem since we'll intelligently use another name for object definitions, something like ObjectDefinition :). We could also change Object but it's less problematic and it's probably ok to keep it. Here's my +1 Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [VOTE][Model] Do we need to change Entity Reference Factory to some other name? And which one?
On Wed, Jan 6, 2010 at 3:27 PM, Thomas Mortagne
thomas.morta...@xwiki.comwrote:
On Wed, Jan 6, 2010 at 15:21, Vincent Massol vinc...@massol.net wrote:
Hi,
This is the current interface:
public interface EntityReferenceFactoryT
{
/**
* @param entityReferenceRepresentation the representation of an
entity reference (eg as a String)
* @param type the type of the Entity (Document, Space, Attachment,
Wiki, etc) to extract from the source
* @return the resolved reference as an Object
*/
EntityReference createEntityReference(T entityReferenceRepresentation,
EntityType type);
}
Now we have 2 different implementations:
- one for which T = String
- one for which T = EntityReference (our normalizer)
In term of usage this means:
EntityReference ref = factory.createEntityReference(wiki:space.page,
EntityType.DOCUMENT);
EntityReference ref = factory.createEntityReference(documentReference,
EntityType.DOCUMENT);
The last example is used to normalize the passed reference, convert it
into the type specified by the second parameter, filling the blanks.
I feel that Factory is no longer an appropriate name, especially for the
second use case. WDYT?
IMO a better name would be Resolver, Normalizer, or Converter. Any other
better name? (I haven't put Parser since I don't believe it's correct).
Examples:
EntityReference ref = resolver.resolve(wiki:space.page,
EntityType.DOCUMENT);
EntityReference ref = resolver.resolve(documentReference,
EntityType.DOCUMENT);
EntityReference ref = normalizer.normalize(wiki:space.page,
EntityType.DOCUMENT);
EntityReference ref = normalizer.normalize(documentReference,
EntityType.DOCUMENT);
EntityReference ref = converter.convert(wiki:space.page,
EntityType.DOCUMENT);
EntityReference ref = converter.convert(documentReference,
EntityType.DOCUMENT);
It's quite a lot of work to change what I have put but since this is an
important API we need to be sure of what we want since we won't be able to
change it later on.
I'm +1 for Resolver.
+1 for Resolver
+1 for resolver also... normalizer is a bit too much abstract IMO
WDYT?
Thanks
-Vincent
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] Smart GWT 2.0 released
not only for them: I use it in my wikis and they have some really great datagrids which integrates perfectly with some XWiki JSON datasources ;) Pascal On Thu, Dec 31, 2009 at 11:34 AM, Vincent Massol vinc...@massol.net wrote: fyi, mostly for our wysiwyg developers: http://www.ongwt.com/post/2009/12/15/Smart-GWT-2.0-has-just-been-released Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] Merry Christmas and Happy New Year 2010
Thank and happy everything also and see you next year for new stories ;) Pascal On Tue, Dec 22, 2009 at 11:53 AM, Vincent Massol vinc...@massol.net wrote: Hi everyone, Just a quick note to wish everyone in the XWiki project very happy festivities and a happy next year for 2010. The XWiki project has seen exciting times in 2009 as described on: http://massol.myxwiki.org/xwiki/bin/view/Blog/XWikiIn2009 Let's all make 2010 even better :) Take care, -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [VOTE] new UI for import
see below On Tue, Dec 22, 2009 at 5:05 PM, Anca Luca ancapaula.l...@xwiki.com wrote: Hi Jerome/Cati, I like them (great, fancy import UI), +1 for D, +1 for A +1 for D since I can barely see any highlighting on my machine for A (it might be my display, etc, but it means it's not good enough contrast). However, I would have some observations: 1/ I think we should keep the select all / deselect all buttons. I understand that when you select/deselect a space, you automatically get all pages in that space selected/deselected (which is very cool), but I think the select all/deselect all still have a use case, for when there are a lot of spaces. The way I used the import until now was either to import all, or just 1-2 pages (so I used the select all / deselect all buttons intensively). I totally agree... I export/import some spaces with thousands of documents and I really appreciate Select All/Deselect All... 2/ I find the 6 items frame for the pages view a bit small. Is that fixed? or it would extend to fit its contents? otherwise put, if there's a space with 50 pages and I want to have a look at the listing before importing, would I need to scroll a lot? Otherwise great job, it's good to see improvements in this area. Happy hacking, Anca nice job anyway regards Pascal On 12/22/2009 04:59 PM, Jerome Velociter wrote: Hi all, Caty made some cool proposals based on the work I've started on a new import UI ( http://jira.xwiki.org/jira/browse/XWIKI-4692 ). You can check them out here : http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ImporterProposal My preference goes for A. I like C too. Which one do you prefer? Thanks, Jerome. ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] mimic relational database one to many relations
Just for information, you can simulate a ONE2MANY relation with dblists. As far as I can remember (I don't have my XWiki in front of me): you create a class CompanyClass with a field that you will manage by yourself as a unique primary key. For example the property name of the company. Each company has a different name. Then you create a class PersonClass with a DBStringList property called company and in the form, you set XWikiClass to CompanyClass and property to name and you set the way to choose the company to select. Then you create some CompanyClass Objects. So when you create a new PersonClass Object, in the inline editor, you should see a list with all the companies names you created. In fact, XWiki performs a HQL request to retrieve a list of the name properties for all CompanyClass objects. It is not a real DB relation as you can imagine in hibernate because there is no physical relationship between 2 table Person and Company. So if a Person has a company property set to a given value and then you change this Company object property name, the Person is not aware about it and will keep the former name. Anyway, this is quite practical in most cases. You can even manage multiple values with a separator. I use it intensively on my side and I love it :) Pascal On Fri, Dec 18, 2009 at 10:49 AM, Helenc truck...@hotmail.com wrote: Hi All, I would really like to be able to mimic one to many relations through classes somehow? I noticed there have been a few posts about how one might go about such a thing using dblists, it's not clear yet to me how I could implement such a thing? I'm wondering if any demo application exist that might give me more of a clue? Let's say I want to set up a simple one to many relationship between information about a company and then individuals who worked for that company. How would I go about such a thing? Do I setup a companyclass and a personsclass and then link them somehow with the dblist? What's the best user interface setup for this too so it's easy for users to enter company and people data? Are there any examples of HQL queries about how one would then search to display individuals details along with elements of their companies details? Referencing the relationship? Or is there another way to do this? Any pointers would be very much appreciated? Thanks Helen -- View this message in context: http://n2.nabble.com/mimic-relational-database-one-to-many-relations-tp4185725p4185725.html Sent from the XWiki- Dev mailing list archive at Nabble.com. ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Proposal] Resource vs Item vs ItemResource vs Model Name vs Path vs Reference
If you look in semantic web definitions, the difference between an entity and a resource is really hard to tell:) Entity seems to be the most generic word to describe something that exists or has existed. On wikipedia, i found this definition: A *resource* is any physical or virtual entity of limited availability, or anything used to help one earn a living.[*citation neededhttp://en.wikipedia.org/wiki/Wikipedia:Citation_needed *] In most cases, commercial or even ethic factors require resource allocation http://en.wikipedia.org/wiki/Resource_allocation through resource management http://en.wikipedia.org/wiki/Resource_management. But I don't really like entity because nowadays, this is really associated to a persisted entity and no more to a thing of any type... Pascal On Thu, Dec 17, 2009 at 9:31 PM, Caleb James DeLisle calebdeli...@lavabit.com wrote: Hi, Big +1 for getUUID() and storing UUID as byte[] and returning java.util.UUID Storage as byte[] will improve db load times. Whatever you like for a name is fine for me but I would caution against over generic words such as Model, Context, Factory, and Manager because when I first began reading the source, I often found these terms unhelpful. Perhaps ObjectReference instead of ModelReference? This would make sense if and when Document, Space, Attachment, and Wiki extend Object. Caleb Vincent Massol wrote: On Dec 17, 2009, at 3:08 PM, Fabio Mancinelli wrote: On Dec 17, 2009, at 1:48 PM, Vincent Massol wrote: Proposal === I'd like to propose ModelReference for the base object and then DocumentReference, SpaceReference, WikiReference, AttachmentReference. Note: This is different from Identity which is unique (a UUID). References do not point to unique objects. I am not sure of having understood the note. In particular what you mean when you say references do not point to unique objects The way I view it is that an object (or Entity or Resource) will have 2 methods: - getReference() (corresponds to Node.getPath() in JCR I believe) - getUUID() In other words, it's possible to have several References pointing to the same object (or Entity or Resource). This is very useful for implementing renames for example. In addition, FTM I'm not sure if a Reference should include the version I need for think a bit more about this since I'm not 100% sure. If you have ideas let me know. Thanks -Vincent Reference makes sense to me since it means what it means... :) For example the API: Document getDocument(DocumentReference) is pretty clear IMO. I would say ResourceReference for the base object and DocumentReference, SpaceReference, WikiReference, AttachmentReference for the specific resource type references. -Fabio ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Proposal] Resource vs Item vs ItemResource vs Model Name vs Path vs Reference
On Thu, Dec 17, 2009 at 11:07 PM, Sergiu Dumitriu ser...@xwiki.com wrote: On 12/17/2009 10:30 PM, Pascal Voitot wrote: If you look in semantic web definitions, the difference between an entity and a resource is really hard to tell:) Entity seems to be the most generic word to describe something that exists or has existed. On wikipedia, i found this definition: A *resource* is any physical or virtual entity of limited availability, or anything used to help one earn a living.[*citation neededhttp://en.wikipedia.org/wiki/Wikipedia:Citation_needed *] In most cases, commercial or even ethic factors require resource allocationhttp://en.wikipedia.org/wiki/Resource_allocation through resource managementhttp://en.wikipedia.org/wiki/Resource_management. I also tend to associate Resource with something that can be measured and priced, like water or wood. But I don't really like entity because nowadays, this is really associated to a persisted entity and no more to a thing of any type... How come? Why do you associate the persisted feature? And isn't it good, since the model will be persisted in the storage? Tell any java developer:entity and he will speak about persistence :)... But you're right, it's not so bad. Anyway, entity always gives me the impression of dealing with some thing. You know in french we have a word to represent anything: we say truc... entity is a bit like that ;) Pascal On Thu, Dec 17, 2009 at 9:31 PM, Caleb James DeLisle calebdeli...@lavabit.com wrote: Hi, Big +1 for getUUID() and storing UUID as byte[] and returning java.util.UUID Storage as byte[] will improve db load times. Whatever you like for a name is fine for me but I would caution against over generic words such as Model, Context, Factory, and Manager because when I first began reading the source, I often found these terms unhelpful. Perhaps ObjectReference instead of ModelReference? This would make sense if and when Document, Space, Attachment, and Wiki extend Object. Caleb Vincent Massol wrote: On Dec 17, 2009, at 3:08 PM, Fabio Mancinelli wrote: On Dec 17, 2009, at 1:48 PM, Vincent Massol wrote: Proposal === I'd like to propose ModelReference for the base object and then DocumentReference, SpaceReference, WikiReference, AttachmentReference. Note: This is different from Identity which is unique (a UUID). References do not point to unique objects. I am not sure of having understood the note. In particular what you mean when you say references do not point to unique objects The way I view it is that an object (or Entity or Resource) will have 2 methods: - getReference() (corresponds to Node.getPath() in JCR I believe) - getUUID() In other words, it's possible to have several References pointing to the same object (or Entity or Resource). This is very useful for implementing renames for example. In addition, FTM I'm not sure if a Reference should include the version I need for think a bit more about this since I'm not 100% sure. If you have ideas let me know. Thanks -Vincent Reference makes sense to me since it means what it means... :) For example the API: Document getDocument(DocumentReference) is pretty clear IMO. I would say ResourceReference for the base object and DocumentReference, SpaceReference, WikiReference, AttachmentReference for the specific resource type references. -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Proposal] Governance for xwiki.org
Hello, I don't know if pascal is me or someone else but I'm also one Pascal so I answer ;) Sorry for the long mail... I agree with this kind of governance as long as XWiki.org keeps fully free and brings the best and latest code with LGPL license. I agree that companies contributing to XWiki could be rewarded by having some visibility on xwiki.org site. I agree with the fact that XWiki SAS needs to earn more money based on XWiki.org because if it earns more money, XWiki will go further etc... The limit between commercial product and free software is not easy to define and to manage... Being an opensource company is really hard, isn't it? The only thing I want XWiki SAS is to keep going as a real opensource company for which the community project is the base of everything and which contains the best of breed of XWiki SAS knowledge. I would be disappointed to see you becoming a company such as the ones I can see for which opensource is just a facade or a marketting argument without any real community development and support. Jboss is not exactly one of those but they give me the impression of going progressively in this direction and after one year working intensively with their professional projects and support, I'm really disappointed because I see that their opensource and community support seems declining or even seems willingly bad sometimes and focused on only some visible projects. I really wonder if opensoure is not getting corrupted by such companies after all... With XWiki, I've been able to develop some little professional projects with the best code coming from XWiki without thinking that, if my project could make or not money, I would have to pay, in any case, the X thousands $ just for the license. My idea was to contribute to XWiki through these projects and if I could earn some money I would contribute to XWiki with something more than my little braincells :)... Sorry about that but the projects I have achieved with XWiki have never gone further than pilots and I have never been able to make a living with that :)... What a shame, isn't it?;) All of that just to explain that the fully open status of XWiki allowed me to bring my ideas into reality and I think your professional but free status is a great attractor for lots of people. So as long as you keep that in mind and in facts, I will keep supporting you and maybe more... Pascal On Tue, Dec 15, 2009 at 5:41 PM, Guillaume Lerouge guilla...@xwiki.comwrote: Hi, On Fri, Dec 4, 2009 at 3:44 PM, Vincent Massol vinc...@massol.net wrote: Hi everyone (devs and users), While we have a clear governance for write access to our source repository (http://dev.xwiki.org), we're missing a clear governance for xwiki.org. The idea is to address mainly the following 2 questions: 1) who owns it and thus controls (or rather provides direction for) its content 2) can it be used for business advertising (support, paid packages, consulting services) Bit of History about XWiki SAS - XWiki SAS (http://xwiki.com) is the company founded by Ludovic Dubost the creator of XWiki (I'm the CTO of XWiki SAS in addition to being a committer here). - Most of the active contributors are also employed and paid by XWiki SAS to develop the XWiki software. Today that's -- 12.5 committers (developers) -- 1 open source product manager (see http://markmail.org/thread/ggaaw4u6yyci4oan for its definition) -- 1 designer -- 1 tester/technical writer - XWiki SAS sells services around the open source software, see http://www.xwiki.com/xwiki/bin/view/Services/ - XWiki SAS truly believes and understands open source, see http://www.xwiki.com/xwiki/bin/view/About/Values -- I also wrote a blog post on this some time back: http://massol.myxwiki.org/xwiki/bin/view/Blog/XWikiSASAndOpenSource - XWiki SAS has promised not to do evil ;), see its manifesto at http://www.xwiki.com/xwiki/bin/view/About/Manifesto - XWiki SAS is paying for the servers and maintenance of xwiki.org, myxwiki.org, the maven repo, the svn repo, the hudson build serversn the free JUG farm, and more Issue at hand === XWiki SAS would like to generate more revenue to be able to increase the development pace of the XWiki software. We'd like to fund even more the development of XWiki, so that it becomes an even better product. We've asked you what you'd like to see in the future in XWiki and you've answered on this survey result: http://www.xwiki.org/xwiki/bin/view/Blog/Features+Survey+Results We'd like to implement those features as fast as possible. For this we need to ensure that users interested in commercial services find easily the way to http://xwiki.com, even when they arrive on xwiki.org. This is true for XWiki SAS's services but also for any company willing to offer services around the XWiki open source project. There's no magic. Developers need to be paid when they work
Re: [xwiki-devs] Distribution with MySQL
On Mon, Dec 7, 2009 at 1:02 PM, Sergiu Dumitriu ser...@xwiki.com wrote: On 12/06/2009 03:16 PM, Thomas Mortagne wrote: Hi xwikiers, I just tough now that we are currently distribution XEM with MySQL included in it and that we maybe don't have right to do it actually. I'm not an expert so not sure what we should do but distribute GPL stuff in a package declared as LGPL is forbidden AFAIK. What exactly are we distributing? The client library, which we probably include in our package and which works directly inside our software, has a FOSS exception to the GPL allowing us to bundle it in a non GPL software: http://www.mysql.com/about/legal/licensing/oem/ -- the For Open Source Projects and Other Developers of Open Source Applications section I doubt that we bundle the server in our current distribution, but even if we will do it in a VM image or something like that, I think we can do it, since it's a server, and we only communicate with it via sockets or pipes, which don't propagate the GPL license. In conclusion, as long as we don't bundle the connector in a proprietary (non-FLOSS) package, we're fine. I confirm that if you only distribute the MYSQL client, there is a FLOSS Licence exception that means you are not outlaw ;) -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] Google wave and Xwiki integration == solve comment issues in Xwiki?
I have a few Google Wave invites yet (about 5), if anyone wants one, don't hesitate to ask, apparently they come quite quick now! So, I also try wave and I find it interesting, not new or revolution but worth spending some time on it. I'm not sure I could use it as it is everyday but I prefer this kind of concept to twitter or facebook which really doesn't bring anything new and I also really like the concept of robots... oh IRCbots are back :):):) ) But, each time I use it with friends, it ends into some threads and discussions which are hard to follow because it's a mess very quick. We tried the instant google translator: really nice concept (you type and each people see it in its language)... maybe you will lose some friends very quick when they see the translation and misunderstand what you say :)... But I think this is a good idea for real! But It reminds me on IRC chats with 10s of people speaking about different things at the same time or google groups with spam everywhere ;) Anyway, I agree it is worth studying what could be done with it! regards Pascal On Thu, Dec 3, 2009 at 10:21 PM, Niels Mayer nielsma...@gmail.com wrote: I just got my Google Wavehttp://mashable.com/2009/05/28/google-wave-guide/invite and have been trying to understand how I can use it with my Xwiki http://xwiki.org-based application (soon launching on http://trainspodder.com see example-screenhttp://nielsmayer.com/prototype-11-17-2009.jpg: my interest in Wave is because my site, in google-parlance, is basically a wave for deep-linking/commenting/annotating/transcludingmashing streaming audiovideo media). One of the areas that I think Wave would help Xwiki-based applications (and wikis/sites) is with Viral commenting so that Wave becomes a central place for comments and conversations on web pages. As it socially networks comments, this enables FOAFs to more easily find out about internet conversations that might otherwise be hidden away on a website that nobody knows about.. Thus, Wave provides a viral commenting mechanism for Xwiki pages that is potentially superior to the other alternatives previously available, e.g. http://massol.myxwiki.org/xwiki/bin/view/Blog/AnonymousComments : XWiki Enterprise allows users to leave comments on pages. However in order to prevent spam on your public wiki instance you usually only want to allow registered users the right to add comments. Thus we need a solution that still allows guest users to leave comments while preventing spam. I'm proposing 2 solutions that I've both tried on this blog and that have worked well: Solution 1: create a special guest account that can be used transparently to leave comments. This can be achieved by creating a custom skin and tweaking the comments form Solution 2: integrate with an external comment web service such as IntenseDebate http://www.intensedebate.com/ . This also requires a custom skin in order to override some templates. It also solves the commenting issues in Xwiki that include (1) controlling comment spam by forcing commenters to login with real Xwiki accounts to post comments; (2) the lack of well-integrated and working right out of the box captcha support in Xwiki to prevent comment spam w/o authentication/login; (3) lack of out of the box OpenID support which would allow easy authentication of public users wanting to leave comments; (4) users wanting to leave comments constantly forgetting the accounts and passwords under which they left comments, as well as not having a centralized place to follow-up on comments they've left, or conversations they've been involved in. Wave seems to solve some of the problems, and might help side-step a lot of others in Xwiki for example, why spend a huge amount of effort tightly integrating OpenID or some other certificate/2FA/SSO-based auth system for the class of wikis that comprise a small number of editors and site maintainers, and a large number of commenters and public that you want to authenticate, identify, and spam-control -- perhaps Xwiki's login/auth system is perfectly adequate for this class of sites, but becomes overwhelmed by logins and accounts that have been created automatically, or just for the purpose of posting a single comment (if people even bother to create an account to leave a comment...). Integrating Wave or IntenseDebate http://www.intensedebate.com/ into Xwiki might give the user experience desired, without the complexity Yesterday, I posted the following to an Xwiki wave I started: https://wave.google.com/wave/#restored:wave:googlewave.com!w%252Bedlc50w0Ghttps://wave.google.com/wave/#restored:wave:googlewave.com%21w%252Bedlc50w0G https://wave.google.com/wave/#restored:wave:googlewave.com%21w%252Bedlc50w0G (please join and lets try this thing out!!) ... FYI, here are some ways Wave has been integrated into other platforms (note MediaWiki
Re: [xwiki-devs] Project Lombok
nice analysis :)
one question that arises in my mind: in the future, in 2, 3 or 4 years, with
all these features integrated in groovy or clojure which tends to be more
efficient syntaxically or more specialized also, I really wonder why we
should keep coding in Java in fact. The question of performance is not
really an issue since everything runs in the JVM at the end.
Anyway, this is not the subject here but I wonder :)
Have you seen last Java7 language evolution?
Pascal
On Wed, Nov 25, 2009 at 12:33 AM, Niels Mayer nielsma...@gmail.com wrote:
On Mon, Nov 23, 2009 at 9:32 PM, Asiri Rathnayake
asiri.rathnay...@gmail.com wrote:
As I understood this is not a change to java syntax or anything. It's
about
augmenting classes when they are compiled. So at source level they do not
have any getXXX() or setXXX() methods but when compiled lombok does it's
magic and add the methods. I think most of the IDEs use compiled .class
files to determine what a class is capable of (rather than analysing the
source code) but still, there will be a problem if you try to lookup
those
methods in the source file.
Am I correct? Anyone who has tried out lombok?
Isn't the automatic creation of getters and setters one of the features of
groovy, which is already tightly integrated into Xwiki?
Looking at lombok feature list, every single feature is already provided by
Groovy, much more elegantly, and already part of Xwiki, except for perhaps
the @Synchronized, which is accomplished far more elegantly in clojure (
http://blip.tv/file/812787/ )
http://projectlombok.org/features/index.html
@Getter / @Setter http://projectlombok.org/features/GetterSetter.html
Never
write public int getFoo() {return foo;} aga...@tostring
http://projectlombok.org/features/ToString.htmlNo
need to start a debugger to see your fields: Just let lombok generate a
toString for y...@equalsandhashcode
http://projectlombok.org/features/EqualsAndHashCode.htmlEquality
made easy: Generates hashCode and equals implementations from the fields
of your obje...@data http://projectlombok.org/features/Data.htmlAll
together now: A shortcut for @ToString, @EqualsAndHashCode, @Getter on
all
fields, and @Setter on all non-final fields. You even get a free
constructor to initialize your final fiel...@cleanup
http://projectlombok.org/features/Cleanup.htmlAutomatic
resource management: Call your close() methods safely with no hassle.
@Synchronized http://projectlombok.org/features/Synchronized.html
synchronized done right: Don't expose your loc...@sneakythrows
http://projectlombok.org/features/SneakyThrows.htmlTo
boldly throw checked exceptions where no one has thrown them before!
Fabio Mancinelli said:
It is indeed cool and it is a nice way for embedding in Eclipse a
rudimental macro processor, making Java look more LISPy :)
W/r/t adding macros or making small custom languages -- groovy has it's
meta-object protocol, and then there's the even nicer way of doing things
--
clojure -- it's silly to try to emulate lisp macros in java because the
syntax is all wrong to begin with. There's solid
theoretical reasons for lisp looking like it does (e.g. Church's lambda
calculus and Quine's set
theoryhttp://www.rbjones.com/rbjpub/logic/cl/index.htm),
and the language-power you get from treating programs as 1st-class data and
vice-versa (where the first-classness, and the ability to create closures
that work transparently and correctly is the key to it all).
IMHO, adding an IDE to make Java look more Lispy is an odd use of precious
resources.
Why not make java look more lispy directly? http://clojure.org/ -- a
project
with far more buzz and traction than lombok, cool-looking-as-it-is; Lombok
would end up microsofting development efforts by forcing a single
solution
on what should be an open-market. IDE-wars are even worse than language
wars, IMHO, which is why I'd hope effort is put into generally-useful
platform solutions that would provide equal benefit to all IDE users as
well as
regular Xwiki web-users.
Note that both clojure and groovy have IDE support in eclipse.
Should language level extensions be necessary, groovy's Meta-object
protocol
support should obviate the need for further Xwiki extensions. See chapters
12 and onward in http://www.pragprog.com/titles/vslg/programming-groovy
Part 3: “MOPping Groovy”
Metaprogramming is one of the biggest benefits of dynamic
languages
and Groovy; it has the ability to inspect classes at runtime and
dynam-
ically dispatch method calls. You’ll explore Groovy’s support for
meta-
programming in Chapter 12, Exploring Meta-Object Protocol (MOP),
on
page 186, beginning with the fundamentals of how Groovy handles
method calls to Groovy objects and Java objects.
Groovy allows you to perform AOP-like method interceptions using
GroovyInterceptable and
Re: [xwiki-devs] Project Lombok
On Tue, Nov 24, 2009 at 8:14 AM, Paul Libbrecht p...@activemath.org wrote: Exactly as I feared. Line numbers are not going to match I'm afraid. oh what a shame :) In fact, the problem is not at IntelliJ or Lombok level, it is at Java level... I wonder why we still have to code getters/setters by default... as usual for Sun standards: someone has to do it by itself and when too many people use it, they are urged to introduce it somewhere as a JSR... and generally worse than the original... concerning line numbers, I have already forgot this IDE feature since I use groovy which also adds lots of things at compilation... our dev IDE are not prepared for this ;)... lets go back to vi! paul Le 24-nov.-09 à 06:32, Asiri Rathnayake a écrit : As I understood this is not a change to java syntax or anything. It's about augmenting classes when they are compiled. So at source level they do not have any getXXX() or setXXX() methods but when compiled lombok does it's magic and add the methods. I think most of the IDEs use compiled .class files to determine what a class is capable of (rather than analysing the source code) but still, there will be a problem if you try to lookup those methods in the source file. Am I correct? Anyone who has tried out lombok? ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [xwiki-users] Page Loading Optimization
Have you seen my mail about JAWR which is exactly this :
On the other hand wro4j allows you to organize your resources in groups
and supports gzip compression.
if you need JS optimization, I think Google Closure Compiler is the way to
look at... With chrome and all the work they do around JS, they are
certainly the ones to follow just now :)
regards
Pascal
On Tue, Nov 10, 2009 at 9:45 AM, Marius Dumitru Florea
mariusdumitru.flo...@xwiki.com wrote:
Hi Vincent,
Vincent Massol wrote:
On Nov 10, 2009, at 8:58 AM, Vincent Massol wrote:
Hi Marius,
On Nov 5, 2009, at 6:56 PM, Marius Dumitru Florea wrote:
Jerome Velociter wrote:
Hi Thibaul, all
Something easy to do that would contribute to reduce the number of
CSS
files is to concatenate all the WYSIWYG CSS files from the various
plugins at build time (there are more than 10 AFAIK). Marius, have
you
looked into this? Do you know if this could be done in the 2.1
timeframe ?
There are I think three steps to be taken in order to minimize the
CSS load:
1) expand @import url('someURL');
2) concatenate CSS files
3) minify the resulted CSS file
So far I haven't found a tool to expand the CSS import declaration.
Maybe I could write a small maven plugin for this.
I've found this:
http://raibledesigns.com/rd/entry/javascript_and_css_concatenation
which leads to wro4j: http://code.google.com/p/wro4j/
wro4j seems to be a runtime optimizer while YUI Compressor is a build
time optimizer. I'm not sure which approach is the best. On the maven
YUI Compressor site they say:
Because Javascript compression could need time and resource, and to
avoid repetitive (stupid) resources consumming at runtime, this plugin
do compression of static files at compile time.
On the other hand wro4j allows you to organize your resources in groups
and supports gzip compression.
hmmm
http://code.google.com/p/wro4j/wiki/KnownIssues
I'll drop the @import declarations and merge the CSS files instead.
Thanks,
Marius
-Vincent
Sounds promising.
Thanks
-Vincent
I think we can adapt to maven what is presented in this article
http://www.samaxes.com/2009/05/combine-and-minimize-javascript-and-css-files-for-faster-loading/
in order to achieve the last two steps.
Marius
Note that the target of 1 CSS and 1 JS is pretty challenging for
XWiki
as we are also making it a modular software where CSS and JS
extensions
can be conditionally loaded on some (not all) of the pages.
Something to
investigate for JavaScript extensions could be a dynamic JS loading
mecanism, a la dojo
(
http://dojocampus.org/content/2008/10/09/dojo-module-packaging-and-loading/
)
Jerome.
PS: I put devs in copy as this is more a developer topic.
On 11/5/09 5:28 PM, Thibaut Camberlin wrote:
Hi all,
Page Loading time is a very important criteria when developing a
web site.
According to a recent
survey
http://www.webdesignerwall.com/general/users-place-more-weight-on-design/
more
than half people would drive away from a site with slow loading
pages.
There are several interesting issues that could be implemented to
substantially improve page loading time in XWiki.
Number one is aggreation of CSS and JS files in order to reduce
HTTP
requests. (For info, we have a total of 25 external CSS and JS
files on a
basic XWiki install when in the best world we would have just 2 -
1 CSS and
1 JS)
Someone interrested in working on this with me ?
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [xwiki-users] Page Loading Optimization
On Tue, Nov 10, 2009 at 10:04 AM, Vincent Massol vinc...@massol.net wrote:
On Nov 10, 2009, at 9:56 AM, Pascal Voitot wrote:
Have you seen my mail about JAWR which is exactly this :
On the other hand wro4j allows you to organize your resources in
groups
and supports gzip compression.
if you need JS optimization, I think Google Closure Compiler is the
way to
look at... With chrome and all the work they do around JS, they are
certainly the ones to follow just now :)
We're already minifying our JS both at build time and at runtime
(although we could switch to Google Closure at some point in the
future if it's better).
apparently it's really efficient but I'm not a JS expert enough to consider
its real power...
But I don't think Google Closure will merge CSS and JS files together.
no i don't think so :)
Re JAWR indeed we've already mentioned it several times on
http://jira.xwiki.org/jira/browse/XWIKI-2022
(the lead dev for it has even commented in that issue!). We should
definitely evaluate it vs wro4j.
don't know wro4j... should have a look at it, just to know!
Thanks
-Vincent
regards
Pascal
On Tue, Nov 10, 2009 at 9:45 AM, Marius Dumitru Florea
mariusdumitru.flo...@xwiki.com wrote:
Hi Vincent,
Vincent Massol wrote:
On Nov 10, 2009, at 8:58 AM, Vincent Massol wrote:
Hi Marius,
On Nov 5, 2009, at 6:56 PM, Marius Dumitru Florea wrote:
Jerome Velociter wrote:
Hi Thibaul, all
Something easy to do that would contribute to reduce the number
of
CSS
files is to concatenate all the WYSIWYG CSS files from the
various
plugins at build time (there are more than 10 AFAIK). Marius,
have
you
looked into this? Do you know if this could be done in the 2.1
timeframe ?
There are I think three steps to be taken in order to minimize the
CSS load:
1) expand @import url('someURL');
2) concatenate CSS files
3) minify the resulted CSS file
So far I haven't found a tool to expand the CSS import
declaration.
Maybe I could write a small maven plugin for this.
I've found this:
http://raibledesigns.com/rd/entry/javascript_and_css_concatenation
which leads to wro4j: http://code.google.com/p/wro4j/
wro4j seems to be a runtime optimizer while YUI Compressor is a build
time optimizer. I'm not sure which approach is the best. On the maven
YUI Compressor site they say:
Because Javascript compression could need time and resource, and to
avoid repetitive (stupid) resources consumming at runtime, this
plugin
do compression of static files at compile time.
On the other hand wro4j allows you to organize your resources in
groups
and supports gzip compression.
hmmm
http://code.google.com/p/wro4j/wiki/KnownIssues
I'll drop the @import declarations and merge the CSS files instead.
Thanks,
Marius
-Vincent
Sounds promising.
Thanks
-Vincent
I think we can adapt to maven what is presented in this article
http://www.samaxes.com/2009/05/combine-and-minimize-javascript-and-css-files-for-faster-loading/
in order to achieve the last two steps.
Marius
Note that the target of 1 CSS and 1 JS is pretty challenging for
XWiki
as we are also making it a modular software where CSS and JS
extensions
can be conditionally loaded on some (not all) of the pages.
Something to
investigate for JavaScript extensions could be a dynamic JS
loading
mecanism, a la dojo
(
http://dojocampus.org/content/2008/10/09/dojo-module-packaging-and-loading/
)
Jerome.
PS: I put devs in copy as this is more a developer topic.
On 11/5/09 5:28 PM, Thibaut Camberlin wrote:
Hi all,
Page Loading time is a very important criteria when developing a
web site.
According to a recent
survey
http://www.webdesignerwall.com/general/users-place-more-weight-on-design/
more
than half people would drive away from a site with slow loading
pages.
There are several interesting issues that could be implemented
to
substantially improve page loading time in XWiki.
Number one is aggreation of CSS and JS files in order to reduce
HTTP
requests. (For info, we have a total of 25 external CSS and JS
files on a
basic XWiki install when in the best world we would have just
2 -
1 CSS and
1 JS)
Someone interrested in working on this with me ?
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [xwiki-users] Page Loading Optimization
On Tue, Nov 10, 2009 at 11:06 AM, Jerome Velociter jer...@xwiki.com wrote:
On 11/10/09 10:41 AM, Pascal Voitot wrote:
On Tue, Nov 10, 2009 at 10:04 AM, Vincent Massolvinc...@massol.net
wrote:
On Nov 10, 2009, at 9:56 AM, Pascal Voitot wrote:
Have you seen my mail about JAWR which is exactly this :
On the other hand wro4j allows you to organize your resources in
groups
and supports gzip compression.
if you need JS optimization, I think Google Closure Compiler is the
way to
look at... With chrome and all the work they do around JS, they are
certainly the ones to follow just now :)
We're already minifying our JS both at build time and at runtime
(although we could switch to Google Closure at some point in the
future if it's better).
apparently it's really efficient but I'm not a JS expert enough to
consider
its real power...
I really think compressing / compiling together JS is for us the tip of
an iceberg in terms of JS optimization.
As I said previously on this thread, we can't do that for JavaScript
extensions which are loaded conditionally in a non-predictable manner.
They represent more than half the JS files we load on the home page
today for example.
Note that we should find a way in the JSFX to declare an extension being
loaded on all pages (it's not possible yet), so that extensions such
as jump to page and other common widgets can be aggregated with other
always served JS.
But even if we do that, remains all the extensions added on demand
(there are some on the home page, too) that can be solved but by an
asynchronous script loading mechanism (see
http://www.stevesouders.com/blog/2008/12/27/coupling-async-scripts/ for
example).
and there are also libraries such as google apps or jquery in which you
generally intercept the onload event to wait for end of loading before
creating your widgets
My 2 cents,
Jerome.
But I don't think Google Closure will merge CSS and JS files together.
no i don't think so :)
Re JAWR indeed we've already mentioned it several times on
http://jira.xwiki.org/jira/browse/XWIKI-2022
(the lead dev for it has even commented in that issue!). We should
definitely evaluate it vs wro4j.
don't know wro4j... should have a look at it, just to know!
Thanks
-Vincent
regards
Pascal
On Tue, Nov 10, 2009 at 9:45 AM, Marius Dumitru Florea
mariusdumitru.flo...@xwiki.com wrote:
Hi Vincent,
Vincent Massol wrote:
On Nov 10, 2009, at 8:58 AM, Vincent Massol wrote:
Hi Marius,
On Nov 5, 2009, at 6:56 PM, Marius Dumitru Florea wrote:
Jerome Velociter wrote:
Hi Thibaul, all
Something easy to do that would contribute to reduce the number
of
CSS
files is to concatenate all the WYSIWYG CSS files from the
various
plugins at build time (there are more than 10 AFAIK). Marius,
have
you
looked into this? Do you know if this could be done in the 2.1
timeframe ?
There are I think three steps to be taken in order to minimize the
CSS load:
1) expand @import url('someURL');
2) concatenate CSS files
3) minify the resulted CSS file
So far I haven't found a tool to expand the CSS import
declaration.
Maybe I could write a small maven plugin for this.
I've found this:
http://raibledesigns.com/rd/entry/javascript_and_css_concatenation
which leads to wro4j: http://code.google.com/p/wro4j/
wro4j seems to be a runtime optimizer while YUI Compressor is a build
time optimizer. I'm not sure which approach is the best. On the maven
YUI Compressor site they say:
Because Javascript compression could need time and resource, and to
avoid repetitive (stupid) resources consumming at runtime, this
plugin
do compression of static files at compile time.
On the other hand wro4j allows you to organize your resources in
groups
and supports gzip compression.
hmmm
http://code.google.com/p/wro4j/wiki/KnownIssues
I'll drop the @import declarations and merge the CSS files instead.
Thanks,
Marius
-Vincent
Sounds promising.
Thanks
-Vincent
I think we can adapt to maven what is presented in this article
http://www.samaxes.com/2009/05/combine-and-minimize-javascript-and-css-files-for-faster-loading/
in order to achieve the last two steps.
Marius
Note that the target of 1 CSS and 1 JS is pretty challenging for
XWiki
as we are also making it a modular software where CSS and JS
extensions
can be conditionally loaded on some (not all) of the pages.
Something to
investigate for JavaScript extensions could be a dynamic JS
loading
mecanism, a la dojo
(
http://dojocampus.org/content/2008/10/09/dojo-module-packaging-and-loading/
)
Jerome.
PS: I put devs in copy as this is more a developer topic.
On 11/5/09 5:28 PM, Thibaut Camberlin wrote:
Hi all,
Page Loading time is a very important criteria when developing a
web site
Re: [xwiki-devs] [xwiki-users] Page Loading Optimization
On Tue, Nov 10, 2009 at 11:16 AM, Jerome Velociter jer...@xwiki.com wrote:
On 11/10/09 11:09 AM, Pascal Voitot wrote:
On Tue, Nov 10, 2009 at 11:06 AM, Jerome Velociterjer...@xwiki.com
wrote:
On 11/10/09 10:41 AM, Pascal Voitot wrote:
On Tue, Nov 10, 2009 at 10:04 AM, Vincent Massolvinc...@massol.net
wrote:
On Nov 10, 2009, at 9:56 AM, Pascal Voitot wrote:
Have you seen my mail about JAWR which is exactly this :
On the other hand wro4j allows you to organize your resources in
groups
and supports gzip compression.
if you need JS optimization, I think Google Closure Compiler is the
way to
look at... With chrome and all the work they do around JS, they are
certainly the ones to follow just now :)
We're already minifying our JS both at build time and at runtime
(although we could switch to Google Closure at some point in the
future if it's better).
apparently it's really efficient but I'm not a JS expert enough to
consider
its real power...
I really think compressing / compiling together JS is for us the tip of
an iceberg in terms of JS optimization.
As I said previously on this thread, we can't do that for JavaScript
extensions which are loaded conditionally in a non-predictable manner.
They represent more than half the JS files we load on the home page
today for example.
Note that we should find a way in the JSFX to declare an extension being
loaded on all pages (it's not possible yet), so that extensions such
as jump to page and other common widgets can be aggregated with other
always served JS.
But even if we do that, remains all the extensions added on demand
(there are some on the home page, too) that can be solved but by an
asynchronous script loading mechanism (see
http://www.stevesouders.com/blog/2008/12/27/coupling-async-scripts/ for
example).
and there are also libraries such as google apps or jquery in which you
generally intercept the onload event to wait for end of loading before
creating your widgets
That we do already :)
Using prototype dom:loaded event (we also have our own event to indicate
the DOM is loaded and has been pre-processed by XWiki scripts, see
http://platform.xwiki.org/xwiki/bin/view/DevGuide/JavaScriptAPI#HDOMEvents
for more)
oh yes guys, nice idea :)
I have been disconnected from you for some time now and I may have missed
some features ;)
Jerome.
My 2 cents,
Jerome.
But I don't think Google Closure will merge CSS and JS files together.
no i don't think so :)
Re JAWR indeed we've already mentioned it several times on
http://jira.xwiki.org/jira/browse/XWIKI-2022
(the lead dev for it has even commented in that issue!). We should
definitely evaluate it vs wro4j.
don't know wro4j... should have a look at it, just to know!
Thanks
-Vincent
regards
Pascal
On Tue, Nov 10, 2009 at 9:45 AM, Marius Dumitru Florea
mariusdumitru.flo...@xwiki.com wrote:
Hi Vincent,
Vincent Massol wrote:
On Nov 10, 2009, at 8:58 AM, Vincent Massol wrote:
Hi Marius,
On Nov 5, 2009, at 6:56 PM, Marius Dumitru Florea wrote:
Jerome Velociter wrote:
Hi Thibaul, all
Something easy to do that would contribute to reduce the number
of
CSS
files is to concatenate all the WYSIWYG CSS files from the
various
plugins at build time (there are more than 10 AFAIK). Marius,
have
you
looked into this? Do you know if this could be done in the 2.1
timeframe ?
There are I think three steps to be taken in order to minimize
the
CSS load:
1) expand @import url('someURL');
2) concatenate CSS files
3) minify the resulted CSS file
So far I haven't found a tool to expand the CSS import
declaration.
Maybe I could write a small maven plugin for this.
I've found this:
http://raibledesigns.com/rd/entry/javascript_and_css_concatenation
which leads to wro4j: http://code.google.com/p/wro4j/
wro4j seems to be a runtime optimizer while YUI Compressor is a
build
time optimizer. I'm not sure which approach is the best. On the
maven
YUI Compressor site they say:
Because Javascript compression could need time and resource, and to
avoid repetitive (stupid) resources consumming at runtime, this
plugin
do compression of static files at compile time.
On the other hand wro4j allows you to organize your resources in
groups
and supports gzip compression.
hmmm
http://code.google.com/p/wro4j/wiki/KnownIssues
I'll drop the @import declarations and merge the CSS files instead.
Thanks,
Marius
-Vincent
Sounds promising.
Thanks
-Vincent
I think we can adapt to maven what is presented in this article
http://www.samaxes.com/2009/05/combine-and-minimize-javascript-and-css-files-for-faster-loading/
in order to achieve the last two steps.
Marius
Note that the target of 1 CSS and 1 JS is pretty challenging for
XWiki
Re: [xwiki-devs] [xwiki-users] Page Loading Optimization
Do you know tools such as JAWR which can take several CSS or js files and
put them in one file using some configurations?
I tried it with Grails for example...
Maybe it could help or give some ideas at leat...
https://jawr.dev.java.net/
regards
Pascal
On Thu, Nov 5, 2009 at 6:56 PM, Marius Dumitru Florea
mariusdumitru.flo...@xwiki.com wrote:
Jerome Velociter wrote:
Hi Thibaul, all
Something easy to do that would contribute to reduce the number of CSS
files is to concatenate all the WYSIWYG CSS files from the various
plugins at build time (there are more than 10 AFAIK). Marius, have you
looked into this? Do you know if this could be done in the 2.1 timeframe
?
There are I think three steps to be taken in order to minimize the CSS
load:
1) expand @import url('someURL');
2) concatenate CSS files
3) minify the resulted CSS file
So far I haven't found a tool to expand the CSS import declaration.
Maybe I could write a small maven plugin for this.
I think we can adapt to maven what is presented in this article
http://www.samaxes.com/2009/05/combine-and-minimize-javascript-and-css-files-for-faster-loading/
in order to achieve the last two steps.
Marius
Note that the target of 1 CSS and 1 JS is pretty challenging for XWiki
as we are also making it a modular software where CSS and JS extensions
can be conditionally loaded on some (not all) of the pages. Something to
investigate for JavaScript extensions could be a dynamic JS loading
mecanism, a la dojo
(
http://dojocampus.org/content/2008/10/09/dojo-module-packaging-and-loading/
)
Jerome.
PS: I put devs in copy as this is more a developer topic.
On 11/5/09 5:28 PM, Thibaut Camberlin wrote:
Hi all,
Page Loading time is a very important criteria when developing a web
site.
According to a recent
survey
http://www.webdesignerwall.com/general/users-place-more-weight-on-design/
more
than half people would drive away from a site with slow loading pages.
There are several interesting issues that could be implemented to
substantially improve page loading time in XWiki.
Number one is aggreation of CSS and JS files in order to reduce HTTP
requests. (For info, we have a total of 25 external CSS and JS files on
a
basic XWiki install when in the best world we would have just 2 - 1 CSS
and
1 JS)
Someone interrested in working on this with me ?
___
users mailing list
us...@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] Lucene search as default search?
Hello, I already use it as default (since 1.9.x) as I have a solution with too many data (mainly attached documents) to index and needed a more powerful indexation engine. Lucene works quite good for me but you are right, those open issues might be ennoying... I'm not expert enough to choose... Pascal On Tue, Oct 27, 2009 at 6:33 PM, Denis Gervalle d...@softec.st wrote: Hi Vincent, 22 opens issues on the lucene plugins seems to me a lot to put it as a default. Of course, I'd really like to see most of them solved, but some seems to me blocker issue to put the lucene plugins as the default: XPLUCENE-5 XPLUCENE-8 XPLUCENE-13 XPLUCENE-30 XPLUCENE-33 XPLUCENE-34 XPLUCENE-35 XPLUCENE-37 XPLUCENE-40 If search seems powerful (which the XWIki search is not), but is unreliable, I think that you will disappoint more than a less powerful but reliable solution (which the XWiki search is). WDYT ? Denis On Oct 26, 2009, at 21:00, Vincent Massol wrote: Hi, Should we make the lucene search the default search or not? In the default XAR the Lucene search is marked as experimental. This has been the case for a long time now. I think we need to do something about this. Do you think the Lucene search is working well enough to be set as the default? WDYT? Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki at the Enterprise 2.0 Conference in California
great ;) 5mn... you have to be sharp :) On Sat, Oct 17, 2009 at 10:36 AM, Ecaterina Valica vali...@gmail.comwrote: This is great. Thanks everyone for your vote :) On Sat, Oct 17, 2009 at 10:47, Ludovic Dubost ludo...@xwiki.com wrote: We did it http://enterprise2blog.com/2009/10/drum-roll-please-our-launch-pad-finalists/ I want to all thank you for helping making this happen. This is just great for XWiki. With this conference where we get 5 minutes on stage in the keynote room + a mini-pod in the exposition room, we will get a huge exposure for XWiki. If there are some Californian's that want to meet while I'm there in San Francisco, please tell me. It Nov 2nd, 3rd at the Moscone. I'll probably stay a few days after. Do come see us at the exposition. If you have a great usage of XWiki come even more to show it to other potential users of XWiki. The best way to help XWiki is to spread it's usage. Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Idea] Objects containing other objects as well as properties
another quick answer ;) On Fri, Oct 2, 2009 at 7:49 PM, Niels Mayer nielsma...@gmail.com wrote: On Thu, Oct 1, 2009 at 10:37 AM, Pascal Voitot pascal.voitot@gmail.com wrote: A quick answer from a user who uses classes quite intensively... you can create links to other class instances (or objects) in your class by using the Database List property type for example. It is very powerful when you want to create a field of a class where values are stored in another class and created dynamically. [...] Thanks for helping me better understand this feature of Xwiki. http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel mentions: - Database List - Database Tree List but the only explanation I'm finding quickly is http://platform.xwiki.org/xwiki/bin/view/DevGuide/DsXWikiDatabaseListClasses and http://dev.xwiki.org/xwiki/bin/view/Drafts/DatabaseListProperties . Are there any examples, tutorials or documentation, or just pointers to source-code using this technique? I don't know any samples or tutorials... I discovered by experience :) Questions: Is there an overall performance penalty with adding database list fields that doesn't occur with a regular type such as a string or static list? Does the associated database query only happen when the databaselist properties are .get()'d explicitly? Also, most of the document properties allow setting. I assume databaselist and databasetreelist are read only and are not quite analogous to the list-type property, where you could set/edit one or more selections, and then retrieve them back again. Or are these just like other document properties (e.g. list) where values can be get/set, the databaselist just determines the set of permissible values dymamically, presents them when the property is edited, and validates against them when the property is set. Naturally this is not a Java-like list... this database list is just a list of values where possible values are retrieved from fields of objects of another XWikiClass... and these values shall be string values as far as I can remember... it is simply a list of options dynamically built from DB... I also remember that the value of the field is stored directly in the parent object property. This means the parent object doesn't store the id of the link object but the value of a field of the link object. So naturally there is a performance penalty when you retrieve the possible values from the instances of the link XWikiClass. But this is much more dynamic than a static list... But if you link your database list with a field of a XWikiClass that is managed as a primary key (unique value), using a simple XWiki request, you can retrieve the linked object itself quite easily and it behaves as if you had a link between 2 objects. You do manually the work hibernate could do for you and it might not be as performant as hibernate could do but in many cases this is more than enough and so easy to use in XWiki... BTW, in looking up info on this, I found these helpful: http://markmail.org/message/dhkrfddcli6fne7m http://lists.xwiki.org/pipermail/users/2007-November/009471.html Sergiu's explanation was the most helpful: http://osdir.com/ml/web.wiki.xwiki.user/2008-02/msg00135.html (I'll reproduce here to save you from the advertising on osdir.com) --- horbjørn Konstantinovitz wrote: Hi, I am currently developing a program documentation system based on xwiki. I am able to create pages which describes programs. For each program which has to be described I programatically creates a page and populate a object with static program information. But I need to document which database files the program uses, with links to the relevant database file descriptions (a list). For that I want to use a database list class. I also want to show a call graph. for that I want to use a database tree class. But I am not able to find any documentation on these class properties. Can anyone give an example of use for each of these two properties or give pointers to relevant examples. The article http://www.theserverside.com/tt/articles/article.tss?l=XWiki on the server side were a very good introduction! But it didn't treat the property Custom Display. Are there any documentation on this property? Cheers /Thorbjørn Konstantinovitz First, a bit of introduction on DBList and DBTreeList. StaticList properties, when edited, allow the user to select one of the predefined values (or more, if the property has multiple select = true). DBList does something similar, allows the user to select one or more values from a list of values, but the list is not predefined, it is populated with values from the database. DBTreeList does the same as DBList, but also induces a pseudo-hierarchy in the option list, displaying the options as a tree. DBList and DBTreeList properties work in two ways
Re: [xwiki-devs] [Idea] Objects containing other objects as well as properties
Hello, A quick answer from a user who uses classes quite intensively... you can create links to other class instances (or objects) in your class by using the Database List property type for example. It is very powerful when you want to create a field of a class where values are stored in another class and created dynamically. You identify the link by the name of the XWiki class and the field name of this class used to establish the link... This is not exactly a reference to another object but a link to a field of another object. So if you use a unique field (some primary key in a relational DB world), you can easily retrieve the object from the field and it behaves as if you have a link between 2 objects. (It looks like a DB foreign key if you prefer) There are also custom mappings which are simply hibernate mappings but it requires some deeper DB experience and I think this might be reserved to cases where you have an existing DB schema or you need performance. regards Pascal On Thu, Oct 1, 2009 at 6:15 PM, Guillem Plasencia guill...@telefonica.netwrote: Hello everybody, this is my first post to the list, i'm also newbie with Xwiki. I was about to post this same question myself but Caleb James DeLisle took the lead: I was wondering if it would be worthwhile to try working on allowing objects to contain other objects as well as properties (like Java) Put in other words, could we have Classes where one (or more) of its properties are instances of other Classes? It seems from what i read on http://platform.xwiki.org/xwiki/bin/view/DevGuide/DataModel that the answer right now would be no. Could someone shed some light on why is it so (what's the reason behind)? Thank you ! Guillem ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [xwiki-users] Who can design nice and unique color themes for xwiki.org
On Tue, Sep 29, 2009 at 8:59 PM, Vincent Massol vinc...@massol.net wrote: On Sep 29, 2009, at 8:47 PM, Ecaterina Valica wrote: Hi, 2 new proposals with color in header done by me and Marta: [Proposal 6] done by Marta XWATCH - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/PlainBlue/XWATCH6.png XWATCHbis - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/PlainBlue/XWATCH6b.png XMANAGER - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/PlainBlue/XMANAGER6.png XWORKSPACES - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/PlainBlue/XWORKSPACES6.png I liked proposal 6 much better than all other proposals so far (I like the darker colors for XWATCH6b rather than XWATCH6). We're getting there! :) I also like sample 6 and also prefer darker colors... Is it possible to try without the footer, right panels and clicked links colored so that they are the same colors for all subwikis? Thanks -Vincent [Proposal 7] Neutral gray XE - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWATCH7/XE7.png XWATCH - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWATCH7/XWATCH7.png XMANAGER - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWATCH7/XMANAGER7.png XWORKSPACES - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWATCH7/XWORKSPACES7.png Thanks, Caty The other proposals were: [Proposal 1] Colors on dark bg XE - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XE/XE.png XWATCH - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWATCH/XWATCH.png XMANAGER - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XMANAGER/XMANAGER.png XWORKSPACES - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWORKSPACES/XWORKSPACES.png [Proposal 2] Same colors as xwiki.org toucan XE - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWORKSPACES2/XE2.png XWATCH - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWORKSPACES2/XWATCH2.png XMANAGER - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWORKSPACES2/XMANAGER2.png XWORKSPACES - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWORKSPACES2/XWORKSPACES2.png [Proposal 3] Brighter colors XE - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XE3/XE3.png XWATCH - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XE3/XWATCH3.png XMANAGER - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XE3/XMANAGER3.png XWORKSPACES - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XE3/XWORKSPACES3.png [Proposal 4] Gradient - I could try make some gradient proposal. This would add images for the page bakcground gradient XWATCH - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XMANAGER4/XMANAGER4.png [Proposal 5] Two colors XE - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWATCH5/XE5.png XWATCH - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWATCH5/XWATCH5.png XMANAGER - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWATCH5/XMANAGER5.png XWORKSPACES - http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWATCH5/XWORKSPACES5.png ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [xwiki-users] Who can design nice and unique color themes for xwiki.org
I have not followed everything about the new skin so my opinion is a bit late but I look the last proposals and I agree with you, Niels, red blue is a bit stressful... blue, red or orange pastel colors are too tasteless to make it attractive also... Moreover, colibri skin seems quite angular and too bright colors with respect to white background and dark grey font colors gives me an impression of not being finished... something under work... you know, something is missing to make it sexy or pro depending on what you are looking for;)... not easy to explain my impression... In fact I wonder whether this is not simply due to this big background panel with a unique color not too light, not too dark... Maybe just playing with some nicer borders and some font color contrasts would make it... Not an easy work... but let me tell you everything you've already done is quite nice anyway... Pascal On Mon, Sep 28, 2009 at 9:39 PM, Niels Mayer nielsma...@gmail.com wrote: http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWATCH5/XE5.png http://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWATCH5/XWATCH5. pnghttp://incubator.myxwiki.org/xwiki/bin/download/ColorThemes/XWATCH5/XWATCH5.%0Apng Combining red and blue is visually stressful. They focus at different lengths and therefore your eyes will be fighting to focus both colors simultaneously. Even orange has enough long-wavelength red in it as to cause this 3d optical illlusion effect slighltly, against short-wavelength blues and purples. Niels http://nielsmayer.com PS: IMHO, there should be an option to put a border/bevel/inset/outset (just regular html, no images or rounded corners) around the different panels. Seems like Gmail has a good look in this regard, with simple borders that look good, render efficient, and aren't distracting: http://gmailblog.blogspot.com/2009/09/four-new-themes.html . They seem to have well-chosen contrasting colors for text areas as well -- what about just copying some of their simpler color themes (the color palette, not the exact look)? ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [VOTE] Change group id for top level pom from com.xpn to xwiki.org
yes please do it... I've been waiting for that for some time now;) On Mon, Sep 21, 2009 at 9:42 PM, Sergiu Dumitriu ser...@xwiki.com wrote: Vincent Massol wrote: Hi From com.xpn.xwiki.platform to org.xwiki.platform. +1 Take care, all other poms depending on it should be updated. -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [xwiki-users] Good News for the XWiki Open Source Project: French State Research funding
I fully agree with you :) Beyond congratulations, let me tell you that, now, when I say the word XWiki when I propose professional solutions, people don't oppose against it anymore and it even tends to bring some credibility to my propositions... What does it mean? Is it XWiki itself gaining notoriety or is it Wiki solutions generally which are becoming more and more common? I will let you guess... Anyway, your announcement is good news and it means we can go on investing time and money into XWiki because this is a project with a future (and a past also ;)) Congratulations guys and go on because I'm interested in the new v2.0 and all the new stuff and I hope I will be able to participate a bit more than my recent busy months:) regards Pascal 2009/9/16 [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net Congratulations! Even though this is important, I am sure this is one a new small step toward an even greater product! I would like to hijack this thread to thank all devs and users to make XWiki better every day. Best wishes for a highly productive new course! Ricardo Ludovic Dubost wrote: Hi XWiki Community, I'm happy to share some good news for the XWiki Platform and Community that we got today. We (XWiki SAS) had responded to a French Government Call for Web 2.0 Projects in early July and we got the good news today that our project was selected with 43 other projects (among 340 proposals) to receive state funding. In this project, where the research entity INRIA/ECOO and Open Source company Mandriva are also participating, we have proposed to enhance XWiki's social features and integrate Real-Time capabilities in XWiki (both for editing information and viewing information in real-time). We already worked with INRIA/ECOO on XWiki Concerto (offline and mobile XWiki) which is the specialist in France and probably Europe of Operational Transformation Technology (which is used in Google Wave for real-time capabilities). We'll talk more about the features this will bring to XWiki when we formally launch the project. We don't know yet how fast it will go to formalize the public funding and start the project (it usually takes at least a few month). It's great to be able to continue to work on innovative technologies in the Wiki space, which is not that easy as we have already so much work to package and polish all the great ideas and features that are already in the XWiki platform. It's also great to see the progress the XWiki software has made in the last year, from XWiki 1.8 to XWiki 2.0 coming out soon. The new rendering, new Wysiwyg editor, the Office Importer and now the new skin are making XWiki do a lightyear of progress in just one year ! Ludovic ___ users mailing list us...@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Ricardo Rodríguez Your EPEC Network ICT Team ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] Translation Wiki
On Tue, Sep 8, 2009 at 10:25 AM, Vincent Massol vinc...@massol.net wrote: Hi Hel, Fixed. Some Kello Kitty perso did some vandalism on the site. What interest could this kitty have in this vandalism ??? Thanks -Vincent On Sep 8, 2009, at 9:44 AM, hel-o wrote: Hi, there seems to be a problem with the translation wiki, just logged in, only language available is zh and theres a application hallo hel. - semantic-web.hel.at h...@hel.at ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] A better UI for annotation module
great tool :) eager to use it :) could be really useful and bring new ideas... regards Pascal On Fri, Sep 4, 2009 at 6:39 PM, Lucien Pereira lucien.pere...@xwiki.comwrote: I uploaded a demo here http://www.vimeo.com/6433080 An annotation enabled test server will be available soon. Lucien. Thibaut DEVERAUX wrote: I can't promise anything yet I stared the topic so... if you need advices. 2009/9/2 Thibaut DEVERAUX thibaut.dever...@gmail.com +1 2009/9/2 Ludovic Dubost ludo...@xwiki.org One important thing I think is that you need to put an annotation feature demo on a public server somewhere, so that we can all see what's the current status Ludovic Lucien Pereira a écrit : Hi all, Annotation module success depends strongly of being able to provide a great user exprerience. So I think current annotation module UI should be improved, for now it has only been tested in firefox. Since I really do not have skills concerning interface ergonomy, I would propose that a designer handle it. annotation feature installation and usage instructions can be found here http://dev.xwiki.org/xwiki/bin/view/Drafts/AnnotationModule WDYT ? Lucien ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] Our strategy for Design docs already implemented
On Wed, Aug 19, 2009 at 9:18 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net wrote: Hi! Hi, Vincent Massol wrote: What do you mean because when I always get the same number of hits with 30 hits per presentation page and 3 pages... From my point of view of XWiki.org user, sometimes, there are some strange results or no result but I think this is due to the fact that the site content has been changed or the server redeployed and lucene has not indexed everything yet or there has been a problem while indexing. I've already asked several times about it and each time, when people look at my problem, it's OK again because lucene periodically indexes as far as I remember :) But you may speak about something else... Sergiu has been recently dealing with this issue. Please, see this... http://n2.nabble.com/Lucene-again-td3273364.html#a3273364 I'm getting now similar results with another searches. For instance, if I do a logged search looking for Servlet, I get this... http://xen.net/images/searchingServlet.jpg Only four entries out of 30 in the first page of results. The second one shows only 3 and the third one, eight out of ten. I am using Firefox 3.5.2 in a Mac OS X 10.5.8 box, and also get the same results using updated releases of Safari and OmniWeb. Cache is clean. What do you do today with your 10s of HardDrives with Mo, Go of deprecated data you don't even remember even if they could be interesting... The loss of digital information meaning also the loss of knowledge and maybe the loss of a part of our history will be one of the challenge in the future (this phrase is too serious so I put a smiley at the end :))... but there is also the case when some info keep going on internet and you would like it to be erased but it's almost impossible :):):) Gonna change the sentence in our home page right now!!! :-) Even though I do prefer to stick with this another one from you also with a smiley at the end... Everything is possible... your imagination is the limit :) Ricardo, I want to keep the copyright of my sentence and let Vincent with his sentence and I really disagree with him because my imagination has no limit :) http://n2.nabble.com/Programming-Help-td509957.html#a17229158 After all, not all is lost in the net. Let's XWiki cope with the challenge! I will be relatively far from computers for five days. But of course I will do as much as I can to follow all the interesting topics that are being discussed in the lists. Thanks for your time. Cheers, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] Our strategy for Design docs already implemented
hi On Wed, Aug 19, 2009 at 1:06 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net wrote: Hi, Vincent Massol wrote: This is the usual question and the answer is usually that you need to keep a reader able to read them along with the data. Even more you need to maintain the reader over time to ensure it continues running on the hardware. Then how long the data is kept online completely depends on the domain and use case. In your case you could keep it 10 years online or more. Provided you have enough disk space and your DB is correctly indexed, that should work fine. I know this is a kind of thread kidnapping, but here we have one our main concerns right now: Lucene search seems to have some issue that prevents it to work fine. For instance. I get 70 hits (logged search) when looking for Servlet... http://www.xwiki.org/xwiki/bin/view/Main/LuceneSearch?text=Servletx=0y=0 Only a variable number of entries are shown in each page, but never the total number. I think this is a major issue concerning how to retrieve stored contents. I don't know if it could be my Internet clients that are doing something wrong, but I keep getting this consistently. What do you mean because when I always get the same number of hits with 30 hits per presentation page and 3 pages... From my point of view of XWiki.org user, sometimes, there are some strange results or no result but I think this is due to the fact that the site content has been changed or the server redeployed and lucene has not indexed everything yet or there has been a problem while indexing. I've already asked several times about it and each time, when people look at my problem, it's OK again because lucene periodically indexes as far as I remember :) But you may speak about something else... For a documentation site it's a bit more problematic since the site needs to be relatively clean and when users go to it they should not feel it's a mess or a work in progress too much since otherwise this feeling will reflect on their feeling for the software. In the case at hand it's acceptable since it's on the dev wiki and not the main documentation wikis. I can only agree with this. It seems to me that I am being a bit naive thinking about a unique repository of prose/data/information from which applying rules and policies will shown the right facet for each type of users. I agree about the fact that clear documentations eases the access of new users to any new system/software. Well I think we both agree: 1) wikis are tools that make it easy to keep stuff up to date and apply refactorings to content 2) in general it's bad form to loose content For 2) I was focusing on the content representing the solution in the design docs which I was proposing to drop from the design doc since I was proposing to move it elsewhere (in the main doc location). However I was indeed also suggesting to loose content (which was the comments in the design docs or some intermediary steps that allowed us to reach the final solution). However Sergiu didn't agree and I could understand why. So I backtracked and I've moved done design docs in a DesignArchive space. At some points it'll get removed but it'll probably be in a few years now. I do hope in a few years time we have the solution for to-be-deprecated contents! What do you do today with your 10s of HardDrives with Mo, Go of deprecated data you don't even remember even if they could be interesting... The loss of digital information meaning also the loss of knowledge and maybe the loss of a part of our history will be one of the challenge in the future (this phrase is too serious so I put a smiley at the end :))... but there is also the case when some info keep going on internet and you would like it to be erased but it's almost impossible :):):) Thanks for your time, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Proposal] Refactoring of DevGuide
good initiative :) Now, what could be interesting would be to provide some newer tutorials concerning XWiki2.0 and new syntax, modules etc... (the TODO tutorials and groovy class are a bit old now) regards Pascal On Mon, Aug 17, 2009 at 7:55 PM, Vincent Massol vinc...@massol.net wrote: Hi, I've started a refactoring of DevGuide today: * Removed the Tutorial page and put everything on DevGuide.WebHome. It was too hard to decide what was a tutorial from what wasn't. * Reordered stuff on DevGuide.WebHome. Notably I've put XWiki Architecture on top and I've started to improve it, see http://platform.xwiki.org/xwiki/bin/view/DevGuide/Architecture * All Reference docs should go in a Module on code:Modules.WebHome * Module doc should contain: - general architecture - features of the module - quick examples where it makes sense - link to tutorials that should be written in the DevGuide WDYT? What am I missing? Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [PROPOSAL] Restrict OO server administration to mainxwiki
I'm also really +1 since this is a bit disturbing... On Wed, Jul 29, 2009 at 12:14 PM, PERINAUD Christophe christophe.perin...@kbl-bank.com wrote: +1 -Message d'origine- De : devs-boun...@xwiki.org [mailto:devs-boun...@xwiki.org] De la part de Asiri Rathnayake Envoyé : mercredi 29 juillet 2009 11:52 À : XWiki Developers Objet : [xwiki-devs] [PROPOSAL] Restrict OO server administration to mainxwiki Hi Devs, Currently on a multi-xwiki installation all the xwikis can manipulate the OO server instance shared between them. I think it makes more sense to allow only the primary xwiki to control the oo server while rest of the xwikis become observers / consumers. WDYT? Here is my +1. Thanks. - Asiri ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs This e-mail is intended only for the addressee named above. It does not bind the sender, except in the case of an existing written convention with the addressee. This e-mail may contain material that is confidential and privileged for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender and delete all copies. While reasonable precautions have been taken to ensure that this e-mail and any attachments are free from any computer virus or similar defect, no liability will be accepted in that respect. Anyone accessing this e-mail must take their own precautions as to security and virus protection. KBL European Private Bankers S.A., 43 boulevard Royal L-2955 Luxembourg, R.C.S. Luxembourg B 6395, T (352) 47 97 1 ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki as simle Web Site Platform
On Mon, Jul 27, 2009 at 9:43 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net wrote: Hi! Pascal Voitot wrote: Sorry guy, yes I know one... football ;) And I really hope this is not an issue to be a man or woman for XWiki :):):)... We are all equal and humble regarding XWiki, aren't we? And anyway, XWiki contains only X chromosom in its name, no Y so I would tend to say it might be more a product for women than for men ;););) :-) As this list is not the right place for small talk, I think that we must move the discussion about football and chromosomes to any more interesting place... perhaps some cold beer will ease the chat. I feel myself more and more comfortable here. After all, ecosystems and chromosomes are, or have been, my work topics for years! you're right, this is not twitter here ;) anyway, we can enjoy a bit before going back to our lifes of resources ;) Cheers, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki as simle Web Site Platform
2009/7/27 [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net Pascal Voitot wrote: sorry for my last empty mail... clicked too quick... I think about Sharepoint for example... this is the first answer you get when dealing with content management in companies where office networks already run on Microsoft technos... I should have a look at it to have some arguments to say this might not be the best solution... apparently it can mix content with structured data as XWiki can do with classes/objects... Anyone knows about it? Sorry, Pascal, I don't understand what content does mean here. Are not strutured data content? Won't be better to say something like apparently it can mix structured and unstructured data being content reserved for the whole thing? And I don't understand the comparison with the use of classes/objects in XWiki. Yes this is exactly what I mean... you can mix some structured data and unstructured also... In my mind, classes/objects in XWiki are the structured data and the classical Wiki content is the unstructured data... Do you thing to put an example is worth here? I can't give an example as I don't have sharepoint :) I am struggling to navigate in the structured data/documents world and getting the right terminology. After only a few weeks back in an old path I've abandoned for more than a year, I think that what we are looking for here is a on-line/off-line Schema-Guided Document-Editing Interface (Schema being here DTD, XML Schema, or whatever other language developed to describe XML schemas). To be able to decide if XWiki would be the framework for such an objective will be of a great help! Don't understand what you mean with your XML Schemas? Do you want to represent your structured data with schemas? Best, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki as simle Web Site Platform
On Mon, Jul 27, 2009 at 8:10 PM, [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net wrote: Pascal Voitot wrote: Yes this is exactly what I mean... you can mix some structured data and unstructured also... In my mind, classes/objects in XWiki are the structured data and the classical Wiki content is the unstructured data... OK. I've got the point. Don't understand what you mean with your XML Schemas? Do you want to represent your structured data with schemas? Yeap. Consider this schema wroten in XML Schema language http://examples.oreilly.com/xmlschema/examples/first.xsd It is possible/it is feasible to be possible working with XWiki to guide the edition of documents complying with this schema? I am sure I am missing a lot of subtle and no so subtle issues here. But I am trying to be as precise as possible. I've been working for Adobe FrameMaker for years, but never got the point of structural enforcement. I am trying now to regain access to this issue and to understand how XWiki could fit with this task. Adobe FrameMaker is a great tool. I missed it a lot! But it could be one of this huge tools that is much bigger than the problem we are facing right now. If XWiki can grow/develop in this direction, we will devote our efforts to solve our needs with it. I'm not the guy to give you any answer but I'm interested in this idea... What do you mean exactly by guide the edition complying with this schema? Should it be just metadata associated with the doc or should the doc follow a template based on this schema or is it a kind a form associated to the document? Sorry for not being able to be clearer! Cheers, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki as simle Web Site Platform
On Mon, Jul 27, 2009 at 12:50 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net wrote: Pascal Voitot wrote: On Sat, Jul 25, 2009 at 11:23 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net wrote: I really agree with you. In my case, I can tell you that I chose XWiki after trying many other solutions and it appears to be the best solution for my problems in the open source world... I use XWiki not just for fun or because it's opensource but because it really fits my needs! And, in the proprietary software world, what are the comparison points for you? Thanks! Greetings! -- Ricardo Rodríguez Your EPEC Network ICT Team ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki as simle Web Site Platform
On Mon, Jul 27, 2009 at 12:55 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net wrote: Pascal Voitot wrote: You would be right in a humanistic world but in ours, companies policies more and more teach me to speak about cattle-days :):)... and tell to your wife not to care about equality because women or men are quite equal with respect to this way of thinking: you're just a resource with a cost, nothing less, nothing more ;) I am sure to be a woman or to be a man is not an issue on this list, or in the XWiki project as a whole! But perhaps you know cases where the cost of the human resource depends, at some extent, on gender. If you don't, those are great news! Sorry guy, yes I know one... football ;) And I really hope this is not an issue to be a man or woman for XWiki :):):)... We are all equal and humble regarding XWiki, aren't we? And anyway, XWiki contains only X chromosom in its name, no Y so I would tend to say it might be more a product for women than for men ;););) Greetings, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki as simle Web Site Platform
On Mon, Jul 27, 2009 at 12:50 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net wrote: Pascal Voitot wrote: On Sat, Jul 25, 2009 at 11:23 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net wrote: I really agree with you. In my case, I can tell you that I chose XWiki after trying many other solutions and it appears to be the best solution for my problems in the open source world... I use XWiki not just for fun or because it's opensource but because it really fits my needs! And, in the proprietary software world, what are the comparison points for you? Thanks! Greetings! sorry for my last empty mail... clicked too quick... I think about Sharepoint for example... this is the first answer you get when dealing with content management in companies where office networks already run on Microsoft technos... I should have a look at it to have some arguments to say this might not be the best solution... apparently it can mix content with structured data as XWiki can do with classes/objects... Anyone knows about it? regards Pascal -- Ricardo Rodríguez Your EPEC Network ICT Team ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki as simle Web Site Platform
On Fri, Jul 24, 2009 at 1:29 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net wrote: Hi! Pascal Voitot wrote: Hm, one thing I'd like to have before going forward with this app is a better event management. The observation component is good, but we're not using it enough. On top of it, we should build a workflow module. Once we have this, writing a publishing control system should be easy. At least a basic one, I don't know what those strange names you used (HIPAA, HL7) imply. About integrating with another tool, this is also a good idea, provided that the tool provides nice APIs, and the tool is complex enough to make a velocity replacement hard to implement. Please guys, don't use heavy orchestration industrial engines. I use them all my days and there are really a pain, almost crazy. I can't understand why people continue to go in this way just to design automaton with few states and actions. Pleaase don't do that ;) Please, what are these heavy orchestration industrial engines you propose to avoid? Thanks! things like workflow engines such as jBPM, Bonita or even if we are crazier, BPEL (I don't see why we could use BPEL here but I really think this is the example of a technology that :) )... I don't say these engines are really bad but they are too much complicated, too much theoretic, too heavy for a simple workflow... Best, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki as simle Web Site Platform
On Fri, Jul 24, 2009 at 2:13 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net wrote: Hi! Pascal Voitot wrote: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Skins Yes I have seen this... As I said, you can customize everything you want in XWiki, even the skin... but it is not quite easy without lots of scripting and CSS-styling etc... And what's interesting in Drupal, Joomla or Magnolia is that you can easily find skin templates on the web with all the UI components needed to build a website and there are also modules that allow to customize graphically the lookfeel of your website. Generally I Don't want to spend too much time on skin design when I begin a new web project... I want to focus on the content, not on the skin... I get your point. But until I see your site done with Magnolia+XWiki, I thought that it is really possible to identify a site done with Drupal or Joomla, by the look of the customized skins done by using the customization wizards of this systems. yes generally, you can see that :) My aim was just to have a quick facade looking like a complete site, not like a wiki or a blog and then I wanted to keep XWiki as the content provider. OK, XWiki has not such kind of tool, but I think I do prefer a clear and complete documentation that can be understood by a design team to be appointed to develop a completely different look and feel over a WYSIWYG wizard allowing, probably, only some actions. the wysiwyg should only be a helper allowing to access some features more easily but we need to keep the deep customization features (the XWiki wysiwyg editor is an example of that... you can write with it but when you need to have a more precise view, you go in the classical editor) I am sure, with an enlarged dev team, none of these will be a problem! for sure, this wouldn't be a problem ;)... Imagine you have a project with a quotation of 1.000.000 mendays... you find 1.000.000 people and in 1 day, you have your solution :) Cheers, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki as simle Web Site Platform
On Fri, Jul 24, 2009 at 9:09 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net wrote: Hi! Pascal Voitot wrote: things like workflow engines such as jBPM, Bonita or even if we are crazier, BPEL (I don't see why we could use BPEL here but I really think this is the example of a technology that :) )... I don't say these engines are really bad but they are too much complicated, too much theoretic, too heavy for a simple workflow... Thanks. I've been taking a look at Bonita and can, more or less, understand what do you mean. Thus, another doubt, why do these workflow engines exist? I mean, what is the difference between the workflows we are speaking about and those jBPM, Bonita or whatever engine you could know must face? Are they in an alternative path or have these engines unnecessary complexity? I don't have a precise answer and I don't want to say stupid things because I'm not exactly an expert at workflow design even if I use that often :)... My feeling is that these technologies are born from the industrial server movement... you know, a bit like J2EE servers... in a charicatural sentence, I would say:the bigger the better... you take all the problems as a whole and you provide a global solution for all problems... and then some people say:don't you think we could have something a bit more lightweight which fulfills only what we need while keeping the possibility to use the big server when we need it?... and people find new ideas, concepts and designs to make things more lightweight and you get things like Spring for example (which is no more so lightweight anyway) and it makes change J2EE servers because these ideas are not so stupid... So now you take the great subject of automaton with states, workflows, orchestrations, business process management and you create a tool allowing to model any process corresponding to the theory, you participate to some standardization meetings to make things a bit more abstract. Finally, you get something powerful, huge, complex that can do everything you need but also you don't need. In fact, if you look carefully, these questions about process management are almost everywhere in the industry but there are no good solutions. There are some professional tools but they cost so much that you can't even imagine paying that just to design a small publishing workflow... BPM, BPM, BPM, BPM everywhere :)... I say that because it seems Business Process Management is becoming a kind of holy grail for marketting people in the software industry... but not sure technical people agree ;););) Ok, that's all for now... There are workflow engines in the opensource world but I don't know them precisely so I can't say they are simpler or better... This is my point of view from the industrial world :) Thanks for your thoughts! Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki as simle Web Site Platform
hello On Fri, Jul 24, 2009 at 1:14 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net wrote: Hi, Pascal, I'am still catching up with the XWiki 2.0. I can more or less understand what you are saying about Magnolia, JCR, MVC and the CMS authoring/public pair (I've seen this in OpenCMS, but I am not sure this is also truth in Joomla, for instance), but I've not been able yet of having an in depth look to the new XWiki 2.0 and its brand new WYSIWYG editor. In fact, I keep using the XWiki edition mode. I guess there are a lot of new features concerning skin customization in this new release but it is possible there are not documented yet. Also, there is an open project, XWiki Skin Extensions, http://jira.xwiki.org/jira/browse/XSKINX, devoted to convert the skin extension module intro a proper component. Have you seen this... http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Skins Yes I have seen this... As I said, you can customize everything you want in XWiki, even the skin... but it is not quite easy without lots of scripting and CSS-styling etc... And what's interesting in Drupal, Joomla or Magnolia is that you can easily find skin templates on the web with all the UI components needed to build a website and there are also modules that allow to customize graphically the lookfeel of your website. Generally I Don't want to spend too much time on skin design when I begin a new web project... I want to focus on the content, not on the skin... Pascal Cheers, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki as simle Web Site Platform
hello, On Wed, Jul 22, 2009 at 8:23 AM, Sergiu Dumitriu ser...@xwiki.com wrote: [Ricardo Rodriguez] Your EPEC Network ICT Team wrote: Hi, Sergiu, thanks for the answer. Sergiu Dumitriu wrote: Well, a pretty simple solution is to use a Draft space, where guests don't have view rights and all the registered users have edit rights, and here people collaborate and create documents. When they consider that a document is ready for the public, they let the admins know about this, and one of the admins moves the document to its final destination, where only admins can write. I agree, this is straightforward. This involves only a bit of access rights tweaking and the Rename menu entry, without any complex tools or processes, but it assumes that people are not evil and will respect the rules, which is usually true inside a company. But evil could be in house. And even though evil is not there we, human beings, are really bad at following rules. Guided editing (something using a DTD, or a XML Schema compliant document,...) could be the key. Even more, there are legal constraints (something like HIPAA and/or HL7 ) that forces us to have a fine grained publishing control system. It is frequent to be required to control what document, or section of a document, has been accessed or edited, when, by whom and from where. And what document or part of a document will be published, when and who has approved this action. Integration of XWiki with other Open Source initiatives seems to be an answer. For me the question here is if it is better to keep developing XWiki in a given area, or to join another project as an alternative. For instance, Pasca Voitot speaks in this same thread about the use of Magnolia to provide a easily customizable front end for XWiki. The result as he shows in his site Mandubian is quite good, but it seems to me that XWiki skins are not so far of being able to allowing something better! One thing that should NOT be done, is to use different tools in parallel. One of the big advantages of XWiki is that it allows to build several application in the same place. True, such a small application done with a piece of Velocity and a bit of JavaScript doesn't have all the power and features of a dedicated system, but the advantages are numerous: - one place - one UI - one common set of rules - one principle: the wiki way - for the developers, one API and one common programming paradigm - etc. One tool to rule them all etc... I have always been fighting against this industrial way of thinking that tend to consider everything can go in the same box... It sounds scary when someone tells me:do NOT use other tools... But I see what you mean: using several tools that do the same thing in parallel is not very good. But I prefer saying I use the best part of each tools and make them fit together. From my point of view, I consider XWiki as a toolbox or an enabler: it allows me to do things I could never do alone because I would spend too much time gathering everything. But sometimes, I don't find what I need in XWiki immediately and I don't have time to develop it completely, so I use another tool and I distort the other tool and XWiki until they fit together. This is not the solution for long term but it works. Moreover, it gives me ideas about the where should go XWiki to fulfill such needs. But, in fact, I really consider XWiki as an engine and I put the UI part aside. I often need a content manager based on the XWiki features and then I need to present this content. To my mind, the UI part of XWiki and the skin should be separated as much as possible from XWiki (it is already the case) and should be given some nice tools inspired by what can be found in other tools for customizing skins. It could be said that all these requirements could be only fulfilled by a top-level commercial software. But we are in the Open Source side of the moon! Why? This is the subject of a PhD dissertation :-) As you say, XWiki apparently has all the required pieces to construct such a system. I am trying to be as sure as possible that we are on the right, or at least as right as possible, place. Hm, one thing I'd like to have before going forward with this app is a better event management. The observation component is good, but we're not using it enough. On top of it, we should build a workflow module. Once we have this, writing a publishing control system should be easy. At least a basic one, I don't know what those strange names you used (HIPAA, HL7) imply. About integrating with another tool, this is also a good idea, provided that the tool provides nice APIs, and the tool is complex enough to make a velocity replacement hard to implement. Please guys, don't use heavy orchestration industrial engines. I use them all my days and there are really a pain, almost crazy. I can't understand why people continue to go in
Re: [xwiki-devs] XWiki as simle Web Site Platform
On Wed, Jul 22, 2009 at 12:51 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team webmas...@environmentalchange.net wrote: Hi! Pascal Voitot wrote: Hello, Here is my experience. For my simple technical website (www.mandubian.org (not ads here)), I used a mix between Magnolia and XWiki: Your site looks nice! thks ;) - Magnolia as the content aggregator and visual facade using Magnolia easily customisable skin system, publishing/workflow features and also for the idea of authoring/public instances. But I don't need anything more from Magnolia. So, it seems that it is worth to invest some efforts to improve and/or ease the skin customization application. I don't know who is actually working in this issue, but I remember a lot of messages about the topic. Don't you think that it is worth to invest some time/resources in developing such an application? yes it is worth... I don't know who works on that now as I'm not in XWiki team but I think this might take some time also. Moreover, the question is: what is a good skin customization tool? (keeping current flexible features around velocity and giving a nice wysiwyg way of structuring your skin)... In a summary, in magnolia, as everything is stored in JCR, everything is a tree and then the skin is a tree. They mix this tree structure with the templating approach. So you build your skin from the top to the bottom: parts embedding other parts embedding other parts etc... And you can say: in this part, I can accept only this and this and this. Then they have a kind of MVC model to represent each part and the rendering part is managed with the templating engine FreeMarker (velocity like). So it is quite easy to change the skin structure. Finally what's nice with their tool is that when you are working on your site, you have a quick view of it and every content in it is enhanced by a small toolbox allowing to edit, move, delete it... with that, you can reorganize the page in a WYSIWYG way. I want this teaser to go before this one, I want to add a new paragraph just here, to change this header or footer here, to change the title etc... almost inline editing... not perfect but quite practical... Not the same approach as the wiki approach but with the xwiki wysiwyg editor, we go in this way. I really like the idea of changing the site from the site itself. (No I don't want to have dreamweaver, just some features of it ;););) ) And something I like in CMS: you have an authoring instance and a public instance of your site. You play in the authoring instance until you are happy and then you publish from the authoring instance into the public instance... You guys at XWiki must be in the middle of the now classical CMS/Wiki conflict but I used some CMS for some time now and XWiki for some time also and my conclusion is that I don't see any reason why XWiki couldn't be used to create nice websites. I am not sure if this is right terms of the discussion. Is it possible to compare a CMS with XWiki? I don't know if it is possible to compare a CMS with other wikis, but XWiki is, if I've well understood, about using the wiki concept to develop applications, no contents. Contents are of course an important part of the system. Thus, publishing control and guided edition could be killer applications. Yes it is possible to compare and lots of people do it all the time and even fight against each other... I'm for CMS... I'm for WIKI... this is the WCM, the war for content management... everyone wants the business of the other one.. I prefer working on their convergence in the domains in which they can converge... XWiki has its own channels for proposals, so it is my responsibility to try to write something with sense and sher it! Mandubian is now in my bookmarks toolbar! Keep it ;) Don't be surprised when it seems down, this is a private server and I perform some experience sometimes... Greetings, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] can/could/will Xwiki work with Google App Engine Javadatabase?
I thought about it and I vote YESSS :)... On Wed, Jul 22, 2009 at 8:43 PM, Niels Mayer nielsma...@gmail.com wrote: http://code.google.com/appengine/docs/whatisgoogleappengine.html Java is supported via Java 6 JVM and standard libs: http://code.google.com/appengine/docs/java/gettingstarted/ My biggest question w/r/t Xwiki is AppEngine's database support: The Datastore App Engine provides a powerful distributed data storage service that features a query engine and transactions. Just as the distributed web server grows with your traffic, the distributed datastore grows with your data. The App Engine datastore is not like a traditional relational database. Data objects, or entities, have a kind and a set of properties. Queries can retrieve entities of a given kind filtered and sorted by the values of the properties. Property values can be of any of the supported property value types http://code.google.com/appengine/docs/python/datastore/typesandpropertyclasses.html . Datastore entities are schemaless. The structure of data entities is provided by and enforced by your application code. The Java JDO/JPA interfaces and the Python datastore interface include features for applying and enforcing structure within your app. Your app can also access the datastore directly to apply as much or as little structure as it needs. The datastore is strongly consistent http://en.wikipedia.org/wiki/Consistency_modeland uses optimistic concurrency control http://en.wikipedia.org/wiki/Optimistic_concurrency_control. An update of a entity occurs in a transaction that is retried a fixed number of times if other processes are trying to update the same entity simultaneously. Your application can execute multiple datastore operations in a single transaction which either all succeed or all fail, ensuring the integrity of your data. The datastore implements transactions across its distributed network using entity groups. A transaction manipulates entities within a single group. Entities of the same group are stored together for efficient execution of transactions. Your application can assign entities to groups when the entities are created. http://code.google.com/appengine/docs/java/gettingstarted/usingdatastore.html App Engine includes support for two different API standards for the datastore: Java Data Objects http://java.sun.com/jdo/index.jsp (JDO) and Java Persistence API http://java.sun.com/developer/technicalArticles/J2EE/jpa/(JPA). These interfaces are provided by DataNucleus Access Platform http://www.datanucleus.org/, an open source implementation of several Java persistence standards, with an adapter for the App Engine datastore. .. Question: What would it take to make Xwiki work on Google App-engine? Is the datastore google provides compatible with xwiki's database needs? What other Java-hosting services out there support Xwiki? Database and java hosting issues for Xwiki can be problematic, even though it makes more sense, to public-host using a language like Java. I think for my own situation, I would end up hosting Xwiki myself, as a $500.00 box can run a few Xwiki-based sites just fine. However, for people/customers wanting an Xwiki-based site that don't know about system administration, JVM's, apache, etc, it would be nice if there was an easier path to managed hosting in an open market. This needn't limit xwiki.com 's hosting market, as much as it would open-up xwiki for wider deployment and use, and make it competitive in situations where Php or RoR might have easier buy-in, such as in the USA Imagine if in the future, one of the installers Xwiki.org offered worked directly with http://appengine.google.com/ so that people would actually have their own live, public xwiki sites hosted for them. There's plenty of sites that would be happy with this level of free service ( http://code.google.com/appengine/docs/quotas.html ): Resource Free Default Quota Billing Enabled Quota Daily Limit Maximum Rate Daily Limit Maximum Rate Requests 1,300,000 requests 7,400 requests/minute 43,000,000 requests 30,000 requests/minute Outgoing Bandwidth (billable http://code.google.com/appengine/docs/quotas.html#Billable_Quotas_and_Fixed_Quotas , includes HTTPS) 1 gigabyte 56 megabytes/minute 1 gigabyte free; 1,046 gigabytes maximum 740 megabytes/minute Incoming Bandwidth (billable http://code.google.com/appengine/docs/quotas.html#Billable_Quotas_and_Fixed_Quotas , includes HTTPS) 1 gigabyte 56 megabytes/minute 1 gigabyte free; 1,046 gigabytes maximum 740 megabytes/minute CPU Time (billable http://code.google.com/appengine/docs/quotas.html#Billable_Quotas_and_Fixed_Quotas ) 6.5 CPU-hours 15 CPU-minutes/minute 6.5 CPU-hours free; 1,729 CPU-hours maximum 72 CPU-minutes/minuteNiels http://nielsmayer.com PS: although at 1 gigabyte outgoing bandwidth, and some of the
Re: [xwiki-devs] can/could/will Xwiki work with Google App Engine Javadatabase?
I don't know if I can say I have time now because I'm so busy but I'm really interested at it... Doesn't the xwiki engine consume too much CPU time? On Wed, Jul 22, 2009 at 9:07 PM, Ludovic Dubost ludo...@xwiki.org wrote: Hi Niels, I have a prototype of XWIki partially working with some changes on app engine http://xwiki1.appspot.com/bin/view/Main/ I've made all the servlet / jvm part work as well as the cache subsystem. The main missing piece is a real storage with support for querying. We have no plans at this point to continue the work. If somebody wants to help I can give directions. Ludovic Niels Mayer a écrit : http://code.google.com/appengine/docs/whatisgoogleappengine.html Java is supported via Java 6 JVM and standard libs: http://code.google.com/appengine/docs/java/gettingstarted/ My biggest question w/r/t Xwiki is AppEngine's database support: The Datastore App Engine provides a powerful distributed data storage service that features a query engine and transactions. Just as the distributed web server grows with your traffic, the distributed datastore grows with your data. The App Engine datastore is not like a traditional relational database. Data objects, or entities, have a kind and a set of properties. Queries can retrieve entities of a given kind filtered and sorted by the values of the properties. Property values can be of any of the supported property value types http://code.google.com/appengine/docs/python/datastore/typesandpropertyclasses.html . Datastore entities are schemaless. The structure of data entities is provided by and enforced by your application code. The Java JDO/JPA interfaces and the Python datastore interface include features for applying and enforcing structure within your app. Your app can also access the datastore directly to apply as much or as little structure as it needs. The datastore is strongly consistent http://en.wikipedia.org/wiki/Consistency_modeland uses optimistic concurrency control http://en.wikipedia.org/wiki/Optimistic_concurrency_control. An update of a entity occurs in a transaction that is retried a fixed number of times if other processes are trying to update the same entity simultaneously. Your application can execute multiple datastore operations in a single transaction which either all succeed or all fail, ensuring the integrity of your data. The datastore implements transactions across its distributed network using entity groups. A transaction manipulates entities within a single group. Entities of the same group are stored together for efficient execution of transactions. Your application can assign entities to groups when the entities are created. http://code.google.com/appengine/docs/java/gettingstarted/usingdatastore.html App Engine includes support for two different API standards for the datastore: Java Data Objects http://java.sun.com/jdo/index.jsp (JDO) and Java Persistence API http://java.sun.com/developer/technicalArticles/J2EE/jpa/(JPA). These interfaces are provided by DataNucleus Access Platform http://www.datanucleus.org/, an open source implementation of several Java persistence standards, with an adapter for the App Engine datastore. .. Question: What would it take to make Xwiki work on Google App-engine? Is the datastore google provides compatible with xwiki's database needs? What other Java-hosting services out there support Xwiki? Database and java hosting issues for Xwiki can be problematic, even though it makes more sense, to public-host using a language like Java. I think for my own situation, I would end up hosting Xwiki myself, as a $500.00 box can run a few Xwiki-based sites just fine. However, for people/customers wanting an Xwiki-based site that don't know about system administration, JVM's, apache, etc, it would be nice if there was an easier path to managed hosting in an open market. This needn't limit xwiki.com's hosting market, as much as it would open-up xwiki for wider deployment and use, and make it competitive in situations where Php or RoR might have easier buy-in, such as in the USA Imagine if in the future, one of the installers Xwiki.org offered worked directly with http://appengine.google.com/ so that people would actually have their own live, public xwiki sites hosted for them. There's plenty of sites that would be happy with this level of free service ( http://code.google.com/appengine/docs/quotas.html ): Resource Free Default Quota Billing Enabled Quota Daily Limit Maximum Rate Daily Limit Maximum Rate Requests 1,300,000 requests 7,400 requests/minute 43,000,000 requests 30,000 requests/minute Outgoing Bandwidth (billable http://code.google.com/appengine/docs/quotas.html#Billable_Quotas_and_Fixed_Quotas , includes HTTPS) 1 gigabyte 56 megabytes/minute 1 gigabyte free;
Re: [xwiki-devs] XWiki as simle Web Site Platform
Hello, Here is my experience. For my simple technical website (www.mandubian.org (not ads here)), I used a mix between Magnolia and XWiki: - Magnolia as the content aggregator and visual facade using Magnolia easily customisable skin system, publishing/workflow features and also for the idea of authoring/public instances. But I don't need anything more from Magnolia. - XWiki as the content provider with a small plugin I developed in order to integrate XWiki into Magnolia. XWiki provides a much simpler and concrete way to create my content because my website is not a commercial site or sport news site. In a summary, I write with XWiki and I publish with Magnolia. So everything is not perfect and well integrated but it works and I can publish my small articles quite easily. In fact, beyond some publishing and workflow features that XWiki lacks, the reason why I chose to use Magnolia CMS for the what you see and XWiki for the what you get is the skin issue: I can't spend too much time customizing the skin and I need a practical base for this: - a nice skin with all the stuff a website usually provides (menus, teasers, panels, events, columns, etc...) - A wysiwyg way to modify the skin and re-organize the structure of the presentation Magnolia (and other CMS) provides it. XWiki provides everything to do it but not out of the box and you need to customize everything manually. I customized XWiki skin for some sites focused on the Wiki features but for a public website, this consumes too much time. You guys at XWiki must be in the middle of the now classical CMS/Wiki conflict but I used some CMS for some time now and XWiki for some time also and my conclusion is that I don't see any reason why XWiki couldn't be used to create nice websites. regards Pascal On Sat, Jul 18, 2009 at 11:35 AM, Ludovic Dubost ludo...@xwiki.org wrote: Hi, Indeed, XWiki is very close to a CMS and actually often used for this (we use it for xwiki.com and xwiki.org). When you look at it, most CMS work like this: 1/ Admin interface allowing to create a page, setup where it will show up (on the home page, in a category menu, in a tag menu, in a Tree menu) but not yet publish it 2/ Review with simple (most often) or more complex workflow 3/ Decide to publish it 4/ Once it's publish it shows up 5/ Then you have tool too manage the result (delete, view stats, etc..) The main difference with XWiki is the way you make the page show up on the end site. In a Wiki you are told to first create the link, then edit the page, which makes the page show up right away. This makes the review part not work at all. Another difference is that you might want to be able to make a bit more complex pages in a CMS (columns and so) However the Blog is not that different from the CMS part, if we added the review and more control of where the page shows up. In a Blog you are very temporal. In a CMS you might not want the page to show up in the Home page at all. You just want the page to show up where you said it should show up. I'm not sure if what you suggest is what you are saying. I think you are more talking about the complex page issue. On this matter we discussed this on a projet last friday where we need columns in the page and we thought the Wysiwyg could handle columns. It would be good to review what CMS do and integrate this nicely in XWiki, as people more and more want to mix Publishing Web site with collaborative ones. Ludovic Andreas Schaefer a écrit : Hi Currently our company is using Magnolia (magnolia.info) as the CMS for our website. Because our website is not very dynamic, big or complex using Magnolia is often a little bit of an overkill and keeping it up to date is not easy. So I was wondering if I could use XWiki to create a simple application that would enable the creation and maintenance of a website. Today the Blog is a list of Blog Document building up the blog page. Breaking up the page into a header, left and right side bar (or using the panels) and columns for the content it should be possible to define a web page. The parts of a page a defined by classes and the content is provided by objects. The application just provides the code that displays the web site and additional elements to create, edit and remove parts of the document (paragraphs) when the user is in edit mode. The application would provide a simple web site but also the framework to create a custom web site by extending the application. What do you think? Andreas Schaefer CEO of Madplanet.com Inc. EMail: andreas.schae...@madplanet.com schaef...@me.com Twitter: andy_mpc AIM: schaef...@me.com ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Re: [xwiki-devs] default behavior of editsection when including documents?
On Fri, Jul 10, 2009 at 8:42 AM, Jean-Vincent Drean
jean-vinc...@drean.orgwrote:
On Thu, Jul 9, 2009 at 7:53 PM, Pascal
Voitotpascal.voitot@gmail.com wrote:
Hello,
I can now edit sections on my 1.9RCx (modifications where light so I
could
retrofit them)
But when I do sthg like:
{{include document=MyDocument/}}
I don't see the section editing for the included content.
Is it the default behavior not to propose section editing when the
document
is included into another one?
Yes, the rule is: if a title is output by a macro (include, velocity,
etc) don't provide a link to edit the section.
The reason we forbid editing of section generated by scripts
(velocity, etc) is quite obvious, these titles can be generated and
thus we wouldn't be able to find them in the wiki source. About titles
coming from included documents, from a usability standpoint it could
be misleading to be redirected to the edition of another document.
Note that the behavior of section editing with xwiki/2.0 mimics the
xwiki/1.0 behavior.
In fact, I quite agree with your choice, I just wanted to be sure about
that...
I wanted to have a main document built just by including other documents and
to be able to edit those documents' sections directly from the main
document.
But I found a solution for my case which respects XWiki behavior: why not
directly integrate the documents I want to edit into the main document. So,
instead of including another document into my main document, I use a script
that reads a document template and pastes its content into my main document.
Pascal
Thanks,
JV.
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] section editing in wiki/2.0
thanks for giving this info, I had no time looking at jira... I'm running my wiki with a 1.9-RCx 3 weeks old... I should try to upgrade my server up to 2.0 but I don't want to break the existing installation since I'm intensively using it. Pascal On Thu, Jul 9, 2009 at 8:10 AM, Marius Dumitru Florea mariusdumitru.flo...@xwiki.com wrote: Hi Pascal, Pascal Voitot wrote: Hello, apparently this feature is no more directly available in wiki/2.0. But when I use /xwiki/bin/edit/MySpace/MyDoc?section=1, it edits the section 1 of my doc but when I save it, it keeps only section 1 in the doc and removes everything else. Is it a bug? http://jira.xwiki.org/jira/browse/XWIKI-4033 http://jira.xwiki.org/jira/browse/XWIKI-2881 So you should be able to edit a section using the query string in 1.9.1 and by clicking on the pen near the section in 2.0 Hope this helps, Marius regards Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] default behavior of editsection when including documents?
Hello,
I can now edit sections on my 1.9RCx (modifications where light so I could
retrofit them)
But when I do sthg like:
{{include document=MyDocument/}}
I don't see the section editing for the included content.
Is it the default behavior not to propose section editing when the document
is included into another one?
regards
Pascal
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] section editing in wiki/2.0
Hello, apparently this feature is no more directly available in wiki/2.0. But when I use /xwiki/bin/edit/MySpace/MyDoc?section=1, it edits the section 1 of my doc but when I save it, it keeps only section 1 in the doc and removes everything else. Is it a bug? regards Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] document name with . in it?
On Mon, Jul 6, 2009 at 7:26 AM, Asiri Rathnayake asiri.rathnay...@gmail.com wrote: Hi, On Sun, Jul 5, 2009 at 3:04 PM, Pascal Voitot pascal.voitot@gmail.comwrote: Hello, For example, I have a space Space and I want to create a doc mydoc.name in it I do xwiki.getDocument(Space.mydoc.name) but it creates a space Space.mydoc and a doc with name name AFAIK if you create a document like a.long.document.name.separated.by.dots xwiki will treat all the characters up to the final dot (.) as the space name and the rest as the page name. I don't think there is a way to overcome this behaviour :( exactly the behaviour I discovered... I would have prefered that it stops to the first . it finds because this is what I need :):):):) Anyway if anyone has a quick solution, I would be glad to know it! Thks Pascal - Asiri is it possible to do that? Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] document name with . in it?
Hello, For example, I have a space Space and I want to create a doc mydoc.name in it I do xwiki.getDocument(Space.mydoc.name) but it creates a space Space.mydoc and a doc with name name is it possible to do that? Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] https in wikimanager
Hello, I'm creating Wiki from XwikiManager and I want to set the option SSL enabled but I don't see any difference when it is enabled or not... Can anyone give some info about this feature because I may have missed something? Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] https in wikimanager
On Wed, Jul 1, 2009 at 12:33 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: Hi, On Wed, Jul 1, 2009 at 12:20, Pascal Voitotpascal.voitot@gmail.com wrote: Hello, I'm creating Wiki from XwikiManager and I want to set the option SSL enabled but I don't see any difference when it is enabled or not... Can anyone give some info about this feature because I may have missed something? This option is just to force using https protocol in generated external URL. Like URL from other wikis. See http://manager.xwiki.org/xwiki/bin/view/AdminGuide/EditWikiDescriptor#HSecure Ok I see but for example when redirecting, should it generate also https url? because I don't see any difference when I activate this option... Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] https in wikimanager
On Wed, Jul 1, 2009 at 2:45 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: On Wed, Jul 1, 2009 at 14:14, Pascal Voitotpascal.voitot@gmail.com wrote: On Wed, Jul 1, 2009 at 12:33 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: Hi, On Wed, Jul 1, 2009 at 12:20, Pascal Voitotpascal.voitot@gmail.com wrote: Hello, I'm creating Wiki from XwikiManager and I want to set the option SSL enabled but I don't see any difference when it is enabled or not... Can anyone give some info about this feature because I may have missed something? This option is just to force using https protocol in generated external URL. Like URL from other wikis. See http://manager.xwiki.org/xwiki/bin/view/AdminGuide/EditWikiDescriptor#HSecure Ok I see but for example when redirecting, should it generate also https url? because I don't see any difference when I activate this option... Where exactly you don't see any difference ? As i said it's only for external URLs, inside the wiki itself most of the URLs are local URLs, meaning something like /xwiki/bin/view/Space/Page so yes you will not see any difference. For example you can quickly see the difference in the /xwiki/bin/view/WikiManager/ list of wikis on the main wiki: if it's enabled you will have in the column Domain names an URL with the protocol https. If it's not enabled it uses the protocol of the URL which called XWiki application. So usually you enable this option if you can't properly configure your proxy/apachehttps to give the right URL to XWiki. Ok I understand... only for external URLs and nothing else... my problem is that I'm behind apachehttps proxy which translates between external https and internal http and everything works fine but the saveandcontinue action... It gives a 302 temporarily moved error but do not redirect anywhere... I will look in the mailing lists if anybody had this problem... maybe a problem in my proxy config... thks anyway Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] XWikiSyntax generates exception
http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax gives : Error number 4001 in 4: Error while parsing velocity page Main.XWikiSyntax Wrapped Exception: Failed to evaluate content with id XWiki Syntax http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax ... org.apache.velocity.exception.MethodInvocationException: Invocation of method 'fromXML' in class com.xpn.xwiki.doc.XWikiDocument threw exception com.xpn.xwiki.XWikiException: Error number 2002 in 2: Error parsing xml Wrapped Exception: Error on line -1 of document : Premature end of file. Nested exception: Premature end of file. @ Main.XWikiSyntax6,16? http://platform.xwiki.org/xwiki/bin/edit/Main/6%2C16?parent=Main.XWikiSyntax at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:286) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:203) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:294) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) at org.xwiki.velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:178) at org.xwiki.velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:143) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:108) at com.xpn.xwiki.render.XWikiVelocityRenderer.render(XWikiVelocityRenderer.java:85) at com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:272) at com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:202) at com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderText(DefaultXWikiRenderingEngine.java:170) at com.xpn.xwiki.render.DefaultXWikiRenderingEngine.renderDocument(DefaultXWikiRenderingEngine.java:159) at com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:490) at com.xpn.xwiki.api.Document.getRenderedContent(Document.java:454) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) regards Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] base url
On Fri, Jun 19, 2009 at 2:04 AM, glenn_en...@agilent.com wrote: Is there a convenient way to obtain the base url? e.g. http://localhost:8080/xwiki or http://mysite.com maybe there are some better ways but in velocity exposed $xwiki, there are some functions such as getWebAppPath which could help you... -- Glenn ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] what's the best way to scrape an HTML document with Xwiki
On Thu, Jun 18, 2009 at 9:04 PM, Vincent Massol vinc...@massol.net wrote: Hi Niels, You could easily call $xwiki.getExternalURL() which returns the content at a URL. Then you can use our XHTML parser to generate a XDOM and then do whatever you want with it. Only little issue: the renderer is not available in the xwiki content right now. But if you're doing groovy it should be easy. For large document we can add a method easily in Parser interface: parser(Reader, Listener). All you'd need to do is implement Listener a groovy script for ex and you'd get called for each element in the page. Thanks -Vincent I agree with Vincent... Groovy is the easiest solution... In the past, I tried another weird solution consisting in integrating a JavaScript rendering engine on the serverside such as rhino... then manipulating a DOM in Javascript was quite natural and I could use great APIs such as prototype... It worked quite well but I'm not sure about the performance and memory issues but I found this idea funny: Javascript on serverside... This might seem a bit heretic to say that but there are some products on the market proposing to build websites with javascript on client and server side... On Jun 18, 2009, at 8:01 PM, Niels Mayer wrote: Is there anything like the Xwiki-feed-plugin except that instead of fetching a feed, it would fetch an HTML document via HTTP, returning a DOM structure that can be scanned or filtered by API-calls, e.g.: $fetchedDom = $xwiki.FetchPlugin.getDocumentDOM(http:// nielsmayer.com) $images = $fetchedDom.getImgList() $media = $fetchedDom.getAnchorHREFsByExtension([.mp3, .mv4, .mp4]) $content = $fetchedDom.getDivListById(['xwikicontent, 'container', 'content']) Since this would happen on the server, you'd probably need to fake being a real browser (or just capture the user's browser configuration and pass it via the call to the hypothetical getDocumentDOM() in order to capture an accurate scraped representation of a modern site.) The existing examples I've seen store an Xwiki document in the database first. I was hoping there was an in memory option that would allow for the document to be maintained in the app's context for long enough to process the remaining stream of plugin calls such as getDivListById() or getAnchorHREFsByExtension() and then appropriately dispose the DOM when no longer referenced, via garbage collection. Maybe compared to the implementation headaches -- of retrieving a potentially large document into memory incrementally, parsing it into a DOM incrementally, making that available in the context, etc -- maybe I should just write the damn document into the database, scrape it, and delete it. Since I would use Xwiki to store a JSON scrape of the document in the DB (as a xwiki doc), I could store it in XWiki.JavaScriptExtension[0] of the retrieved document, and then just delete the wiki-contents after scraping So actually, if anybody has any suggestions for scraping with a retrieved document, stored as Xwiki doc, please, suggest as well! This seems like an area potentially fraught with peril that many people have already dealt with, so I would appreciate advice. Thanks, Niels http://nielsmayer.com ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] Please re-index XWiki.org website, search engine returns only release pages...
Thanks Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Rendering] Two ideas using Transformation
Now the search engine works but yesterday when I search Rest for example, I got only some pages concerning recent Releases... But Vincent, you're right, the site is really slow... thks anyway guys Pascal On Fri, Jun 19, 2009 at 12:16 PM, Vincent Massol vinc...@massol.net wrote: Hi, Need 1: Be able to prevent some macros from execution in some contexts. For example in the comments field prevent usage of script and html macros Proposed solution: Use a Rendering Transformation with a high priority that removes (or that generate an error) those macros (the list of macros can be retrieved from a config file or from some execution context) Need 2: Ensure that renderers generate valid content (eg valid XHTML for the WYSIWYG editor). For example if the user uses the HTML macro and puts invalid HTML the WYSIWYG editor should still work Proposed solution: Use a Rendering Transformation with a low priority that traverses the XDOM to validate it (for example remove inline elements that are placed in a standalone context). WDYT? Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] logout redirection problem with XWiki server behind an apache proxy
Hello, I wonder whether this is a error in my servers configurations or this is a bug... I have an XWiki server running behind an Apache server and the link between them is performed using the simple mod_proxy with some pass such as: ProxyPass /xwiki/ http://localhost:8080/xwiki/ It works perfectly except when I logout... I get redirected to an URL looking like: http://localhost:8080/xwikihttp://mydomain/xwiki/bin/login/XWiki/XWikiLogin?srid=qr0P1jiA Do you have an idea of the reason of this behavior? regards Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] logout redirection problem with XWiki server behind an apache proxy
Ok I found the problem... I forgot just a thing: ProxyPreserveHost On By default it is OFF in apache mod_proxy and without it, xwiki has some problem... I have been tracking this stupid problem for a long time :) I found the solution while searching the mail archives... thks to the mail archives :) Pascal On Mon, Jun 15, 2009 at 10:59 AM, Pascal Voitot pascal.voitot@gmail.com wrote: Hello, I wonder whether this is a error in my servers configurations or this is a bug... I have an XWiki server running behind an Apache server and the link between them is performed using the simple mod_proxy with some pass such as: ProxyPass /xwiki/ http://localhost:8080/xwiki/ It works perfectly except when I logout... I get redirected to an URL looking like: http://localhost:8080/xwikihttp://mydomain/xwiki/bin/login/XWiki/XWikiLogin?srid=qr0P1jiA Do you have an idea of the reason of this behavior? regards Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] wiki manager - URL path access - problem with editor form buttons
Hello, I tried using the URL path based wiki access as described in Manager Admin Guide: http://localhost:8080/xwiki/wiki/mydomain.com/view/Main/WebHome It works perfectly but then I click on the Edit menu for any content from such an URL. Finally I try to click on a bottom button Cancel, Preview etc... It redirects me to : http://127.0.0.1:8080/xwiki/bin/login/XWiki/XWikiLogin?srid= So apparently with URL based notation, the form action is badly managed and redirect to 127.0.0.1 and then to the login as I'm not logger on 127.0.0.1... Do you know this issue? Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Rendering] Adding a Plain text parser syntax
finally there will be a plain/1.0 syntax :) This means, json will use it? Pascal On Wed, Jun 3, 2009 at 9:29 PM, Vincent Massol vinc...@massol.net wrote: Hi, I think we need to add a plain text parser a plain/1.0 syntax id. Here's a use case: you want to add a groovy class in a wiki page (and you don't want it to be rendered as wiki syntax of course). WDYT? Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Rendering] Adding a Plain text parser syntax
On Thu, Jun 4, 2009 at 12:55 PM, Vincent Massol vinc...@massol.net wrote: On Jun 4, 2009, at 12:49 PM, Pascal Voitot wrote: finally there will be a plain/1.0 syntax :) This means, json will use it? Note that the plain text renderer is already implemented (but not linked to a URL action yet). This is about a plain text *parser* Yes I see but it is a bit symmetric... parser/renderer... anyway, a plain text approach would be really useful... Thanks -Vincent On Wed, Jun 3, 2009 at 9:29 PM, Vincent Massol vinc...@massol.net wrote: Hi, I think we need to add a plain text parser a plain/1.0 syntax id. Here's a use case: you want to add a groovy class in a wiki page (and you don't want it to be rendered as wiki syntax of course). WDYT? Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] JSON with XWiki/2.0 ???
On Tue, Jun 2, 2009 at 9:01 AM, Vincent Massol vinc...@massol.net wrote:
Hi Pascal,
See http://jira.xwiki.org/jira/browse/XWIKI-3413
Thanks
-Vincent
Ok I see!
And has anyone tried to hook the text renderer or at least chosen the URL?
:)
(?xpage=text)
(?xpage=plaintext)
or simply replace (?xpage=plain)
Pascal
On Jun 2, 2009, at 12:37 AM, Pascal Voitot wrote:
Hello,
I try to create a page in XWiki/2.0 generating some JSON data but I
have
some problems and I have to go back to XWiki/1.0...
* when you write this in a page MySpace.MyPage:
[
{ field : value }
]
you call MySpace.MyPage?xpage=plain and you get some HTML code:
pbr/.{nbsp;fieldnbsp:nbspvalue...br//p
this is not good for the JSON parser...
* So I try using the verbatim {{{}}}
{{{
[
{ field : value }
]
}}}
and I call again MySpace.MyPage?xpage=plain and I get:
pre
[
{ field : value }
]
/pre
Ok for the JSON data but the pre/pre is not good also for JSON
parser...
* If I write some velocity inside:
{{velocity}}
#doit()
[
{ field : ${value} }
]
{{/velocity}
I get some !-- velocity-macros -- comments or something like that
before
my json encoded into HTML...
not good for the JSON parser also...
What's the solution in XWiki/2.0 to make a page generate JSON?
For the time being, I use XWiki/1.0 but this is not a viable solution.
thanks
Pascal
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] JSON with XWiki/2.0 ???
On Tue, Jun 2, 2009 at 9:23 AM, Vincent Massol vinc...@massol.net wrote:
On Jun 2, 2009, at 9:12 AM, Pascal Voitot wrote:
On Tue, Jun 2, 2009 at 9:01 AM, Vincent Massol vinc...@massol.net
wrote:
Hi Pascal,
See http://jira.xwiki.org/jira/browse/XWIKI-3413
Thanks
-Vincent
Ok I see!
And has anyone tried to hook the text renderer or at least chosen
the URL?
:)
(?xpage=text)
(?xpage=plaintext)
or simply replace (?xpage=plain)
see http://markmail.org/thread/bao6nn5qgmo7w45j
It is quite strange to speak with someone quoting Jira :)
Ok Mr. Jira and do you confirm that nobody coded this part which routes the
renderer to the plain text renderer when syntax is 2.0?
-Vincent
On Jun 2, 2009, at 12:37 AM, Pascal Voitot wrote:
Hello,
I try to create a page in XWiki/2.0 generating some JSON data but I
have
some problems and I have to go back to XWiki/1.0...
* when you write this in a page MySpace.MyPage:
[
{ field : value }
]
you call MySpace.MyPage?xpage=plain and you get some HTML code:
pbr/.{nbsp;fieldnbsp:nbspvalue...br//p
this is not good for the JSON parser...
* So I try using the verbatim {{{}}}
{{{
[
{ field : value }
]
}}}
and I call again MySpace.MyPage?xpage=plain and I get:
pre
[
{ field : value }
]
/pre
Ok for the JSON data but the pre/pre is not good also for JSON
parser...
* If I write some velocity inside:
{{velocity}}
#doit()
[
{ field : ${value} }
]
{{/velocity}
I get some !-- velocity-macros -- comments or something like that
before
my json encoded into HTML...
not good for the JSON parser also...
What's the solution in XWiki/2.0 to make a page generate JSON?
For the time being, I use XWiki/1.0 but this is not a viable
solution.
thanks
Pascal
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] JSON with XWiki/2.0 ???
On Tue, Jun 2, 2009 at 10:43 AM, Vincent Massol vinc...@massol.net wrote:
On Jun 2, 2009, at 10:21 AM, Pascal Voitot wrote:
On Tue, Jun 2, 2009 at 9:23 AM, Vincent Massol vinc...@massol.net
wrote:
On Jun 2, 2009, at 9:12 AM, Pascal Voitot wrote:
On Tue, Jun 2, 2009 at 9:01 AM, Vincent Massol vinc...@massol.net
wrote:
Hi Pascal,
See http://jira.xwiki.org/jira/browse/XWIKI-3413
Thanks
-Vincent
Ok I see!
And has anyone tried to hook the text renderer or at least chosen
the URL?
:)
(?xpage=text)
(?xpage=plaintext)
or simply replace (?xpage=plain)
see http://markmail.org/thread/bao6nn5qgmo7w45j
It is quite strange to speak with someone quoting Jira :)
That was a mail thread, not jira. I'm sorry but I don't have the time
to copy paste all past discussions just for your pleasure or not
having to read an email thread... ;)
Really sorry about that but I'm also in a hurry looking at several things at
the same time and I just thought I was still in JIRA without looking at the
mail thread behind...For my (p)leasure, I will read it because it seems to
answer my question...
Ok Mr. Jira and do you confirm that nobody coded this part which
routes the
renderer to the plain text renderer when syntax is 2.0?
Hmm... why don't you look at the jira issue? There's a field named
status which shows if the issue has been implemented or not...
Hint: it says open. So yes it's not been done...
I can see that but this status doesn't mean that anybody has never tried to
code it...
but you're a bad guy making me a fool like that because you've just modified
the JIRA in the meantime to add the mail thread in case anybody thought I
was not silly enough :):):):)
Thanks
-Vincent
On Jun 2, 2009, at 12:37 AM, Pascal Voitot wrote:
Hello,
I try to create a page in XWiki/2.0 generating some JSON data
but I
have
some problems and I have to go back to XWiki/1.0...
* when you write this in a page MySpace.MyPage:
[
{ field : value }
]
you call MySpace.MyPage?xpage=plain and you get some HTML code:
pbr/.{nbsp;fieldnbsp:nbspvalue...br//p
this is not good for the JSON parser...
* So I try using the verbatim {{{}}}
{{{
[
{ field : value }
]
}}}
and I call again MySpace.MyPage?xpage=plain and I get:
pre
[
{ field : value }
]
/pre
Ok for the JSON data but the pre/pre is not good also for JSON
parser...
* If I write some velocity inside:
{{velocity}}
#doit()
[
{ field : ${value} }
]
{{/velocity}
I get some !-- velocity-macros -- comments or something like
that
before
my json encoded into HTML...
not good for the JSON parser also...
What's the solution in XWiki/2.0 to make a page generate JSON?
For the time being, I use XWiki/1.0 but this is not a viable
solution.
thanks
Pascal
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] Dropping support of Plexus (temporarily)?
On Mon, Jun 1, 2009 at 10:29 AM, Vincent Massol vinc...@massol.net wrote: Hi, I'm having 2 problems with Plexus: 1) I tried to upgrade and it's not working. They've dropped the ability to dynamically register a new component instance for an existing role. Jason Van Zyl said he's ok to fix it but he's busy on other stuff and it's been now 2 weeks since he said he'll fix it. Generally speaking there are not many people working on Plexus core so it's not moving much. 2) I tried using events (it was there in alpha-31 but seem to have disappeared in recent versions - I may be wrong. However since there's zero documentation I had to try to find it in the code and couldn't find it) and couldn't. Even in alpha-31 it doesn't work (it works only for components located in components.xml but since we're dynamically registering components it doesn't work for us. Thus I'm more and more tempted to drop support for Plexus and instead use our Embedded component manager for now and start a xwiki-osgi module that would implement our SPI for OSGi. I've read OSGi documentation and it looks not too difficult to do. I didn't follow the embedded component manager... apparently it manages component descriptions with annotations? I began working with OSGI (not much yet because I'm too busy on other stuff)... what do you mean by implementing our SPI for OSGI? I have all the code done for sending Component Manager events but it won't work with Plexus so I'm proposing to use our Embedded CM for now. In the meantime I'll try to talk to Jason to see what can be done on the plexus side. WDYT? Note that our Embedded CM hasn't been tested for multithreading so we'll need to verify it works in the 2.0 dev cycle and fix any threading issue. Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] Dropping support of Plexus (temporarily)?
On Mon, Jun 1, 2009 at 11:05 AM, Sergiu Dumitriu ser...@xwiki.com wrote: Vincent Massol wrote: Hi, I'm having 2 problems with Plexus: 1) I tried to upgrade and it's not working. They've dropped the ability to dynamically register a new component instance for an existing role. Jason Van Zyl said he's ok to fix it but he's busy on other stuff and it's been now 2 weeks since he said he'll fix it. Generally speaking there are not many people working on Plexus core so it's not moving much. 2) I tried using events (it was there in alpha-31 but seem to have disappeared in recent versions - I may be wrong. However since there's zero documentation I had to try to find it in the code and couldn't find it) and couldn't. Even in alpha-31 it doesn't work (it works only for components located in components.xml but since we're dynamically registering components it doesn't work for us. Thus I'm more and more tempted to drop support for Plexus and instead use our Embedded component manager for now and start a xwiki-osgi module that would implement our SPI for OSGi. I've read OSGi documentation and it looks not too difficult to do. I have all the code done for sending Component Manager events but it won't work with Plexus so I'm proposing to use our Embedded CM for now. In the meantime I'll try to talk to Jason to see what can be done on the plexus side. WDYT? Note that our Embedded CM hasn't been tested for multithreading so we'll need to verify it works in the 2.0 dev cycle and fix any threading issue. We can also take a look at Guice. I don't know what the switch implies, but since we're in the early stages of 2.0, we can try it on the trunk. I had some reading about guice and it seems quite powerful and well designed and much lighter and focused on DI than Spring and maybe a bit more modern and alive than plexus even if plexus did it right... there is also an out-of-the-box OSGI integration extension http://code.google.com/p/peaberry/ -- Sergiu Dumitriu http://purl.org/net/sergiu/ ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] JSON with XWiki/2.0 ???
Hello,
I try to create a page in XWiki/2.0 generating some JSON data but I have
some problems and I have to go back to XWiki/1.0...
* when you write this in a page MySpace.MyPage:
[
{ field : value }
]
you call MySpace.MyPage?xpage=plain and you get some HTML code:
pbr/.{nbsp;fieldnbsp:nbspvalue...br//p
this is not good for the JSON parser...
* So I try using the verbatim {{{}}}
{{{
[
{ field : value }
]
}}}
and I call again MySpace.MyPage?xpage=plain and I get:
pre
[
{ field : value }
]
/pre
Ok for the JSON data but the pre/pre is not good also for JSON parser...
* If I write some velocity inside:
{{velocity}}
#doit()
[
{ field : ${value} }
]
{{/velocity}
I get some !-- velocity-macros -- comments or something like that before
my json encoded into HTML...
not good for the JSON parser also...
What's the solution in XWiki/2.0 to make a page generate JSON?
For the time being, I use XWiki/1.0 but this is not a viable solution.
thanks
Pascal
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] xwiki 1.9-rc1 issues
Hello,
I have recompiled a XWiki 1.9-RC1 for jetty+derby and I have some little
problems and I prefer asking before thinking:
- I don't see the icons in the administration page and the last item
OpenOffice Importer seems badly HTML formed and displays
http://www.mandubian.org/xwiki/bin/download/XWiki/OfficeImporterAdmin/icon.png)
no-repeat;OpenOffice Server
Please see the attached screenshot
- I can't view Blog.WebHome because there is some bad SQL for Derby
apparently
Caused by: com.xpn.xwiki.XWikiException: Error number 3223 in 3: Exception
while searching documents with SQL [select distinct doc.space, doc.name,
publishDate.value from XWikiDocument as doc , DBStringListProperty as
categories join categories.list as category, BaseObject obj, IntegerProperty
isPublished, IntegerProperty hidden, DateProperty publishDate
where (doc.hidden true or doc.hidden is null) and doc.fullName
'Blog.BlogPostTemplate' and
obj.name = doc.fullName and obj.className = 'Blog.BlogPostClass' and
publishDate.id.id = obj.id and publishDate.id.name = 'publishDate' and
isPublished.id.id = obj.id and isPublished.id.name = 'published' and
hidden.id.id = obj.id and hidden.id.name = 'hidden' and
(doc.creator = 'XWiki.Admin' or (isPublished.value = 1 and
hidden.value = 0)) and obj.id = categories.id.id and
categories.id.name='category'
and category in ('Blog.News') order by publishDate.value desc]
Wrapped Exception: could not execute query
at
com.xpn.xwiki.store.XWikiHibernateStore.searchDocumentsNamesInternal(XWikiHibernateStore.java:2302)
at
com.xpn.xwiki.store.XWikiHibernateStore.searchDocumentsNames(XWikiHibernateStore.java:2266)
at
com.xpn.xwiki.store.XWikiHibernateStore.searchDocumentsNames(XWikiHibernateStore.java:2747)
at
com.xpn.xwiki.store.XWikiCacheStore.searchDocumentsNames(XWikiCacheStore.java:267)
at com.xpn.xwiki.api.XWiki.searchDocuments(XWiki.java:406)
at sun.reflect.GeneratedMethodAccessor325.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:389)
at
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:378)
at
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:270)
... 154 more
2009-05-29 12:01:25,585 [http://localhost:8080/xwiki/bin/view/Blog/]
[1857040...@qtp0-6] WARN util.JDBCExceptionReporter - SQL Error:
2, SQLState: XJ061
2009-05-29 12:01:25,585 [http://localhost:8080/xwiki/bin/view/Blog/]
[1857040...@qtp0-6] ERROR util.JDBCExceptionReporter - The 'absolute()'
method is only allowed on scroll cursors. [ERROR] Exception in macro
#getPagedBlogEntries at Blog.WebHome[line 141, column 5]
[ERROR] Exception in macro #getBlogEntries at Blog.WebHome[line 17, column
3]
[ERROR] Exception in macro #printBlog at Blog.WebHome[line 7, column 3]
org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with
id [Blog.WebHome]
any idea?
Pascal
attachment: xwiki_screenshot.jpg___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki 1.9-RC1: XWiki2.0 syntax by default breaks the creation of XWikiClass
In fact, this is a problem for all the class scripts because the scripts
include other scripts from other page which are also in XWiki/1.0...
This is quite a problem these inclusion issues between XWiki/2.0 and
XWiki/1.0...
Have you thought about that?
Pascal
On Fri, May 29, 2009 at 2:25 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
The XWikiClassTemplate velocity script is in a XWiki/1.0 syntax doc:
## replace Main with the Space where you want your documents to be created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class = $doc.name.substring(0,$doc.name.indexOf(Class)))
#set($defaultparent = kmbase.${class}Class)
#set($defaultweb = kmbase)
#includeForm(XWiki.ClassSheet)
but now when you create a class, it is XWiki/2.0 and should be:
{{velocity}}
{{html wiki=true}}
## replace Main with the Space where you want your documents to be created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class = $doc.name.substring(0,$doc.name.indexOf(Class)))
#set($defaultparent = kmbase.${class}Class)
#set($defaultweb = kmbase)
#includeForm(XWiki.ClassSheet)
{{/html}}
{{/velocity}}
What's the best solution to your mind in order to have something working in
all the cases?
Pascal
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki 1.9-RC1: XWiki2.0 syntax by default breaks the creation of XWikiClass
On Fri, May 29, 2009 at 2:34 PM, Guillaume Lerouge guilla...@xwiki.comwrote:
Hi Pascal,
On Fri, May 29, 2009 at 2:25 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
The XWikiClassTemplate velocity script is in a XWiki/1.0 syntax doc:
## replace Main with the Space where you want your documents to be
created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class = $doc.name.substring(0,$doc.name.indexOf(Class)))
#set($defaultparent = kmbase.${class}Class)
#set($defaultweb = kmbase)
#includeForm(XWiki.ClassSheet)
but now when you create a class, it is XWiki/2.0 and should be:
{{velocity}}
{{html wiki=true}}
## replace Main with the Space where you want your documents to be
created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class = $doc.name.substring(0,$doc.name.indexOf(Class)))
#set($defaultparent = kmbase.${class}Class)
#set($defaultweb = kmbase)
#includeForm(XWiki.ClassSheet)
{{/html}}
{{/velocity}}
What's the best solution to your mind in order to have something working
in
all the cases?
Well, since now all new documents will be created in syntax 2.0, we could
convert the XWiki.XWikiClassTemplate page and make it 2.0 by default in
the
wiki. Not sure whether this would break existing classes but I don't think
so...
the scripts in XWiki/1.0 must be modified a bit to be XWiki/2.0 because they
contain a mix of velocity and html that renders bad in XWiki/2.0...
such as
a href=$doc.getURL(edit, xpage=editclass)Edit the Class/a
Guillaume
Pascal
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki 1.9-RC1: XWiki2.0 syntax by default breaks the creation of XWikiClass
On Fri, May 29, 2009 at 2:47 PM, Vincent Massol vinc...@massol.net wrote:
On May 29, 2009, at 2:42 PM, Pascal Voitot wrote:
On Fri, May 29, 2009 at 2:35 PM, Vincent Massol vinc...@massol.net
wrote:
Hi Pascal,
On May 29, 2009, at 2:25 PM, Pascal Voitot wrote:
The XWikiClassTemplate velocity script is in a XWiki/1.0 syntax doc:
## replace Main with the Space where you want your documents to be
created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class = $doc.name.substring(0,$doc.name.indexOf(Class)))
#set($defaultparent = kmbase.${class}Class)
#set($defaultweb = kmbase)
#includeForm(XWiki.ClassSheet)
but now when you create a class, it is XWiki/2.0 and should be:
{{velocity}}
{{html wiki=true}}
## replace Main with the Space where you want your documents to be
created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class = $doc.name.substring(0,$doc.name.indexOf(Class)))
#set($defaultparent = kmbase.${class}Class)
#set($defaultweb = kmbase)
#includeForm(XWiki.ClassSheet)
{{/html}}
{{/velocity}}
What's the best solution to your mind in order to have something
working in
all the cases?
The created page will use the syntax of the template page thus it
should work in all cases.
not sure to understand...
Do you mean if the template is 1.0, the created page should be 1.0
also?
yes
Apparently, this is not the case yet, isn't it?
It's supposed to be (I coded it ;)).
The code is in XWikiDocument.readFromTemplate():
// Set the new document syntax as the syntax of
the template since the template content
// is copied into the new document
setSyntaxId(templatedoc.getSyntaxId());
Apparently it's not working for you it seems. Please open a jira issue
if that's the case.
Thanks
-Vincent
I recompiled everything from scratch so I should have a good release now!
Can you test it to verify? Just create a new class from the XWikiClasses
editor and see if the doc is XWiki/1.0 or 2.0?
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki 1.9-RC1: XWiki2.0 syntax by default breaks the creation of XWikiClass
In the scripts, there are some:
form action=$xwiki.getURL(${doc.space}.${class}ClassSheet,edit)
method=post
and when you render that inside {{velocity}}{{html}}/{{/html}}{{/velocity}},
this is quite a problem because it render the $xwiki.getUrl and then treats
it as wiki syntax and surrounds it with span...
and you can't remove the wiki=true because in other part of the scripts,
there is real wiki syntax...
What can we do to go around this?
On Fri, May 29, 2009 at 2:51 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Fri, May 29, 2009 at 2:47 PM, Vincent Massol vinc...@massol.netwrote:
On May 29, 2009, at 2:42 PM, Pascal Voitot wrote:
On Fri, May 29, 2009 at 2:35 PM, Vincent Massol vinc...@massol.net
wrote:
Hi Pascal,
On May 29, 2009, at 2:25 PM, Pascal Voitot wrote:
The XWikiClassTemplate velocity script is in a XWiki/1.0 syntax doc:
## replace Main with the Space where you want your documents to be
created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class = $doc.name.substring(0,$doc.name.indexOf(Class)))
#set($defaultparent = kmbase.${class}Class)
#set($defaultweb = kmbase)
#includeForm(XWiki.ClassSheet)
but now when you create a class, it is XWiki/2.0 and should be:
{{velocity}}
{{html wiki=true}}
## replace Main with the Space where you want your documents to be
created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class = $doc.name.substring(0,$doc.name.indexOf(Class)))
#set($defaultparent = kmbase.${class}Class)
#set($defaultweb = kmbase)
#includeForm(XWiki.ClassSheet)
{{/html}}
{{/velocity}}
What's the best solution to your mind in order to have something
working in
all the cases?
The created page will use the syntax of the template page thus it
should work in all cases.
not sure to understand...
Do you mean if the template is 1.0, the created page should be 1.0
also?
yes
Apparently, this is not the case yet, isn't it?
It's supposed to be (I coded it ;)).
The code is in XWikiDocument.readFromTemplate():
// Set the new document syntax as the syntax of
the template since the template content
// is copied into the new document
setSyntaxId(templatedoc.getSyntaxId());
Apparently it's not working for you it seems. Please open a jira issue
if that's the case.
Thanks
-Vincent
I recompiled everything from scratch so I should have a good release now!
Can you test it to verify? Just create a new class from the XWikiClasses
editor and see if the doc is XWiki/1.0 or 2.0?
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki 1.9-RC1: XWiki2.0 syntax by default breaks the creation of XWikiClass
On Fri, May 29, 2009 at 3:19 PM, Vincent Massol vinc...@massol.net wrote:
On May 29, 2009, at 3:03 PM, Pascal Voitot wrote:
In the scripts, there are some:
form action=$xwiki.getURL(${doc.space}.${class}ClassSheet,edit)
method=post
and when you render that inside {{velocity}}{{html}}/{{/html}}{{/
velocity}},
this is quite a problem because it render the $xwiki.getUrl and then
treats
it as wiki syntax and surrounds it with span...
This looks like a bug of the HTML macro. Can you create a jira issue?
I will
and you can't remove the wiki=true because in other part of the
scripts,
there is real wiki syntax...
Actually you can by using clean=false and break it into several html
macros.
what does it do exactly as it's not explained in the macro doc ?
Thanks
-Vincent
What can we do to go around this?
On Fri, May 29, 2009 at 2:51 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Fri, May 29, 2009 at 2:47 PM, Vincent Massol
vinc...@massol.netwrote:
On May 29, 2009, at 2:42 PM, Pascal Voitot wrote:
On Fri, May 29, 2009 at 2:35 PM, Vincent Massol
vinc...@massol.net
wrote:
Hi Pascal,
On May 29, 2009, at 2:25 PM, Pascal Voitot wrote:
The XWikiClassTemplate velocity script is in a XWiki/1.0 syntax
doc:
## replace Main with the Space where you want your documents to
be
created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class = $doc.name.substring(0,$doc.name.indexOf(Class)))
#set($defaultparent = kmbase.${class}Class)
#set($defaultweb = kmbase)
#includeForm(XWiki.ClassSheet)
but now when you create a class, it is XWiki/2.0 and should be:
{{velocity}}
{{html wiki=true}}
## replace Main with the Space where you want your documents to
be
created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class = $doc.name.substring(0,$doc.name.indexOf(Class)))
#set($defaultparent = kmbase.${class}Class)
#set($defaultweb = kmbase)
#includeForm(XWiki.ClassSheet)
{{/html}}
{{/velocity}}
What's the best solution to your mind in order to have something
working in
all the cases?
The created page will use the syntax of the template page thus it
should work in all cases.
not sure to understand...
Do you mean if the template is 1.0, the created page should be 1.0
also?
yes
Apparently, this is not the case yet, isn't it?
It's supposed to be (I coded it ;)).
The code is in XWikiDocument.readFromTemplate():
// Set the new document syntax as the syntax of
the template since the template content
// is copied into the new document
setSyntaxId(templatedoc.getSyntaxId());
Apparently it's not working for you it seems. Please open a jira
issue
if that's the case.
Thanks
-Vincent
I recompiled everything from scratch so I should have a good
release now!
Can you test it to verify? Just create a new class from the
XWikiClasses
editor and see if the doc is XWiki/1.0 or 2.0?
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki 1.9-RC1: XWiki2.0 syntax by default breaks the creation of XWikiClass
On Fri, May 29, 2009 at 3:19 PM, Vincent Massol vinc...@massol.net wrote:
On May 29, 2009, at 3:03 PM, Pascal Voitot wrote:
In the scripts, there are some:
form action=$xwiki.getURL(${doc.space}.${class}ClassSheet,edit)
method=post
and when you render that inside {{velocity}}{{html}}/{{/html}}{{/
velocity}},
this is quite a problem because it render the $xwiki.getUrl and then
treats
it as wiki syntax and surrounds it with span...
This looks like a bug of the HTML macro. Can you create a jira issue?
in fact I wonder if this is the normal behavior
if you write
{{velocity}}
{{html wiki=true}}
form action=$xwiki.getURL(${doc.space}.${class}ClassTemplate,edit)
method=post
/form
{{/html}}
{{/velocity}}
isn't it normal that it renders ?
form action=span class=wikiexternallink
a class=wikimodel-freestanding href=
http://www.mandubian.org/xwiki/bin/edit/myspace/%24%7Bclass%7DClassTemplate;
span class=wikigeneratedlinkcontent
http://www.mandubian.org/xwiki/bin/edit/myspace/%24%7Bclass%7DClassTemplate
/span
/a
/span
method=post
in order not to treat the URL as wiki, it should be set to wiki=false...
Pascal
and you can't remove the wiki=true because in other part of the
scripts,
there is real wiki syntax...
Actually you can by using clean=false and break it into several html
macros.
Thanks
-Vincent
What can we do to go around this?
On Fri, May 29, 2009 at 2:51 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Fri, May 29, 2009 at 2:47 PM, Vincent Massol
vinc...@massol.netwrote:
On May 29, 2009, at 2:42 PM, Pascal Voitot wrote:
On Fri, May 29, 2009 at 2:35 PM, Vincent Massol
vinc...@massol.net
wrote:
Hi Pascal,
On May 29, 2009, at 2:25 PM, Pascal Voitot wrote:
The XWikiClassTemplate velocity script is in a XWiki/1.0 syntax
doc:
## replace Main with the Space where you want your documents to
be
created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class = $doc.name.substring(0,$doc.name.indexOf(Class)))
#set($defaultparent = kmbase.${class}Class)
#set($defaultweb = kmbase)
#includeForm(XWiki.ClassSheet)
but now when you create a class, it is XWiki/2.0 and should be:
{{velocity}}
{{html wiki=true}}
## replace Main with the Space where you want your documents to
be
created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class = $doc.name.substring(0,$doc.name.indexOf(Class)))
#set($defaultparent = kmbase.${class}Class)
#set($defaultweb = kmbase)
#includeForm(XWiki.ClassSheet)
{{/html}}
{{/velocity}}
What's the best solution to your mind in order to have something
working in
all the cases?
The created page will use the syntax of the template page thus it
should work in all cases.
not sure to understand...
Do you mean if the template is 1.0, the created page should be 1.0
also?
yes
Apparently, this is not the case yet, isn't it?
It's supposed to be (I coded it ;)).
The code is in XWikiDocument.readFromTemplate():
// Set the new document syntax as the syntax of
the template since the template content
// is copied into the new document
setSyntaxId(templatedoc.getSyntaxId());
Apparently it's not working for you it seems. Please open a jira
issue
if that's the case.
Thanks
-Vincent
I recompiled everything from scratch so I should have a good
release now!
Can you test it to verify? Just create a new class from the
XWikiClasses
editor and see if the doc is XWiki/1.0 or 2.0?
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] XWiki 1.9-RC1: XWiki2.0 syntax by default breaks the creation of XWikiClass
On Fri, May 29, 2009 at 3:43 PM, Vincent Massol vinc...@massol.net wrote:
On May 29, 2009, at 3:34 PM, Pascal Voitot wrote:
On Fri, May 29, 2009 at 3:19 PM, Vincent Massol vinc...@massol.net
wrote:
On May 29, 2009, at 3:03 PM, Pascal Voitot wrote:
In the scripts, there are some:
form action=$xwiki.getURL(${doc.space}.$
{class}ClassSheet,edit)
method=post
and when you render that inside {{velocity}}{{html}}/{{/html}}{{/
velocity}},
this is quite a problem because it render the $xwiki.getUrl and then
treats
it as wiki syntax and surrounds it with span...
This looks like a bug of the HTML macro. Can you create a jira issue?
in fact I wonder if this is the normal behavior
if you write
{{velocity}}
{{html wiki=true}}
form action=$xwiki.getURL(${doc.space}.$
{class}ClassTemplate,edit)
method=post
/form
{{/html}}
{{/velocity}}
isn't it normal that it renders ?
form action=span class=wikiexternallink
a class=wikimodel-freestanding href=
http://www.mandubian.org/xwiki/bin/edit/myspace/%24%7Bclass%7DClassTemplate
span class=wikigeneratedlinkcontent
http://www.mandubian.org/xwiki/bin/edit/myspace/%24%7Bclass%7DClassTemplate
/span
/a
/span
method=post
Yes this is normal. Since you've specified wiki=true it treats
content as wiki content and thus sees the external link.
Now what we could maybe do is decide that inline references should not
be used inside the html macro since there's no wiki special symbol to
indicate it's a link.
There are alternatives:
- several html macros with wiki=false
- use {{html wiki=true}}{{velocity}} maybe
I'll let thomas answer since I haven't thought much about it (I'm on
something else right now).
I see...
I'm beginning to use xwiki/2.0 intensively and I'm trying to make it clear
in my head when using velocity and html macro... Let me tell this is not so
easy and trivial... when you mix wiki/velocity/html, it becomes quite
tricky... I will tell with the experience if I can do everything I need but
sometimes I spend some minutes trying several solutions to obtain what I
want...
Thanks
-Vincent
in order not to treat the URL as wiki, it should be set to
wiki=false...
Pascal
and you can't remove the wiki=true because in other part of the
scripts,
there is real wiki syntax...
Actually you can by using clean=false and break it into several html
macros.
Thanks
-Vincent
What can we do to go around this?
On Fri, May 29, 2009 at 2:51 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Fri, May 29, 2009 at 2:47 PM, Vincent Massol
vinc...@massol.netwrote:
On May 29, 2009, at 2:42 PM, Pascal Voitot wrote:
On Fri, May 29, 2009 at 2:35 PM, Vincent Massol
vinc...@massol.net
wrote:
Hi Pascal,
On May 29, 2009, at 2:25 PM, Pascal Voitot wrote:
The XWikiClassTemplate velocity script is in a XWiki/1.0 syntax
doc:
## replace Main with the Space where you want your documents to
be
created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class =
$doc.name.substring(0,$doc.name.indexOf(Class)))
#set($defaultparent = kmbase.${class}Class)
#set($defaultweb = kmbase)
#includeForm(XWiki.ClassSheet)
but now when you create a class, it is XWiki/2.0 and should be:
{{velocity}}
{{html wiki=true}}
## replace Main with the Space where you want your documents to
be
created
## replace the default parent with the one of your choice
## Save this template using the 'Save' button
#set( $class =
$doc.name.substring(0,$doc.name.indexOf(Class)))
#set($defaultparent = kmbase.${class}Class)
#set($defaultweb = kmbase)
#includeForm(XWiki.ClassSheet)
{{/html}}
{{/velocity}}
What's the best solution to your mind in order to have
something
working in
all the cases?
The created page will use the syntax of the template page thus
it
should work in all cases.
not sure to understand...
Do you mean if the template is 1.0, the created page should be
1.0
also?
yes
Apparently, this is not the case yet, isn't it?
It's supposed to be (I coded it ;)).
The code is in XWikiDocument.readFromTemplate():
// Set the new document syntax as the syntax of
the template since the template content
// is copied into the new document
setSyntaxId(templatedoc.getSyntaxId());
Apparently it's not working for you it seems. Please open a jira
issue
if that's the case.
Thanks
-Vincent
I recompiled everything from scratch so I should have a good
release now!
Can you test it to verify? Just create a new class from the
XWikiClasses
editor and see if the doc is XWiki/1.0 or 2.0?
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] A GWT space/page XWiki Selection tool
Hello all, I have developped a little XWiki selection tool because I needed it for own purpose. It provides a way to hook the xwikiexplorer provided within the Wysiwyg editor to an existing form and when you select a space and page, the result is put into the form. This is a standalone gwt client module with no server part based mainly on the wysiwyg code. It doesn't require the wysiwyg to compile (lots of code comes directly from wysiwyg but not all the code from wysiwyg was needed) It can be deployed outside XWiki and uses an existing XWiki instance in the same domain. It also provides a way to login/logout to the existing XWiki instance. I wondered whether it would be of any interest to someone... The idea is described here in details and there is a demo site it also... http://www.mandubian.org/magnoliaPublic/mandubian-org/opensource-playground/xwiki-selector.html Don't hesitate to comment... this is a draft... regards Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] A GWT space/page XWiki Selection tool
On Wed, May 27, 2009 at 5:32 PM, Guillaume Lerouge guilla...@xwiki.comwrote: Hi Pascal, On Wed, May 27, 2009 at 4:50 PM, Pascal Voitot pascal.voitot@gmail.comwrote: Hello all, I have developped a little XWiki selection tool because I needed it for own purpose. It provides a way to hook the xwikiexplorer provided within the Wysiwyg editor to an existing form and when you select a space and page, the result is put into the form. This is a standalone gwt client module with no server part based mainly on the wysiwyg code. It doesn't require the wysiwyg to compile (lots of code comes directly from wysiwyg but not all the code from wysiwyg was needed) It can be deployed outside XWiki and uses an existing XWiki instance in the same domain. It also provides a way to login/logout to the existing XWiki instance. I wondered whether it would be of any interest to someone... The idea is described here in details and there is a demo site it also... http://www.mandubian.org/magnoliaPublic/mandubian-org/opensource-playground/xwiki-selector.html Don't hesitate to comment... this is a draft... It's obviously still a bit rough but it looks great :-) There's a lot of potential behind the idea / concept and we should start working on making it easier to embed WYSIWYG component outside of XWiki. DID YOU SAY IT SOMEWHERE ELSE? ;) The fact that the modal box is centered on the page looks a bit weird since the select is at the top left of the page but it's a pretty minor issue... not my fault :) This is the wysiwyg code which centers it ;);););) (if you look at the project code, I have copied not all but lots of wysiwyg classes... a bit nasty but it works well enough to demonstrate) Anyway, where would you like to see it? around the select ? I did everything I could not to redevelop anything... I spent some time understanding the wysiwyg and overriding only bare necessities. I think the wizard could also be externalized from the wysiwyg and generalized... It is quite useful to create some gwt tools. We could use such a selector for selecting the page where to import a given document in the XWiki Office Importer for instance. Actually it could be used in the Create page panel too... Did I say this concept had a great potential already? ;-) yes you did :) For example, I use the selector in my magnolia+Xwiki module to add a new XWiki paragraph in my magnolia website... I can also create a Xwiki page from the selector... I can build one magnolia page from several xwiki page etc... As I didn't want to access the full XWiki interface just to edit a paragraph, I also created a lightweight skin with just the wysiwyg/wiki editor+syntax choice but no object/class/attachment/comment/... I can integrate it into a Magnolia dialog... quite practical also... I will explain that on my website when I have some time... Nice work, Guillaume regards Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/ ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
[xwiki-devs] parameters for embedded docs don't work...
Hello again, I write something like: (% style=somestyle %) ((( my embedded wikipage ))) the style is not applied to the div surrounding the embedded wikipage. Is it normal or is it a bug? Pascal ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] parameters for embedded docs don't work...
On Wed, May 27, 2009 at 6:16 PM, Vincent Massol vinc...@massol.net wrote: On May 27, 2009, at 6:13 PM, Pascal Voitot wrote: Hello again, I write something like: (% style=somestyle %) ((( my embedded wikipage ))) the style is not applied to the div surrounding the embedded wikipage. Is it normal or is it a bug? It should work AFAIK. What version of core? this is my strange 1.9-snapshot... I'm going to use 1.9 RC1 asap but I need to recompile it with derby and I'm lazy :) and does * (% style=mystyle %)((( embedded content ))) works? Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] parameters for embedded docs don't work...
On Wed, May 27, 2009 at 6:29 PM, Guillaume Lerouge guilla...@xwiki.comwrote: Hi, On Wed, May 27, 2009 at 6:21 PM, Pascal Voitot pascal.voitot@gmail.comwrote: On Wed, May 27, 2009 at 6:16 PM, Vincent Massol vinc...@massol.net wrote: On May 27, 2009, at 6:13 PM, Pascal Voitot wrote: Hello again, I write something like: (% style=somestyle %) ((( my embedded wikipage ))) the style is not applied to the div surrounding the embedded wikipage. Is it normal or is it a bug? It should work AFAIK. What version of core? this is my strange 1.9-snapshot... I'm going to use 1.9 RC1 asap but I need to recompile it with derby and I'm lazy :) and does * (% style=mystyle %)((( embedded content ))) works? Nope, it doesn't seem to work. This is my precise case in fact... so is it a bug? Guillaume Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/ ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] parameters for embedded docs don't work...
On Wed, May 27, 2009 at 6:37 PM, Guillaume Lerouge guilla...@xwiki.comwrote:
Hi,
On Wed, May 27, 2009 at 6:34 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Wed, May 27, 2009 at 6:29 PM, Guillaume Lerouge guilla...@xwiki.com
wrote:
Hi,
On Wed, May 27, 2009 at 6:21 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Wed, May 27, 2009 at 6:16 PM, Vincent Massol vinc...@massol.net
wrote:
On May 27, 2009, at 6:13 PM, Pascal Voitot wrote:
Hello again,
I write something like:
(% style=somestyle %)
(((
my embedded wikipage
)))
the style is not applied to the div surrounding the embedded
wikipage.
Is it normal or is it a bug?
It should work AFAIK. What version of core?
this is my strange 1.9-snapshot...
I'm going to use 1.9 RC1 asap but I need to recompile it with derby
and
I'm
lazy :)
and does
* (% style=mystyle %)(((
embedded content
)))
works?
Nope, it doesn't seem to work.
This is my precise case in fact... so is it a bug?
Well,
(% style=color: green; %)
* ((({{include document=Main.Papillon /}})))
works
- couldn't you use that instead?
yes I could but this is not really what I would like :)
Guillaume
Guillaume
Thanks
-Vincent
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] parameters for embedded docs don't work...
In fact, I want something like
* (% style=mystyle %)(((
blablblabla
|=bliblibli
|=blublublu
)))
and everything is aligned on the bullet's column even the table...
On Wed, May 27, 2009 at 6:41 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Wed, May 27, 2009 at 6:37 PM, Guillaume Lerouge guilla...@xwiki.comwrote:
Hi,
On Wed, May 27, 2009 at 6:34 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Wed, May 27, 2009 at 6:29 PM, Guillaume Lerouge guilla...@xwiki.com
wrote:
Hi,
On Wed, May 27, 2009 at 6:21 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Wed, May 27, 2009 at 6:16 PM, Vincent Massol vinc...@massol.net
wrote:
On May 27, 2009, at 6:13 PM, Pascal Voitot wrote:
Hello again,
I write something like:
(% style=somestyle %)
(((
my embedded wikipage
)))
the style is not applied to the div surrounding the embedded
wikipage.
Is it normal or is it a bug?
It should work AFAIK. What version of core?
this is my strange 1.9-snapshot...
I'm going to use 1.9 RC1 asap but I need to recompile it with derby
and
I'm
lazy :)
and does
* (% style=mystyle %)(((
embedded content
)))
works?
Nope, it doesn't seem to work.
This is my precise case in fact... so is it a bug?
Well,
(% style=color: green; %)
* ((({{include document=Main.Papillon /}})))
works
- couldn't you use that instead?
yes I could but this is not really what I would like :)
Guillaume
Guillaume
Thanks
-Vincent
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] parameters for embedded docs don't work...
On Wed, May 27, 2009 at 6:49 PM, Guillaume Lerouge guilla...@xwiki.comwrote:
Re,
On Wed, May 27, 2009 at 6:44 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
In fact, I want something like
* (% style=mystyle %)(((
blablblabla
|=bliblibli
|=blublublu
)))
and everything is aligned on the bullet's column even the table...
What about
(% style=color: green; %)
* (((
blablblabla
|=bliblibli
|=blublublu
)))
(%%)
* item 2
?
The problem is that I want the style to apply on the div corresponding to
the ((())) not on the ul...
so I want a list item embedding some content and apply my style on this
content...
Anyway, I can use CSS instead...
Guillaume
On Wed, May 27, 2009 at 6:41 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Wed, May 27, 2009 at 6:37 PM, Guillaume Lerouge
guilla...@xwiki.com
wrote:
Hi,
On Wed, May 27, 2009 at 6:34 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Wed, May 27, 2009 at 6:29 PM, Guillaume Lerouge
guilla...@xwiki.com
wrote:
Hi,
On Wed, May 27, 2009 at 6:21 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Wed, May 27, 2009 at 6:16 PM, Vincent Massol
vinc...@massol.net
wrote:
On May 27, 2009, at 6:13 PM, Pascal Voitot wrote:
Hello again,
I write something like:
(% style=somestyle %)
(((
my embedded wikipage
)))
the style is not applied to the div surrounding the
embedded
wikipage.
Is it normal or is it a bug?
It should work AFAIK. What version of core?
this is my strange 1.9-snapshot...
I'm going to use 1.9 RC1 asap but I need to recompile it with
derby
and
I'm
lazy :)
and does
* (% style=mystyle %)(((
embedded content
)))
works?
Nope, it doesn't seem to work.
This is my precise case in fact... so is it a bug?
Well,
(% style=color: green; %)
* ((({{include document=Main.Papillon /}})))
works
- couldn't you use that instead?
yes I could but this is not really what I would like :)
Guillaume
Guillaume
Thanks
-Vincent
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] parameters for embedded docs don't work...
On Wed, May 27, 2009 at 6:58 PM, Guillaume Lerouge guilla...@xwiki.comwrote:
Re,
On Wed, May 27, 2009 at 6:56 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Wed, May 27, 2009 at 6:49 PM, Guillaume Lerouge guilla...@xwiki.com
wrote:
Re,
On Wed, May 27, 2009 at 6:44 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
In fact, I want something like
* (% style=mystyle %)(((
blablblabla
|=bliblibli
|=blublublu
)))
and everything is aligned on the bullet's column even the table...
What about
(% style=color: green; %)
* (((
blablblabla
|=bliblibli
|=blublublu
)))
(%%)
* item 2
?
The problem is that I want the style to apply on the div corresponding
to
the ((())) not on the ul...
so I want a list item embedding some content and apply my style on this
content...
Anyway, I can use CSS instead...
*
(% style=color: green; %)(((
blablblabla
|=bliblibli
|=blublublu
)))
works ;-)
Since there's no blank line between * and (% they're considered as part of
the same paragraph.
you're right it works :)
will you put this case in the documentation ? :):):)
it reminds of my past french grammar courses... this rule works all the time
but not in this, this, this, this and this cases and in that case, it works
like that...
Guillaume
Guillaume
On Wed, May 27, 2009 at 6:41 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Wed, May 27, 2009 at 6:37 PM, Guillaume Lerouge
guilla...@xwiki.com
wrote:
Hi,
On Wed, May 27, 2009 at 6:34 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Wed, May 27, 2009 at 6:29 PM, Guillaume Lerouge
guilla...@xwiki.com
wrote:
Hi,
On Wed, May 27, 2009 at 6:21 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Wed, May 27, 2009 at 6:16 PM, Vincent Massol
vinc...@massol.net
wrote:
On May 27, 2009, at 6:13 PM, Pascal Voitot wrote:
Hello again,
I write something like:
(% style=somestyle %)
(((
my embedded wikipage
)))
the style is not applied to the div surrounding the
embedded
wikipage.
Is it normal or is it a bug?
It should work AFAIK. What version of core?
this is my strange 1.9-snapshot...
I'm going to use 1.9 RC1 asap but I need to recompile it
with
derby
and
I'm
lazy :)
and does
* (% style=mystyle %)(((
embedded content
)))
works?
Nope, it doesn't seem to work.
This is my precise case in fact... so is it a bug?
Well,
(% style=color: green; %)
* ((({{include document=Main.Papillon /}})))
works
- couldn't you use that instead?
yes I could but this is not really what I would like :)
Guillaume
Guillaume
Thanks
-Vincent
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume
Re: [xwiki-devs] Xwiki+Simile Exhibit integration // request for help w/ portability issue
I've taken a few minutes looking a bit more deeply at simile and it sounds cool! Nice idea to integrate that in XWiki :) Pascal On Wed, May 6, 2009 at 8:25 PM, Niels Mayer nielsma...@gmail.com wrote: Although I was previously able to do a hack integration with Simile's Exhibit and Xwiki, it was too heinous to actually live with. A cleaner solution, using Xwiki's skin extensions for stylesheets and javascript now works. The clean solution required hosting my own copy of Exhibit based on checking out from the trunk the latest copy of Exhibit. Hosting my own copy of Exhibit seems to be problematic, as the version of Exhibit I checked out from svn/trunk has issues such as (1) a non-working minified jquery that needed to be replaced w/ original, and (2) portability issue on IE (see below) on which I need help/advice. Here's my example of Xwiki/Exhibit integration: http://nielsmayer.com/xwiki/bin/view/Exhibit/Presidents Here's the original example from which above was derived: http://simile-widgets.org/exhibit/examples/presidents/presidents.html Xwiki Source Code: Presidents http://nielsmayer.com/xwiki/bin/view/Exhibit/Presidents?viewer=code Data used by example: PresidentsSchemaJSON http://nielsmayer.com/xwiki/bin/view/Exhibit/PresidentsSchemaJSON?xpage=plain , PresidentsJSON http://nielsmayer.com/xwiki/bin/view/Exhibit/PresidentsJSON?xpage=plain Attached, because there's no easy way to view these, the contents of XWiki.StyleSheetExtension[0] and XWiki.JavaScriptExtension[0] -- these are objects attached to the underlying Xwiki document http://nielsmayer.com/xwiki/bin/view/Exhibit/Presidents which cause the appropriate magic to happen in the header via calls to $xwiki.ssx.use($doc.fullName) and $xwiki.jsx.use($doc.fullName). It's all explained in the preamble for http://nielsmayer.com/xwiki/bin/view/Exhibit/Presidents?viewer=code : ## Note that to get this whole thing working requires jquery NOT FROM EXHIBIT SVN TRUNK ##( http://nielsmayer.com/js/exhibit/api/scripts/jquery-1.3.2.min.js ) ## Instead, preload http://nielsmayer.com/xwiki/resources/js/exhibit/api/scripts/jquery-1.3.2.min.js ## for details see http://nielsmayer.com/xwiki/resources/js/exhibit/api/scripts/jquery-1.3.2.min.js.README $xwiki.jsfx.use(js/exhibit/api/scripts/jquery-1.3.2.min.js)## ## Note that http://nielsmayer.com/xwiki/resources/js/exhibit/api/exhibit-api.jsdifferent ## to trunk http://nielsmayer.com/js/exhibit/api/exhibit-api.js $xwiki.jsfx.use(js/exhibit/api/exhibit-api.js)## ## though http://nielsmayer.com/xwiki/resources/js/Simile/Exhibit/webapp/styles.cssworksthe line below does not: ##$xwiki.ssfx.use(js/simile/Exhibit/webapp/styles.css)##same loaded from XWiki.StyleSheetExtension[0] via ssx.use. $xwiki.ssx.use($doc.fullName)## $xwiki.jsx.use($doc.fullName)## ISSUE AND REQUEST FOR HELP: In IE, after the simile busy-spinner has popped up indicating a successful load of Exhibit, the following errors happen, causing three successive dialog boxes: (1) Caught exception: ColorCoder: Error processing configuration of coder Details: 'firstChild.nodeValue' is null or not an object (2) Caught exception: undefined Details: 'firstChild.nodeValue' is null or not an object (3) IE error: Line 1831, char 52, Error: object expected Suggestions on which version of Exhibit or Simile-Ajax-API to use in order to get rid of this error would be appreciated. It is interesting to note that the trunk version of the same example http://trunk.simile-widgets.org/exhibit/examples/presidents/presidents.htmlworks fine in IE. Is this the same issue noted previously: http://www.mail-archive.com/simile-widg...@googlegroups.com/msg00385.html http://www.mail-archive.com/simile-widg...@googlegroups.com/msg00391.html http://www.mail-archive.com/simile-widg...@googlegroups.com/msg00846.html? ?? -- TODO: One last remaining hack is that I put the following in the headers link rel=exhibit/data type=application/json href=$xwiki.getURL(Exhibit.PresidentsSchemaJSON,view,xpage=plain) / link rel=exhibit/data type=application/json href=$xwiki.getURL(Exhibit.PresidentsJSON,view,xpage=plain) / via the Exhibit space's HTTP Meta Information administration setting ( http://nielsmayer.com/xwiki/bin/admin/Exhibit/WebPreferences?editor=spaceadminsection=Presentationspace=Exhibit ). I would like to figure out a way to set these values directly in javascript inside the document itself (or inside additional instances of XWiki.JavaScriptExtension) rather than having them read as external json files, e.g. http://www.mail-archive.com/gene...@simile.mit.edu/msg02434.html http://www.nabble.com/JSON-created-locally-td17507332.html http://www.patrickgmj.net/node/161 -- Niels. http://nielsmayer.com ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [VOTE] Change of behavior for the HTML macro when wiki=true
)
at
org.apache.xerces.parsers.XML11NonValidatingConfiguration.parse(Unknown
Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333)
at
org.wikimodel.wem.xhtml.filter.DefaultXMLFilter.parse(DefaultXMLFilter.java:48)
at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333)
at
org.wikimodel.wem.xhtml.filter.DefaultXMLFilter.parse(DefaultXMLFilter.java:48)
at org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333)
at
org.wikimodel.wem.xhtml.filter.DefaultXMLFilter.parse(DefaultXMLFilter.java:48)
at
org.xwiki.rendering.internal.macro.html.HTMLMacro.parseXHTML(HTMLMacro.java:212)
... 70 more
On Tue, May 5, 2009 at 5:07 PM, Pascal Voitot
pascal.voitot@gmail.comwrote:
On Tue, May 5, 2009 at 5:04 PM, Vincent Massol vinc...@massol.net wrote:
On May 5, 2009, at 5:01 PM, Pascal Voitot wrote:
I will try to compile it and deploy it on my website...
To be quicker, what module have you modified?
xwiki-xml
xwiki-rendering-api
xwiki-rendering-macro-html
You can also wait for a snapshot build at http://maven.xwiki.org
I love compiling, this is a hobby ;););)
Thanks
-Vincent
regards
Pascal
On Tue, May 5, 2009 at 4:58 PM, Vincent Massol vinc...@massol.net
wrote:
On May 5, 2009, at 4:16 PM, Pascal Voitot wrote:
no better idea...
a very special case to remind in the syntax help to my mind...
Just committed the new behavior. Would be great if some users/devs
could verify it works on their use cases.
Thanks
-Vincent
Pascal
On Tue, May 5, 2009 at 9:40 AM, Vincent Massol vinc...@massol.net
wrote:
After trying to implement it I've found the following caveats:
* if the user wants an html comment he needs to escape the --
* if the user wants a NL he'll need to enter br/
* if the user wants a paragraph he'll need to enter p.../p
* And the most problematic one IMO: the user needs to be very
careful
about new lines since:
table
tr
td
* [[listitem]]
/td
/tr
/table
is very different from
table
tr
td
* [[listitem]]
/td
/tr
/table
In the first case the /td, /tr and /table and continuation of
the list item written in wiki syntax since the wiki parser accepts
multiline content... hence you'll get in XHTML:
tabletbodytrtdulli!--startwikilink:listitem--span
class=wikicreatelinka href=/xwiki/bin/view/listitem?
parent=xwiki:Space.Pagespan
class=wikigeneratedlinkcontentPage/
span/a/span!--stopwikilink--/td/tr/tbody/table/
li/
ul
which is completely invalid.
The same applies for:
{{macro/}}
/td
vs
{{macro/}}
/td
in the first case the macro is inline and will generate inline
content
and in the second case it's standalone.
Still trying to figure out a best solution but I don't see one
right
now...
If you have any idea, shoot!
Thanks
-Vincent
On May 4, 2009, at 3:25 PM, Vincent Massol wrote:
Hi,
After discussing with Thomas we've reached the conclusion that we
should change the way the HTML macro handle its content when
wiki=true.
For ex take the following input:
{{velocity}}
...
{{html wiki=true}}
form
$xwiki.includeForm(XWiki.MyClassSheet)
br /
p
input type=submit name=submit value=Create this new
Workpackage /
/p
/form
{{/html}}
...
{{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code
which thus generate {{html}} macros.
Current Result
Right now here's what happens:
1) velocity macro is executed and $xwiki.includeForm executes
2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki=true}}
form
{{html}}...someTag.../someTag{{/html}}
/form
{{/html}}
3) After velocity has finished executing the velocity macro calls
the wiki parser on the result and thus the top level HTML macro
executes
4) since wiki=true the content is given to a SAX parser and each
XML
tag content is given to the wiki parser. Thus {{html}}..., ...
and {{/html}} will be parser by the wiki parser separately
(because someTag is valid XML), thus generating non expected
content as a result.
Proposed change
==
Modify the HTML behavior so that the wiki parser executes first
(instead of the SAX parser) and render the result using a special
renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the
special renderer
Note that this means that if in HTML your write content that has a
meaning in some wiki syntax you'll need to escape it. For
example if
you have:
{{html wiki=true}}
!--hello--
{{/html
Re: [xwiki-devs] [VOTE] Change of behavior for the HTML macro when wiki=true
On Wed, May 6, 2009 at 2:45 PM, Vincent Massol vinc...@massol.net wrote:
On May 6, 2009, at 2:31 PM, Pascal Voitot wrote:
Just a quick question, I have recompiled my server with your last
commits
and when I write this page:
{{velocity}}
{{html wiki=true}}
#warning((% style='font-size: 130%;' %)blablabla)
{{/html}}
{{/velocity}}
I get the following exception...
Can you confirm it works on your test server? It would confirm I
have a
problem on my server...
yes works fine here.
Thanks, I will clean and recompile from scratch...
Thanks
-Vincent
thanks
Pascal
org.xwiki.rendering.macro.MacroExecutionException: Failed to parse
HTML content [?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
htmldiv class=warningmessagespan class=messagetypeWarning:
/span(% style='font-size: 130%;' %)blablabla/div/html
]
at
org
.xwiki
.rendering.internal.macro.html.HTMLMacro.parseXHTML(HTMLMacro.java:
215)
at
org
.xwiki
.rendering.internal.macro.html.HTMLMacro.execute(HTMLMacro.java:175)
at
org
.xwiki
.rendering.internal.macro.html.HTMLMacro.execute(HTMLMacro.java:61)
at
org
.xwiki
.rendering
.internal
.transformation
.MacroTransformation.transformOnce(MacroTransformation.java:169)
at
org
.xwiki
.rendering
.internal
.transformation
.MacroTransformation.transform(MacroTransformation.java:113)
at
org
.xwiki
.rendering
.internal
.transformation
.DefaultTransformationManager
.performTransformations(DefaultTransformationManager.java:72)
at
com
.xpn
.xwiki.doc.XWikiDocument.performSyntaxConversion(XWikiDocument.java:
5123)
at
com
.xpn
.xwiki.doc.XWikiDocument.performSyntaxConversion(XWikiDocument.java:
5096)
at
com
.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:
531)
at com.xpn.xwiki.api.Document.getRenderedContent(Document.java:472)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun
.reflect
.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun
.reflect
.DelegatingMethodAccessorImpl
.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.velocity.util.introspection.UberspectImpl
$VelMethodImpl.invoke(UberspectImpl.java:295)
at
org
.apache
.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:245)
at
org
.apache
.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:
203)
at
org
.apache
.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:
294)
at
org
.apache
.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318)
at
org
.xwiki
.velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:
178)
at
org
.xwiki
.velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:
143)
at
com
.xpn
.xwiki
.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:108)
at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1611)
at com.xpn.xwiki.web.Utils.parseTemplate(Utils.java:124)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:226)
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.doPost(ActionServlet.java:
432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1124)
at
com
.xpn
.xwiki
.wysiwyg
.server.filter.ConversionFilter.doFilter(ConversionFilter.java:145)
at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1115)
at
com
.xpn
.xwiki
.web
.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:
295)
at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1115)
at
com
.xpn
.xwiki
.web
.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:
112)
at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1115)
at
org.mortbay.jetty.servlet.ServletHandler.handle
Re: [xwiki-devs] [VOTE] Change of behavior for the HTML macro when wiki=true
no better idea...
a very special case to remind in the syntax help to my mind...
Pascal
On Tue, May 5, 2009 at 9:40 AM, Vincent Massol vinc...@massol.net wrote:
After trying to implement it I've found the following caveats:
* if the user wants an html comment he needs to escape the --
* if the user wants a NL he'll need to enter br/
* if the user wants a paragraph he'll need to enter p.../p
* And the most problematic one IMO: the user needs to be very careful
about new lines since:
table
tr
td
* [[listitem]]
/td
/tr
/table
is very different from
table
tr
td
* [[listitem]]
/td
/tr
/table
In the first case the /td, /tr and /table and continuation of
the list item written in wiki syntax since the wiki parser accepts
multiline content... hence you'll get in XHTML:
tabletbodytrtdulli!--startwikilink:listitem--span
class=wikicreatelinka href=/xwiki/bin/view/listitem?
parent=xwiki:Space.Pagespan class=wikigeneratedlinkcontentPage/
span/a/span!--stopwikilink--/td/tr/tbody/table/li/ul
which is completely invalid.
The same applies for:
{{macro/}}
/td
vs
{{macro/}}
/td
in the first case the macro is inline and will generate inline content
and in the second case it's standalone.
Still trying to figure out a best solution but I don't see one right
now...
If you have any idea, shoot!
Thanks
-Vincent
On May 4, 2009, at 3:25 PM, Vincent Massol wrote:
Hi,
After discussing with Thomas we've reached the conclusion that we
should change the way the HTML macro handle its content when
wiki=true.
For ex take the following input:
{{velocity}}
...
{{html wiki=true}}
form
$xwiki.includeForm(XWiki.MyClassSheet)
br /
p
input type=submit name=submit value=Create this new
Workpackage /
/p
/form
{{/html}}
...
{{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code
which thus generate {{html}} macros.
Current Result
Right now here's what happens:
1) velocity macro is executed and $xwiki.includeForm executes
2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki=true}}
form
{{html}}...someTag.../someTag{{/html}}
/form
{{/html}}
3) After velocity has finished executing the velocity macro calls
the wiki parser on the result and thus the top level HTML macro
executes
4) since wiki=true the content is given to a SAX parser and each XML
tag content is given to the wiki parser. Thus {{html}}..., ...
and {{/html}} will be parser by the wiki parser separately
(because someTag is valid XML), thus generating non expected
content as a result.
Proposed change
==
Modify the HTML behavior so that the wiki parser executes first
(instead of the SAX parser) and render the result using a special
renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the
special renderer
Note that this means that if in HTML your write content that has a
meaning in some wiki syntax you'll need to escape it. For example if
you have:
{{html wiki=true}}
!--hello--
{{/html}}
you'll get some strikethrough. So you'll need to write instead:
{{html wiki=true}}
!~-~-hello~-~-
{{/html}}
WDYT?
Here's my +1
Thanks
-Vincent
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [VOTE] Change of behavior for the HTML macro when wiki=true
I will try to compile it and deploy it on my website...
To be quicker, what module have you modified?
regards
Pascal
On Tue, May 5, 2009 at 4:58 PM, Vincent Massol vinc...@massol.net wrote:
On May 5, 2009, at 4:16 PM, Pascal Voitot wrote:
no better idea...
a very special case to remind in the syntax help to my mind...
Just committed the new behavior. Would be great if some users/devs
could verify it works on their use cases.
Thanks
-Vincent
Pascal
On Tue, May 5, 2009 at 9:40 AM, Vincent Massol vinc...@massol.net
wrote:
After trying to implement it I've found the following caveats:
* if the user wants an html comment he needs to escape the --
* if the user wants a NL he'll need to enter br/
* if the user wants a paragraph he'll need to enter p.../p
* And the most problematic one IMO: the user needs to be very careful
about new lines since:
table
tr
td
* [[listitem]]
/td
/tr
/table
is very different from
table
tr
td
* [[listitem]]
/td
/tr
/table
In the first case the /td, /tr and /table and continuation of
the list item written in wiki syntax since the wiki parser accepts
multiline content... hence you'll get in XHTML:
tabletbodytrtdulli!--startwikilink:listitem--span
class=wikicreatelinka href=/xwiki/bin/view/listitem?
parent=xwiki:Space.Pagespan
class=wikigeneratedlinkcontentPage/
span/a/span!--stopwikilink--/td/tr/tbody/table/li/
ul
which is completely invalid.
The same applies for:
{{macro/}}
/td
vs
{{macro/}}
/td
in the first case the macro is inline and will generate inline
content
and in the second case it's standalone.
Still trying to figure out a best solution but I don't see one right
now...
If you have any idea, shoot!
Thanks
-Vincent
On May 4, 2009, at 3:25 PM, Vincent Massol wrote:
Hi,
After discussing with Thomas we've reached the conclusion that we
should change the way the HTML macro handle its content when
wiki=true.
For ex take the following input:
{{velocity}}
...
{{html wiki=true}}
form
$xwiki.includeForm(XWiki.MyClassSheet)
br /
p
input type=submit name=submit value=Create this new
Workpackage /
/p
/form
{{/html}}
...
{{/velocity}}
And assume that MyClassSheet has some $doc.display() velocity code
which thus generate {{html}} macros.
Current Result
Right now here's what happens:
1) velocity macro is executed and $xwiki.includeForm executes
2) MyClassSheet generate {{html}} macro content thus yielding:
{{html wiki=true}}
form
{{html}}...someTag.../someTag{{/html}}
/form
{{/html}}
3) After velocity has finished executing the velocity macro calls
the wiki parser on the result and thus the top level HTML macro
executes
4) since wiki=true the content is given to a SAX parser and each XML
tag content is given to the wiki parser. Thus {{html}}..., ...
and {{/html}} will be parser by the wiki parser separately
(because someTag is valid XML), thus generating non expected
content as a result.
Proposed change
==
Modify the HTML behavior so that the wiki parser executes first
(instead of the SAX parser) and render the result using a special
renderer that prints the special symbols and text as is.
When run on our example this would give (same steps 1) and 2)):
3) wiki parser executes and generate XDOM. Render it using the
special renderer
Note that this means that if in HTML your write content that has a
meaning in some wiki syntax you'll need to escape it. For example if
you have:
{{html wiki=true}}
!--hello--
{{/html}}
you'll get some strikethrough. So you'll need to write instead:
{{html wiki=true}}
!~-~-hello~-~-
{{/html}}
WDYT?
Here's my +1
Thanks
-Vincent
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
