November 2009 - xwiki-devs@xwiki.org

[xwiki-devs] Questions about fixing getRenderedContent() bug
by Vincent Massol 18 Feb '15

18 Feb '15

Hi, Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274 Basically if you do $xwiki.getDocument("someDoc").getRenderedContent() it'll get executed in the context of the current doc which I believe is wrong especially since other signatures of getRenderedContent() execute in the target document's context. I have fixed this locally but found that admin.vm for example is assuming that getRenderedContent() will get executed in the context of the calling doc (i.e. XWiki.Import when doing an import for example). FYI the chain flow is admin.vm -- getRenderedContent() --> XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which requires the current doc to be XWiki.Import (to get/put attachments from/to it). I can fix this easily using a new getRenderedContent signature I've introduced. However I'm wondering if we have other places that incorrectly use getRenderedContent() and assume it won't be rendered in the context of the target document. Is this change too dangerous to make? If not know, we'll need to it quickly (2.1M1?) since it's an important bug IMO. WDYT? Thanks -Vincent

4 7

[xwiki-devs] Redirect to a space
by Bruno Amaro Almeida 04 Jun '13

04 Jun '13

Hi How can i redirect the users after login to a space ? I`m looking at login.vm but i have no clue to do this Thanks

4 6

[xwiki-devs] Pretty Time library
by Vincent Massol 11 Jul '12

11 Jul '12

Could be useful: http://ocpsoft.com/prettytime/ Idea of usage: For ex we could use that to show the last modified document dates for dates in the past week (for ex): "Document created 2 days ago" It's in the maven central repo and it's under LGPL -Vincent

5 7

[xwiki-devs] How to load GWT application on Xwiki pages?
by Leon Wang 24 Nov '11

24 Nov '11

Hi Everyone! I have read this document "Writing GWT applications in XWiki" ( http://dev.xwiki.org/xwiki/bin/view/Drafts/WritingGWTApplicationsInXWiki) And I know how to develop GWT module for xwiki now. I also have read the document "WYSIWYG Editor Module" ( http://code.xwiki.org/xwiki/bin/view/Modules/WysiwygEditorModule) I followed the instruction which tried to integrate the WYSIWYG editor(GWT application) in wiki pages, and I put the following code in my wiki editor: "{{html}} <script type="text/javascript" src="XWikiWysiwyg.js"> alert('WYSIWYG code is loaded!'); </script> <textarea id="demo"></textarea> <script type="text/javascript"> Wysiwyg.onModuleLoad(function() { new WysiwygEditor({hookId:'demo'}); alert('WYSIWYG code is loaded!'); }); Wysiwyg.onModuleLoad(function() { editor = new WysiwygEditor({hookId: 'demo'}); }); }); </script> {{/html}}" After saved, it only display a blank text area without any sign of WYSIWYG editor, also there is no alart 'WYSIWYG code is loaded!' popup. Can you help me figure it out what is wrong with it? I am planing to develop a tree view using GWT to display Design Rationale Element. Could you give me some ideas of after my development, how can I embeded the GWT application into Xwiki pages and interact with the GWT application? Thank you very much! Leon

6 5

[xwiki-devs] [PROPOSAL] Rendering l10n
by Thomas Mortagne 21 Apr '10

21 Apr '10

Hi devs, We need to support some way internationalization of everything in the rendering that appear in the UI, for now it's mainly related to macros. What I propose is to introduce the rule that any displayable String returned by the API (MacroDescriptor#getName, ParameterDescriptor#getDescription, etc.) could be a l10n key. Then the API user call the l10n component to get the final String. pros: - no need to touch the current API - it avoid having complex API to support l10n specifics and makes pretty much everything depends on l10n component. It's easier for macro author to write a quick macro with some description without having to create l10n resource and call the l10n component just for english for example. - the displayer can control how to get actual translations the way it wants - we need something like that for wiki macros anyway: XWiki does not support translations of objects yet (and for long I guess since the issue is at database level) and it would be a pain to have to copy the content of the macro by language since most of the time the script of the macro would not be related to the language cons: - it's more work for the API user to filter the String with the l10n component to get the actual final String One detail I'm not sure of is if we introduce some syntax to explicitly indicate it's a l10n key or if we just always give the String to the l10n component which will return it as it is if it can't find any matching key. Having an explicit way to indicate a String is a key would be better to track l10n keys bugs but introduce a syntax is always more complex (what chars to choose, how to escape, etc...). WDYT ? Thanks, -- Thomas Mortagne

3 5

[xwiki-devs] [Proposal] XWiki.org horizontal navigation + home page
by Vincent Massol 26 Mar '10

26 Mar '10

Hi there, I'd like to start a overhaul of the xwiki.org home page + a first level navigation overhaul. Today: * Home page = list the different products * First level nav = the ecosystem panel Problems: * We now have a single product: XE and all the others are actually modules that plugin into the main products. Hence we shouldn't focus on other products so much IMO. * I'd like to view xwiki.org as a forge of projects. Today our top level projects are the ones listed here: http://svn.xwiki.org/svnroot/xwiki/ * The main page should be more dynamic and show some news and activity instead of being static * People are confused by the top level navigation vs the second level one because they both use panels and it's not easy to differentiate them Proposal: * Use a horizontal top level navigation with the following items (from left to right): - Overview or Home (the main page) - Platform - Projects (when clicked will list all top level projects) - We could have the list of subproject available as submenu items too (as it's done on http://jboss.org/) - Support (when clicked will explain the various ways to get support including mailing list/forum, irc/jabber, FAQ & listing companies offering commercial support) - Contribute or Community (when clicked we'll get dev.xwiki.org) - Playground This means that the panels on the right will become the second level navigation and the content will depend completely on where you are on the site. * Have some facilities links in the header on the right: - News - Downloads (as a visible button maybe) * On the home page: - Have a nice diagram of the xwiki platform that shows how XE, XE modules are positioned on the platform so that people understand right away that xwiki is a collaborative web dev platform - Have a Highlight box with XE so that users looking for a full- fledged wiki can quickly see it and click on it + maybe one featured screenshot of an entry from the References page that would be different every time the page is refreshed (this could encourage people to add references + provide a link to the references directly) - Have a Featured project box and list 3-4 featured projects (XE, XEM, XEclipse, XOffice for ex to start with) - Have some news: -- latest 5 blog post titles -- latest 5 code zone additions (all snippet, plugins, macro, apps, etc included) -- latest 5 mailing list threads subjects (with links to our nabble forum) We could not have any second level navigation for the home page in order to have more space for displaying the elements above. WDYT? If/when we're ok in term of content maybe Cati (or anyone interested) could provide some mockups of what it could look like. Thanks -Vincent PS: Let's not get bogged down with details at this point. I think what's important is to make progress and refine later on. What's important is that we agree on the broad lines at this stage.

10 49

[xwiki-devs] How to deal with statistics duplications
by Thomas Mortagne 24 Feb '10

24 Feb '10

Hi, Since we introduce document footer informations view statistics are store several time for the same user view of a page. See http://jira.xwiki.org/jira/browse/XWIKI-4590 The issue is that theses tabs are loaded asynchronously in ajax and make a call using view action. Here are some solutions: 1/ introduce a new action "viewinternal", "service" or anything else that would be a "view" action without UI and not taken into account by statistics (that register for "view" action events) 2/ pretty much the same thing that 1/ but based on a URL parameter 3/ use an additional AJAX request similar to a google analytics call to record statistics As i said in jira I'm against 3/ 2/ seems too big for a URL parameter to me and it makes statistics depends on URL parameters where 1/ fix the issue without touching anything in the statistics module +1 for 1/ +0 for 2/ -1 for 3/ -- Thomas Mortagne

8 39

[xwiki-devs] [Proposal] Script Bridge
by Vincent Massol 04 Feb '10

04 Feb '10

Hi, This is following the proposal done here some time ago: http://markmail.org/message/nnybto3mluvp2rov Since we now have a generic Script notion we need to revisit it in that light. Also we really need to implement it now since more and more components are put in the velocity context (office importer, syntax factory, etc) and we need to bring some order. Here's a new generic proposal: Short term ======== * The variable "services" is bound in the script context. For ex in Velocity: $services * The Services object (ScriptServiceManager) has a ScriptService get(String serviceName) method which returns the service * We use the namespace: services.<module name>.<method>. Each module provides only one service entry point. * ScriptService interface (empty interface) represents a service to be bound in the context * ScriptServiceManager.get() looks for all components of role ScriptService and returns the component matching the the name as the component hint. Ex: @Component("mymodule") public class MyModuleScriptService implements ScriptService, MyModuleBusinessInterface { public void myMethod() {} } In script: {{velocity}} $services.mymodule.myMethod {{/velocity}} Medium term ========== * We handle @authorization(Authorization.PROGRAMMING) annotations to check for access rights. To do this in ScriptServiceManager.get() we use a Dynamic Proxy to implement MyModuleBusinessInterface (we probably need a ScriptService.getInterface() method to make it unambiguous). The Dynamic Proxy checks the annotation before proxying to the real object. WDYT? Thanks -Vincent PS: This is to answer Sergiu's question about where is getAvailableParserSyntaxes() from my other mail... ;) Answer: It would be in RenderingScriptService.

5 17

[xwiki-devs] [Proposal] [GSOC] Wiki Importer Enhancement
by Arun Reddy 10 Jan '10

10 Jan '10

Hi Devs, As the existing Wiki Importer ( GSOC PROJECT - SANDBOX <http://svn.xwiki.org/svnroot/xwiki/sandbox/gsoc/importexport/>) have few set backs in architecture, i would like to make a proposal to modify and enhance to make it better. Here is my proposal : http://gsoc.myxwiki.org/xwiki/bin/view/Import+Export+other+wikis/Wiki+Impor… - A new Wiki model api ( Wiki, Wiki Page, Wiki Page Revision, Wiki Attachment ) which adheres to XWiki Standards. - Separation of Import process, Parsing the import data into a abstract wiki model will be a component. Clients can use it to make their own custom implementation. This abstract model is used by the other XWiki component / client code (Groovy & velocity ) to load the data into XWiki with standard features and little customization (like Preserving history, default names, attachments etc.. ). - Using the existing XWiki model api or xwiki-bridge rather than coming up with a new one. But the issues here is, i dont have all the things which are needed and it has lot more methods which are of no use in import process. Can i proceed with a custom wiki model like this. ? - As wiki importer process large streams of data, would it be wise to design the API more stream oriented and include few stream oriented methods.? I would like to have your suggestions on this. Thanks -Arun Reddy

3 20

[xwiki-devs] [VOTE] Strategy for handling translations
by Vincent Massol 02 Jan '10

02 Jan '10

Hi devs, We need to define a strategy for better handling translations. I've had a call with Guillaume and Jean-Vincent and here's the process we'd like to propose: * One person is in charge of http://l10n.xwiki.org/. This means monitoring the work there, coordinating validation of key values and ensuring validated translations are incorporated in the source tree. Guillaume is willing to take that role for now. * The XE release manager has the responsibility of taking the validated keys on l10n.xwiki.org and committing them during the Milestone 2 dev (before the RC1). * The l10n manager should ping the release manager whenever there are translated and validated keys ready to be incorporated or if there have been important changes to be included in the release after M2 has been released. * The l10n manager should test XE and the applications after the keys have been applied to ensure quality. Basically the l10n manager is responsible for the quality of translations in general. Here's my +1 Thanks -Vincent

10 20