- xwiki-devs@xwiki.org - lists.xwiki.org

[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

[xwiki-devs] [ANN] XWiki Enterprise 1.7 Milestone 3 Released
by Thomas Mortagne 21 Nov '08

21 Nov '08

he XWiki development team is pleased to announce the release of XWiki Enterprise 1.7 Milestone 3. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download Last milestone of the XWiki Enterprise 1.7 version. Main changes: * Webdav support * Groovy upgrade * New script macro Important bug fixes: * The old LDAP authenticator is still used by default in some cases Note that general goals for XWiki Enterprise 1.7 are * Working and usable (i.e. users can use them for their day to day work instead of the old Syntax and old WYSIWYG editor) versions of new rendering and new WYSIWYG editor. * Working JCR (can be used for day to day work instead of Hibernate). * French XE * Blog revamping * Webdav integration For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise17M3 Thanks, The XWiki dev team

1 0

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-macro-groovy/src xwiki-macros/xwiki-macro-groovy/src/main xwiki-macros/xwiki-macro-groovy/src/main/resources xwiki-macros/xwiki-macro-groovy/src/main/resources/META-INF xwiki-macros/xwiki-macro-groovy/src/main/resources/META-INF/plexus xwiki-macros/xwiki-macro-gro
by Sergiu Dumitriu 21 Nov '08

21 Nov '08

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? - 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. - The javadocs on the interfaces could be improved... They are rather short right now. -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

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 Sergiu Dumitriu 21 Nov '08

21 Nov '08

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()); -- Sergiu Dumitriu http://purl.org/net/sergiu/

1 0

Re: [xwiki-devs] [xwiki-notifications] r14297 - in platform/core/trunk: xwiki-bridge/src/main/java/org/xwiki/bridge xwiki-core/src/main/java/com/xpn/xwiki/doc xwiki-rendering/src/test/java/org/xwiki/rendering/internal
by Sergiu Dumitriu 19 Nov '08

19 Nov '08

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-11-19 15:48:09 +0100 (Wed, 19 Nov 2008) > New Revision: 14297 > > Modified: > platform/core/trunk/xwiki-bridge/src/main/java/org/xwiki/bridge/DocumentAccessBridge.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/DefaultDocumentAccessBridge.java > platform/core/trunk/xwiki-rendering/src/test/java/org/xwiki/rendering/internal/MockDocumentAccessBridge.java > Log: > XWIKI-2855: Add a bridge to know if current document author has programming rights > I don't quite like this. Programming rights should not be part of the model. -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 1