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

Re: [xwiki-devs] [xwiki-notifications] r15087 - in sandbox/xwiki-core-rest/src/main: java java/components java/components/org java/components/org/xwiki java/components/org/xwiki/rest java/components/org/xwiki/rest/internal resources/META-INF/plexus

by Vincent Massol

Hi Fabio On Jan 6, 2009, at 1:46 AM, fmancinelli (SVN) wrote: > Author: fmancinelli > Date: 2009-01-06 01:46:26 +0100 (Tue, 06 Jan 2009) > New Revision: 15087 > > Added: > sandbox/xwiki-core-rest/src/main/java/components/ > sandbox/xwiki-core-rest/src/main/java/components/org/ > sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/ > sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/ > sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/ > SpacesResource.java > sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/ > XWikiResource.java > sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/ > XWikiResourceFinder.java > sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/ > XWikiResourceRepresenter.java > sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/ > XWikiRestApplication.java > sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/ > XWikiRestletServlet.java > sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/ > internal/ > sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/ > internal/PlainTextSpacesRepresenter.java > sandbox/xwiki-core-rest/src/main/java/components/org/xwiki/rest/ > internal/XmlTextSpacesRepresenter.java > Modified: > sandbox/xwiki-core-rest/src/main/resources/META-INF/plexus/ > components.xml > Log: > Added a fully componentized version of the REST infrastructure. > > Now resources and "representers" (i.e., objects that are in charge > for representing a given resource for a given media type) are > declared through components.xml and automatically registered: > > 1) At the application level routes are created for all the > components declaring the org.xwiki.rest.XWikiResource role. The role > hint defines the uri template. > > 2) Representers components are associated to resource components by > looking at the role hint (which should reflect the resource a given > representer is associated to) [snip] > + restApplication = (XWikiRestApplication) > componentManager.lookup(applicationClass); > + > + > restApplication.setName(getServletConfig().getServletName()); > + restApplication.setContext(new > ServletContextAdapter(this, context)); > + > restApplication > .getContext().setLogger(restApplication.getClass().getName()); Looks good in general. Just making sure: is createApplication() and hence the code above executed only once? All components you've created are singletons so you need to be careful that they don't hold state or if they do (as above) then this needs to be a state that is common for all threads and thus only initialized once for the entire app lifetime. [snip] Thanks -Vincent

16 years, 8 months

2
2
0 0

[xwiki-devs] Build error of fresh checkout on Windows Vista

by smithmarkl

Howdy, I've checked out the source code HEAD revision from: http://svn.xwiki.org/svnroot/xwiki/platform/trunks I've installed Maven, setup my .../.m2/settings.xml, and am running "mvn -Pwindows install". The build seems to proceed part way, then one of the tests fails: Running com.xpn.xwiki.tool.xar.XarMojoTest [info] Using the existing package.xml descriptor at [C:\temp\xwiki\tools\xwiki-x ar-plugin\target\test-classes\malformedXml\src\main\resources\package.xml] [error] The existing package.xml is invalid. java.lang.Exception: The supplied document contains no document list at com.xpn.xwiki.tool.xar.XarMojo.getDocumentNamesFromXML(XarMojo.java:2 72) at com.xpn.xwiki.tool.xar.XarMojo.addFilesToArchive(XarMojo.java:321) at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:124) at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:76) Any ideas? -- View this message in context: http://n2.nabble.com/Build-error-of-fresh-checkout-on-Windows-Vista-tp21117… Sent from the XWiki- Dev mailing list archive at Nabble.com.

16 years, 8 months

3
5
0 0

[xwiki-devs] [VOTE][UI] WYSIWYG Macro dialogs

by Jean-Vincent Drean

Hi, I've made a mockup for the macro dialog in the WYSIWYG editor : http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/MacroDialog… I've assumed that using a tree to browse macros was : - Scalable. - Consistent with link dialogs. Shout if you think about another way of displaying them. Note that the second dialog is generated dynamically and will vary a lot according to macros needs (see 2 bis), its layout must remain as simple as possible. Here's my +1. JV.

16 years, 8 months

8
14
0 0

Re: [xwiki-devs] [xwiki-notifications] r15061 - in sandbox/xwiki-core-rest: . src/main/java/org/xwiki/rest

by Vincent Massol

On Jan 5, 2009, at 1:05 PM, fmancinelli (SVN) wrote: > Author: fmancinelli > Date: 2009-01-05 13:05:32 +0100 (Mon, 05 Jan 2009) > New Revision: 15061 > > Modified: > sandbox/xwiki-core-rest/.classpath > sandbox/xwiki-core-rest/src/main/java/org/xwiki/rest/ > PageResource.java > sandbox/xwiki-core-rest/src/main/java/org/xwiki/rest/ > RestApplication.java > Log: > Componentized page representation with plexus components as > suggested on the mailing list. > > Modified: sandbox/xwiki-core-rest/.classpath > =================================================================== > --- sandbox/xwiki-core-rest/.classpath 2009-01-05 12:01:09 UTC (rev > 15060) > +++ sandbox/xwiki-core-rest/.classpath 2009-01-05 12:05:32 UTC (rev > 15061) > @@ -1,6 +1,7 @@ > <?xml version="1.0" encoding="UTF-8"?> > <classpath> > <classpathentry kind="src" output="target/classes" path="src/main/ > java"/> > + <classpathentry kind="src" path="src/main/resources"/> > <classpathentry kind="src" path="src/test/java"/> > <classpathentry kind="src" path="src/test/resources"/> > <classpathentry kind="con" > path="org.eclipse.jdt.launching.JRE_CONTAINER/ > org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/> > > Modified: sandbox/xwiki-core-rest/src/main/java/org/xwiki/rest/ > PageResource.java > =================================================================== > --- sandbox/xwiki-core-rest/src/main/java/org/xwiki/rest/ > PageResource.java 2009-01-05 12:01:09 UTC (rev 15060) > +++ sandbox/xwiki-core-rest/src/main/java/org/xwiki/rest/ > PageResource.java 2009-01-05 12:05:32 UTC (rev 15061) > @@ -1,14 +1,15 @@ > package org.xwiki.rest; > > +import java.util.Map; > + > import org.restlet.Context; > import org.restlet.data.MediaType; > import org.restlet.data.Request; > import org.restlet.data.Response; > import org.restlet.data.Status; > import org.restlet.resource.Representation; > -import org.restlet.resource.StringRepresentation; > import org.restlet.resource.Variant; > -import org.xwiki.rest.model.Page; > +import org.xwiki.component.manager.ComponentLookupException; > > import com.xpn.xwiki.api.Document; > > @@ -29,9 +30,19 @@ > public PageResource(Context context, Request request, Response > response) > { > super(context, request, response); > - getVariants().clear(); > - getVariants().add(new Variant(MediaType.TEXT_XML)); > - getVariants().add(new Variant(MediaType.TEXT_PLAIN)); > + > + /* Configure Media types from registered PageRepresenter > components */ > + try { > + getVariants().clear(); > + Map<String, Object> map = com.xpn.xwiki.web.Utils.getComponentManager > ().lookupMap(PageRepresenter.ROLE); > + for (String mediaTypeName : map.keySet()) { > + MediaType mediaType = > MediaType.valueOf(mediaTypeName); > + getVariants().add(new Variant(mediaType)); > + } > + } catch (ComponentLookupException e) { > + throw new RuntimeException(e); > + } The ideal way would be for PageResource to be a component. You could then have a component map directly injected in PageResource using Plexus and you wouldn't need to use the xwiki-core dep on web.Utils which we need to get rif of. -Vincent

