xwiki-devs May 2011

xwiki-devs@xwiki.org

31 participants
77 discussions

[xwiki-devs] [UX][Consistency][Vote] "Page" vs. "Document" consistent naming

by Ecaterina Moraru (Valica)

Hi, We are using mixed naming when referring to a document/page, not only on different pages, but also in the same context (Rename step for example). There is also an issue referring to this problem XWIKI-5401<http://jira.xwiki.org/jira/browse/XWIKI-5401>and we need to find an answer in order to move forward consistency. So the question is which version we prefer: "Page" or "Document" ? I'm voting +1 for "Page". "Page" is more used IMO, especially in the "Space"/"Page" context. "Page" is more general than "Document" and better fitted for a platform that encapsulates all kind of content (not just documents). Please cast your vote. Thanks, Caty

8 years, 10 months

[xwiki-devs] Questions about fixing getRenderedContent() bug

by Vincent Massol

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

9 years, 5 months

[xwiki-devs] Redirect to a space

by Bruno Amaro Almeida

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

11 years, 1 month

[xwiki-devs] Pretty Time library

by Vincent Massol

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

12 years

[xwiki-devs] How to load GWT application on Xwiki pages?

by Leon Wang

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

12 years, 8 months

[xwiki-devs] XWiki logo around

by coldserenity

Hi, I remember once there was a contest for new XWiki logo but due to elections fail (there would have been too many unsatisfied people if any of newly suggested logos had been approved) the process has gracefully ended (which, in my opinion, was a good decision) I also think that it would be worthless to conduct another competition/election amongst users because as the saying goes - tastes differ. The only thing users can contribute are their ideas (which might be accepted or might not which is fair) regarding shapes and symbols to use. Decision about visual design should be made within very very small circle of visual designers probably with one or two people involved in the project to chill down designers' burning imagination :) Having all of the above said, I would suggest to collect a set of shapes and symbols for new XWiki logo each supplied with description of underlying meaning. And then (having revised all of the comments in some of the former posts regarding what new logo should be: symmetric/asymmetric, complex/simple, round/firm) provide all that to a designer to draw several sketches. And then by internal vote (at maximum the development team members involved) choose the new logo. This thread is for storing all of the ideas on the new XWiki logo. At least that's what I (as a user) will be using it for may any ideas to come. Join :) Regards, Roman -- View this message in context: http://xwiki.475771.n2.nabble.com/XWiki-logo-around-tp6074956p6074956.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

12 years, 8 months

[xwiki-devs] [Proposal] Use artifact id as directory names

by Vincent Massol

Hi devs, The proposal is to use artifactid as directory names. Note that this is what I did for commons and rendering when I did the move to top level project. You can check how it looks like here: http://svn.xwiki.org/svnroot/xwiki/commons/ http://svn.xwiki.org/svnroot/xwiki/rendering/ I suggest we keep one strategy only for consistency. Some discussion here too: http://www.sonatype.com/people/2011/01/maven-tip-project-directories-and-ar… I know there are some cons (see my comment in the link above) but overall I find it simple to implement and with autocompletion not such a big issue. WDYT? If you don't like this then please propose an alternative solution and remember that we'll need to refactor commons and rendering in this case too. Thanks -Vincent

12 years, 9 months

[xwiki-devs] [VOTE] Create xwiki-contrib organization on GitHub + move retired platform modules to it

by Vincent Massol

Hi, I'm proposing to move the following modules from xwiki-platform-core to separate git repos in a xwiki-contrib organization on GitHub: xwiki-platform-calendar xwiki-platform-exo xwiki-platform-adwords xwiki-platform-alexa xwiki-platform-photoalbum xwiki-platform-s5 xwiki-platform-workstream Rationale: * They're no longer working or supported * We can move them back if the xwiki dev team wants to support them again in the future * It's cleaner than having a retired module in the xwiki organization since a) it's not "polluting" the list of repos supported by the xwiki dev team and b) it allows them to be separated in repos Future: * Also move modules currently in svn contrib to xwiki-contrib org. Note that we need to verify if the svn app works with the GitHub svn integration too since several users of svn contrib are using it. Here's my +1 Thanks -Vincent

12 years, 10 months

[xwiki-devs] Ready to move the Albatross skin to contrib/retired?

by Vincent Massol

Hi (especially Sergiu), I think you worked on removing the dependency on Albatross, right? Is it finished? Can can we move the Albatross skin to contrib/retried? See http://xwiki.markmail.org/thread/jx5vyqtrwwaidfka Thanks -Vincent

12 years, 10 months

[xwiki-devs] hibernate cache optimization?

by Paul Libbrecht

Hello XWiki-devs, maybe this forum is better than curriki-dev. In short: how can I boost the size of the cache of objects held by hibernate? thanks in advance paul > as you know curriki.org is somewhat of a fat server serving really many requests. > > One symptom we are seeing on the production machine only, almost, is: > xwiki.getPlugin("curriki").fetchUserGroups(). > that sometimes takes more than 1 minute and sometimes much less, all for the same user. > On the development machine it takes time with users with a lot of groups only when the hibernate cache is flushed. > > My interpretation is that this method is fetching the group and probably a lot more. My answer would be to go low-level. > > But another answer would be to ensure that the hibernate cache is big enough so that all these stay in memory. Making this possible would also speed up a huge amount of other things. > > Are we talking of the file ehcache.xml's attribute: > maxElementsInMemory="10000" > ? > I sure could raise this by a factor 10 if true. > > thanks in advance > > paul

13 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs May 2011