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

[xwiki-devs] Controlling the size of the editor for editing textarea properties?

by Vincent Massol

Hi guys, Is it possible to have a textarea property for which you have a wysiwyg editor that doesn't take all the horizontal space. For ex if the textarea property says 20 chars, is it possible to have an editor that is 20 chars wide? Same question with the wiki editor. Thanks -Vincent

16 years

2
2
0 0

[xwiki-devs] Orphaned Wiki Macro Classes

by Vincent Massol

Hi Asiri, You should put a parent when you create wiki macro classes since they're now orphaned. We should do this for RC2. Thanks -Vincent

16 years

2
4
0 0

[xwiki-devs] [VOTE] Release 2.0RC1 on the 10th of Sep (tomorrow)

by Vincent Massol

Hi, I'd also like to propose to release RC1 tomorrow (and note have colibri as the default skin in it), and continue fixing colibri in RC1, and release RC2 as planned on the 17th of sep, hoping that there's no RC3. This will allow people to start testing RC1 since it's an RC for everything except the new skin. Here's my +1 Thanks -Vincent

16 years

7
12
0 0

[xwiki-devs] [UX] Devs - UXdesigners collaboration point

by Thibaut DEVERAUX

Hi devs, I get some anxiety about two facts I noticed. I'm wondering if I should. Maybe you can give me advices ? Points are : - UX design can be faster than dev. Especially when UX design is made upon rapid expertise according to the UX designer experience. - Open source devs sometime dev for them own fun. People want UX advice, which can also easily transform in a list of a bunch of things to do. Well, even when UX goes faster than dev, a brainstorming period let ideas mature, fork, merge, jump to new ones... So it is not important if the UX specifications is not implemented immediatly as it mature among analysis & dev iterations. UX designers may have to explore various dimensions too detect the major points. This process can reveal also bunches of minor points that could be capitalised for later. What amaze me is when a UX analysis create to too many potential dev work, I'm always afraid of the risk of stressing and discouraging devs that code on them free time. This is quite the same as making user tests, or a vote, so this already exists. The result is a list of points to work on, with intrinsic relative importance evaluation. This could be a good point for classifing things, yet I'm amways affraid that some devs can feel less fun if this look like a pile of things to do (beacause I may feel it, that's why). Also when this is user advices, the dev is making is own classification by analysing the comments. So it is his classification. I know that, for my part, this sort of thing can be key in my motication. The fact may be that when asking an expert advice this is a bit different. The advice come directly from one person so if the dev consider the UX designer as an authority advice this may not be anymore his own classification. An approach that may be interesting could be that if the UX designer act as a consultant. I mean he transfert his knowledge to the dev by giving the details on how he makes his analysis and detect UX implications. So that the dev can take himself the decision of classifing the by mixing UX and Dev priorities according to the importance he gives to each single point. This means the dev has a will in entering the UX process details and gaining skills. Also this could be interesting for the UX designer because it let him share the brainstorming with devs and other UX designers before the decision is taken by project manager, community or the main dev. Iterations is always good in the UX design process. So this an approach. There may be others ones better, or adaptated among each cases. I would love to have feedbacks on this points, to be able to understand how people are felling about this. Thanks ! Thibaut.

16 years

1
0
0 0

[xwiki-devs] [VOTE] New title behavior handling for the 2.0 release

by Vincent Massol

Hi, Let's vote on how to handle the title behavior for the 2.0 final release so that we're all on the same page. After talking to several people here's what I propose: 1) We remove the top level H1 only if the title compat flag is on and the title H1 is the same as the top level H1 2) The compat flag is off by default in our distributions 3) We modify the Toucan and Albatross skins to display the title (same as Colibri) 4) We modify the Default XE XAR to have titles for all its pages (and remove the header 1 in page content) This should cover both user upgrades and new behavior. Note that user custom skin will still work in most cases since they're not normally touching the contentview.vm file. Here's my +1 Thanks -Vincent

16 years

7
18
0 0

[xwiki-devs] [VOTE] Let's have a XWiki Syntax 2.1 version for the future + freeze XWiki Syntax 2.0

by Vincent Massol

Hi, Even though we're relasing XE 2.0 final along with a finalized XWiki Syntax 2.0 there are still several improvements we'd like to bring to the syntax. To name a few: * Fix 2 passes done for wiki context inside links which requires escaping some chars in link labels. * Add support for comments - http://jira.xwiki.org/jira/browse/XWIKI-4027 * Mixed list syntax - http://jira.xwiki.org/jira/browse/XWIKI-3133 * Add format parameters support for macros - http://jira.xwiki.org/jira/browse/XWIKI-3237 * Add support for list item parameters in XWiki syntax - http://jira.xwiki.org/jira/browse/XWIKI-3132 * Complete advanced table syntax for XWiki 2.0 rendering - http://jira.xwiki.org/jira/browse/XWIKI-2658 (still to be decided) * XWiki Syntax 2.0 should ignore spaces before any "standalone block" syntax - http://jira.xwiki.org/jira/browse/XWIKI-3214 * Add support for relative paths in Link and Image XWiki Syntax 2.0 - http://jira.xwiki.org/jira/browse/XWIKI-3611 * ... and a lot more... Any of these changes are potentially breaking for existing content. For example if some current content uses the same syntax as the one we'll use for comments it's going to break the content. Thus the solution Thomas and I are proposing is to evolve the syntax by creating a XWiki Syntax 2.1 version: * Start working on it in XE 2.1 timeframe * Define precisely the changes we want to bring for this evolution * Let's name it something like "XWiki 2.1 (dev)" to show that it's not final and rename it to "XWiki 2.1" when it's finished and frozen For end users they'll be able to switch from any current syntax to the 2.1 syntax very easily simply by converting page by page (or by running a converter to convert a whole wiki). The conversion should be perfect. Let's this vote be also about freezing the XWiki 2.0 syntax with the 2.0 final release. This will mean we're forbidden to modify it and all changes should go in the XWiki Syntax 2.1. Here's my +1 to have a XWiki Syntax 2.1 in some not too far future and +1 to freeze the current 2.0 syntax with the XE 2.0 release. Thanks -Vincent

