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

[xwiki-devs] Skin tutorial, custom logo?

by Lilianne E. Blaze

Hello, Could you please consider writing a short tutorial on creating / modifying skins? For example, how to use a custom logo? Right now I'm trying to replace standard Toucan logo with my own with a couple links below it, I tried replacing <div id="companylogo"> fragment in global.vm, but I'm completely stuck with the css part. The logo and the links are there all right, but the layout is wrong. And I can't simply search-and-replace all 220s and 80s, because it's not a single picture but a table with 2 pictures and 5 links inside. I'd probably manage to do it by trial and error, but then I'd have no idea if it looks the same on other systems. It's probably easy, but my knowledge of css is rudimentary (basically I know what it is, how to apply it, and how to use it for fonts, sizes and colors; layouts are beyond me). It would be nice to have a basic tutorial like "if you want to replace the logo with your own picture enter it's size here, here and here, if you want to replace it with arbitrary html change this, this and this so the height of the logo area isn't hardcoded". Greetings, Lilianne

16 years, 1 month

5
6
0 0

[xwiki-devs] Introducing the equation rendering component and the equation macro

by Sergiu Dumitriu

Hello Community, I have committed today the first implementation of a new XWiki feature: rendering mathematical equations into images. It is available as a standalone component, and as a syntax 2.0 macro. About the functionality. Equations are written in the TeX/LaTeX syntax, which is pretty simple, and seems to be the syntax of choice for mathematical equations in other wikis, too. The macro can distinguish between inline and block equations and render them accordingly. The output can be either PNG (the default one), GIF or JPEG. While PNG is definitely the best, I kept the other two in case somebody really wants to use ancient browsers that only understand GIF. Q: Should I leave just PNG as the output format? Another feature is that the font size can be specified, in order to render larger or smaller equations. All the font size commands from LaTeX (from \tiny to \Huge) have an equivalent. I renamed them to a more easy to understand name (also because the configuration is case insensitive, so there's no difference between large and LARGE). By default images are generated so that the font looks relatively OK with the default XWiki skin on a 72 or 96 DPI display. They might look disproportionate with a different DPI, or with a different default font size. Q: Is the default DPI setting OK? Second, a few technical details: The standalone component is located in platform/core/xwiki-equation-rendering. I don't know if the name is the best (Vincent complained). On one hand, this describes better what the component does: it renders equations. On the other hand, it might cause confusion with the xwiki-rendering system. The component currently has three implementations: - a native one, which relies on the latex system being present. It gives the best results, from a graphical point of view, but requires the presence of external programs, and involves a slight overhead for starting new processes and for working with the disk. Currently it might have some security problems, I'll have to see if opening input and output files from TeX is a problem, or how to disable this. Any help from someone who know more about TeX? Q: Does anybody know of any security issues with running latex, dvips or convert? Especially with the \openin and \openout commands? - one which uses MathTran as a remote service through HTTP requests. It gives results as good as the native one, enhanced with some metadata, and depending on the configuration of the server, it might have better performance than the native one. The disadvantage is that it relies heavily on a remote server. Note that MathTran is free software, and can be installed locally on the same or a neighboring server. Oh, another minor problem is that it uses a variant of the TeX syntax, not LaTeX. - one which uses SnuggleTeX and JEuclid to transform LaTeX into MathML, and then render it into images. The results are not as eye-pleasing as those obtained from LaTeX, but it is a self-contained solution, with no external dependencies. SnuggleTeX uses the liberal 3-clause BSD license, JEuclid uses the Apache v2 license, so both can be deployed. Together, they weight in at 730k, so it's not a big impact. The other two implementations are not contaminated by the licenses of the underlying system, so there's no license conflict. Q: Should either one be removed? Q: Do you know of any other (better) alternative? By default the native renderer is used, since it gives the best results and doesn't depend on an external service. SnuggleTeX is configured as a backup (safe) renderer which kicks in when the default one isn't working (missing tex subsystem, or communication error with the remote server). Q: Is this setup OK as the default one? (native by default, snuggletex as fallback). The generated images are stored in a cache (using the cache component), for improved performance. This new cache might increase the memory requirements, but fortunately it is easy to configure. The rendering macro is located in platform/core/xwiki-rendering/xwiki-renderig-macros/xwiki-rendering-macro-equation, and the macro can be used with {{equation}}\sum_{i=0}^{\infty}{{/equation}}. Q: Is the macro name appropriate? Do you know of a better one? Future work: - make sure that there are no security issues with the Native backend - add support for MathML display for the clients that understand it - improve the alignment of images (especially for the Native backend), as right now they are a bit raised above the text baseline Many thanks to Guillaume Legris who provided the starting point for this component. -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 1 month

5
13
0 0

[xwiki-devs] [Proposal] Package names clarification

by Vincent Massol

Hi, We have some rules on http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle#HPackagenames I'd like to clarify it with this: * A module's package name should be of the form org.xwiki.....<modulename> * Thus the internal package should start at org.xwiki.....<modulename>.internal.* * Default modules (*-default) should use the same package root as the - api module they're implementing. WDYT? Thanks -Vincent

16 years, 1 month

2
1
0 0

[xwiki-devs] [VOTE] Release XE 1.9.3 and XEM 1.7.3 on wednesday 12th of August

by Jean-Vincent Drean

Hi, I'd like to propose to release XE 1.9.3 on 12th of August. There are some critical issues that it'd be good to ship ASAP: http://jira.xwiki.org/jira/browse/XWIKI/fixforversion/11178 XE 1.9.3 will also benefits from the latests fixes on the tag and mailsender plugins: http://jira.xwiki.org/jira/browse/XATAG/fixforversion/11188 http://jira.xwiki.org/jira/browse/XPMAIL/fixforversion/11132 Here's my +1 Thanks, JV.

16 years, 1 month

5
4
0 0

[xwiki-devs] Macros and JavaScript working together (was Re: [DISCUSSION] XWiki Chart Api & Chart Macro)

by Niels Mayer

On Thu, Jun 25, 2009 at 9:44 PM, Asiri Rathnayake < asiri.rathnayake(a)gmail.com> wrote: > Hi, > > On Thu, Jun 25, 2009 at 11:53 PM, Niels Mayer <nielsmayer(a)gmail.com> > wrote: > > > Another interesting advanced JS data-visualization toolkit that would be > > useful to integrate in Xwiki. > > > > http://vis.stanford.edu/protovis/ > > http://www.technologyreview.com/computing/22927/?nlid=2130 > > http://flare.prefuse.org/launch/apps/job_voyager > > Protovis sounds cool, but the way xwiki macros work will make it difficult > (or messy) to implement a macro that will have to depend on a JS library. > What we can do is this: > > * Implement the wiki-macro bridge: > http://jira.xwiki.org/jira/browse/XWIKI-3213 (Basically this will allow > you > to convert any wiki content into your personal macro) - I'll finish this in > a week or so. > > * We use a JSX (?) to get protovis support. > > * Neils can implement a js charting wiki-macro using protovis ;) > > I want to ask other developers, Is this possible? (I have a confusion about > macros + js working together) I have Macros/JS working together all the time, using JSX. I'm certain it's possible, given the kinds of integration I've been able to do in Exhibit&Xwiki, e.g. http://nielsmayer.com/xwiki/bin/view/Exhibit/NPRpods3 ... Here's a simple example, which are tests for my Xwiki integration of http://www.longtailvideo.com/players/jw-flv-player/ which is the media player used in the NPRpods3 application above: http://nielsmayer.com/xwiki/bin/view/Macros/JWPlayer?viewer=code http://nielsmayer.com/xwiki/bin/view/Macros/JWPlayerJSPL_Test (xwiki integration of http://home5.inet.tele.dk/nyboe/flash/mediaplayer4/JW_API_xmpl_5-2-4-0.html with an improvement, the JWplayer example doesn't work on Linux/Firefox, mine does!) http://nielsmayer.com/xwiki/bin/view/Macros/JWPlayerJSPL_Test?viewer=code (wiki-code for above) http://nielsmayer.com/xwiki/bin/jsx/Macros/JWPlayerJSPL_Test (the javascript playlist from XWiki.JavaScriptExtension[0]) ## ## Load and initialize LoadJS: defines injectJS(url) required by JWPlayer ## #includeMacros("Macros.LoadJS")## #loadjs_xwiki_init()## ## ## Load and initialize JWPlayer after LoadJS. ## #includeMacros("Macros.JWPlayer")## #jwplayer_xwiki_init()## ## ## Load JavaScript playlist from object XWiki.JavaScriptExtension[0] into ## js variable jwplayer_jspl, used below in parameter to jwplayer_embed_generic() ## function(jwpl){jwpl.sendEvent(’LOAD’, jwplayer_jspl);}. This function called ## by jwplayer’s playerReady() calback when player has been instantiated, and ## causes the javascript-based playlist to get loaded. ## $xwiki.jsx.use("$doc.fullName")## ... #set( $jw_name = "$doc.name" )## #set( $jw_player = "jwplayer_embed_generic(’$jw_name’, ’mpl’, ’&autostart=false&playlist=right&playlistsize=250&shuffle=false&repeat=always’, function(jwpl){jwpl.sendEvent(’LOAD’, jwplayer_jspl);}, ’100%’, ’385px’);" )## #jwplayer_create("$jw_name", "$jw_player")## http://nielsmayer.com/xwiki/bin/view/Macros/JWPlayerPL_Test is another test using playlists. This also calls JS jwplayer_embed_generic(), but with an external file, passed as URL/string, instead of creating the playlist in lambda-function as above. ( http://nielsmayer.com/xwiki/bin/view/Macros/JWPlayerPL_Test?viewer=code ): #set( $jw_player = "jwplayer_embed_generic(’$jw_name’, ’mpl’, ’&autostart=false&playlist=right&playlistsize=250&shuffle=false&repeat=always’, ’/xwiki/bin/view/Macros/JWPlayer_PlayList?xpage=plain’, ’100%’, ’385px’);" )## JS functions jwplayer_embed(), jwplayer_embed_generic() and macros #jwplayer_xwiki_init(), #jwplayer_create() are from http://nielsmayer.com/xwiki/bin/view/Macros/JWPlayer?viewer=code --- Going in "the other direction", here's an example of using velocity to compute results returned by Javascript: http://svn.xwiki.org/svnroot/xwiki/curriki/branches/curriki-1.8/web/src/mai… #set( $total_attachments_size = 0 ) ## javascript:getAttachmentsSize() #set( $total_attachments_names = [] ) ## javascript:getAttachmentsNames() #foreach ($attach in $doc.attachmentList) ## { #set( $ok = $total_attachments_names.add("'${attach.filename}'") ) ## append attachment filename to ArrayList #set( $total_attachments_size = ${total_attachments_size} + ${attach.getFilesize()} ) ## compute total size of atttachments #end ## } -- foreach ... function getAttachmentsNames() { return (${total_attachments_names}); } function getAttachmentsSize() { return (${total_attachments_size}); } ... lpattachments is called from an iframe. The parent document accesses the iframe'd document's javascript functions like this: ( http://svn.xwiki.org/svnroot/xwiki/curriki/branches/curriki-1.8/wiki/src/ma… ) // // get size of files in attachments iframe // function getAttachmentsSize() { return (window.frames['attachment_iframe'].getAttachmentsSize()); } // // retrieve ArrayList of filenames contained in attachment // function getAttachmentsNames() { return (window.frames['attachment_iframe'].getAttachmentsNames()); } -- Niels http://nielsmayer.com

16 years, 1 month

2
2
0 0

Re: [xwiki-devs] Blog Wiki 2.0 Upgrade 7th Draft

by Andreas Schaefer

Hi Marius >>> Collections.EMPTY_MAP is used to fill a "missing" parameter when a >>> method is overloaded. Use the signature that specifies the parameter: >>> >>> public SyndEntrySourceApi getSyndEntryArticleSource() >>> public SyndEntrySourceApi getSyndEntryArticleSource(Map params) >> > >> I noticed that but the problem is that later these maps are used to > >Used where? In your code or in the feed plug-in code? I doubt it's in >the feed plug-in code because the semantic I choose was: if you don't >specify any parameters then you don't have any parameters and thus >there's no need to change the map. If you want to specify parameters >then you have to provide at least an empty (mutable) map. > >Can you give me a code snipped that shows the failure? Calling getBlogFeed(String,int,int): public SyndFeed getBlogFeed(String query, int count, int start) { return getBlogFeed(query, count, start, Collections.EMPTY_MAP); } Call THIS: public SyndFeed getBlogFeed(String query, int count, int start, Map metadata) { if (query == null) { XWikiRequest request = getXWikiContext().getRequest(); String category = request.getParameter("category"); if (category == null || category.equals("")) { query = ", BaseObject as obj where obj.name=doc.fullName and obj.className='XWiki.ArticleClass' and obj.name<>'XWiki.ArticleClassTemplate' order by doc.creationDate desc"; } else { query = ", BaseObject as obj, DBStringListProperty as prop join prop.list list where obj.name=doc.fullName and obj.className='XWiki.ArticleClass' and obj.name<>'XWiki.ArticleClassTemplate' and obj.id=prop.id.id and prop.id.name='category' and list = '" + category + "' order by doc.creationDate desc"; } } SyndFeed blogFeed = getArticleFeed(query, count, start, fillBlogFeedMetadata(metadata)); if (blogFeed != null) { blogFeed.setImage(getDefaultFeedImage()); } return blogFeed; } which calls THIS: private Map fillWebFeedMetadata(Map metadata) { fillDefaultFeedMetadata(metadata); // these strings should be taken from a resource bundle String title = "Feed for document changes"; String description = title; if (!keyHasValue(metadata, "title", "")) { metadata.put("title", title); } if (!keyHasValue(metadata, "description", "")) { metadata.put("description", description); } return metadata; } which calls THIS where it fails because the MAP is immutable: private Map fillDefaultFeedMetadata(Map metadata) { XWiki xwiki = getXWikiContext().getWiki(); XWikiDocument doc = getXWikiContext().getDoc(); if (metadata.get("author") == null) { metadata.put("author", xwiki.getUserName(doc.getAuthor(), null, false, getXWikiContext())); } if (!keyHasValue(metadata, "copyright", "")) { metadata.put("copyright", xwiki.getWebCopyright(getXWikiContext())); } if (!keyHasValue(metadata, "encoding", "")) { metadata.put("encoding", xwiki.getEncoding()); } if (!keyHasValue(metadata, "url", "")) { metadata.put("url", "http://" + getXWikiContext().getRequest().getServerName()); } if (!keyHasValue(metadata, "language", "")) { metadata.put("language", doc.getDefaultLanguage()); } return metadata; } >> The FeedPlugin has two problems. A default query is not working >> because it looks for XWiki.ArticleClass which I changed but also it >> uses the XWiki.ArticleClass to define the properties to read out the >> values and that fails with a NPE: Here is where XWiki.ArticleClass is used: public SyndFeed getBlogFeed(String query, int count, int start, Map metadata) { if (query == null) { XWikiRequest request = getXWikiContext().getRequest(); String category = request.getParameter("category"); if (category == null || category.equals("")) { query = ", BaseObject as obj where obj.name=doc.fullName and obj.className='XWiki.ArticleClass' and obj.name<>'XWiki.ArticleClassTemplate' order by doc.creationDate desc"; } else { query = ", BaseObject as obj, DBStringListProperty as prop join prop.list list where obj.name=doc.fullName and obj.className='XWiki.ArticleClass' and obj.name<>'XWiki.ArticleClassTemplate' and obj.id=prop.id.id and prop.id.name='category' and list = '" + category + "' order by doc.creationDate desc"; } } SyndFeed blogFeed = getArticleFeed(query, count, start, fillBlogFeedMetadata(metadata)); if (blogFeed != null) { blogFeed.setImage(getDefaultFeedImage()); } return blogFeed; } >> I had to change the Source >> Parameters in order to make it work. I will have a closer look at the >> Feed Plugin and provide a patch when I could make it work. > >Again, can you provide a code snipped that shows the issue? > >SyndEntryDocumentSource is a generic feed entry source that knows >nothing about XWiki.ArticleClass. It can generate a feed entry by >collecting values from different properties of different objects >attached to the source document. You can even specify velocity >expressions to fill feed entry fields. > >Feed plug-in provides some helper methods for generating a feed from >XWiki.ArticleClass objects. Forget about it. For the new blog you have >to use the generic API and specify the mapping between feed entry fields >and Blog.BlogPostClass properties. Take a closer look at my example >http://tinyurl.com/cps7oa . As you can see I map: > >* ContentLength field -> a constant, 10 >* title field -> document title >* description field -> the content property of the first >XWiki.ArticleClass object attached to the source document >* publishedDate -> the date property of the XWiki.ArticleClass object >with index 0 among all the XWiki.ArticleClass objects attached to the >source document >* updatedDate -> a velocity expression, $doc.date.time >* categories -> a list: $doc.space, $doc.name, $doc.isNew() > >So what stops you from mapping feed entry fields to Blog.BlogPostClass >properties ? If we have methods that provide default values shouldn't it then work. The SyndEntryDocumentSource uses the XWiki.ArticleClass as the default mapping for the properties and it fails silently if the properties cannot be found. Shouldn't we then provide a default mapping for getBlogFeed() methods that don't have one? I will use the code snipped you mentioned above and see if I can make it work with 2.0m2 when it comes out. Thanks - Andy

16 years, 1 month

1
0
0 0

[xwiki-devs] Blog Wiki 2.0 Upgrade 7th Draft

by Andreas Schaefer

Hi I just attached the 7th draft of the Blog 2.0 Wiki Syntax upgrade to this JIRA report: http://jira.xwiki.org/jira/browse/XABLOG-50 This one includes the upgrades of the Panels to the 2.0 syntax. The only thing remaining are the RSS feeds and these cannot be upgraded now because the XHTML renderer does add the macro content as comment to the top of the output AHEAD of the <?xml> which is not allowed by the XML specification. So far I could not find a way to suppress that. I tried to create a XML renderer macro but got nowhere with it. My own Blog: http://madplanet.com/xwiki/bin/view/Blog/ uses the latest (7th) draft of the blog upgrade. Cheers Andreas Schaefer CEO of Madplanet.com Inc. EMail: andreas.schaefer(a)madplanet.com schaefera(a)me.com Twitter: andy_mpc AIM: schaefera(a)me.com

16 years, 1 month

5
14
0 0

[xwiki-devs] [VOTE] Add macro name in the Macro descriptor

by Vincent Massol

Hi, Right now we have a macro description in the macro descriptor but we're missing the macro name (ie a human understandable name to be used when displaying the list of macros in the wysiwyg editor for example). So I'm proposing we: * rename getMacroNames* methods in MacroManager/MacroCategoryManagers to getMacroIds * add a getName() in MacroDesciptor Here's my +1 Thanks -Vincent

16 years, 1 month

5
4
0 0

Re: [xwiki-devs] [xwiki-notifications] r22458 - in platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-equation/src/test: java/org/xwiki/rendering resources

by Vincent Massol

On Aug 10, 2009, at 11:41 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-08-10 11:41:27 +0200 (Mon, 10 Aug 2009) > New Revision: 22458 > > Added: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/resources/macroequation1.test > Removed: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/resources/macromessage1.test > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/java/org/xwiki/rendering/ > RenderingTests.java > Log: > XWIKI-4139: New {{equation}} macro for displaying mathematical > expressions > Adding a simple test > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/ > xwiki-rendering-macro-equation/src/test/java/org/xwiki/rendering/ > RenderingTests.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/java/org/xwiki/rendering/ > RenderingTests.java 2009-08-10 09:03:24 UTC (rev 22457) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/java/org/xwiki/rendering/ > RenderingTests.java 2009-08-10 09:41:27 UTC (rev 22458) > @@ -45,7 +45,7 @@ > { > RenderingTestSuite suite = new RenderingTestSuite("Test > Equation Macro"); > > - suite.addTestsFromResource("macromessage1", true); > + suite.addTestsFromResource("macroequation1", true); > > ComponentManagerTestSetup testSetup = new > ComponentManagerTestSetup(suite); > setUpMocks(testSetup.getComponentManager()); > @@ -80,16 +80,16 @@ > context.checking(new Expectations() > { > { > - oneOf(mockDocumentAccessBridge).getURL(null, "tex", > null, null); > + > atLeast(2).of(mockDocumentAccessBridge).getURL(null, "tex", null, > null); are 2 calls really part of the contract? If you don't need to test the number of calls you should use allow(). -Vincent > will(returnValue("/xwiki/bin/view/Main/")); > > - oneOf(mockConfiguration).getRenderer(); > + atLeast(2).of(mockConfiguration).getRenderer(); > will(returnValue("snuggletex")); > > - oneOf(mockImageStorage).get(with(any(String.class))); > - will(returnValue(false)); > + > atLeast(2).of(mockImageStorage).get(with(any(String.class))); > + will(returnValue(null)); > > - > oneOf(mockImageStorage).put(with(any(String.class)), > with(any(ImageData.class))); > + > atLeast(2).of(mockImageStorage).put(with(any(String.class)), > with(any(ImageData.class))); > } > }); > } > > Copied: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/ > xwiki-rendering-macro-equation/src/test/resources/ > macroequation1.test (from rev 22456, platform/core/trunk/xwiki- > rendering/xwiki-rendering-macros/xwiki-rendering-macro-equation/src/ > test/resources/macromessage1.test) > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/resources/ > macroequation1.test (rev 0) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/resources/macroequation1.test > 2009-08-10 09:41:27 UTC (rev 22458) > @@ -0,0 +1,18 @@ > +.#----------------------------------------------------- > +.input|xwiki/2.0 > +.#----------------------------------------------------- > +{{equation}}a+b{{/equation}} > +.#----------------------------------------------------- > +.expect|event/1.0 > +.#----------------------------------------------------- > +beginDocument > +beginMacroMarkerStandalone [equation] [] [a+b] > +beginParagraph > +onImage: [/xwiki/bin/view/Main// > 06fbba0acf130efd9e147fdfe91a943cc4f3e29972c6cd1d972e9aabf0900966] > [false] [[alt]=[a+b]] > +endParagraph > +endMacroMarkerStandalone [equation] [] [a+b] > +endDocument > +.#----------------------------------------------------- > +.expect|xwiki/2.0 > +.#----------------------------------------------------- > +{{equation}}a+b{{/equation}} > > Deleted: platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/ > xwiki-rendering-macro-equation/src/test/resources/macromessage1.test > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/resources/macromessage1.test > 2009-08-10 09:03:24 UTC (rev 22457) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki- > rendering-macro-equation/src/test/resources/macromessage1.test > 2009-08-10 09:41:27 UTC (rev 22458) > @@ -1,17 +0,0 @@ > -.#----------------------------------------------------- > -.input|xwiki/2.0 > -.#----------------------------------------------------- > -{{equation}}a+b{{/equation}} > -.#----------------------------------------------------- > -.expect|event/1.0 > -.#----------------------------------------------------- > -beginDocument > -beginMacroMarkerStandalone [equation] [] [a+b] > -beginParagraph > -endParagraph > -endMacroMarkerStandalone [equation] [] [a+b] > -endDocument > -.#----------------------------------------------------- > -.expect|xwiki/2.0 > -.#----------------------------------------------------- > -{{equation}}a+b{{/equation}}

16 years, 1 month

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r22449 - in platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src: main/java/org/xwiki/rendering/internal/macro test/java/org/xwiki/rendering/internal/macro

by Vincent Massol

On Aug 9, 2009, at 9:12 PM, asiri (SVN) wrote: > Author: asiri > Date: 2009-08-09 21:12:30 +0200 (Sun, 09 Aug 2009) > New Revision: 22449 > > Modified: > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/macro/ > DefaultMacroCategoriesManager.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/test/ > java/org/xwiki/rendering/internal/macro/ > DefaultMacroCategoriesManagerTest.java > Log: > XWIKI-4131: Add support for organizing macros by category > > * getMacroNames() should return only macro names, not macro hints. > * Fixed a NPE possibility. > * Added one more test case. > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/ > src/main/java/org/xwiki/rendering/internal/macro/ > DefaultMacroCategoriesManager.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/macro/ > DefaultMacroCategoriesManager.java 2009-08-09 14:04:29 UTC (rev 22448) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/ > java/org/xwiki/rendering/internal/macro/ > DefaultMacroCategoriesManager.java 2009-08-09 19:12:30 UTC (rev 22449) > @@ -19,25 +19,25 @@ > */ > package org.xwiki.rendering.internal.macro; > > +import java.util.Collections; > +import java.util.HashMap; > +import java.util.HashSet; > +import java.util.Map; > +import java.util.Properties; > +import java.util.Set; > + > import org.xwiki.component.annotation.Component; > import org.xwiki.component.annotation.Requirement; > import org.xwiki.component.logging.AbstractLogEnabled; > import org.xwiki.component.manager.ComponentLookupException; > import org.xwiki.component.manager.ComponentManager; > +import org.xwiki.rendering.configuration.RenderingConfiguration; > import org.xwiki.rendering.macro.Macro; > import org.xwiki.rendering.macro.MacroCategoriesManager; > import org.xwiki.rendering.macro.MacroLookupException; > import org.xwiki.rendering.macro.MacroManager; > import org.xwiki.rendering.parser.Syntax; > -import org.xwiki.rendering.configuration.RenderingConfiguration; > > -import java.util.Set; > -import java.util.Collections; > -import java.util.Map; > -import java.util.HashMap; > -import java.util.Properties; > -import java.util.HashSet; > - > /** > * Default implementation of {@link MacroCategoriesManager}. > * > @@ -115,7 +115,7 @@ > return true; > } > }).get(category); > - return Collections.unmodifiableSet(macros); > + return (null != macros) ? > Collections.unmodifiableSet(macros) : Collections.<String>emptySet(); > } > > /** > @@ -131,7 +131,7 @@ > return macroManager.exists(macroName, syntax); > } > }).get(category); > - return Collections.unmodifiableSet(macros); > + return (null != macros) ? > Collections.unmodifiableSet(macros) : Collections.<String>emptySet(); > } > > /** > @@ -152,8 +152,21 @@ > > // Loop through all the macros and categorize them. > Properties categories = > this.configuration.getMacroCategories(); > - for (Map.Entry<String, Macro> entry : allMacros.entrySet()) { > - if (matcher.match(entry.getKey())) { > + for (Map.Entry<String, Macro> entry : allMacros.entrySet()) { > + // Extract macro name. > + String [] hintParts = entry.getKey().split("/"); > + String macroName = null; > + if (hintParts.length > 0) { > + macroName = hintParts[0]; > + } else { > + // Question: Will we ever reach this code? > + getLogger().warn("Invalid macro hint : [" + > entry.getKey() + "]"); > + // Skip this macro. > + continue; > + } This can be improved by sharing code with the MacroManager, by creating some kind of macro syntax parser or factory. Another solution is to rethink they way we register a macro for a given syntax. [snip] Thanks -Vincent

16 years, 1 month

1
1
0 0

[xwiki-devs] Wiki Macro Bridge on 2.0M2 for Groovy (was Re: Macros and JavaScript working together (was Re: [DISCUSSION] XWiki Chart Api & Chart Macro))

by Niels Mayer

On Tue, Aug 4, 2009 at 9:29 AM, Asiri Rathnayake <asiri.rathnayake(a)gmail.com > wrote: > > The wiki macro bridge has been released with 2.0M2. ... > > If you come across any problems while you are at it, we can improve wiki > macro bridge :) > Thanks for reminding me about the Xwiki macro bridge. Looks great and is a big improvement over how things were done previously. Your message was timely as helped me answer one of my big questions about having groovy or clojure macros available on virtual-wiki setup: http://platform.xwiki.org/xwiki/bin/view/DevGuide/WikiMacroTutorial - Wiki macro authors need to have programming rights - Wiki macros can only be defined inside the main wiki, though they can be used throughout a farm I wrote my first macro-bridge macro (see attachment Main.TestMacroBridge.xar ) in groovy in preparation for my experiments with scripting in Clojure. The hardest thing was finding out that the name of "context" had changed to "xcontext" for groovy and other JSR-223 languages, whereas velocity (and WikiMacroTutorial) uses "context". This has been discussed on the lists ( http://markmail.org/message/o2trzrnv5xts6x6v ), and the WikiMacroTutorial needs updating to reflect the final status & naming-conventions. My macro is quite simple. but does a lot, taken from here: http://www.ibm.com/developerworks/java/library/j-pg05199/index.html Usage: {{weather_by_zip zip=92625 /}} Code: ............................... Objects of type XWiki.WikiMacroClass WikiMacroClass 0: weather_by_zip {{script language=groovy}} def rss = new XmlSlurper().parseText((" http://weather.yahooapis.com/forecastrss?p=" + xcontext.macro.params.zip).toURL().text) println rss.channel.title println "Sunrise: ${rss.channel.astronomy.@sunrise}" println "Sunset: ${rss.channel.astronomy.@sunset}" println "Currently:" println "\t" + rss.channel.item.condition.@date println "\t" + rss.channel.item.condition.@temp println "\t" + rss.channel.item.condition.@text {{/script}} Objects of type XWiki.WikiMacroParameterClass WikiMacroParameterClass 0: zip ............................... May be you can put it to test by trying to implement your chart macro ;) It would be more useful to offer all-new Exhibit<http://www.simile-widgets.org/exhibit/> functionality with tighter integration into the Xwiki back-end, e.g. having document/space and other Xwiki "model" information abstractly available to an Exhibit-based "view/controller" to provide a "faceted views" presentation of Xwiki documents and contents. FYI, My existing Exhibit integration with Xwiki demo: http://nielsmayer.com/xwiki/bin/view/Exhibit/Presidents4 (source: http://nielsmayer.com/xwiki/bin/download/Exhibit/Presidents4/Presidents4Pkg…) My main commitment right now is an experiment to see if I can get JSR223-supported Clojure scripting in Xwiki. This message didn't give me much hope of success right now ( http://groups.google.com/group/clojure/msg/ad811b69d448e3db ) but I'll give Clojure on Xwiki a try anyways, and revisit later if it's just a matter of getting more solid JSR223 support for Clojure as development progresses. Niels http://nielsmayer.com

16 years, 1 month

2
5
0 0

[xwiki-devs] [VOTE] Use JUnit 4.x and JMock 2.x for all new code

by Vincent Massol

For an example: http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-observation/sr… If you need to access components you should use AbstractComponentTestCase from shared-tests (instead of AbstractXWikiComponentTestCase which is for JUnit 3.x and JMock 1.x). Here's my +1 Thanks -Vincent

16 years, 1 month

7
6
0 0

[xwiki-devs] [VOTE] Remove the TableTraining page from the Sandbox space

by Guillaume Lerouge

Hi Devs, as described in http://jira.xwiki.org/jira/bro wse/XE-472<http://jira.xwiki.org/jira/browse/XE-472> , I've rewritten the Sandbox space in syntax 2.0. Since operations in table (Sum, multiplication etc...) are not yet supported in XWiki 2.0 syntax, I suggest we remove the Sandbox.TableTraining page for the time being instead of keeping a XWiki 1.0 syntax page in the Sandbox since it doesn't bring much value and cannot be converted satisfactorily as of today. I can't remember any recent email about operations in tables on this list (at least not in the past 2 years), thus I think removing it won't cause too many problems. I'll rewrite it later if / when the new syntax supports such operations once again. Here's my +1 for removing the Sandbox.TableTraining page. Thanks for your feedback, Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/

16 years, 1 month

7
7
0 0

[xwiki-devs] [VOTE] API change for Rendering module

by Vincent Massol

Hi, I'd like to propose the following API changes to the Rendering module: 1) Modify PrintRendererFactory a) There's now one factory component per Renderer type with the following interface: public interface PrintRendererFactory { /** * @return the Syntax supported by the Renderer type * @since 2.0M3 */ Syntax getSyntax(); /** * @param printer the printer to use to output renderer data * @return a new Renderer instance (stateful) * @since 2.0M3 */ PrintRenderer createRenderer(WikiPrinter printer); } b) The getAvailableSynatxes() doesn't exist anymore. It's been moved to SyntaxFactory, see below. 2) Modify SyntaxFactory a) Remove getAvailableSyntaxes() since there are different types of syntaxes: Parser syntaxes, Renderer syntaxes and even amongst Parser/ Renderer there will be different types of them: streaming, block. Thus the new strategy is for client code to directly ask for syntaxes by looking up the objects against the CM. getAvailableSyntaxes() has been deprecated. 3) Introduce BlockRenderer @ComponentRole public interface BlockRenderer { /** * @param block the block to render in the target syntax * @param printer the object where to output the result of the rendering */ void render(Block block, WikiPrinter printer); /** * @param blocks the list of blocks to render in the target syntax * @param printer the object where to output the result of the rendering * @todo remove this API once we introduce the notion of BlockCollection */ void render(Collection<Block> blocks, WikiPrinter printer); } Goals: a) Have 2 types of Renderers (as we'll have 2 types of Parsers in the future): Stream and Block b) reduce code duplication since using the BlockRenderer will simplify the client code 4) Introduce Converter @ComponentRole public interface Converter { void convert(Reader source, Syntax sourceSyntax, Syntax targetSyntax, WikiPrinter printer) throws ConversionException; } Goal: Simplify client code when the need is pure conversion. 5) Move Renderer's implementation classes (components now) in the internal package They're now components and thus we can move them in the internal package. Here's my +1 to all Thanks -Vincent

16 years, 1 month

5
6
0 0

[xwiki-devs] [VOTE] Generic stub XWikiContext provider and initializer

by Thomas Mortagne

Hi devs, Remote observation manager receive remote events and convert before injecting it in a specific thread. For this to work properly as usual the execution context need to be initialized for this thread. Initialize ExecutionContext is pretty clean and component oriented but we also need a stub XWikiContext initialized in the ExecutionContext. I propose to implements a generic stib xwiki context initializer and provider: the initializer react to ExecutionContextInitializer, when receiving the first ExecutionContext initialization containing a XWikiContext it call XWikiStubContextProvider.initialize to create a XWiki context independent from the request but still containing scheme/host/port information and when ExecutionContextInitializer is called with a ExecutionContext which doe snot contains any XWikiContext a clone of the stub XWikiContext is injected in the Execution context. To resume, it uses the first request generated XWikiContext to create an XWikiContext independent form the request and use it to generate default XWikiContext for thread not generated by the application server when theses are initializing ExecutionContext. WDYT ? -- Thomas Mortagne

16 years, 1 month

2
2
0 0

[xwiki-devs] [Proposal] Putting the Component Manager in the Script Context for script engines having programming rights

by Vincent Massol

The idea is that if you have programming rights you should probably be allowed to access components and possibly even register new components. WDYT? Thanks -Vincent

16 years, 1 month

1
0
0 0

[xwiki-devs] [VOTE] Rule for naming configuration properties

by Vincent Massol

Hi, After discussing with thomas here's what we propose: * remove the org.xwiki or com.xpn.xwiki part before the module name * use <module>.<propertyName>. Ex: rendering.linkLabelFormat * for submodules use <module>.<sunmodule>.<propertyName>. Ex: rendering.macro.velocity.filter. ** Note1: the current property for the macro velocity filter is wrongly named: macro.velocity.filter. That would need to be fixed at some point. ** Note2: the configs in xwiki-rendering-xwiki module should be named rendering.xwiki.linkLabelFormat. We'll need to fix this at some point or rename that module to some other name. Or find a sub rule to handle this case. * use camelcase for the property name itself. ex: linkLabelFormat Here's my +1 Thanks -Vincent

16 years, 1 month

3
2
0 0

[xwiki-devs] [Proposal] Configuration keys for Macro Categories

by Vincent Massol

Hi, After a discussion with Thomas we'd like to propose the following format for defining macro categories in xwiki.properties: rendering.macroCategories = <macro id>=<cateogory name> Ex: rendering.macroCategories = toc:presentation rendering.macroCategories = velocity=code Internally the config will be available from RenderingConfiguration: public interface RenderingConfiguration { /** * A link label format is the format used to decide how to display links that have no label. * By default the page name is displayed. However it's possible to customize it using the * following tokens: * <ul> * <li>%w: wiki name</li> * <li>%s: space name</li> * <li>%p: page name</li> * <li>%P: page name with spaces between camel case words, i.e. "My Page" * if the page name is "MyPage"</li> * <li>%t: page title</li> * </ul> * Note that if the page title is empty or not defined then it defaults to %p. This is also the case * if the title cannot be retrieved for the document. * * The default is "%p". Some examples: "%s.%p", "%w:%s.%p". * * @return the format to use to display link labels when the user hasn't specified a label */ String getLinkLabelFormat(); /** * @return the category names to use for the macros. These are the categories under which they'll be listed * in UIs for example. If a category for a macro is null then the category defined in the macro * descriptor (ie defined by the macro author) will be used */ Properties getMacroCategories(); WDYT? If no negative comments are given I'd like to implement this ASAP. Thanks -Vincent

16 years, 1 month

3
2
0 0

[xwiki-devs] [Fwd: [people] CFP: ISWC 2009 Workshop on Collaborative Construction, Management and Linking of Structured Knowledge]

by [Ricardo Rodriguez] Your EPEC Network ICT Team

Sorry for being late with this message! The deadline for paper submission is 10 August 2009, but only now I've regained access to the nepomuk-kde list. Greetings, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team

16 years, 1 month

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r22431 - in sandbox/gsoc/importexport/xwiki-core-importer/src: main/java/org/xwiki/platform main/java/org/xwiki/platform/internal test/java/org/xwiki/platform/mediawiki

by Vincent Massol

Hi Arun, On Aug 8, 2009, at 10:29 PM, arun (SVN) wrote: > Author: arun > Date: 2009-08-08 22:29:54 +0200 (Sat, 08 Aug 2009) > New Revision: 22431 > > Modified: > sandbox/gsoc/importexport/xwiki-core-importer/src/main/java/org/ > xwiki/platform/WikiImporter.java > sandbox/gsoc/importexport/xwiki-core-importer/src/main/java/org/ > xwiki/platform/internal/ConfluenceWikiImporter.java > sandbox/gsoc/importexport/xwiki-core-importer/src/main/java/org/ > xwiki/platform/internal/MediaWikiImporter.java > sandbox/gsoc/importexport/xwiki-core-importer/src/test/java/org/ > xwiki/platform/mediawiki/MediaWikiTest.java > Log: > [Changes] > New Rendering Module Syntax Converter component is used to conver > Wiki Syntax. > > > Modified: sandbox/gsoc/importexport/xwiki-core-importer/src/main/ > java/org/xwiki/platform/WikiImporter.java > =================================================================== > --- sandbox/gsoc/importexport/xwiki-core-importer/src/main/java/org/ > xwiki/platform/WikiImporter.java 2009-08-08 19:44:33 UTC (rev 22430) > +++ sandbox/gsoc/importexport/xwiki-core-importer/src/main/java/org/ > xwiki/platform/WikiImporter.java 2009-08-08 20:29:54 UTC (rev 22431) > @@ -44,9 +44,9 @@ > T parse(byte[] bytes) throws Exception; > > /** > - * Creates XWiki Pages based on the given Wiki Instance and > Wiki Type > + * Import Wiki content based on the given Wiki Instance and > Wiki Type > * > - * @param wiki Wiki object returned by {@link > #processInputDump(byte[], String)} > + * @param wiki Wiki object returned after parsing the input. > * @return Summary of import process as a list. > * @throws Exception > */ > > Modified: sandbox/gsoc/importexport/xwiki-core-importer/src/main/ > java/org/xwiki/platform/internal/ConfluenceWikiImporter.java > =================================================================== > --- sandbox/gsoc/importexport/xwiki-core-importer/src/main/java/org/ > xwiki/platform/internal/ConfluenceWikiImporter.java 2009-08-08 > 19:44:33 UTC (rev 22430) > +++ sandbox/gsoc/importexport/xwiki-core-importer/src/main/java/org/ > xwiki/platform/internal/ConfluenceWikiImporter.java 2009-08-08 > 20:29:54 UTC (rev 22431) > @@ -20,6 +20,7 @@ > package org.xwiki.platform.internal; > > import java.io.ByteArrayInputStream; > +import java.io.StringReader; > import java.util.ArrayList; > import java.util.Iterator; > import java.util.List; > @@ -38,11 +39,11 @@ > import org.xwiki.platform.internal.confluence.ConfluenceSpace; > import org.xwiki.platform.internal.confluence.ConfluenceWiki; > import org.xwiki.platform.internal.confluence.ProcessConfluenceXml; > -import org.xwiki.platform.parser.ImportWikiParser; > -import org.xwiki.platform.renderer.ImportWikiRenderer; > import org.xwiki.platform.wiki.Summary; > +import org.xwiki.rendering.converter.Converter; > import org.xwiki.rendering.parser.Syntax; > -import org.xwiki.rendering.parser.SyntaxType; > +import org.xwiki.rendering.renderer.printer.DefaultWikiPrinter; > +import org.xwiki.rendering.renderer.printer.WikiPrinter; > > /** > * Confluence Wiki Importer processes the Input data and creates > wiki pages. > @@ -66,11 +67,8 @@ > private DocumentAccessBridge docAccessBridge; > > @Requirement > - private ImportWikiParser parser; > + private Converter converter; > > - @Requirement > - private ImportWikiRenderer renderer; > - > /** > * Process Input data and returns Wiki object of Confluence Wiki > Type. > * > @@ -153,7 +151,6 @@ > { > Map<String, ConfluenceRevision> revisions = > page.getConfluenceRevisions(); > Iterator<String> iterator = revisions.keySet().iterator(); > - Syntax syntax = new Syntax(SyntaxType.CONFLUENCE, "1.0"); > String title = ""; > > // Title > @@ -169,7 +166,9 @@ > // Revisions. > while (iterator.hasNext()) { > ConfluenceRevision rev = revisions.get(iterator.next()); > - String text = > this > .renderer.renderFromWikiXdom(this.parser.getWikiXdom(rev.getText(), > syntax)); > + WikiPrinter printer = new DefaultWikiPrinter(); > + converter.convert(new StringReader(rev.getText()), > Syntax.CONFLUENCE_1_0, Syntax.XWIKI_2_0, printer); > + String text = printer.toString(); > this.docAccessBridge.setDocumentContent(title, text, > rev.getComment(), rev.getMinorEdit()); > > } > > Modified: sandbox/gsoc/importexport/xwiki-core-importer/src/main/ > java/org/xwiki/platform/internal/MediaWikiImporter.java > =================================================================== > --- sandbox/gsoc/importexport/xwiki-core-importer/src/main/java/org/ > xwiki/platform/internal/MediaWikiImporter.java 2009-08-08 19:44:33 > UTC (rev 22430) > +++ sandbox/gsoc/importexport/xwiki-core-importer/src/main/java/org/ > xwiki/platform/internal/MediaWikiImporter.java 2009-08-08 20:29:54 > UTC (rev 22431) > @@ -20,6 +20,7 @@ > package org.xwiki.platform.internal; > > import java.io.ByteArrayInputStream; > +import java.io.StringReader; > import java.util.ArrayList; > import java.util.List; > > @@ -34,11 +35,11 @@ > import org.xwiki.platform.internal.mediawiki.MediaWikiPage; > import org.xwiki.platform.internal.mediawiki.MediaWikiRevision; > import org.xwiki.platform.internal.mediawiki.ProcessMediaWikiXml; > -import org.xwiki.platform.parser.ImportWikiParser; > -import org.xwiki.platform.renderer.ImportWikiRenderer; > import org.xwiki.platform.wiki.Summary; > +import org.xwiki.rendering.converter.Converter; > import org.xwiki.rendering.parser.Syntax; > -import org.xwiki.rendering.parser.SyntaxType; > +import org.xwiki.rendering.renderer.printer.DefaultWikiPrinter; > +import org.xwiki.rendering.renderer.printer.WikiPrinter; > > /** > * Default Wiki Importer - Imports other Wiki types into XWiki. > @@ -62,11 +63,8 @@ > private DocumentAccessBridge docAccessBridge; > > @Requirement > - private ImportWikiParser parser; > + private Converter converter; > > - @Requirement > - private ImportWikiRenderer renderer; > - > public void initialize() throws InitializationException > { > getLogger().debug("MediaWiki Importer Intialized"); > @@ -113,16 +111,18 @@ > private List<Summary> importMediaWiki(MediaWiki mediawiki) > throws Exception > { > List<Summary> wikiSummary = new ArrayList<Summary>(); > - Syntax syntax = new Syntax(SyntaxType.MEDIAWIKI, "1.0"); > > // For every mediawiki page > for (MediaWikiPage mediaWikiPage : mediawiki.getWikiPages()) { > // Fore every mediawiki revision of a page > for (MediaWikiRevision mediaWikiRevision : > mediaWikiPage.getRevisions()) { > > - // Read the body content parse it to xdom and > render it into XWiki Syntax. > - String text = > - > this > .renderer > .renderFromWikiXdom > (this.parser.getWikiXdom(mediaWikiRevision.getText(), syntax)); > + // Read the body content convert it into XWiki > Syntax. > + WikiPrinter printer = new DefaultWikiPrinter(); > + converter.convert(new > StringReader(mediaWikiRevision.getText()), Syntax.MEDIAWIKI_1_0, > + Syntax.XWIKI_2_0, printer); > + String text = printer.toString(); > + > // Create the page using document access bridge > > this.docAccessBridge.setDocumentContent(mediaWikiPage.getPageName(), > text, mediaWikiRevision > .getComment(), mediaWikiRevision.getMinorEdit()); > > Modified: sandbox/gsoc/importexport/xwiki-core-importer/src/test/ > java/org/xwiki/platform/mediawiki/MediaWikiTest.java > =================================================================== > --- sandbox/gsoc/importexport/xwiki-core-importer/src/test/java/org/ > xwiki/platform/mediawiki/MediaWikiTest.java 2009-08-08 19:44:33 UTC > (rev 22430) > +++ sandbox/gsoc/importexport/xwiki-core-importer/src/test/java/org/ > xwiki/platform/mediawiki/MediaWikiTest.java 2009-08-08 20:29:54 UTC > (rev 22431) > @@ -19,15 +19,21 @@ > */ > package org.xwiki.platform.mediawiki; > > +import java.io.StringReader; > import java.util.List; > import java.util.Map; > import java.util.TreeMap; > > import junit.framework.TestCase; > > +import org.xwiki.component.embed.EmbeddableComponentManager; > import org.xwiki.platform.internal.mediawiki.MediaWiki; > import org.xwiki.platform.internal.mediawiki.MediaWikiPage; > import org.xwiki.platform.internal.mediawiki.ProcessMediaWikiXml; > +import org.xwiki.rendering.converter.Converter; > +import org.xwiki.rendering.parser.Syntax; > +import org.xwiki.rendering.renderer.printer.DefaultWikiPrinter; > +import org.xwiki.rendering.renderer.printer.WikiPrinter; > > /** > * @version $Id$ > @@ -66,5 +72,21 @@ > > } > > + public void renderXWiki20SyntaxAsXHTML() throws Exception > + { > + // Initialize Rendering components and allow getting > instances > + EmbeddableComponentManager ecm = new > EmbeddableComponentManager(); > + ecm.initialize(this.getClass().getClassLoader()); This should be getComponentManager() instead from AbstractComponentTestCase Thanks -Vincent > + > + // Use a the Converter component to convert between one > syntax to another. > + Converter converter = ecm.lookup(Converter.class); > > + // Convert input in XWiki Syntax 2.0 into XHTML. The result > is stored in the printer. > + WikiPrinter printer = new DefaultWikiPrinter(); > + converter.convert(new StringReader("This is **bold**"), > Syntax.XWIKI_2_0, Syntax.XHTML_1_0, printer); > + > + assertEquals("This is bold", > printer.toString()); > + } > +

16 years, 1 month

1
0
0 0

[xwiki-devs] [DISCUSSION] Implementing an XWiki component in groovy

by Asiri Rathnayake

Hi All, When working on officeimporter document splitting feature we wanted to make it possible to provide hooks so that the whole import process can be customized external to the officeimporter module via a groovy class (on a wiki page). Since we were in a little hurry, the solution we devised might be called "hackish"; we provided the following interface which can be implemented in groovy: <code> public interface OfficeImporterFilter { void filter(String documentName, Document document); void filter(String documentName, XDOM xdom, boolean isSplit); String filter(String documentName, String content, boolean isSplit); void setDocBridge(DocumentAccessBridge docBridge); } </code> Now, Officeimporter application would pass a parameter into DefaultOfficeImporter indicating the wiki page which contains the groovy filter implementation. Then we do something like: <code> String groovyFilterParam = params.get("groovyFilter"); String groovyScript = docBridge.getDocumentContent(groovyFilterParam); GroovyClassLoader gcl = new GroovyClassLoader(); OfficeImporterFilter importerFilter = (OfficeImporterFilter) gcl.parseClass(groovyScript).newInstance(); importerFilter.setDocBridge(docBridge); return importerFilter; } </code> The purpose of setDocBridge() method is to inject the DAB into the filter so that it can access wiki documents. Now I question myself why it is not possible for a groovy class to access wiki documents without the DAB. This also proves that this solution was not well planned or discussed with the community. Another problem with the filter interface is that it does several things. It would have been better to have three filters instead. Now to the topic of this email; if we can allow groovy code to implement XWiki components (if it is possible), we can make this whole thing very simple. For an example, officeimporter application would pass the role-hint of the component implementing a particular filter (which is a groovy implementation) and DefaultOfficeImporter will simply lookup this component and use it. As for implementing this kind of a mechanism, we can follow something similar to what we did with wiki macros. A special class XWiki.XWikiComponent would contain fields like componentRole (String), roleHint (String) & groovyClass(TextArea) and when a document with an object of XWiki.WikiComponent is saved, we can register a new component against the CM. This idea was suggested to me by vincent & I thought it's time to start a discussion about this to see what others think. Although I have few unclear points (like how dependency injection would work), I think it would be a handy tool to have. Thanks in advance for your comments & suggestions :) - Asiri PS: OfficeImporter code has been polluted a lot because I have stuffed a lot of features into it without properly designing them. I will be refactoring officeimporter a little by little in coming days (as time permits).

16 years, 1 month

2
2
0 0

[xwiki-devs] [VOTE] Remove TransformationManager in Rendering module

by Vincent Massol

Hi, I'm proposing to remove the TxManager. Reason: * We need to offer a way for users of the rendering to control which transformations are executed. * It'll become clear to users of the rendering api how their XDOM will be transformed. Right now they didn't even know they were running macro transformation when they used the TxManager. Here's my +1 Thanks -Vincent

16 years, 1 month

1
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r22420 - in platform/core/trunk/xwiki-containers: xwiki-container-api/src/main/java/org/xwiki/container xwiki-container-portlet/src/main/java/org/xwiki/container/portlet xwiki-container-servlet/src/main/java/org/xwiki/container/servlet

by Vincent Massol

On Aug 8, 2009, at 12:42 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-08-08 12:42:34 +0200 (Sat, 08 Aug 2009) > New Revision: 22420 > > Modified: > platform/core/trunk/xwiki-containers/xwiki-container-api/src/main/ > java/org/xwiki/container/Response.java > platform/core/trunk/xwiki-containers/xwiki-container-portlet/src/ > main/java/org/xwiki/container/portlet/PortletResponse.java > platform/core/trunk/xwiki-containers/xwiki-container-servlet/src/ > main/java/org/xwiki/container/servlet/ServletResponse.java > Log: > XWIKI-4134: Add methods for writing content to the Response component > Done. > > Modified: platform/core/trunk/xwiki-containers/xwiki-container-api/ > src/main/java/org/xwiki/container/Response.java > =================================================================== > --- platform/core/trunk/xwiki-containers/xwiki-container-api/src/ > main/java/org/xwiki/container/Response.java 2009-08-08 00:04:58 UTC > (rev 22419) > +++ platform/core/trunk/xwiki-containers/xwiki-container-api/src/ > main/java/org/xwiki/container/Response.java 2009-08-08 10:42:34 UTC > (rev 22420) > @@ -20,6 +20,32 @@ > */ > package org.xwiki.container; > > +import java.io.IOException; > +import java.io.OutputStream; > + > public interface Response > { > + /** > + * Returns an OutputStream suitable for writing binary data in > the response. > + * > + * @return the binary OutputStream for the response, or {@code > null} if the response does not allow writing data > + * @throws IOException if an output exception occurred > + */ > + OutputStream getOutputStream() throws IOException; > + > + /** > + * Sets the length of the content body in the response. If this > length is not relevant to the type of connection, it > + * will simply be ignored. > + * > + * @param length an integer specifying the length of the > content being returned to the client > + */ > + void setContentLength(int length); > + > + /** > + * Sets the content type of the response being sent to the > client, as a MIME type string. For example, {@code > + * text/html}. If the MIME type is not relevant to the type of > connection, it will simply be ignored. > + * > + * @param mimeType the MIME type for this response, according > to the RFC 2045. > + */ > + void setContentType(String mimeType); > } > > Modified: platform/core/trunk/xwiki-containers/xwiki-container- > portlet/src/main/java/org/xwiki/container/portlet/PortletResponse.java > =================================================================== > --- platform/core/trunk/xwiki-containers/xwiki-container-portlet/src/ > main/java/org/xwiki/container/portlet/PortletResponse.java > 2009-08-08 00:04:58 UTC (rev 22419) > +++ platform/core/trunk/xwiki-containers/xwiki-container-portlet/src/ > main/java/org/xwiki/container/portlet/PortletResponse.java > 2009-08-08 10:42:34 UTC (rev 22420) > @@ -20,6 +20,11 @@ > */ > package org.xwiki.container.portlet; > > +import java.io.IOException; > +import java.io.OutputStream; > + > +import javax.portlet.RenderResponse; > + > import org.xwiki.container.Response; > > public class PortletResponse implements Response > @@ -35,4 +40,33 @@ > { > return this.portletResponse; > } > + > + /** > + * {@inheritDoc} > + */ > + public OutputStream getOutputStream() throws IOException > + { > + if (this.portletResponse instanceof RenderResponse) { > + return ((RenderResponse) > this.portletResponse).getPortletOutputStream(); > + } > + return null; > + } > + > + /** > + * {@inheritDoc} > + */ > + public void setContentLength(int length) > + { > + // No content length for portlets, do nothing > + } > + > + /** > + * {@inheritDoc} > + */ > + public void setContentType(String mimeType) > + { > + if (this.portletResponse instanceof RenderResponse) { > + ((RenderResponse) > this.portletResponse).setContentType(mimeType); > + } > + } > } > > Modified: platform/core/trunk/xwiki-containers/xwiki-container- > servlet/src/main/java/org/xwiki/container/servlet/ServletResponse.java > =================================================================== > --- platform/core/trunk/xwiki-containers/xwiki-container-servlet/src/ > main/java/org/xwiki/container/servlet/ServletResponse.java > 2009-08-08 00:04:58 UTC (rev 22419) > +++ platform/core/trunk/xwiki-containers/xwiki-container-servlet/src/ > main/java/org/xwiki/container/servlet/ServletResponse.java > 2009-08-08 10:42:34 UTC (rev 22420) > @@ -20,10 +20,13 @@ > */ > package org.xwiki.container.servlet; > > -import org.xwiki.container.Response; > +import java.io.IOException; > +import java.io.OutputStream; > > import javax.servlet.http.HttpServletResponse; > > +import org.xwiki.container.Response; > + > public class ServletResponse implements Response > { > private HttpServletResponse httpServletResponse; > @@ -37,4 +40,32 @@ > { > return this.httpServletResponse; > } > + > + /** > + * {@inheritDoc} > + */ > + public OutputStream getOutputStream() throws IOException > + { > + try { > + return this.httpServletResponse.getOutputStream(); > + } catch (IllegalStateException ex) { > + return null; Why don"'t you throw an IOException instead of returning null? Thanks -Vincent > + } > + } > + > + /** > + * {@inheritDoc} > + */ > + public void setContentLength(int length) > + { > + this.httpServletResponse.setContentLength(length); > + } > + > + /** > + * {@inheritDoc} > + */ > + public void setContentType(String mimeType) > + { > + this.httpServletResponse.setContentType(mimeType); > + } > }

16 years, 1 month

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r22419 - in platform: core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/doc core/trunk/xwiki-rendering/xwiki-rendering-api core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/parser core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer core/trunk/xwiki-rendering/xwiki-rendering-api

by Jerome Velociter

vmassol (SVN) wrote: > Author: vmassol > Date: 2009-08-08 02:04:58 +0200 (Sat, 08 Aug 2009) > New Revision: 22419 > > Added: > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/event/EventsChainingRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/plain/PlainTextChainingRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/AnnotatedXHTMLBlockRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/AnnotatedXHTMLChainingRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/AnnotatedXHTMLImageRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/AnnotatedXHTMLLinkRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/AnnotatedXHTMLRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/AnnotatedXHTMLRendererFactory.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/XHTMLChainingRenderer.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/listener/chaining/EmptyBlockChainingListener.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/test/java/org/xwiki/rendering/listener/chaining/EmptyBlockChainingListenerTest.java > Removed: > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/chaining/ > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/renderer/printer/MonitoringWikiPrinter.java > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Document.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/XWiki.java > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java > platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/doc/XWikiDocumentRenderingTest.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/parser/DefaultSyntaxFactory.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/AbstractBlockRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/AbstractPrintRendererFactory.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/event/EventRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/plain/PlainTextRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/DefaultXHTMLImageRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/DefaultXHTMLLinkRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/XHTMLBlockRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/XHTMLMacroRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/XHTMLRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xwiki/XWikiSyntaxRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/parser/Syntax.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/parser/SyntaxType.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/renderer/printer/XHTMLWikiPrinter.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/renderer/xhtml/XHTMLImageRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/renderer/xhtml/XHTMLLinkRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/resources/META-INF/components.txt > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/test/java/org/xwiki/rendering/listener/chaining/LookaheadChainingListenerTest.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/test/java/org/xwiki/rendering/parser/SyntaxTest.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-box/src/test/resources/macrobox5.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-box/src/test/resources/macrobox6.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-chart/src/test/resources/macrochart1.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-chart/src/test/resources/macrochart2.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-chart/src/test/resources/macrochart3.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-chart/src/test/resources/macrochart4.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-code/src/main/java/org/xwiki/rendering/internal/parser/pygments/PygmentsParser.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-code/src/test/resources/macrocode7.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/main/java/org/xwiki/rendering/internal/macro/html/HTMLMacroXHTMLChainingRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/main/java/org/xwiki/rendering/internal/macro/html/HTMLMacroXHTMLRenderer.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/main/java/org/xwiki/rendering/internal/macro/html/HTMLMacroXHTMLRendererFactory.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/test/resources/macrohtml1.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/test/resources/macrohtml10.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/test/resources/macrohtml11.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/test/resources/macrohtml13.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/test/resources/macrohtml14.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/test/resources/macrohtml15.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/test/resources/macrohtml16.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/test/resources/macrohtml2.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/test/resources/macrohtml8.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-html/src/test/resources/macrohtml9.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-id/src/test/resources/macroid1.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-id/src/test/resources/macroid2.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-rss/src/test/resources/macrorss1.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-rss/src/test/resources/macrorss2.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-toc/src/test/resources/macrotoc8.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-toc/src/test/resources/macrotoc9.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/test/resources/macrovelocity1.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/test/resources/macrovelocity4.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/test/resources/macrovelocity5.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/test/resources/macrovelocity6.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/test/resources/macrovelocity7.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-velocity/src/test/resources/macrovelocity8.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/java/org/xwiki/rendering/internal/parser/DefaultSyntaxFactoryTest.java > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/escape/escape10.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/escape/escape15.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/escape/escape16.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/escape/escape17.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/escape/escape7.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/image/image1.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/image/image2.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/image/image3.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/image/image4.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links1.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links10.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links12.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links13.test > 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/links15.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links16.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links17.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links18.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links2.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links20.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links21.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links3.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links4.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links5.test > 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/links7.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links8.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/link/links9.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/macros/macro1.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/macros/macro10.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/macros/macro11.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/macros/macro12.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/macros/macro13.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/macros/macro14.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/macros/macro5.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/macros/macro6.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/macros/macro7.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/macros/macro8.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/macros/macro9.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/paragraph/paragraph4.test > platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/resources/section/section10.test > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js > platform/web/trunk/standard/src/main/webapp/templates/wysiwyginput.vm > platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/server/DefaultWysiwygService.java > platform/web/trunk/wysiwyg/src/main/java/com/xpn/xwiki/wysiwyg/server/converter/internal/DefaultHTMLConverter.java > Log: > XWIKI-4028: Use a XHTML renderer that doesn't add round-trip comments when viewing a wiki page in view mode in ordre to improve performances > > + various refactorings (SyntaxType improvement and others) > > [snip] > > Modified: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js 2009-08-07 19:35:57 UTC (rev 22418) > +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js 2009-08-08 00:04:58 UTC (rev 22419) > @@ -363,39 +363,23 @@ > > // Section count starts at one, not zero. > var sectioncount = 1; > - // We can't use element.select() since it does not allow to retrieve comment nodes. > - var nodes = $("xwikicontent").childNodes; > - // We don't have to use a macro depth variable since multiple macro levels will generate only one comment. > - var withinmacro = false; > - > - for (var i = 0; i < nodes.length; i++) { > - var node = $(nodes[i]); > + > + // For all non-generated headers, add a SPAN and A element in order to be able to edit the section. > + $('xwikicontent').select('h1:not([class~=wikigeneratedheader])', > + 'h2:not([class~=wikigeneratedheader])').each(function(header) { Moving the dom injection in a named method + using "invoke" (http://www.prototypejs.org/api/enumerable/invoke) instead of "each" might perform better on documents with a lot of non-generated headers. See http://www.prototypejs.org/api/enumerable/each > > - // Deactivate "edit section" links insertion when we are in content generated by a macro. > - // Examples: include macro, velocity macro. > - if (node.nodeName == "#comment") { > - if (node.data.match(/^startmacro/) != null) { > - withinmacro = true; > - } else if (node.data == "stopmacro") { > - withinmacro = false; > - } > - } > + var editspan = document.createElement("SPAN"); > + var editlink = document.createElement("A"); > > - // Insert "edit section" links after level 1 and level 2 headings. > - if (withinmacro == 0 && (node.nodeName == "H1" || node.nodeName == "H2")) { > - var editspan = document.createElement("SPAN"); > - var editlink = document.createElement("A"); > - > - editlink.href = window.docediturl + "?section=" + sectioncount; > - editlink.style.textDecoration = "none"; > - editlink.innerHTML = "$msg.get('edit')"; > - editspan.className = "edit_section"; > + editlink.href = window.docediturl + "?section=" + sectioncount; > + editlink.style.textDecoration = "none"; > + editlink.innerHTML = "$msg.get('edit')"; > + editspan.className = "edit_section"; There is an easier way of doing this, using prototype : var editlink = new Element("link", { "href": window.docediturl + "?section=" + sectioncount, "style" : "text-decoration:none", "class" : "edit_section" } ).update("$msg.get('edit')"); > > - editspan.appendChild(editlink); > - node.insert( { 'after': editspan } ); > - sectioncount++; > - } > - } > + editspan.appendChild(editlink); > + header.insert( { 'after': editspan } ); > + sectioncount++; > + }); > } > }, > > > [snip] > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

16 years, 1 month

1
0
0 0

[xwiki-devs] [VOTE] Special event matching all events

by Thomas Mortagne

Hi, For network event distribution I need to be able to receive all events (because it's not done by ObservationManager itself but by an external module). Currently ObservationManager only match events with the exact same class so it's impossible to match all events or event several events of same subject like documents event for example. I don't have time to design a generic multievent matcher and a redesign of the OM is already started for activity stream so for now I propose to introduce a special AllEvent event ObservationManager will trait as a particular case when returned by a listener (with lots of comments of course). WDYT ? here is my +1 -- Thomas Mortagne

16 years, 1 month

2
2
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