December 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] Introduce new tempresource action
by Vincent Massol 26 May '10

26 May '10

Hi, Part I ===== I've started implementing a Ditaa Macro over the weekend (http://ditaa.sourceforge.net/ ) but we need an Action to return the Ditaa-generated image file. For the chart macro we're using the charting action but I think we can make this generic and instead introduce a tmp (or temp or tmpresource or ...) action instead that would return any resource located in the xwiki temporary directory. For ex: /xwiki/bin/tmp/SomeResource would return SomeResource found in container.getApplicationContext().getTemporaryDirectory(). Part II ===== The only thing to be careful about is to not be able to read what's for another user and for which you don't have access to see it. For example an image generated by the chart macro for a page for which the user doesn't have view rights. This can be partially solved by ensuring that file names include a generated token. However the pb is that this token cannot be unique since, for ex, generated image need to be shared to anyone having the rights to view a page. <brainstomring mode> A solution I see would be to include the "rights" to check + the full page name in the URL, in addition to the resource. For example: /xwiki/bin/tmp/view/wiki:Space.Page/SomeResource A more generic solution would be to add a notion of Check Handler, i.e. code that would perform the check. For example in the previous solution it's not possible to check for 2 permissions, nor any complex scheme. This would mean something like: /xwiki/bin/tmp/<check handler name>/<resource name>?<check params> Ex: /xwiki/bin/tmp/simple/SomeResource? checkPermission="view"&checkDocument="wiki:Space.Page" Implementation: A component with a role hint of "simple" would be looked-up and the check logic delegated to it. However someone could use a some check for a resource that wasn't meant to be used for that resource. Thus the check and its params should probably instead be included in the resource name with some algorithm instead. Thus the solution maybe to have a high level API to create a resource name and that API would take a Check Handler hint + some arbitrary params and that API would generate a resource name with these added. For ex something like:: "SomeResource-simple-view-wiki:Space.Page" (or any other format). Another solution would be to follow a completely different direction and for example to introduce a new XDOM representation for a TMP- image, i.e. in addition to URLImage and DocumentImage, to add a TemporaryImage implementation. </brainstomring mode> WDYT about these 2 ideas and especially about Part I since I would need that sooner rather than later to implement the Ditaa macro, and Part II is already a problem today. Thanks -Vincent

7 16

[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] [Proposal] Governance for xwiki.org
by Vincent Massol 17 Mar '10

17 Mar '10

Hi everyone (devs and users), While we have a clear governance for write access to our source repository (http://dev.xwiki.org) we're missing a clear governance for xwiki.org. The idea is to address mainly the following 2 questions: 1) who "owns" it and thus "controls" (or rather provides direction for) its content 2) can it be used for business advertising (support, paid packages, consulting services) Bit of History about XWiki SAS ======================== - XWiki SAS (http://xwiki.com) is the company founded by Ludovic Dubost the creator of XWiki (I'm the CTO of XWiki SAS in addition to being a committer here). - Most of the active contributors are also employed and paid by XWiki SAS to develop the XWiki software. Today that's -- 12.5 committers (developers) -- 1 open source product manager (see http://markmail.org/thread/ggaaw4u6yyci4oan for its definition) -- 1 designer -- 1 tester/technical writer - XWiki SAS sells services around the open source software, see http://www.xwiki.com/xwiki/bin/view/Services/ - XWiki SAS truly believes and understands open source, see http://www.xwiki.com/xwiki/bin/view/About/Values -- I also wrote a blog post on this some time back: http://massol.myxwiki.org/xwiki/bin/view/Blog/XWikiSASAndOpenSource - XWiki SAS has promised "not to do evil" ;), see its manifesto at http://www.xwiki.com/xwiki/bin/view/About/Manifesto - XWiki SAS is paying for the servers and maintenance of xwiki.org, myxwiki.org, the maven repo, the svn repo, the hudson build serversn the free JUG farm, and more Issue at hand =========== XWiki SAS would like to generate more revenue to be able to increase the development pace of the XWiki software. We'd like to fund even more the development of XWiki, so that it becomes an even better product. We've asked you what you'd like to see in the future in XWiki and you've answered on this survey result: http://www.xwiki.org/xwiki/bin/view/Blog/Features+Survey+Results We'd like to implement those features as fast as possible. For this we need to ensure that users interested in commercial services find easily the way to http://xwiki.com, even when they arrive on xwiki.org. This is true for XWiki SAS's services but also for any company willing to offer services around the XWiki open source project. There's no magic. Developers need to be paid when they work full time on some project. We need a commercial ecosystem around XWiki for it to progress as quickly as its competitors (the collaboration market). We need to allow for commercial companies the ability to generate revenue from their work on the XWiki open source project. However we also want to continue ensuring that all the XWiki development is done in open source, under a LGPL license. Governance Proposal ================= 1) xwiki.org is controlled by the XWiki committers. This means that important changes brought to it should be discussed/vote on the list, using the same practices as for code commits 2) xwiki.org stays open in edit mode to all external contributors (and XWiki committers continue to monitor it to remove spam, etc) 3) we agree to start with 3 zones where companies can advertise their commercial offers on top of the XWiki open source product: -- On the download page (for business packages, subscriptions, hosting) -- On the support page (for services: support, consulting) -- (still to be defined) Possibly on a "Products" tab in the new horizontal navigation. The idea would be to do as jboss.org is doing. Projects are open source and community and Products are commercial 4) the company offerings are listed by their amount of contributions to the XWiki open source project. The company that contributes most (XWiki SAS today) gets the best spots (top of the list, bigger space) 5) Companies who want to be listed should provide some proof of their contributions to the XWiki open source project 6) XWiki SAS gets some acknowledgment for paying for the xwiki.org server/maintenance of it. Probably somewhere in the footer of the site or on side panel somewhere 7) xwiki.org should always remain a site for the xwiki open source community Conclusion ========= We want to stress that this proposal is not about XWiki SAS making a commercial takeover of the xwiki.org site. It's about recognizing that if the XWiki open source software progresses quickly today, it's thanks to contributors but also for a very large proportion to companies paying developers to work on it, either directly (like XWiki SAS or other companies that have developers contributing) or indirectly (by paying for example XWiki SAS or other companies to work on specific features). It's also about recognizing that XWiki SAS is happy to see other companies willing to contribute to the progress of the XWiki open source project and thus to provide a place for these companies to be visible too. I hope that all our contributors but also users of the XWiki Open Source software will find this proposal acceptable and I welcome any feedback on it. Thanks -Vincent Massol Hat 1: XWiki SAS CTO Hat 2: XWiki committer

10 15

[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