16 years

5
4
0 0

[xwiki-devs] [Proposal] Change of title behavior proposal

by Vincent Massol

Hi everyone, With Colibri we've started to display the doc title as the document's rendered title. This is a big change that not only affects Colibri but in general the way people write documents. Here's what I suggest: 1) Display doc titles with <div> 2) Display document content headers using <h1>-<h6> 3) Display doc titles with a larger font size than h1 (or h1 with a smaller font size) 4) Force cursor to be in the title field when editing a new document. Force cursor in the content field when editing an existing document. This is to make it easy using the keyboard only to enter doc titles (since it's currently dead easy, we need something close in easiness) 5) Modify all our existing skins: Toucan, Albatross, Finch and Dodo so that they use they display the doc title, similarly to Colibri 6) Have a title compatibility flag in xwiki.cfg. When active, use a Javascript to do this: if there's no title specified for a page and if the first content is a H1 then use it as the page's title. We need at least 1), 3), 6) to be able to release the Colibri skin for 2.0 final IMO. WDYT? Thanks -Vincent

16 years

9
28
0 0

Re: [xwiki-devs] [xwiki-notifications] r23373 - in platform/core/trunk/xwiki-rendering: xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xwiki xwiki-rendering-tests/src/test/resources/link

by Vincent Massol

On Sep 9, 2009, at 1:00 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-09 13:00:18 +0200 (Wed, 09 Sep 2009) > New Revision: 23373 > > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/xwiki/ > XWikiSyntaxChainingRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ > resources/link/links6.test > Log: > XWIKI-4294: xhtml renderer wrong escape reference in the startlink > html comment > XWIKI-4194: Inconsistent behavior when escaping "-" symbols > * improve a little escaping in links labels (less useless escaping) > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/ > src/main/java/org/xwiki/rendering/internal/renderer/xwiki/ > XWikiSyntaxChainingRenderer.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/xwiki/ > XWikiSyntaxChainingRenderer.java 2009-09-09 10:53:09 UTC (rev 23372) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/xwiki/ > XWikiSyntaxChainingRenderer.java 2009-09-09 11:00:18 UTC (rev 23373) > @@ -760,13 +760,6 @@ > @Override > public void onImage(Image image, boolean isFreeStandingURI, > Map<String, String> parameters) > { > - // Flush test content before the link. > - // TODO: improve the block state renderer to be able to > make the difference between what is bufferized > - // before the link and what in the label link > - getXWikiPrinter().setBeforeLink(true); > - getXWikiPrinter().flush(); > - getXWikiPrinter().setBeforeLink(false); > - > Link link = new Link(); > link.setReference("image:" + > getImageRenderer().renderImage(image)); > link.setType(LinkType.URI); > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/ > src/test/resources/link/links6.test > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/resources/link/links6.test 2009-09-09 10:53:09 UTC (rev 23372) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/resources/link/links6.test 2009-09-09 11:00:18 UTC (rev 23373) > @@ -55,7 +55,7 @@ > [[Label>Reference]] > [[Reference|Param=Value]] > [[[[no link]]>>Reference]] > -[[~[~[image:whatever>>Reference]] > +[[~~[~~[image:whatever>>Reference]] ah less great... Why did you have to change it back from the previous commit? Thanks -Vincent

16 years

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r23372 - in platform/core/trunk/xwiki-rendering: xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/printer xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xwiki xwik

by Thomas Mortagne

On Wed, Sep 9, 2009 at 13:05, Vincent Massol<vincent(a)massol.net> wrote: > > On Sep 9, 2009, at 12:53 PM, tmortagne (SVN) wrote: > >> Author: tmortagne >> Date: 2009-09-09 12:53:09 +0200 (Wed, 09 Sep 2009) >> New Revision: 23372 >> >> Modified: >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >> java/org/xwiki/rendering/internal/renderer/printer/ >> XWikiSyntaxEscapeWikiPrinter.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >> java/org/xwiki/rendering/internal/renderer/xwiki/ >> XWikiSyntaxChainingRenderer.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >> java/org/xwiki/rendering/internal/renderer/xwiki/ >> XWikiSyntaxEscapeHandler.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ >> java/org/xwiki/rendering/internal/renderer/xwiki/ >> XWikiSyntaxLinkRenderer.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki- >> rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/ >> internal/parser/wikimodel/xhtml/XWikiCommentHandler.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ >> java/org/xwiki/rendering/SimpleRenderingTests.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ >> resources/link/links14.test >> platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ >> resources/link/links6.test >> Log: >> XWIKI-4294: xhtml renderer wrong escape reference in the startlink >> html comment >> XWIKI-4194: Inconsistent behavior when escaping "-" symbols >> * improve a little escaping in links labels (less useless escaping) >> > > [snip] > >> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/ >> src/test/java/org/xwiki/rendering/SimpleRenderingTests.java >> =================================================================== >> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ >> test/java/org/xwiki/rendering/SimpleRenderingTests.java 2009-09-09 >> 10:43:50 UTC (rev 23371) >> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ >> test/java/org/xwiki/rendering/SimpleRenderingTests.java 2009-09-09 >> 10:53:09 UTC (rev 23372) >> @@ -204,6 +204,26 @@ >> suite.addTestsFromResource("misc/misc7", false); >> suite.addTestsFromResource("encoding/encoding1", false); >> >> + suite.addTestsFromResource("escape/escape1", false); >> + suite.addTestsFromResource("escape/escape2", false); >> + suite.addTestsFromResource("escape/escape3", false); >> + suite.addTestsFromResource("escape/escape4", false); >> + suite.addTestsFromResource("escape/escape5", false); >> + suite.addTestsFromResource("escape/escape6", false); >> + suite.addTestsFromResource("escape/escape7", false); >> + suite.addTestsFromResource("escape/escape8", false); >> + suite.addTestsFromResource("escape/escape9", false); >> + suite.addTestsFromResource("escape/escape10", false); >> + suite.addTestsFromResource("escape/escape11", false); >> + suite.addTestsFromResource("escape/escape12", false); >> + suite.addTestsFromResource("escape/escape13", false); >> + suite.addTestsFromResource("escape/escape14", false); >> + suite.addTestsFromResource("escape/escape15", false); >> + suite.addTestsFromResource("escape/escape16", false); >> + suite.addTestsFromResource("escape/escape17", false); >> + suite.addTestsFromResource("escape/escape18", false); >> + suite.addTestsFromResource("escape/escape19", false); > > We were missing all those tests? Sorry, debugging leftover. > >> return new ComponentManagerTestSetup(suite); >> } >> } >> >> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/ >> src/test/resources/link/links14.test >> =================================================================== >> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ >> test/resources/link/links14.test 2009-09-09 10:43:50 UTC (rev 23371) >> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ >> test/resources/link/links14.test 2009-09-09 10:53:09 UTC (rev 23372) >> @@ -24,7 +24,7 @@ >> .#----------------------------------------------------- >> .expect|xwiki/2.0 >> .#----------------------------------------------------- >> -[[[[image:attach.png~|~|height="100" width="100"~]~]>>http://xwiki.org >> ||param="value"]] >> +[[[[image:attach.png||height="100" width="100"]]>>http://xwiki.org|| >> param="value"]] > > great! > >> .#----------------------------------------------------- >> .input|xhtml/1.0 >> .#----------------------------------------------------- >> >> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/ >> src/test/resources/link/links6.test >> =================================================================== >> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ >> test/resources/link/links6.test 2009-09-09 10:43:50 UTC (rev 23371) >> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ >> test/resources/link/links6.test 2009-09-09 10:53:09 UTC (rev 23372) >> @@ -55,7 +55,7 @@ >> [[Label>Reference]] >> [[Reference|Param=Value]] >> [[[[no link]]>>Reference]] >> -[[~~[~~[image:whatever>>Reference]] >> +[[~[~[image:whatever>>Reference]] > > great too! > > Thanks > -Vincent > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Thomas Mortagne

