November 2008 - xwiki-devs@xwiki.org

[xwiki-devs] java.lang.ClassNotFoundException: org.xwiki.container.servlet.XWikiPlexusServletContextListener
by Juergen Lorenz Simon 24 Nov '08

24 Nov '08

Hi, I'm attempting to develop a couple of plugins to integrate XWiki into a portal solution. Unfortunately I'm having problems getting a debug session going in Eclipse. I followed the instructions in the XWiki dev wiki to the letter, with the small change of going from 1.6 (as stated in the wiki examples) to 1.7, which seems to be the latest snapshot. Also I'm using Tomcat 6. I get the following exception when attempting to run the app on the server: SEVERE: Error configuring application listener of class org.xwiki.container.servlet.XWikiPlexusServletContextListener java.lang.ClassNotFoundException: org.xwiki.container.servlet.XWikiPlexusServletContextListener at org .apache .catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java: 1360) at org .apache .catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java: 1206) at org .apache .catalina.core.StandardContext.listenerStart(StandardContext.java:3786) at org.apache.catalina.core.StandardContext.start(StandardContext.java: 4350) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java: 1045) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java: 1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java: 443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java: 710) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) 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.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) I also noticed that the tmp0/wtpapps/xe-debug-web/WEB-INF/lib directory only contains the plugin code. All other dependencies are not pulled in. That does not seem right. I'm using Eclipse 3.4, M2Eclipse 0.9.6 and Tomcat 6. Here is the xe-debug-web's pom file:

1 0

[xwiki-devs] [proposal] Access to XWQL & QueryManager for scripts
by Artem Melentyev 24 Nov '08

24 Nov '08

Hi devs! As you know XWQL was introduced in 1.6, but without some easy access from scripts. Currently it is accessible via $xwiki.xWiki.store.queryManager.createQuery(stmt, "xwql") and only with programming rights. We need some easy ways to access to XWQL similar as $xwiki.searchDocuments, countDocuments and search. This will allow to users much more test XWQL and send us feedback. I planed to implement this by 1.7RC1 or 1.7. This is just an interface for xwiki scripts and doesn't affect to important parts of platform. Name of this service? 1. $xwiki.queryManager ($xwiki.query is occupied by old QueryPlugin) Later this will be obsoleted by 2. or 2. $services.query $services was proposed in our velocity bridge proposal[1]. We may implement only $service now as just simple services holder, without uberspectors. $services will be reimplemented later, but "$service.query" name will be saved. [1] http://markmail.org/message/nnybto3mluvp2rov I'm for 1 because velocity bridge isn't exist yet and its design may be changed. Technically it will be just some proxy for QueryManager and Query with access right checking. Functionality? 1. Just the same as QueryManager so: .createQuery("stmt", "lang").execute() or 2. The same as QueryManager + .xwql("stmt") method which will call .createQuery("stmt", "xwql") .xwql("stmt") is much more laconically than createQuery. Later it may be transparently replaced by 3. or 3. QueryManager + dynamic methods like .language("stmt") impossible without velocity bridge uberspectors. I'm for 2. Access rights? One way: 1. short-form xwql queries like "where <whereexpr>" and "from <fromexp> where <whereexpr>" return only document names, so will be available for everyone. this is analogue for $xwiki.searchDocuments() 2. full-form xwql ("select <selectlist> from <etc>" ) will require programming rights. this is analogue for $xwiki.search() 3. all other languages (currently only HQL) in QueryManager will require programming rights. 4. Query.setWiki will require programming rights. So we need to wrap Query with some SecureQuery. How should be analogue for "$xwiki.countDocuments"? Ways: 0. No analogue. just query.execute().size() JCRSQL2 has no aggregate functions at all. We could make lazy query result list to fix negatives. 1. just accept all queries like "select count(*) ..." ("*" is not supported in count() according jpql) 2. implement some simple syntax extension in xwql: "count [from ...] where ..." no parser change, just replace the statement prefix I'm 0 for now. WDYT? -- Artem Melentyev

5 5

[xwiki-devs] [Proposal][Vote] Design of Annotation feature
by Lucien PEREIRA 24 Nov '08

24 Nov '08

