xwiki-devs October 2008

xwiki-devs@xwiki.org

40 participants
133 discussions

[xwiki-devs] [Rendering] Image support & Parameters for links/images

by Vincent Massol

Hi, There are 2 features I need to finish implementing for the new rendering and I have some doubts. 1) Parameters for links Problem ======= We decided to use the (% param=value %)[[link]] notation. However this is raising some issues. First the user needs to close the parameter list so that it doesn't affect other elements coming after. For example: (% rel="_blank" %)[[link]](%%) hello is different from: (% rel="_blank" %)[[link]] hello In the second case the rel="_blank" applied to both the link, the space and the word "hello". However if we consider the params to only apply the link then we cannot set params anymore that span more than the link. For example: (% style="color:red" %)[[link]] and some text(%%) Note that technically the params currently generate a <span> element with the params as attributes. Thus right now using rel="_blank" is set on the span and not on the <a> element which means it doesn't work. Solutions ======= a) Add again the notion of parameters inside the link syntax: [[label>>reference>>>param=value...]] (or using some other separator) b) Use a different syntax for link parameters, for ex: {% param=value %}[[link]] (but I really don't like it) c) Force the params in the (% %)[[link]] notation to always apply only to the link and thus force users to use a space if they want to start a styled portion of text beginning with a link: (% param=value %) [[link]] something else %) As much as I hate having to recode what I've removed, I think the best solution is a). 2) Syntax for images Problem ======= We had decided to use the following syntax: image:wiki:Space.Page^my.png (note: not sure we agreed about the use of ^ but that's a detail - I couldn't find the email where we discussed that) The question is how do we set parameters for images. For example: alt, title, width, height, etc? We have the exact same problem as for links but it's even worse since we don't have the ability to define the parameters inside the image syntax since the image syntax is too limited. Solutions ======= a) Use a different syntax such as: !!label>>image>>>param=value...!! (note that there are several wikis using the !! notation for images, including confluence) Ex: !!my.png!! !!my image>>my.png!! !!wiki:Space.Page^my.png>>>width=100 height=200!! b) Decide not to have a syntax for images and instead use an image macro. Ex: {{image name="my.png" document="wiki:Space.Page" width="100" height="200"/}} Note that there's one problem with not having a syntax for images in the grammar: it makes it harder to convert from one syntax for another. For example people using wikimodel wouldn't be able to convert from xwiki to another syntax easily and viceversa. In XWiki itself we would need to have some extra handling code to handle the fact that the image is a macro to convert it to another syntax but that's possible (not the easiest but possible). WDYT for 1) and 2)? My choice: 1) a) For 2) I'd prefer to have a syntax for images (for the conversion between syntaxes issue and for the fact that the syntax wouldn't be complete - We've added tables in the syntax so it would be a pity not to have a syntax for images IMO). There's only possibility though: that we add {{image...}} in the syntax, so it would generate an onImage() event in XWiki and we would just convert it internally to an image macro. Ideally I'd still prefer a clean syntax but that'd be my second choice. Thanks -Vincent

15 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r13864 - in platform/core/trunk/xwiki-rendering/src: main/java/org/xwiki/rendering/block test/java/org/xwiki/rendering/block

by Sergiu Dumitriu

vmassol (SVN) wrote: > Author: vmassol > Date: 2008-10-28 09:19:23 +0100 (Tue, 28 Oct 2008) > New Revision: 13864 > > Added: > platform/core/trunk/xwiki-rendering/src/test/java/org/xwiki/rendering/block/XMLBlockTest.java > Modified: > platform/core/trunk/xwiki-rendering/src/main/java/org/xwiki/rendering/block/XMLBlock.java > Log: > XWIKI-2785: The order in which XML attributes are printed when converted to XWiki syntax is not fixed > > + public void testAttributeOrder() > + { > + Map<String, String> attributes = new HashMap<String, String>(); > + attributes.put("aaa", "value1"); > + attributes.put("bbb", "value2"); > + XMLBlock block = new XMLBlock("element", attributes); > + > + Iterator<String> it = attributes.keySet().iterator(); > + Iterator<String> newIt = block.getAttributes().keySet().iterator(); > + while (it.hasNext()) { > + assertEquals(newIt.next(), it.next()); > + } > + } I'm not sure this test is enough, since the order for two attributes could happen to be the same. Why not add 10 attributes (aN = vN, where N goes from 0 to 9)? -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 10 months