16 years, 8 months

2
10
0 0

[xwiki-devs] [Proposal] Make our new GWT WYSIWYG editor a top level standalone project

by Vincent Massol

Hi devs, This is not a priority (we need to finish our first stable release of the WYSIWYG editor first) but I wanted to propose 2 things and start a discussion on it: * That we make our new GWT WYSIWYG editor a top level project (i.e. with a separate jira, separate wiki like http://wysiwyg.xwiki.org with a better name, etc) * Make it usable by someone who is not using XWiki The rationale is: * If we want our editor to become strong and compete with the likes of FCKEditor/TinyMCE we need to open it up to others and for that we need to: - advertise it (hence the http://wysiwyg.xwiki.org that would lists all features same as http://www.fckeditor.net/) - make it be usable easily and thus without dragging xwiki dependencies Other options: 1) Don't do anything. Cons: we won't get enough help and it'll be hard to compete with other editors. They'll have more features/less bugs and we'll have a hard time keeping up. In addition it's possible someone else creates a new GWT WYSIWYG editor and it would be better if we could all join force on that and using what we have started 2) Externalize it on some forge other than the xwiki forge. This is nice from a marketing point of view (i.e. easier to show it as a pure wysiwyg editor) but it has some drawbacks: - further from the xwiki community and thus harder for us to maintain it there - doesn't strengthen our xwiki project In addition, what we need to evaluate is how do we make it independent of xwiki and how long would that take. This is probably more a question for Marius. Marius this is not urgent compared to the 1.7.1 release. Whenever you have time. Thanks -Vincent

16 years, 8 months

4
4
0 0

[xwiki-devs] [VOTE] Allow multi-line headers

by Marius Dumitru Florea

Hi devs, A) Should xwiki/2.0 support multi-line headers? I'm +0. Wikimodel, HTML and Open Office support them. B) What should happen when you press Enter inside a header in the new WYSIWYG? B1) Currently, the text is moved on a new line, but still inside the header (multi-line header). I'm +1 since it's already done (We agreed that you have to press Enter twice to generate a new paragraph). B2) Text is moved in a new paragraph, below the header. Shift+Enter would have the effect described in B1). I'm -0. B3) Text is moved in a new header of the same level, below the current one. Shift+Enter would have the effect described in B1). This is what Open Office does (and we agreed not to follow it). I'm -0. Please cast your vote asap. Thanks, Marius.

16 years, 8 months

8
16
0 0

[xwiki-devs] [Proposal]Adding ability to display an optional image and a optional title in the Box macro

by Dan Miron