Hi, I'd like to propose this design <http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature> for annotation feature implementation. Vote is about choosing between solution 1 and 2. if we can have an (almost) perfect bijective function between HTML and XWiki code, I'm +1 for solution 2 because implementation will be more efficient , stable and clean. Otherwise solution 1 seems to be a good solution. WDYT? Lucien

6 10

Re: [xwiki-devs] [VOTE][UI] WYSIWYG general layout (SUMMARY)
by Jean-Vincent Drean 24 Nov '08

24 Nov '08

Six +1, no 0, no -1. Vote passed. Thanks, JV. On Fri, Nov 21, 2008 at 10:33 AM, Jean-Vincent Drean <jv(a)xwiki.com> wrote: > Hi XWikiers, > > I've started to refactor WYSIWYG mockups according to the last > discussions on the list. For this first vote I propose to validate its > general layout. > The mockup can be found here, I hope it is self-explaining : > http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface#HToolb… > You can ignore the inline syntax help in wiki mode, it was just a > thought while doing the mockup. > > Here's my +1. > > JV. >

1 0

[xwiki-devs] [VOTE][UI] WYSIWYG general layout
by Jean-Vincent Drean 24 Nov '08

24 Nov '08

Hi XWikiers, I've started to refactor WYSIWYG mockups according to the last discussions on the list. For this first vote I propose to validate its general layout. The mockup can be found here, I hope it is self-explaining : http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface#HToolb… You can ignore the inline syntax help in wiki mode, it was just a thought while doing the mockup. Here's my +1. JV.

7 9

[xwiki-devs] [Rendering] Parameters for images that are linked to
by Vincent Massol 22 Nov '08

22 Nov '08