[xwiki-devs] Javascript in {{html}} or {{xhtml}} blocks in syntax 2.0

by Jerome Velociter

Hello, I realize that entering the following in a wiki document using syntax xwiki/2.0 : {{html}} <script type="text/javascript"> //<![CDATA[ alert("Hello, World") // ]]> </script> {{/html}} Results in html as :  So the script tag is not rendered at all, thus the javascript not interpreted. Is this expected ? Is there a way to embed JS in a html block ? Regards, Jerome.

15 years, 10 months

[xwiki-devs] IE issue with placing the caret at the beginning of a text node

by Marius Dumitru Florea

Hi devs, To explain the issue lets consider the following scenario: * Edit a new page with the new WYSIWYG editor. * Type "foobar" and place the caret as in "foo|bar", where the pipe represents the caret. * Press the Bold button or type CRTL+B in order to start typing bold text at the current insertion point. * At this moment, the HTML should be "foo<strong>|</strong>bar" where the pipe represents the caret. The Problem In Mozilla it's easy to place the caret as suggested. In IE it's impossible (this weekend I tried all sort of things and search desperately on Google..). What I can easily do in IE is either "foo|<strong></strong>bar" or "foo<strong></strong>|bar". The workaround that I found is to use a special space symbol http://en.wikipedia.org/wiki/Zero-width_non-joiner inside the strong tag (before, it had an empty text node inside) and place the caret just after this special space symbol. PROs: * When the use will type the text will be bold. CONs: * Although the space character is not visible you have to jump over it while navigating with the arrow keys. * Although we can remove these special symbols before converting to wiki syntax, the user will have them when copy&pasting. I'm in favor of using this special space symbol. WDYT? Thanks, Marius. P.S.: I need your opinion ASAP, thanks!

15 years, 10 months

[xwiki-devs] [VOTE] Make ditribution maven packages not "generics" anymore

by Thomas Mortagne

Hi devs, I finished a maven build for XWiki+GlassFish+derby distribution. So this means a distribution not based on jetty and we can't use database profile to decide what distribution to build anymore. So I propose: 1) havnig distributions like jetty-hsqldb, glassfish-derby, etc. and to remove distribution we are not releasing/using right now on XE/XEM like hsqldb-pgsql, hsqldb-derby etc. On maven build this means that to build XE glassfish-derby you will need to execute: - on XE parent : mvn install -Pci,derby,glassfish-derby - on the distribution : mvn install This will change all distributions ids but I don't think it's a problem. 2) jetty-hsqldb remain the default distribution for now Here is my +1 for both -- Thomas Mortagne

15 years, 10 months

[xwiki-devs] [vote] Apply inline style to the whole word or just the insertion point?

by Marius Dumitru Florea

Hi devs, Let's consider the following scenario: * Edit a new page with the new WYSIWYG editor. * Type a word like "ubuntu". * Move the caret inside the word like "ubu|ntu". * Press the Bold button or type CTRL+B. Question: What is the expected behavior? a) Apply the inline style (bold) only to the insertion point. The next letters typed will have this style applied. b) Apply the inline style (bold) to the word that contains the insertion point ("ubuntu"). Note: b) is the current behavior in Open Office and IE. FF behaves as in a). The behavior currently implemented in the new WYSIWYG editor is a). Also, by choosing b) I avoid the use of the special space character in IE (see my previous mail), but I have to re-implement the current behavior of the new WYSIWYG. I need around 2 days for it. Of course, it will work for any inline style like bold, italic etc. I'm +1 for b) Thanks, Marius.

15 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r13850 - sandbox/xwiki-plugin-officeimporter

by Sergiu Dumitriu