Hi. Regarding the http://jira.xwiki.org/jira/browse/XWIKI-2967 issue and the http://jira.xwiki.org/jira/browse/XWIKI-2882 one, this is the proposal: Proposal: The title to support wiki syntax and the image to support absolute URLs as well as local stored images. Reason: The goal is to reuse the boxMacro in for implementing RssMacro, Warning and Error macros. The most complex of them being the RssMacro. So, a RSS feed should be rendered as follows: --------------------------------------- optional image (provided as an URL to an image stored outside the wiki, anywhere in the web) title (which can be a static text or a link to a web location containing the full news article) body - which consists of several news articles, each article being structured as follows: ................................................. title (link or static text, the same situation as above) optional body (plain text) ................................................. ----------------------------------------- Basically, the Wiki 2.0 RssMacro should behave like the old Radeox RssMacro. Now, for the RssMacro I was planning to use a "big" box (rendendered using the improved BoxMacro) which would take care of the title and the image of the RSS feed and which would contain nested "small" boxes for each news article. Also, i was planning of offering the same CSS-related features as the old Radeox RssMacro. (see http://code.xwiki.org/xwiki/bin/view/Macros/RssMacro for details) for which adding an optional cssClass parameter to the BoxMacroParameters is required. So I look forward to knowing what you think about this. Tnx. PS: all I posted here was suggested in a skype discussion with Vincent and Thomas: ................................................................................... [15:34:31] Dan Miron: well, the title is not an ordinary text it's an anchor to a web location [15:34:31] Vincent Massol: but on the general principle, do you agree about a single box macro? [15:34:48] Dan Miron: +1 for me [15:34:50] Vincent Massol: I don't understand the use case [15:34:52] … can you give one? [15:35:04] … I've never seen a title be a url [15:35:24] Dan Miron: well, when displaying the contents of a Rss feed [15:35:43] … each title is a link to the site which contains that specific article [15:36:15] Vincent Massol: you want one box per post? [15:36:24] … currentl all posts are in a single box [15:36:34] Thomas Mortagne: dan it's not the title of the box you want ? [15:36:56] … I did not understood that [15:37:23] Vincent Massol: IMO it's one box [15:37:31] Thomas Mortagne: yes [15:37:32] Vincent Massol: and iside the box macro you can put whatever wiki syntax you want [15:37:40] … including links [15:37:39] Thomas Mortagne: the macro is an entire feed [15:37:55] Dan Miron: well, i need a big box for the hole rss content which holds several other "small" boxes for each article [15:38:16] Vincent Massol: oh you want to nest box macros [15:38:19] Thomas Mortagne: theses small bowex are not macros [15:38:27] Vincent Massol: it could be thomas [15:38:36] Thomas Mortagne: well [15:38:57] Dan Miron: i was planing to use for both the big and the small boxes the same messageboxMacro i was going to create [15:38:59] Thomas Mortagne: I don't like very much that a macro generate other macro if it's not really needed [15:39:25] Vincent Massol: but if he wants to have a style for the boxes inside he'll need that I think [15:39:26] Thomas Mortagne: but meybe it make sense here [15:39:43] Vincent Massol: or he'll have to reinvent the box macro [15:40:10] Thomas Mortagne: this means the boxmacro need to support to be in a boxmacro [15:40:26] Vincent Massol: that's supported by the rendering engine [15:40:35] Thomas Mortagne: currently it's not the case as the big and small box will have the same color for example [15:40:44] … it needs some css [15:40:45] Vincent Massol: but the box macro will need to support this [15:40:49] … yes [15:40:55] Thomas Mortagne: but on pure rendering side yes it's supported [15:41:59] … so yes use nested macro boxes is a good idea here Dan ;) [15:42:26] Vincent Massol: now re the links I'm not sure yet [15:42:37] … there are different ways of doing that I guess [15:43:29] … one idea (brainstorming): we could allow inline wiki syntax to be used the title parameter maybe [15:44:14] Dan Miron: yes, it could be a way [15:44:17] Thomas Mortagne: I like that yes [15:46:45] Vincent Massol: hmm I wonder if this is something we'd want for all macros [15:47:09] … not sure [15:47:17] Thomas Mortagne: at wors we can add a isTitleWiki [15:47:19] Vincent Massol: even for this use case I'm stil not fully sure [15:47:51] … it sounds good but I wonder if we'd get side effects [15:48:09] … actually we wan't do that in a generic way for all macros [15:48:20] … since it's not going to generate text [15:48:25] … but Blocks [15:48:32] … so the macro needs to handle that [15:48:50] … s/Wan't/can't/ [15:49:33] … ok I think I'm +1 for making the image and title params allow inline wiki syntax here for this macro [15:49:45] … (it's a good experiment, we'll see how it goes) [15:49:49] … wdyt? [15:49:53] Thomas Mortagne: +1 [15:50:03] Jean-Vincent Drean: +1 [15:50:45] Thomas Mortagne: by the way Dan, Vincent already created http://jira.xwiki.org/jira/browse/XWIKI-2967 (on which you are assigned) [15:51:01] Vincent Massol: since our wiki syntax is clean there's little chance a normal title will not be rendered as the user thinks [15:52:11] Dan Miron: +1 [15:53:03] Vincent Massol: dan: I think you can close http://jira.xwiki.org/jira/browse/XWIKI-3025 as duplicate [15:54:16] Dan Miron: so we drop the idea of creating a new messaboxMacro and we focus on using the existing boxMacro? [15:55:09] Vincent Massol: yep [15:55:32] … and at the same time if you could implement info/message/error macros that would be great [15:55:41] … (there are already jira issues assigned to you for those I believe) [15:56:54] Dan Miron: in this case, could we enhance the boxmacro a little bit? [15:56:58] … for example [15:57:08] … the ability to specify custom css sheets [15:57:18] Vincent Massol: it's already supported [15:57:32] … using the (% %) notation [15:57:36] … isn't it? [15:58:54] … (% class="whatever" %){{box...}} [15:59:09] Thomas Mortagne: boxmacro alreadu support custom for the box it sould be enought [15:59:39] Dan Miron: the only way i knew for specifying a css class is inheriting the AbstractBoxMacro and overriding the getClassProperty() method [15:59:44] Thomas Mortagne: then you can use .rssbox a { } isn't it ? [16:00:42] … (for the link of rss box) [16:00:50] … an same for other content [16:01:13] … (it's maybe not the better way i'm not a css expert) [16:01:36] Vincent Massol: thomas: that's not good enough [16:01:43] … since there can be other a inside other boxes [16:02:01] … but using a FormatBlock can be used to create a new class as I mentioned above [16:02:07] Thomas Mortagne: then bow can define specific class for title and such [16:02:31] … and then you use .rssbox .box_titlea { } [16:02:57] … bow = box macro [16:04:14] Vincent Massol: not sure we support params for block macros [16:04:16] … checking... [16:04:19] … but we should [16:04:40] Thomas Mortagne: we support in Block but maybe XHTMLRender does not [16:04:49] Vincent Massol: wikimodel [16:05:56] Thomas Mortagne: ok I was speaking about parameters blocks in the macro [16:06:17] Vincent Massol: inside the macro is ok since it's inline [16:06:17] Thomas Mortagne: I don't think the Xiki parser support (%%) parameters for macro [16:06:22] Vincent Massol: and we support inline params [16:06:25] … for everything [16:06:47] … note that they'll be applied to a span surrounding the element [16:07:02] Thomas Mortagne: boxmacro content is not inline [16:07:10] … you could have table intable etc. [16:08:24] Vincent Massol: ok I've checked and I don't think it's implemented [16:08:33] … we have it for all other block elements [16:08:41] … but it doesn't seem to be there for macros [16:09:02] Thomas Mortagne: as macro as parameter I guess we did not thing of supporting generic parameters [16:09:29] Vincent Massol: it could be added easily though [16:09:37] Dan Miron: if you mean specifying a css class via block parameters, it's not working, i tried that, but it gets overriden [16:11:06] Vincent Massol: actually it should even maybe fail [16:11:17] … I don't have the time to work on this right now unfortunately [16:11:56] … maybe for now you could have an optional "cssClass" parameter? [16:12:24] … and when thomas or me implement params for block macros we could refactor it [16:13:09] Dan Miron: yes, that's what i was thinking about from the beggining [16:13:37] Vincent Massol: it would be only temporary ...................................................................................

16 years, 8 months

5
8
0 0

[xwiki-devs] [VOTE][UI] WYSIWYG Table dialog

by Jean-Vincent Drean

Hi, I've made a mockup for the table dialog in the WYSIWYG editor : http://incubator.myxwiki.org/xwiki/bin/download/Mockups/WebHome/TableDialog… I don't think there's a lot of room for debate with this one but I'd like to make sure we all agree. I'm sure the label for table header checkbox could be improved, any proposal ? Here's my +1. JV.