Hi, We have a decision to take to support image parameters when we're linking to an image. Here's what this would mean with the current syntax: [[[[image:attach.png||height="100" width="100"]]>>http://xwiki.org|| param=value]] Is that what we want? I'm not even sure we can implement this since wikimodel will consider the reference to be: [[[[image:attach.png||height="100" width="100"]] (since it'll use the first closing reference marker, i.e. "]]") So the question is: do we want to use a different syntax for images or should I try to make this one work? WDYT? Thanks -Vincent

4 10

Re: [xwiki-devs] [xwiki-notifications] r14301 - in platform/core/trunk/xwiki-rendering/src: main/java/org/xwiki/rendering/internal/transformation test/java/org/xwiki/rendering test/java/org/xwiki/rendering/internal/transformation test/resources/META-INF/plexus test/resources/macros
by Vincent Massol 21 Nov '08

21 Nov '08

On Nov 21, 2008, at 2:51 AM, Sergiu Dumitriu wrote: > vmassol (SVN) wrote: >> + getLogger().debug("The [" + >> macroHolder.macroBlock.getName() + "] macro doesn't support inline >> mode."); > >> + getLogger().debug("Failed to execute macro [" + >> macroHolder.macroBlock.getName() + "]. Internal error [" >> + + e.getMessage() + "]"); > >> getLogger().debug("Failed to locate macro [" + >> macroBlock.getName() + "]. Ignoring it."); > > You should use the new formatting logger methods, like: > > getLogger().debug("Failed to locate macro [{0}]. Ignoring it.", > macroBlock.getName()); Can you remind me what are the advantages since I see 2 drawbacks: * the log message becomes harder to write and read since you need to mentally map the numbers with the parameters * If you have single quote in debug messages it'll fail (in message formats you must always use '' (two single quotes) to display a single single quote. I've been bitten by this in the past. Note that performance don't matter at all for logging errors. One advantage I'd see is to for i18n, However I don't think we want to internationalize error messages. I'm not against using this. I just want to be sure we have a good rationale before we start converting systematically all our logs to it. Thanks -Vincent

2 1

Re: [xwiki-devs] [xwiki-notifications] r14355 - sandbox/xwiki-application-ratings/src/main/resources/XWiki
by Sergiu Dumitriu 21 Nov '08

21 Nov '08

jvelociter (SVN) wrote: > +Event.observe(window, 'load', function() I learned that the version of prototype we are using allows us to use: document.observe("dom:loaded", function(){...}); This is better, since onload is triggered once all the components of the page are loaded (including images), while dom:loaded is triggered as soon as all the HTML was received, without waiting for other resources to load. More info on http://www.prototypejs.org/api/document/observe -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 2

Re: [xwiki-devs] [xwiki-notifications] r14298 - in platform/core/trunk: . xwiki-core xwiki-core/src/main/java/com/xpn/xwiki/render xwiki-core/src/main/java/com/xpn/xwiki/render/groovy xwiki-macros xwiki-macros/xwiki-macro-groovy xwiki-macros/xwiki-ma
by Thomas Mortagne 21 Nov '08

21 Nov '08

On Fri, Nov 21, 2008 at 7:28 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > tmortagne (SVN) wrote: >> Author: tmortagne >> Date: 2008-11-19 15:57:38 +0100 (Wed, 19 Nov 2008) >> New Revision: 14298 > >> Log: >> XWIKI-2825: Create a generic script macro > > A quick review of the xwiki-script module: > > - DefaultScriptContextManager and ScriptExecutionContextInitializer > should be in the internal package. > - ScriptExecutionContextInitializer is not declared in components.xml, > thus it is not used. > - getScriptContext calls the initializers on each call. Is that correct? > Shouldn't the context be initialized only once? It in initialized only once (there is an if if (scriptContext.getAttribute("util") == null) in it). I was in a hurry for the 1.7M3 release so I just follow the way it's done for Velocity. > - scriptContextInitializerList (which also contains a typo in its name) > could be completely injected by Plexus, thus there's no need for > Initializable and Composable on this class. Just declare a dependency on > ScriptContextInitializer components. How do you do that ? The context initializers are retrieved the same way in DefaultExecutionContextInitializerManager so I assumed it was not possible to inject a list of dependencies in component.xml. > - The javadocs on the interfaces could be improved... They are rather > short right now. > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne

2 1

[xwiki-devs] [OFFICEIMPORTER] Style Filtering Policy & Mechanism.
by Asiri Rathnayake 21 Nov '08

21 Nov '08

Hi Devs, I'm working on implementing the style filtering functionality of xwiki-office-importer application. But first, i need to make sure that I'm clear about the policy and the correct approach towards filtering style information from imported office documents. I would really appreciate your input on this because I'm not an expert on either html or css :) Ok, I plan to do two types of filtering. One is filtering various attributes of various elements (like removing bgcolor attribute from the <body> element). And the second one is filtering css related stuff. Let's take one by one. 1. Filtering attributes. This is quite straight-forward but i see two possible approaches. * The first approach is to keep a list of attributes that we allow when importing documents. We'll scan each and every tag and strip off any unwanted attributes present. * The second approach is to associate each tag with what attributes we allow for that tag. A list of legal attributes for common tags is presented here http://www.devx.com/projectcool/Article/19816. Similarly, we'll have our tag_name->allowed_attributes mapping and filter all other attributes present. I'm currently leaning towards the second option, WDYT ? 2. Filtering css styles. Ok, there are three ways one can associate css with html content. Let's take one by one. (i) External Style Sheet Well, AFAIK OpenOffice server does not produce this type of output when converting office documents into html. I mean it doesn't output html files that refer external css files. So I guess this is something we don't need to worry about. (ii) Internal Style Sheet This is something we need to worry about. OpenOffice server produces html pages with content like <head><style type="text/css">....</style></head>. Currently we strip off <style> tags completely regardless of the filtering mode (i.e whether styles are set to be filtered or not <style> tags get removed). Does this behaviour need to change ? (iii) In-line Styles This is the most common type of styling found (Example : <p style="....">). Present behaviour is to strip off this style attribute completely (if filterStyles is set to true). The question is, there are some inline styles that directly maps to xwiki 2.0 syntax like <p style="font-weight:bold">, what are we going to do about these ? In any case, I will have to parse the in-line style attribute string to filter those style directives that are not necessary. The complete grammar for in-line style attributes seems to be a bit complicated to be hand crafted (http://www.w3.org/TR/css-style-attr) although in OpenOffice converted documents i have only seen the "key:value;key:value" format. What should be the correct approach to parse the style attribute string ? Thank you very much for your ideas. :) [image: Asiri Rathnayake's Facebook profile]<http://www.facebook.com/people/Asiri_Rathnayake/534607921>

4 14