asiri (SVN) wrote: > Author: asiri > Date: 2008-10-27 14:00:09 +0100 (Mon, 27 Oct 2008) > New Revision: 13850 > > Removed: > sandbox/xwiki-plugin-officeimporter/BUILD > sandbox/xwiki-plugin-officeimporter/README > Log: > Removing out dated / unnecessary files. > The README file contained useful information; I hope you copied it someplace else (the xwiki.org site) before, right? -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r13849 - in sandbox: xwiki-application-officeimporter xwiki-plugin-officeimporter

by Sergiu Dumitriu

asiri (SVN) wrote: > Author: asiri > Date: 2008-10-27 13:49:42 +0100 (Mon, 27 Oct 2008) > New Revision: 13849 > > Modified: > sandbox/xwiki-application-officeimporter/pom.xml > sandbox/xwiki-plugin-officeimporter/pom.xml > Log: > Changing the name of the officeimporter plugin & application to make more sense. Asiri, the description of the field should not duplicate the name. - The artifactId should be lowercase, no space, and have a specific format (like xwiki-plugin-alexa); this is an identifier intended for machines, to be able to identify and locate the artifact. - The name should be like a breadcrumb, from general to specific, human readable, separated by dashes (like XWiki Platform - Plugins - Alexa); this is a human readable identifier (name) of the project, intended for humans to quickly see what module this is. - The description should be prose, describing what the module does. It is intended to describe the purpose of the module. I know that most of the modules simply use the name as the description, but that does not add any useful information, thus it is wrong. See http://maven.apache.org/pom.html#More_Project_Information and http://maven.apache.org/ref/current/maven-model/maven.html#class_project > - <description>import office documents such as MS word to xwiki page</description> > + <description>XWiki Platform - Applications - Office Importer</description> -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 10 months

[xwiki-devs] JMesa and our new table support in the new rendering?

by Vincent Massol

Hi Thomas (and others), Just found JMesa: http://code.google.com/p/jmesa/ Maybe that's something we could be interested in using for our new table implementation? Or maybe not. I just wanted to raise the topic (note that dynamic table support is planned for XE 1.8 and not 1.7). One caveat: It seems to like JQuery. I don't know if it'll work with prototype for example. Thanks -Vincent

15 years, 10 months

[xwiki-devs] [vote] Next localization steps

by Sergiu Dumitriu

Hi devs, The new localization component is committed. I think it is working pretty well, so it's time to decide what to do next (estimate deadlines and responsibles after each item): 0. Outside review - me and Marta refactored it about 5 times already, a third opinion would be nice. ASAP, let's say by the end of the week - volunteers; this is a good exercise, as it shows how to write and use components 1. Add it in the build cycle (include it in the core pom as a submodule) ASAP - me 2. Deprecate the XWikiMessageTool class and methods. Should be completely phased out by 1.9 according to our deprecation strategy. ASAP - me 3. Use it in the xwiki-core, replacing the messagetool Full replacement until 1.7M2 - me and other volunteers 4. Propose a standard for writing keys Next week - me + discussion on devs 5. Start properly translating applications in their own documents Until 1.7 final - everybody, especially application owners 6. Split ApplicationResources into smaller files, moving everything to its proper place: .properties files in plugins, wiki documents for applications, CoreResources.properties (the clean version of ApplicationResources). Until 1.7 final - everybody 7. Improve the localization component: 7a. Replace hashmaps with caches Until 1.7M2 - me or volunteers 7b. Write tests Until 1.7M2 - me or volunteers A note for items 2 and 3: The localization component interface is compatible with the message tool, as it provides the get(string) and get(string, list) methods. However, old code casts the retrieved object to XWikiMessageTool, so replacing the "msg" context variable is not advisable yet. I used 'l10n' as the variable name for the new tool, as it reflects better what it does. And, as Vincent suggested, this is a workaround until the velocity bridge is in place, when we shouldn't use direct context variables, but request access to services through this bridge. >From me, +1 to all of these. WDYT? Any volunteers where needed? -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 10 months

← Newer
1
2
3
4
5
6
7
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2008