16 years

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r23372 - in platform/core/trunk/xwiki-rendering: xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/printer xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xwiki xwiki-rendering-parsers/xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/internal/parser/wikimodel/xhtml xwiki-rendering-tests/src/test/java/org/xwiki/rendering xwiki-rendering-tests/src/test/resources/link

by Vincent Massol

On Sep 9, 2009, at 12:53 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-09 12:53:09 +0200 (Wed, 09 Sep 2009) > New Revision: 23372 > > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/printer/ > XWikiSyntaxEscapeWikiPrinter.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/xwiki/ > XWikiSyntaxChainingRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/xwiki/ > XWikiSyntaxEscapeHandler.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/renderer/xwiki/ > XWikiSyntaxLinkRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki- > rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/ > internal/parser/wikimodel/xhtml/XWikiCommentHandler.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ > java/org/xwiki/rendering/SimpleRenderingTests.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ > resources/link/links14.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/ > resources/link/links6.test > Log: > XWIKI-4294: xhtml renderer wrong escape reference in the startlink > html comment > XWIKI-4194: Inconsistent behavior when escaping "-" symbols > * improve a little escaping in links labels (less useless escaping) > [snip] > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/ > src/test/java/org/xwiki/rendering/SimpleRenderingTests.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/java/org/xwiki/rendering/SimpleRenderingTests.java 2009-09-09 > 10:43:50 UTC (rev 23371) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/java/org/xwiki/rendering/SimpleRenderingTests.java 2009-09-09 > 10:53:09 UTC (rev 23372) > @@ -204,6 +204,26 @@ > suite.addTestsFromResource("misc/misc7", false); > suite.addTestsFromResource("encoding/encoding1", false); > > + suite.addTestsFromResource("escape/escape1", false); > + suite.addTestsFromResource("escape/escape2", false); > + suite.addTestsFromResource("escape/escape3", false); > + suite.addTestsFromResource("escape/escape4", false); > + suite.addTestsFromResource("escape/escape5", false); > + suite.addTestsFromResource("escape/escape6", false); > + suite.addTestsFromResource("escape/escape7", false); > + suite.addTestsFromResource("escape/escape8", false); > + suite.addTestsFromResource("escape/escape9", false); > + suite.addTestsFromResource("escape/escape10", false); > + suite.addTestsFromResource("escape/escape11", false); > + suite.addTestsFromResource("escape/escape12", false); > + suite.addTestsFromResource("escape/escape13", false); > + suite.addTestsFromResource("escape/escape14", false); > + suite.addTestsFromResource("escape/escape15", false); > + suite.addTestsFromResource("escape/escape16", false); > + suite.addTestsFromResource("escape/escape17", false); > + suite.addTestsFromResource("escape/escape18", false); > + suite.addTestsFromResource("escape/escape19", false); We were missing all those tests? > return new ComponentManagerTestSetup(suite); > } > } > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/ > src/test/resources/link/links14.test > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/resources/link/links14.test 2009-09-09 10:43:50 UTC (rev 23371) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/resources/link/links14.test 2009-09-09 10:53:09 UTC (rev 23372) > @@ -24,7 +24,7 @@ > .#----------------------------------------------------- > .expect|xwiki/2.0 > .#----------------------------------------------------- > -[[[[image:attach.png~|~|height="100" width="100"~]~]>>http://xwiki.org > ||param="value"]] > +[[[[image:attach.png||height="100" width="100"]]>>http://xwiki.org|| > param="value"]] great! > .#----------------------------------------------------- > .input|xhtml/1.0 > .#----------------------------------------------------- > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/ > src/test/resources/link/links6.test > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/resources/link/links6.test 2009-09-09 10:43:50 UTC (rev 23371) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/ > test/resources/link/links6.test 2009-09-09 10:53:09 UTC (rev 23372) > @@ -55,7 +55,7 @@ > [[Label>Reference]] > [[Reference|Param=Value]] > [[[[no link]]>>Reference]] > -[[~~[~~[image:whatever>>Reference]] > +[[~[~[image:whatever>>Reference]] great too! Thanks -Vincent

