February 2010 - 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] [VOTE] Edit UI improvements and panelless edit
by Sergiu Dumitriu 27 Sep '10

27 Sep '10

Hi devs, We've been working on improving the editors (content, class, object), and now I have some pretty important UI changes to commit, but not everybody seems to agree with them, so I bring up a vote. The whole improvements can be seen on http://incubator.myxwiki.org/xwiki/bin/Improvements/ImprovedEdit Here are the individual voted points: 0 Remove all panels in edit mode 1a Parent and title above the content in wiki/wysiwyg mode 1b The same style in edit mode as in view mode for the parent/title fields 1c AJAX Suggest for the parent field 2a New label for the content textarea ("Content") 2b List of included documents after the Content label 3a Syntax switcher in the top right corner of the content 3b Syntax help in the top right corner of the content 3c Syntax help and switcher only in the wiki editor 4 Better label for the version comment 5a Right float the Minor edit field 5b Put the Minor edit label after the checkbox 6 Move autosave in line with the submit buttons 7 Introduce new AJAX-powered Add Object i) above the objects ii) bellow the objects 8 Introduce new AJAX-powered Add Object from this class i) at the top of the list of existing objects ii) at the end of the list 9 Move the class switcher in the top right corner 9b Remove the class switcher 10 Introduce new AJAX-powered Add Property i) at the top of the list of properties ii) at the end of the list I vote +1 for all of the above, except 9b (-0), and with options 7i), 8ii), and 10ii) -- Sergiu Dumitriu http://purl.org/net/sergiu/

7 13

[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] [UX][Proposal] Annotation UI Improvements
by Ecaterina Valica 17 Mar '10

17 Mar '10

Hi, I made some UI suggestions for the annotations. Overview: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Annotations/pr… Details: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/AnnotationsProposal Please let us (me and Anca) know what you think. Thanks, Caty

10 33

[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