16 years, 8 months

5
4
0 0

[xwiki-devs] [PROPOSAL] Summary of improvements/bugfixes needed on list syntax

by Thomas Mortagne

Hi xwikiers, During the process of doing a 1.0 to 2.0 syntax converter I found some bugs on XWiki 2.0 lists syntax/parser. Let's list them: a) The parser repeat list parameters on each sub list. See http://jira.xwiki.org/jira/browse/XWIKI-3067 for details. b) any parameter on a sub list break the list c) IMO we should support mixed list syntax (see http://markmail.org/message/a3bzyzxk4yxcwb7x), like in 1. item 1 ** item 2 (% style="list-style-type: lower-alpha" %) *** subitem 2.1 *** subitem 2.2 ** item 3 1. item 4 d) we should support adding any parameter on list item. We dont have any syntax for that. For all this I propose the following: 1) A sub list inherits from its parent 1.a) Stop repeating parameters in parser 1.b) A sub list can add new parameters 1.c) A sub list can override a parameter 2) Add support for mixed list syntax. This is about "1." and "*", the mixing of different "*" style is already covered by 1) 1.first level item ** second level item ** second level item 1. first level item 2.a) Remove the 1*. syntax support 3) Add support for list item (LI) parameters. 3.a) We will need a syntax for it. For now I propose: if this is not the first item list or if there is two parameter token the second is for the list item. This means you will need to explicitly add a empty parameters token when you want to add parameters on an the item list. (%%) (% param=value %) * first item (% param2=value %) * second item 1) +1 2) +1 because it's easier for user IMO and a lot more simple for parser than having a specific syntax for mixing syntax like with "1*.". Plus I voted for 1) and I don't like particular cases. 2.a) +1 for cleaner parser and syntax 3) +1, we need it since we generally allow custom parameters everywhere Thanks, -- Thomas Mortagne

16 years, 8 months

2
1
0 0

Re: [xwiki-devs] [VOTE] Support multilines headers (SUMMARY)

by Thomas Mortagne

Three +1, two 0 and no -1 It will be part of 1.7.1. See http://jira.xwiki.org/jira/browse/XWIKI-3066 On Mon, Dec 29, 2008 at 3:30 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: > Hi everyone > > Currently the XWiki 2.0 parser does not support multilines headers, > meaning that it consider new line as end of header: > > = Heading > 1 = > > give "<h1>Heading</h1><p>1 =</p>" > > I propose to have the same things than paragraphs: need two > consecutive new lines (or the =* syntax of course) to be end of > header. > > = Heading > 1 = > = Heading > > 2 = > > would give "<h1>Heading<br/>1</h1><h1>Heading</h1><p>2 =</p>" > > Here is my +1 > > Thanks, > -- > Thomas Mortagne > -- Thomas Mortagne

16 years, 8 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r15058 - in sandbox/xwiki-core-rest/src/main/java/org/xwiki/rest: . internal

by Vincent Massol

On Jan 5, 2009, at 1:00 PM, fmancinelli (SVN) wrote: > Author: fmancinelli > Date: 2009-01-05 13:00:42 +0100 (Mon, 05 Jan 2009) > New Revision: 15058 > > Added: > sandbox/xwiki-core-rest/src/main/java/org/xwiki/rest/internal/ > sandbox/xwiki-core-rest/src/main/java/org/xwiki/rest/internal/ > PageRepresenter_TEXT_PLAIN.java > sandbox/xwiki-core-rest/src/main/java/org/xwiki/rest/internal/ > PageRepresenter_TEXT_XML.java I don't think this follows the Java coding conventions for Java class Names... IMO would be better named: PlainTextPagePresenter XMLTextPagePresenter -Vincent

16 years, 8 months

2
2
0 0

[xwiki-devs] [Proposal] WYSIWYG roadmap

by Jean-Vincent Drean

Hi devs, As stated in a previous thread we need a roadmap for the implementation of the final WYSIWYG specifications. This roadmap is also about making the WYSIWYG use a 3rd party framework and re-usable components. Here's a proposal : - Until december 17 all the persons working on the WYSIWYG continue fixing bugs. (Marius, Anca, JV) - December 23 : -- First version of the "wiki explorer" [1] based on smartGWT, allow to browse wikis, spaces and pages. See if it is a valid option with the link plugin as a real world example (Marius). -- Wysiwyg wizard, allow to chain dialogs and to navigate between them. Use of this wizard in the image plugin with 3 dialogs : current image browser, upload file dialog, upload in progress dialog (Anca). -- Final version of the Table UI (JV). - January 9 : -- WIP on the "wiki explorer". Allow to add spaces, add pages, browse pages attachments (Marius). -- Final version of the Link UI (Anca). -- Verbatim and quote features implemented (JV). - January 16 : -- Final version of the "wiki explorer" : allow to rename pages/spaces, to change pages parent with drag and drop. Replacement of the YUI tree by the GWT one in XE (Marius). -- Final version of the Image UI (Anca). -- Definition list feature implemented (JV). - January 23 -- First version of the Macro plugin (Anca). -- Alignment, color [2], font family [2], font size [2], custom parameters features implemented (Marius). - January 30 -- Import plugin (Marius). -- WIP on the Macro plugin, hopefully a final version (Anca). [1] Components like "wiki explorer", "color picker", "file uploader" must be usable outside of the WYSIWYG. [2] We need to vote for the inclusion of those features. JV.

16 years, 8 months

3
3
0 0

[xwiki-devs] [VOTE] Tab key behavior in the new WYSIWYG editor

by Marius Dumitru Florea

Hi devs, We have to decide upon the proper behavior of the Tab key in the new WYSIWYG editor. Open Office has the following behavior: A) If the caret is inside a table cell then jump to the next one (or previous one with Shift). B) If the caret is at the beginning of a list item then indent that item (or outdent with Shift). By indent I mean make it a subitem of the previous list item. C) Otherwise insert a Tab. The Tab doesn't always have the same width; it depends on the top ruler and on the caret position. Shift+Tab is ignored. I'm +1 for A) and B) Regarding C), it's difficult to have the same behavior. What we can do is: C1) Insert spaces (say 4); we would have to use non-breaking spaces of course. C2) Insert just one (breaking) space to discourage users from using the tab key to layout text. I'm +0 for C1) and +0.5 for C2). I need your vote asap. Thanks, Marius