16 years

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r23347 - in platform: core/trunk/xwiki-core/src/main/resources web/trunk/standard/src/main/webapp/templates xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist

by Sergiu Dumitriu

Could you merge the changes for menuview.vm to the colibri skin? On Tue, Sep 8, 2009 at 18:09, jvdrean<platform-notifications(a)xwiki.org> wrote: > Author: jvdrean > Date: 2009-09-08 18:09:29 +0200 (Tue, 08 Sep 2009) > New Revision: 23347 > > Modified: > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties > platform/web/trunk/standard/src/main/webapp/templates/menuview.vm > platform/web/trunk/standard/src/main/webapp/templates/watch.vm > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListEvent.java > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListEventMatcher.java > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListJob.java > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListPluginApi.java > platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist/WatchListStore.java > Log: > XWIKI-4298 : Add watch/unwatch wiki in the Watch menu > XPWATCHLIST-60 : Watch List should support registering for user activity > > The API is now complete. The backend for the future "follow user activity" is implemented and can be used through the object editor. -- http://purl.org/net/sergiu

16 years

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r23368 - platform/skins/trunk/colibri/src/main/resources/colibri

by Vincent Massol

Hi Sergiu, On Sep 9, 2009, at 8:28 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-09-09 08:28:17 +0200 (Wed, 09 Sep 2009) > New Revision: 23368 > > Modified: > platform/skins/trunk/colibri/src/main/resources/colibri/ > contentview.vm > Log: > XSCOLIBRI-68: Duplicate titles on some pages > Fixed on most pages. > > > Modified: platform/skins/trunk/colibri/src/main/resources/colibri/ > contentview.vm > =================================================================== > --- platform/skins/trunk/colibri/src/main/resources/colibri/ > contentview.vm 2009-09-09 06:07:41 UTC (rev 23367) > +++ platform/skins/trunk/colibri/src/main/resources/colibri/ > contentview.vm 2009-09-09 06:28:17 UTC (rev 23368) > @@ -33,7 +33,6 @@ > #set($content = > $content.trim().substring($content.trim().indexOf($util.newline))) > #end > #end > - ## #set($renderedContent =$cdoc.getRenderedContent()) > #set($renderedContent = $cdoc.getRenderedContent($content, > $cdoc.syntaxId)) > #end > <div id="document-title"><h1>$tdoc.displayTitle</h1></div> > @@ -42,7 +41,7 @@ > ## > ## Display the rendered content > ## > -$renderedContent > +$renderedContent.replaceFirst('^[ \n\r\t]*+<h1.*?</h1>', '') I'm not sure I understand the algorithm. Also you mention "most pages". Does it mean there are cases where this is not working? Thanks -Vincent PS: We're also missing the config flag.

16 years

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r23356 - in platform/core/trunk/xwiki-rendering: . xwiki-rendering-parsers/xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/internal/parser/wikimodel

by Vincent Massol

