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

[xwiki-devs] [ANN] XWiki Enterprise Manager 1.7.3 Released
by Jean-Vincent Drean 12 Aug '09

12 Aug '09

The XWiki development team is pleased to announce the release of XWiki Enterprise Manager 1.7.3. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download XWiki Enterprise Manager 1.7.3 uses XWiki Enterprise 1.9.3. For more information see the release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise193 Thanks, The XWiki dev team

1 0

[xwiki-devs] [ANN] XWiki Enterprise 1.9.3 Released
by Jean-Vincent Drean 12 Aug '09

12 Aug '09

The XWiki development team is pleased to announce the release of XWiki Enterprise 1.9.3. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is a bug fix and enhancement release mainly around security and the tag and mailsender applications. Changes since XWiki Enterprise 1.9.2. Improvements: * XWIKI-4065 New Footnote macro Important Bugs fixed: * XWIKI-4109: Guest users are sometimes logged in with another user account * XWIKI-3827: GWT wysiwyg editor has dark background with Albatross skin * XPMAIL-17: Wrong characters in non-ascii emails * XATAG-21: List documents with tag, rename/delete tag fails with specific versions of MySQL5 * XATAG-22: Rename and delete actions fail with tag containing non-ascii chars * XABLOG-27: Article date not displayed properly in IE6 For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise193 Thanks, The XWiki dev team

1 0

[xwiki-devs] [Proposal] Wiki 2.0 Menu
by Ecaterina Valica 12 Aug '09

12 Aug '09

Hi, Please give feedback on the menu iteration. You can view the mockups at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20Menu 1. We need to decide the way we handle the actions we are able to do (depending on the rights we have): enable/disable them or hide them. 2. You can select to have an simple or advanced menu (View and Edit submenus affected) Thanks, Caty

5 9

[xwiki-devs] [VOTE] Move remote observation manager from sandbox to core
by Thomas Mortagne 12 Aug '09

12 Aug '09

Hi devs, I would like to introduce a first partial beta of the event network distribution system in the 2.0M3. Note that the module itself is complete what will need to be done with debugging is making everything in core use the new Observation Manager instead of the old notification service. For this release i plan to: - add the remote observation manager module (disabled by default) - implement a EventConverter for documents events (event convert has a generic converter for Serializables events but documents converted has XWikiDocument and XWikiContext we want to filter before sending it to the network). - make XWiki cache store listen to remote doc event to invalidate the cache accordingly (this is the main thing that will bring event based clustering support to XWiki, all the rest is already supposed to update its cache based on events remote or not) Here is my +1 -- Thomas Mortagne

4 14

Re: [xwiki-devs] Blog Wiki 2.0 Upgrade 7th Draft
by Andreas Schaefer 12 Aug '09

12 Aug '09

Hi I know that we all volunteer for this project and so this is not a critic of anybody's work but I have to say that the Feed Plugin has more holes than a Swiss cheese and I should know. I could work around all the issues but now the SyndEntryDocumentSource class does not render Wiki 2.0 code (hard coded to 1.0). There is also an issue where the conversion of Categories fails in the Rome Converters because the Categories is a String but the Rome expects a SyncdCategory. The only conversion that works so far is atom_0.3. One of the problems I see with the Feed Plugin is that the test suite is not sufficient and therefore many of the method now fail in 2.0. I would volunteer to help to build it if someone could show me to how to setup a test environment where I could execute the Feed Plugin against (Blog first). Is there a plugin that tests against a mock up XWiki to make sure it is working? Cheers Andreas Schaefer

4 4

[xwiki-devs] Skin tutorial, custom logo?
by Lilianne E. Blaze 12 Aug '09

12 Aug '09

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

5 6

[xwiki-devs] Introducing the equation rendering component and the equation macro
by Sergiu Dumitriu 11 Aug '09

11 Aug '09

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/

5 13

[xwiki-devs] [Proposal] Package names clarification
by Vincent Massol 11 Aug '09

11 Aug '09

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

2 1

[xwiki-devs] [VOTE] Release XE 1.9.3 and XEM 1.7.3 on wednesday 12th of August
by Jean-Vincent Drean 11 Aug '09

11 Aug '09

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.

5 4

[xwiki-devs] Macros and JavaScript working together (was Re: [DISCUSSION] XWiki Chart Api & Chart Macro)
by Niels Mayer 11 Aug '09

11 Aug '09

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

2 2