16 years, 8 months

7
9
0 0

Re: [xwiki-devs] [xwiki-notifications] r14987 - sandbox/xwiki-core-rest/src/main/java/org/xwiki/rest

by Sergiu Dumitriu

fmancinelli (SVN) wrote: > Author: fmancinelli > Date: 2008-12-31 11:06:24 +0100 (Wed, 31 Dec 2008) > New Revision: 14987 > > Modified: > sandbox/xwiki-core-rest/src/main/java/org/xwiki/rest/PageResource.java > sandbox/xwiki-core-rest/src/main/java/org/xwiki/rest/PagesResource.java > sandbox/xwiki-core-rest/src/main/java/org/xwiki/rest/SpacesResource.java > Log: > Added proper error handling and status code setting in response headers. > > Modified: sandbox/xwiki-core-rest/src/main/java/org/xwiki/rest/PageResource.java > =================================================================== > + /* Represent */ > + if (variant.getMediaType().equals(MediaType.TEXT_XML)) { > + return new StringRepresentation(Utils.toXml(DomainObjectFactory.createPage(getRequest(), doc)), > + MediaType.APPLICATION_XML); > + } else if (variant.getMediaType().equals(MediaType.TEXT_PLAIN)) { > + return new StringRepresentation(doc.getContent(), MediaType.TEXT_PLAIN); > + } This if-else looks bad. What will happen when we support more formats? PDF, XAR, HTML, RTF, zip, RDF... -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 8 months

3
3
0 0

[xwiki-devs] [VOTE] XWiki 2.0 syntax does not support list starting at second level or more

by Thomas Mortagne

Hi xwikiers, Currently the syntaxes ** list item and * ** list item are giving exactly the same rendering: <ul><li><ul><li>list item</li></ul></li></ul> This is expected and we have even a unit test for that but I think it's a wrong behavior. The "problem" is not really at rendering level but at wikimodel XWiki parser which send the same events for the two syntaxes: beginList beginListItem beginList beginListItem [...] endListItem endList endListItem endList I propose to change that for ** list item to render beginList beginList beginListItem [...] endListItem endList endList and <ul><ul><li>list item</li></ul></ul> and same concept for any other list level (like *** , **** , etc.). Since XDOM and XHTML support it, here is my +1. See also http://jira.xwiki.org/jira/browse/XWIKI-3057 Thanks, -- Thomas Mortagne

16 years, 8 months

3
9
0 0

[xwiki-devs] New blog on XWiki

by Vincent Massol

Just wanted to let you know I have started a new personal blog at http://massol.net which will talk a lot about XWiki (amongst other things). Hope you'll enjoy it. Thanks -Vincent http://xwiki.com http://massol.net http://xwiki.org

16 years, 8 months

3
2
0 0

[xwiki-devs] [Ideas] Some goals for 2009

by Vincent Massol

Here are some 5 ideas from what I'd like us to do in 2009... 1) Get more known * Reach 20K downloads per month (we're at 10K+ right now) * Double our mailing lists subcribers (we're at 509 on the users list and 264 on the devs list) * Double our email flow on the lists (that is probably related to the point above) (we're at 2500 mails per month roughly) * More talks about XWiki at conferences * More articles on the web about xwiki 2) Finish moving to an all-component architecture 3) Reorganize xwiki.org and establish XWiki as a place where to find components for writing content-based web applications 4) Start a bounty system and create a thriving community of XWiki extensions (apps, macros, extensions, etc) for code.xwiki.org 5) Work on better polishing what we have already and stabilize everything Note: This is not a roadmap! It's just some ideas thrown out for fun and to see what everyone's wishes are for 2009 :) What are your wishes for 2009? Thanks -Vincent http://xwiki.com http://massol.net http://xwiki.org

16 years, 8 months

4
3
0 0

Re: [xwiki-devs] [xwiki-notifications] r14997 - in sandbox/xwiki-officeimporter: . src/main/java/org/xwiki/officeimporter/html/cleaner src/main/java/org/xwiki/officeimporter/transformer src/main/java/org/xwiki/officeimporter/utils

by Sergiu Dumitriu

asiri (SVN) wrote: > Author: asiri > Date: 2009-01-01 11:43:23 +0100 (Thu, 01 Jan 2009) > New Revision: 14997 > > Modified: > sandbox/xwiki-officeimporter/pom.xml > sandbox/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/html/cleaner/OfficeImporterHTMLCleaner.java > sandbox/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/transformer/HtmlToXWikiPresentationTransformer.java > sandbox/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/transformer/HtmlToXWikiTransformer.java > sandbox/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/transformer/HtmlToXWikiTwoZeroTransformer.java > sandbox/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/transformer/OfficeToHtmlTransformer.java > sandbox/xwiki-officeimporter/src/main/java/org/xwiki/officeimporter/utils/ImporterContext.java > Log: > * Fixed compile errors > * Fixed failing test cases > > However I couldn't get rid of following two test scoped dependencies despite all my efforts : > > 2. > > <dependency> > <groupId>com.xpn.xwiki.platform</groupId> > <artifactId>xwiki-core</artifactId> > <version>${pom.version}</version> > <scope>test</scope> > </dependency> > > This is something I don't have any clue about. Removing this dependency breaks the tests with following trace : http://tinypaste.com/pre.php?id=10b99 > > I initially thought this is because DefaultDocumentAccessBridge is defined inside xwiki-core (by looking at the trace). But xwiki-redering faces the same situation but avoids this xwiki-core dependency. I wonder if the dependency on xwiki-velocity module has to do something with this. For testing, xwiki-rendering defines its own mock implementation of the document access bridge. You should look in the src/test directory of xwiki-rendering to see what it does there. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 8 months

2
1
0 0

[xwiki-devs] Listing requirements for the new XWiki Model 2.0 module

by Vincent Massol