On Sep 8, 2009, at 8:52 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-08 20:52:51 +0200 (Tue, 08 Sep 2009) > New Revision: 23356 > > Modified: > platform/core/trunk/xwiki-rendering/pom.xml > platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/xwiki- > rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/ > internal/parser/wikimodel/XDOMGeneratorListener.java > Log: > XWIKI-4177: Verbatim block and monospace break table > > Modified: platform/core/trunk/xwiki-rendering/pom.xml > =================================================================== > --- platform/core/trunk/xwiki-rendering/pom.xml 2009-09-08 18:12:11 > UTC (rev 23355) > +++ platform/core/trunk/xwiki-rendering/pom.xml 2009-09-08 18:52:51 > UTC (rev 23356) > @@ -41,7 +41,7 @@ > <dependency> > <groupId>org.wikimodel</groupId> > <artifactId>org.wikimodel.wem</artifactId> > - <version>2.0.7-20090811</version> > + <version>2.0.7-20090908</version> > </dependency> > </dependencies> > </dependencyManagement> > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering- > parsers/xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/ > rendering/internal/parser/wikimodel/XDOMGeneratorListener.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/ > xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/ > internal/parser/wikimodel/XDOMGeneratorListener.java 2009-09-08 > 18:12:11 UTC (rev 23355) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-parsers/ > xwiki-rendering-parser-wikimodel/src/main/java/org/xwiki/rendering/ > internal/parser/wikimodel/XDOMGeneratorListener.java 2009-09-08 > 18:52:51 UTC (rev 23356) > @@ -302,55 +302,57 @@ > */ > public void endFormat(WikiFormat format) > { > - // Get the styles: the styles are wiki syntax styles (i.e. > styles which have a wiki syntax such as bold, italic ,etc). > - // As opposed to format parameters which don't have any > specific wiki syntax (they have a generic wiki syntax such as > + // Get the styles: the styles are wiki syntax styles (i.e. > styles which have a wiki syntax such as bold, italic > + // ,etc). > + // As opposed to format parameters which don't have any > specific wiki syntax (they have a generic wiki syntax > + // such as > // (% a='b' %) for example in XWiki Syntax 2.0. > List<WikiStyle> styles = format.getStyles(); > - > - // If there's any style or parameter defined, do something. > The reason we need to check for this is because wikimodel > + > + // If there's any style or parameter defined, do something. > The reason we need to check for this is because > + // wikimodel > // sends an empty begin/endFormat event before starting an > inline block (such as a paragraph). > if ((styles.size() > 0) || (format.getParams().size() > 0)) { > > // Generate nested FormatBlock blocks since XWiki uses > nested Format blocks whereas Wikimodel doesn't. > // > // Simple Use Case: (% a='b' %)**//hello//**(%%) > - // WikiModel Events: > - // beginFormat(params: a='b', styles = BOLD, ITALIC) > - // onWord(hello) > - // endFormat(params: a='b', styles = BOLD, ITALIC) > + // WikiModel Events: > + // beginFormat(params: a='b', styles = BOLD, ITALIC) > + // onWord(hello) > + // endFormat(params: a='b', styles = BOLD, ITALIC) > // XWiki Blocks: > - // FormatBLock(params: a='b', format = BOLD) > - // FormatBlock(format = ITALIC) > + // FormatBLock(params: a='b', format = BOLD) > + // FormatBlock(format = ITALIC) > // > // More complex Use Case: **(% a='b' %)hello**world > - // WikiModel Events: > - // beginFormat(params: a='b', styles = BOLD) > - // onWord(hello) > - // endFormat(params: a='b', styles = BOLD) > - // beginFormat(params: a='b') > - // onWord(world) > - // endFormat(params: a='b') > + // WikiModel Events: > + // beginFormat(params: a='b', styles = BOLD) > + // onWord(hello) > + // endFormat(params: a='b', styles = BOLD) > + // beginFormat(params: a='b') > + // onWord(world) > + // endFormat(params: a='b') > // XWiki Blocks: > - // FormatBlock(params: a='b', format = BOLD) > - // WordBlock(hello) > - // FormatBlock(params: a='b') > - // WordBlock(world) > - > + // FormatBlock(params: a='b', format = BOLD) > + // WordBlock(hello) > + // FormatBlock(params: a='b') > + // WordBlock(world) > + > // TODO: We should instead have the following which > would allow to simplify XWikiSyntaxChaining Renderer > // which currently has to check if the next format has > the same params as the previous format to decide > // whether to print it or not. > - // FormatBlock(params: a='b') > - // FormatBlock(format = BOLD) > - // WordBlock(hello) > - // WordBlock(world) > - > + // FormatBlock(params: a='b') > + // FormatBlock(format = BOLD) > + // WordBlock(hello) > + // WordBlock(world) Thomas there are lots of reformatting in your commit. In general it would be great to not reformat during a normal commit since it makes it harder to read. In addition I have the feeling the reformatting has broken all my formatting. Thanks -Vincent > + > FormatBlock block; > if (styles.size() > 0) { > block = new FormatBlock(generateListFromStack(), > convertFormat(styles.get(styles.size() - 1))); > } else { > block = new FormatBlock(generateListFromStack(), > Format.NONE); > } > - > > if (styles.size() > 1) { > ListIterator<WikiStyle> it = > styles.listIterator(styles.size() - 1); > @@ -377,7 +379,7 @@ > } > > } else { > - // Empty format. We need to remove our marker so pop > all blocks after our marker and push them back on > + // Empty format. We need to remove our marker so pop > all blocks after our marker and push them back on > // the stack. > for (Block block : generateListFromStack()) { > this.stack.push(block); > @@ -559,10 +561,11 @@ > > /** > * {@inheritDoc} > - * > - * <p>Called when WikiModel finds an reference (link or image) > such as a URI located directly in the text > - * (free-standing URI), as opposed to a link/image inside wiki > link/image syntax delimiters.</p> > - * > + * <p> > + * Called when WikiModel finds an reference (link or image) > such as a URI located directly in the text > + * (free-standing URI), as opposed to a link/image inside wiki > link/image syntax delimiters. > + * </p> > + * > * @see org.wikimodel.wem.IWemListener#onLineBreak() > */ > public void onReference(String reference) > @@ -613,8 +616,8 @@ > */ > public void onImage(WikiReference ref) > { > - this.stack.push(new > ImageBlock(this.imageParser.parse(ref.getLink()), false, > convertParameters(ref > - .getParameters()))); > + this.stack.push(new > ImageBlock(this.imageParser.parse(ref.getLink()), false, > + convertParameters(ref.getParameters()))); > } > > /** > @@ -784,4 +787,28 @@ > > return resultBlock; > } > + > + public void beginSection(int docLevel, int headerLevel, > WikiParameters params) > + { > + // TODO add support for it > + > + } > + > + public void beginSectionContent(int docLevel, int headerLevel, > WikiParameters params) > + { > + // TODO add support for it > + > + } > + > + public void endSection(int docLevel, int headerLevel, > WikiParameters params) > + { > + // TODO add support for it > + > + } > + > + public void endSectionContent(int docLevel, int headerLevel, > WikiParameters params) > + { > + // TODO add support for it > + > + } > }

16 years

1
0
0 0

[xwiki-devs] Does it make sense to add a method for saving many docs in one transaction?

by Caleb James DeLisle

It seems like there is increasing need for saving groups of documents in a single transaction. I was thinking maybe this would be a good method: XWiki.saveDocuments(List<XWikiDocument> XWikiContext) It would be up to the calling method to set the comment and isMinorEdit field in the documents before sending them to saveDocuments. Is this deserving of a jira improvement issue? What do you folks think? Caleb James DeLisle

16 years

2
1
0 0

[xwiki-devs] Translation Wiki

by hel-o

Hi, there seems to be a problem with the translation wiki, just logged in, only language available is zh and theres a application "hallo" hel. ----- semantic-web.hel.at hel(a)hel.at -- View this message in context: http://n2.nabble.com/Translation-Wiki-tp3601693p3601693.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

16 years

3
3
0 0

Re: [xwiki-devs] [xwiki-notifications] r23335 - platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-python/src/main/java/org/xwiki/rendering/internal/macro/python

by Vincent Massol

Thomas, Be careful that you need to update the jython macro doc on code.xwiki.org too since it says both macro names can be used I think. Thanks -Vincent On Sep 8, 2009, at 10:08 AM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-08 10:08:09 +0200 (Tue, 08 Sep 2009) > New Revision: 23335 > > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-python/src/main/java/org/xwiki/rendering/internal/ > macro/python/PythonMacro.java > Log: > XWIKI-2798: Create jython macro for rendering 2.0 > * remove "jython" hint until we find a better solution from the > WYSIWYG POV > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/ > xwiki-rendering-macro-python/src/main/java/org/xwiki/rendering/ > internal/macro/python/PythonMacro.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-python/src/main/java/org/xwiki/rendering/internal/ > macro/python/PythonMacro.java 2009-09-08 06:38:19 UTC (rev 23334) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-python/src/main/java/org/xwiki/rendering/internal/ > macro/python/PythonMacro.java 2009-09-08 08:08:09 UTC (rev 23335) > @@ -30,7 +30,7 @@ > * @version $Id$ > * @since 2.0M2 > */ > -@Component(hints = {"python", "jython" }) > +@Component("python") > public class PythonMacro extends > AbstractJSR223ScriptMacro<JSR223ScriptMacroParameters> > { > /**

16 years

1
0
0 0

Re: [xwiki-devs] Blog Plugin Proposal

by Guillaume Lerouge

Hi Andreas, On Mon, Aug 31, 2009 at 1:11 AM, Andreas Schaefer <schaefera(a)me.com> wrote: > My try to deploy the Blog Plugin together with the updated Blog > Application failed miserably today and my dislike of Velocity reach a > new high. > > Because I see the value of the scripting nature of the Blog allowing > users to customize their Blog to a quite large degree I don't want to > ditch that but I have a lot of problems with Velocity and the way is > plastering over issues. I rather fail fast than late with hardly a > trail to understand what is going on. > My personal experience with velocity is more of a try & fail, try & fail, try and succeed one than anything else. What I found out is that I was msot of the time better off rewriting stuff starting with small chunks rather than trying to take existing code and reuse it all at once. The current blog is a fairly complex piece of velocity code (that is, given the lack of debugging tools when coding in velocity in the wiki). This is one of the reasons I think Sergiu's argument that "devs will be able to look at the code and learn from it" is not entirely true ;-) What's really important for the blog is that it can be customized easily at 2 levels: - Look: an user should be able to use the panels she wants for her blog - Deployment: an user should be able to create a new space blog or global wiki blog in any space she wants Besides that the way the blog is code doesn't matter much for the end user. That said I still think that it might be a good idea to convert the > scripted part of the Blog over to Groovy and keep the rest in the Blog > Plugin. I don't have any experience with Groovy inside XWiki but for > sure the documentation of Groovy outside is excellent compared to > Velocity. I will use the next week to get up to speed and try to > convert a piece of the Blog over to Groovy. Then go ahead and give it a go :-) One thing you need to be aware of when using Groovy inside the wiki is that your pages will haveto be saved using programming rights. This can cause a number of issues, don't forget to code with an user that has them, it will save yo ua lot of hassle ;-) > Cheers - Andy > Good luck and thanks for all the nice work, Guillaume > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

16 years

3
3
0 0

[xwiki-devs] Can't find descriptor for the component DocumentAccessBridge

by Juri Kühn

Hi all, first of all, thanks for the great work, xwiki is a great product i'm trying to integrate the rendering component of xwiki into our application for hours, without success. I included all the libraries from XWiki 2.0 M4 and was running following code in a standalone application (not within servlet container, but thats no problem?) -- EmbeddableComponentManager componentManager = new EmbeddableComponentManager(); componentManager.initialize(this.getClass().getClassLoader()); Parser parser = (Parser)componentManager.lookup(Parser.class, Syntax.XWIKI_2_0.toIdString()); XDOM xdom = parser.parse(new StringReader("test")); // Generate XHTML PrintRendererFactory rf = componentManager.lookup(PrintRendererFactory.class, Syntax.XHTML_1_0.toIdString()); DefaultWikiPrinter printer = new DefaultWikiPrinter(); Renderer htmlRenderer = rf.createRenderer(printer); // Perform the rendering - the exception is raised here xdom.traverse(htmlRenderer); -- The stacktrace is attached below. The DocumentAccessBridge component cannot be loaded. I tried to figure out what is going on and debugged around. The loop that loads all descriptors for xwiki components doesnt include DocumentAccessBridge. There is no META-INF/components.txt in the xwiki-core-bridge-2.0-milestone-4.jar and no class in this library has the @Component annotation. I just cannot figure out what is going wrong. Different parsers and printrenderers (other than XWIKI_2_0 and XHTML_1_0) as the use of the Converter instead of Parser produce the same result. What am i doing wrong? Any help would be really appreciated. Best regards, Juri Output and Stacktrace: 05.09.2009 00:50:35 org.xwiki.component.logging.CommonsLoggingLogger warn WARNUNG: Component [org.xwiki.rendering.internal.configuration.DefaultRenderingConfiguration] is being overwritten by component [org.xwiki.rendering.internal.configuration.XWikiRenderingConfiguration] for Role/Hint [role = [org.xwiki.rendering.configuration.RenderingConfiguration] hint = [default]]. It will not be possible to look it up. 05.09.2009 00:50:35 org.xwiki.component.logging.CommonsLoggingLogger warn WARNUNG: Component [org.xwiki.rendering.internal.renderer.DefaultLinkLabelGenerator] is being overwritten by component [org.xwiki.rendering.internal.renderer.XWikiLinkLabelGenerator] for Role/Hint [role = [org.xwiki.rendering.renderer.LinkLabelGenerator] hint = [default]]. It will not be possible to look it up. 05.09.2009 00:50:35 org.xwiki.component.logging.CommonsLoggingLogger warn WARNUNG: Failed to load configuration file [/WEB-INF/xwiki.properties]. Using default configuration. Internal error [null] Exception in thread "main" java.lang.RuntimeException: Failed to create [XHTML 1.0] renderer at org.xwiki.rendering.internal.renderer.AbstractPrintRendererFactory.createRenderer(AbstractPrintRendererFactory.java:51) at de.lernbase.XWikiRenderTest.doit(XWikiRenderTest.java:30) at de.lernbase.XWikiRenderTest.main(XWikiRenderTest.java:58) Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.rendering.renderer.PrintRenderer] hint = [xhtml/1.0]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.internal.DefaultComponentManager.lookup(DefaultComponentManager.java:85) at org.xwiki.rendering.internal.renderer.AbstractPrintRendererFactory.createRenderer(AbstractPrintRendererFactory.java:49) ... 2 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.rendering.renderer.xhtml.XHTMLLinkRenderer] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 5 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.rendering.renderer.LinkLabelGenerator] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 9 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.rendering.configuration.RenderingConfiguration] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 13 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.configuration.ConfigurationSource] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 17 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.configuration.ConfigurationSource] hint = [wiki]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 21 more Caused by: org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [org.xwiki.bridge.DocumentAccessBridge] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:311) at org.xwiki.component.embed.EmbeddableComponentManager.lookup(EmbeddableComponentManager.java:109) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:347) at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:328) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 25 more Caused by: org.xwiki.component.manager.ComponentLookupException: Can't find descriptor for the component [role = [org.xwiki.bridge.DocumentAccessBridge] hint = [default]] at org.xwiki.component.embed.EmbeddableComponentManager.createInstance(EmbeddableComponentManager.java:325) at org.xwiki.component.embed.EmbeddableComponentManager.initialize(EmbeddableComponentManager.java:304) ... 29 more

16 years

4
5
0 0

Re: [xwiki-devs] [xwiki-users] [Vote] Default Color Theme

by Ecaterina Valica

Current Votes: (0) +0.5 Anca (1) (2) +1 Lucien, +0.66 Marta, +0.5 Jean C, +1 Gaëtan, +0.66 Raluca, +0.5 Vincent G, +1 Emilie, (3) +1 G, +1 Christophe P, +0.33 Raluca, (4) +1 Caty, +1 Vincent, +1 Ricardo R, +1 Florin, +1 Silvia, +0.5 Trevor, +1 Marius (5) +0.33 Marta, (A) (B) +1 Oana, +1 Thomas M, +1 Sergiu, +0.5 Vincent G, +1 Philipp, +1 Martijn, +0.5 Trevor (C) +0.5 Anca, +0.5 Jean C (D) (E) (F) (G) (H)

16 years

4
7
0 0

[xwiki-devs] documenting changes in trusted rights

by [Ricardo Rodriguez] Your EPEC Network ICT Team

Hi! One of the biggest problems I've been facing concerning changes in a property, or the access rights to a document or space is how to keep track of the reasons that cause them. I mean, for instance, how could we document the reason (a message sent by the responsible of some contents, a detected abuse,...) why some rights have been granted or denied to one or several users or a group? Is this a matter of programming, data model or it is an absolutely absurd idea? Having the wiki model in charge of documenting who, when and why a change is done in a document, I truly miss a system to keep track on the assigned rights as a metaphor of the trusting relationship on a given document or space. Thanks in advance for your thoughts! Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team

16 years

1
0
0 0

[xwiki-devs] Annotation module source code review

by Lucien Pereira

Hi all, In order to start integration of annotation module to XWiki, I would encourage you to review annotation module source code. Lucien

16 years

1
2
0 0

[xwiki-devs] [VOTE] Ensure that getRenderedContent(String, String, String) is executed in its own context

by Vincent Massol

Hi, We currently have a bug with script macros and contexts: http://jira.xwiki.org/jira/browse/XWIKI-4279 I can easily solve it by backuping and restoring the Execution Context in getRenderedContent(String, String, String). I think this is the correct way since the context should be isolated when rendering IMO. Now, note that isolating the EC means the velocitycontext will be cloned (shallow cloning though right now). Which means that if some calls to getRenderedContent(String, String, String) save stuff in the velo context for the caller they may fail. I don't know if this happens anywhere in our code but it's unlikely since the calls from vm files are usually calls to getRenderedContent() without parameters which doesn't save/Restore the contexts. Here's my +1 for isolating the contexts in getRenderedContent(String, String, String) and my +1 to apply this change now for RC1. Thanks -Vincent

16 years

4
3
0 0

Re: [xwiki-devs] [xwiki-notifications] r23282 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/objects/classes

by Vincent Massol

On Sep 4, 2009, at 4:08 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2009-09-04 16:08:55 +0200 (Fri, 04 Sep 2009) > New Revision: 23282 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/objects/ > classes/DBListClass.java > Log: > [misc] Improve log > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > objects/classes/DBListClass.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > objects/classes/DBListClass.java 2009-09-04 13:46:26 UTC (rev 23281) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > objects/classes/DBListClass.java 2009-09-04 14:08:55 UTC (rev 23282) > @@ -286,8 +286,7 @@ > try { > sql = context.getWiki().parseContent(sql, context); > } catch (Exception e) { > - LOG.warn("Failed to parse SQL script [" + sql + "]. > Internal error [" + e.getMessage() > - + "]. Continuing with non-rendered script."); > + LOG.warn("Failed to parse SQL script [" + sql + "]. > Continuing with non-rendered script.", e); Thomas, why is that better? Thanks -Vincent

16 years

2
3
0 0

Re: [xwiki-devs] [UX] Edit Buttons Order

by PERINAUD Christophe

+1 (C) For my opinion the "Preview" button is necessary because the final structure of the page is different then the edition one. Because of panels, colors etc, you can want to check the global look and integration of your page And also all buttons should be in one group. It's all actions that you can iniate from the editor. Subgroups don't sound necessary for me. > -----Message d'origine----- > De : devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] > De la part de Ecaterina Valica > Envoyé : vendredi 4 septembre 2009 13:09 > À : XWiki Mailinglist; XWiki Mailinglist > Objet : [xwiki-devs] [UX] Edit Buttons Order > > Hi, > > Because we want to make a standard from vertical-aligned > form, this means > the buttons should be left-ordered with the most important > action first. > This should be changed also in Toucan and Albatross skin, not > only just in > Colibri. > > Right now the Edit Actions are "Cancel", "Preview", "Save&Continue", > "Save&View". > > What do you think is the right order for them when they are > left-aligned? > > (A) Save&View, Save&Continue, Preview, Cancel (as it is - > just in reverse) > > (B) Save&View, Preview, Save&Continue, Cancel > > (C) Preview, Save&Continue, Save&View, Cancel > > (D) other variation > > Remarks: > > - "Cancel" should be *last* because it's a terminal (takes > you out of the > editor), no-saving action. This is the least important. > > - "Save & View" is also a terminal action (takes you out of > the editor) - > having it* first* you have the 2 terminal actions at extremities. > - "Preview" is the least damaging action in case of accidental submit > (Silvia + Marta) - should be *first*? > > - Some people use ("Preview" + "Save&Continue") {many times} > + "Save&View" > {final} > - Other people just use "Save&Continue" + "Save & View" {final}, never > "Preview", etc > > - What is the necessity for the "Preview" button in a WYSIYWG > editor? On the > other hand "Preview" is very important if you edit in "Wiki" mode. > > - Should "Preview" separate the two other SAVING actions? (Marta) > - Should "Save&Continue" separate the two other VIEW actions? > > Thanks, > Caty > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -------------------------------------------------------------------------------- This e-mail is intended only for the addressee named above. It does not bind the sender, except in the case of an existing written convention with the addressee. This e-mail may contain material that is confidential and privileged for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender and delete all copies. While reasonable precautions have been taken to ensure that this e-mail and any attachments are free from any computer virus or similar defect, no liability will be accepted in that respect. Anyone accessing this e-mail must take their own precautions as to security and virus protection. KBL European Private Bankers S.A., 43 boulevard Royal L-2955 Luxembourg, R.C.S. Luxembourg B 6395, T (352) 47 97 1

16 years

1
0
0 0

[xwiki-devs] [Proposal] Adding attachment JARs in a URL classloader for scripts

by Vincent Massol

Hi, I'd like to implement this behavior: {{script language="..." jarPages="Space1.Page1, Space2.Page, ..."}} ... {{/script}} Optional: - offer a way to specify explcitley the jars. For example: Space1.Page1(a)myjar.jar It would add the jars located in the specified pages to a URLClassLoader used to execute the script. Obviously programming rights would be checked. WDYT? Thanks -Vincent

16 years

3
4
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