Hi everyone, In order to design the new model module we need to list the requirements for it. Here are some I have found by reviewing existing mailing on our list: * Notions of: ** multi wiki ** wiki ** space ** document ** document metadata (language, syntax id, etc) ** document objects ** document classes ** attachment * UUIDs for Documents, Spaces, Wikis, Farms ** Ability to have multiple URIs for model objects * Nested spaces * Ability to version model objects * Ability to add metadata to model objects * Easy to use API (typed API) * Simple API to get other sub elements in model objects (for ex: ability to get documents in a given space). More complex retrieval API in the Query Manager * Authentication/Authorization relationship with model to be defined ** Should checks be done outside of the model module? ** Should we use JAAS and if so what's the relationship * Allow inheritance for document objects/classes ** objects with more than 1 class? (sergiu) * Observation: Ability to get callbacks when objects are modified/ created/removed * Ability to lock model objects to prevent modifications in some cases (when someone is already modifying them or if the wiki is in readonly mode for example) Are there any requirements I've missed? Thanks -Vincent http://xwiki.com http://massol.net http://xwiki.org

16 years, 8 months

2
3
0 0

Re: [xwiki-devs] [xwiki-notifications] r14999 - platform/web/trunk/standard/src/main/webapp/templates

by Sergiu Dumitriu

Any reason why these files were changed? If not, they should be rolled back. ludovic (SVN) wrote: > Author: ludovic > Date: 2009-01-01 11:57:53 +0100 (Thu, 01 Jan 2009) > New Revision: 14999 > > Modified: > platform/web/trunk/standard/src/main/webapp/templates/attachmentsinline.vm > platform/web/trunk/standard/src/main/webapp/templates/attachwysiwyg.vm > platform/web/trunk/standard/src/main/webapp/templates/macros.vm > platform/web/trunk/standard/src/main/webapp/templates/uploadattachwysiwyg.vm > Log: > XWIKI-3060 Adding Google calendar velocity macros to the core > > Modified: platform/web/trunk/standard/src/main/webapp/templates/attachmentsinline.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/attachmentsinline.vm 2009-01-01 10:56:59 UTC (rev 14998) > +++ platform/web/trunk/standard/src/main/webapp/templates/attachmentsinline.vm 2009-01-01 10:57:53 UTC (rev 14999) > @@ -31,7 +31,7 @@ > <div id="_attachments"> > #if($attachments.size()>0) > #foreach ($attach in $attachments) > - <div class="attachment #if($velocityCount % 2 == 0) even #else odd #end"> > + <div class="displayers #if($velocityCount % 2 == 0) even #else odd #end"> > <span class="mime">#mimetypeimg($attach.getMimeType().toLowerCase() $attach.getFilename().toLowerCase())</span> > <div class="information"> > <span class="name"><a href="$doc.getAttachmentURL("${attach.filename}", "download")" title="$msg.get("downloadthisattachment")">#packName($attach.filename)</a></span> > > Modified: platform/web/trunk/standard/src/main/webapp/templates/attachwysiwyg.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/attachwysiwyg.vm 2009-01-01 10:56:59 UTC (rev 14998) > +++ platform/web/trunk/standard/src/main/webapp/templates/attachwysiwyg.vm 2009-01-01 10:57:53 UTC (rev 14999) > @@ -9,7 +9,7 @@ > <br /><br /> > $msg.get("choosefiletoupload"): > <input type="file" name="filepath" value="" size="40" /> <br /><br /> > - <input type="submit" id="attachment" name="attachment" value="$msg.get("attachthisfile")" /> > + <input type="submit" id="displayers" name="displayers" value="$msg.get("attachthisfile")" /> > </p> > </form> > #set($counter=0) > Modified: platform/web/trunk/standard/src/main/webapp/templates/uploadattachwysiwyg.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/uploadattachwysiwyg.vm 2009-01-01 10:56:59 UTC (rev 14998) > +++ platform/web/trunk/standard/src/main/webapp/templates/uploadattachwysiwyg.vm 2009-01-01 10:57:53 UTC (rev 14999) > @@ -7,6 +7,6 @@ > $msg.get("choosefiletoupload"): > <input type="file" name="filepath" value="" size="40" /> <br /><br /> > #set($action = $doc.getURL("upload")) > - <input type="button" id="attachment" name="attachment" onclick="updateAttachName(document.forms.attach); document.forms.attach.action = '$action' ; document.forms.attach.submit();" value="$msg.get("attachthisfile")" /> > + <input type="button" id="displayers" name="displayers" onclick="updateAttachName(document.forms.attach); document.forms.attach.action = '$action' ; document.forms.attach.submit();" value="$msg.get("attachthisfile")" /> > </p> > </div> > \ No newline at end of file -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 8 months

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r15020 - in platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml: html internal/html

by Vincent Massol

Hi Asiri, You absolutely need a JIRA issue for this! Actually you would also normally need a vote since you're modifying a public API but it's probably ok.... See also the comments below. On Jan 2, 2009, at 5:07 PM, asiri (SVN) wrote: > Author: asiri > Date: 2009-01-02 17:07:40 +0100 (Fri, 02 Jan 2009) > New Revision: 15020 > > Modified: > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/ > HTMLCleaner.java > platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/internal/ > html/DefaultHTMLCleaner.java > Log: > * Introduced a clean(Reader html, Map<String, String> params) method > to the HTMLCleaner interface. > > Modified: platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/ > html/HTMLCleaner.java > =================================================================== > --- platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/ > HTMLCleaner.java 2009-01-02 15:42:50 UTC (rev 15019) > +++ platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/html/ > HTMLCleaner.java 2009-01-02 16:07:40 UTC (rev 15020) > @@ -20,12 +20,13 @@ > package org.xwiki.xml.html; > > import java.io.Reader; > +import java.util.Map; > > import org.w3c.dom.Document; > > /** > * Transforms any HTML content into valid XHTML that can be feed to > the XHTML Parser for example. > - * > + * > * @version $Id: $ > * @since 1.6M1 > */ > @@ -43,4 +44,14 @@ > * @return the cleaned HTML as a w3c DOM (this allows further > transformations if needed) > */ > Document clean(Reader originalHtmlContent); > + > + /** > + * Transforms any HTML content into valid XHTML. Additional > parameters may be passed in to fine tune the cleaning > + * process. > + * > + * @param originalHtmlContent The original html content to be > cleaned. > + * @param params Additional parameters (implementation > dependent) for cleaning. > + * @return The cleaned HTML as a w3c DOM You should use "the" and not "The". See http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle which points to http://java.sun.com/j2se/javadoc/writingdoccomments/ > > + */ > + Document clean(Reader originalHtmlContent, Map<String, String> > params); Can you rename params to cleaningParameters since this is more explicit and this is what we discussed? > > } > > Modified: platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/ > internal/html/DefaultHTMLCleaner.java > =================================================================== > --- platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/ > internal/html/DefaultHTMLCleaner.java 2009-01-02 15:42:50 UTC (rev > 15019) > +++ platform/core/trunk/xwiki-xml/src/main/java/org/xwiki/xml/ > internal/html/DefaultHTMLCleaner.java 2009-01-02 16:07:40 UTC (rev > 15020) > @@ -24,6 +24,7 @@ > import java.io.StringReader; > import java.util.ArrayList; > import java.util.List; > +import java.util.Map; > > import org.htmlcleaner.CleanerProperties; > import org.htmlcleaner.CleanerTransformations; > @@ -64,20 +65,20 @@ > this.filters = new ArrayList<CleaningFilter>(); > this.filters.add(new ListCleaningFilter()); > this.filters.add(new DocTypeCleaningFilter()); > - > + > // The clean method below is thread safe. However it seems > that DOMOutputter.output() is not > // fully thread safe since it causes the following exception > on the first time it's called > // from different threads: > - // Caused by: org.jdom.JDOMException: Reflection failed > while creating new JAXP document: > - // duplicate class definition: org/apache/xerces/jaxp/ > DocumentBuilderFactoryImpl > - // at > org.jdom.adapters.JAXPDOMAdapter.createDocument(JAXPDOMAdapter.java: > 191) > - // at > org > .jdom > .adapters.AbstractDOMAdapter.createDocument(AbstractDOMAdapter.java: > 133) > - // at > org.jdom.output.DOMOutputter.createDOMDocument(DOMOutputter.java:208) > - // at > org.jdom.output.DOMOutputter.output(DOMOutputter.java:127) > + // Caused by: org.jdom.JDOMException: Reflection failed > while creating new JAXP document: > + // duplicate class definition: org/apache/xerces/jaxp/ > DocumentBuilderFactoryImpl > + // at > org.jdom.adapters.JAXPDOMAdapter.createDocument(JAXPDOMAdapter.java: > 191) > + // at > org > .jdom > .adapters.AbstractDOMAdapter.createDocument(AbstractDOMAdapter.java: > 133) > + // at > org.jdom.output.DOMOutputter.createDOMDocument(DOMOutputter.java:208) > + // at org.jdom.output.DOMOutputter.output(DOMOutputter.java: > 127) Why did you remove the white space I had put to indent the stack trace? :) > > // Since this only happens once, we call it first here at > initialization time (since there's > // no thread contention at that time). > // Note: This email thread seems to say it's thread safe but > that's not what we see here: > - // http://osdir.com/ml/text.xml.xforms.chiba.devel/2006-09/msg00025.html > + // http://osdir.com/ml/text.xml.xforms.chiba.devel/2006-09/msg00025.html same here. > > clean(new StringReader("")); > } > > @@ -90,25 +91,30 @@ > { > org.w3c.dom.Document result; > > - // HtmlCleaner is not threadsafe. Thus we need to recreate > an instance at each run since otherwise > - // we would need to synchronize this clean() method which > would slow down the whole system by > + // HtmlCleaner is not threadsafe. Thus we need to recreate > an instance at each run since > + // otherwise Why did you break at 100 chars when we are breaking at 120? > > + // we would need to synchronize this clean() method which > would slow down the whole system > + // by > // queuing up cleaning requests. > - // See http://sourceforge.net/tracker/index.php?func=detail&aid=2139927&group_id=1… > + // See > + // http://sourceforge.net/tracker/index.php?func=detail&aid=2139927&group_id=1… > + // 903699 Same here. > > HtmlCleaner cleaner = new HtmlCleaner(); > cleaner.setTransformations(getCleaningTransformations()); > CleanerProperties cleanerProperties = cleaner.getProperties(); > cleanerProperties.setOmitUnknownTags(true); > > - // By default HTMLCleaner treats style and script tags as > CDATA. This is causing errors if we use > + // By default HTMLCleaner treats style and script tags as > CDATA. This is causing errors if > + // we use > // the best practice of using CDATA inside a script. For > example: > - // <script type="text/javascript"> > - // //<![CDATA[ > - // ... > - // // ]]> > - // </script> > + // <script type="text/javascript"> > + // //<![CDATA[ > + // ... > + // // ]]> > + // </script> > // Thus we need to turn off this feature. > cleanerProperties.setUseCdataForScriptAndStyle(false); > - > + > TagNode cleanedNode; > try { > cleanedNode = cleaner.clean(originalHtmlContent); > @@ -120,7 +126,7 @@ > > // Fix cleaned node bug > fixCleanedNodeBug(cleanedNode); > - > + > Document document = new JDomSerializer(cleanerProperties, > false).createJDom(cleanedNode); > > // Perform other cleaning operation this time using the W3C > Document interface. > @@ -139,9 +145,20 @@ > } > > /** > - * @return the cleaning transformations to perform on tags, in > addition to the base transformations done by > - * HTML Cleaner > + * {@inheritDoc} > + * <p> > + * {@link DefaultHTMLCleaner} does not allow fine-tuning of > html cleaning via parameters. > + * </p> > */ > + public org.w3c.dom.Document clean(Reader originalHtmlContent, > Map<String, String> params) > + { > + return clean(originalHtmlContent); the params don't seem to be used? > > + } > + > + /** > + * @return the cleaning transformations to perform on tags, in > addition to the base transformations done by HTML > + * Cleaner > + */ > private CleanerTransformations getCleaningTransformations() > { > CleanerTransformations transformations = new > CleanerTransformations(); > @@ -174,9 +191,9 @@ > } > > /** > - * There's a known limitation (bug?) in HTML Cleaner where if > there's a XML declaration specified > - * it'll be copied as the first element of the body. Thus > remove it if it's there. > - * See https://sourceforge.net/forum/message.php?msg_id=4657800 > + * There's a known limitation (bug?) in HTML Cleaner where if > there's a XML declaration specified it'll be copied as > + * the first element of the body. Thus remove it if it's there. > See > + * https://sourceforge.net/forum/message.php?msg_id=4657800 > * > * @param cleanedNode the cleaned node (ie after the HTML > cleaning) > */ Thanks -Vincent http://xwiki.com http://massol.net http://xwiki.org

16 years, 8 months

2
4
0 0

Re: [xwiki-devs] [Issue] Commented: (XAOFFICE-1) Develop the initial feature set for office-importer plugin.

by Asiri Rathnayake

Hi vincent, Vincent Massol commented on XAOFFICE-1: > --------------------------------------- > > 31-12-2008 Review: > * Invalid dep: Log4j Fixed. * components must be in an internal package, see > http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HXWikisp… Fixed. > * Abstract classes must have Abstract in their name as a prefix. > OfficeImporterHTMLCleaner is not following this. See > http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle Fixed * OfficeImporterHTMLCleaner should be named AbstractOfficeHTMLCleaner Fixed. * I don't think that the default/strict/moderate thing should be implemented > as components. IMO there should be a singme OpenOfficeHTMLCleaner and a > single MicrosoftOfficeHTMLCleaner and the interface signature should be > something like: clean(Reader, CleaningStrategy) where CleaningStrategy is an > enum of STRICT, MODERATE or LENIENT. The reason is that it's a property of > the cleaning IMO and not a different type of cleaner. Fixed. * The org.xwiki.officeimporter.html.cleaner package should be instead > org.xwiki.officeimporter.cleaner. No need for "html" since we don't have > any other cleaner. > * org.xwiki.officeimporter.html.filter should renamed to > org.xwiki.officeimporter.cleaner.filter Fixed. * Don't use public static final String in an interface since String are > always public static final in interfaces! Fixed. * Fix javadoc errors Partially Fixed (working on it) * I have no idea why we need a special cleaner WysiwygDefaultHTMLCleaner and > the javadoc doesn't help to understand the reason. Need to improve the javadoc comments. * OfficeImporter.import takes a byte[] array. I don't think this is a good > idea since you'd also need to specify the encoding. Better use a Reader. As I explained, office documents are binary files. So this has to be a byte[]. * OfficeImporterVelocityContextInitializer should be in the internal package Fixed. * "private static final String[] presentationFormatExtensions" private > static final strings should be in uppercase. Also this would be better as an > enum. Fixed. * I don't understand the notion of Transformer. What's the difference > between Transformer and Importer? Transformers are now inside internal package and they are not components anymore. Importer is composed of DocumentTransformers. * components that wants logging must extend AbstractLogEnabled Fixed. * filters need to be reorganized. There are too many notions mixed together: > strict/lenient/moderate vs ImageFilter/Etc I'm not sure how to do this. Unlike other filters, ImageFilter needs to have access to the original XWikiDocument (via DocumentAccessBridge) other than the w3c DOM. This is because when cleaning image links, the src attribute need to be replaced by the corresponding attachment url. This is why I introduced XWikiHTMLCleaner which takes in the OfficeImporterContext in addition to the w3c dom. * there shouldn't be a utils package Fixed. * role hints should be simpler and lowercase Fixed. * there are no tests! Few added. More unit/integration tests will be added. > * there are test resources but they're not used! > Fixed (Removed) Thanks. - Asiri

16 years, 8 months

2
4
0 0

[xwiki-devs] [VOTE] Support mixed syntaxes for lists

by Thomas Mortagne

Hi xwikiers, Currently XWiki 2.0 only support the same way of mixing lists than XWiki 1.0: --------------------- 1. item 1 1*. item 2 1*. item 3 1. item 4 --------------------- This only support two syntaxes : the default ordered numbers and the default point list. Plus It does not sounds very natural to me. I propose to be able to really mix list syntaxes without any particular syntax: ------------------------------ 1. item 1 ** item 2 (% style="list-style-type: lower-alpha" %) *** subitem 2.1 *** subitem 2.2 ** item 3 1. item 4 --------------------------- Currently this generate 5 different lists: <ol> <li>item 1</li> </ol> <ul> <li> <ul> <li>item 2</li> <li>item 3</li> </ul> </li> </ul> <ul style="list-style-type: lower-alpha"> <li> <ul> <li> <ul> <li>subitem 2.1</li> <li>subitem 2.2</li> </ul> </li> </ul> </li> </ul> <ul> <li> <ul> <li>item 3</li> </ul> </li> </ul> <ol> <li>item 4</li> </ol> Also another problem is also that this will generate a very different XWiki syntax that the original one. I propose to generate only one big list giving something like: <ol> <li> item 1 <ul> <li> item 2 <ul style="list-style-type: lower-alpha"> <li>subitem 2.1</li> <li>subitem 2.2</li> </ul> </li> <li> item 3</li> </ul> </li> <li> item 4</li> </ol> Here is my +1 Thanks, -- Thomas Mortagne

16 years, 8 months

3
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r14932 - platform/core/trunk/xwiki-macros/xwiki-macro-groovy

by Sergiu Dumitriu

tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-12-27 17:18:10 +0100 (Sat, 27 Dec 2008) > New Revision: 14932 > > Modified: > platform/core/trunk/xwiki-macros/xwiki-macro-groovy/pom.xml > Log: > XWIKI-3038: Move Groovy dependency to 1.6 RC1 > > Modified: platform/core/trunk/xwiki-macros/xwiki-macro-groovy/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-macros/xwiki-macro-groovy/pom.xml 2008-12-27 16:17:57 UTC (rev 14931) > +++ platform/core/trunk/xwiki-macros/xwiki-macro-groovy/pom.xml 2008-12-27 16:18:10 UTC (rev 14932) > @@ -41,7 +41,7 @@ > <dependency> > <groupId>com.sun.script</groupId> > <artifactId>groovy-engine</artifactId> > - <version>1.6-beta-2-xwiki</version> > + <version>1.6-RC-1-xwiki</version> Why are we using a custom build of Groovy? -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 8 months

2
1
0 0

[xwiki-devs] Include 2 patches in 1.7.1

by Ludovic Dubost

Hi, I would like to vote to include the 2 following patches on 1.7.1. They would allow Curriki to run on the standard 1.7.1 core (except for Lucene which has other changes). http://jira.xwiki.org/jira/browse/XWIKI-3054 Support configurable velocity macro files in xwiki.cfg http://jira.xwiki.org/jira/browse/XWIKI-3054 Fix a bug which prevents to use "order by" in queries on DBListClass Both patches have been used successfully on a custom 1.5.2 based core in Curriki Here is my +1 Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

16 years, 8 months

5
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs