xwiki-devs August 2010

xwiki-devs@xwiki.org

29 participants
47 discussions

[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] [Proposal] Introduce user management configuration in virtual mode

by Jean-Vincent Drean

Hi Devs, I'd like to introduce a new configuration property that would define at which level users should be handled in a farm. See the proposition about the new entry in xwiki.properties, it should be self-explanatory: --------------------------------8<-------------------------------- #-# [Since 2.5M1] #-# Define at which level users and groups should be handled in the farm. Available modes: #-# #-# mixed (default): #-# - user registration available in the main wiki and local wikis #-# - users from the current wiki and the main wiki will be displayed in the rights interface and user suggests #-# - user administration is present in all the wikis #-# #-# local: #-# - user registration available in the main wiki and local wikis #-# - only users from the current wiki will be displayed in the rights interface and user suggests #-# - user administration is present in all the wikis #-# #-# global: #-# - user registration available in the main wiki only, the register link in local wikis will point to the main wiki #-# - only users from the main wiki will be displayed in the rights interface and user suggests #-# - user administration is present in the main wiki only core.virtual.users=mixed -------------------------------->8-------------------------------- More details are available here: http://dev.xwiki.org/xwiki/bin/view/Design/UsersModule WDYT ? Thanks, JV.

13 years, 2 months

[xwiki-devs] jgroups update to 2.8 causes problem in the build on some machines

by Vincent Massol

Hi, I'm getting this error when running the tests for xwiki-observation-remote: Caused by: java.lang.RuntimeException: the type of the stack (IPv6) and the user supplied addresses (IPv4) don't match: localhost/127.0.0.1. Use system props java.net.preferIPv4Stack or java.net.preferIPv6Addresses to pick the correct stack at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:108) at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:54) at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:453) at org.jgroups.JChannel.init(JChannel.java:1702) This thread explains the problem: http://old.nabble.com/Protocol-stack-issue-on-dual-stack-(IPv4-and-v6)-mach… This issue has been created to track the problem: https://jira.jboss.org/browse/JGRP-1152 I've tested with jgroups 2.10.0.Beta2 and it works fine. I've seen on http://jira.xwiki.org/jira/browse/XWIKI-4917 that jgroups 2.9 and above require JDK 6+. What do we do? Should we set the jgroups property to force ipv4 or ipv6? Thanks -Vincent

13 years, 9 months

[xwiki-devs] [VOTE] Edit UI improvements and panelless edit

by Sergiu Dumitriu

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/

13 years, 10 months

[xwiki-devs] [proposal] Dashboard macro implementation

by Anca Luca

Hi devs, knowing that gadgets will be xwiki macros instances (in any of the approaches) we need a way to add all these in a dashboard. Proposed options are at http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HDashboardMacr… . Currently implemented solution is 1/ which has a few drawbacks: it defines a meta syntax for its content and this syntax doesn't allow more complex layouts than a number of columns. The new proposal is 4) http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HOption429Colu… , which basically proposes to use nested column macros ( http://svn.xwiki.org/svnroot/xwiki/contrib/projects/xwiki-macro-column/ ) to do layouting and extend the section macro with a dashboard macro which would be used on the first level to mark that the columned content is a dashboard and not just regular wiki content. For more details about the approach see the description in the design page, as well as for the advantages of this proposal. my +1, I like this approach, I will try to prove the concept in the next days. WDYT? Thanks, Anca

13 years, 10 months

Re: [xwiki-devs] [Proposal][UX] Recent Changes Improvements

by Jerome Velociter

----- "Fabio Mancinelli" <fabio.mancinelli(a)xwiki.com> wrote: > On 08/30/2010 05:46 PM, Ecaterina Valica wrote: > > Hi Fabio, > > > > This means I am iterating and I gather feedback and depending on > that > > feedback we must agree on a version. > > > Ok. I thought that "old" meant "superseded by" :) > > > On a wiki platform, what do you think is more relevant: the user or > page > > centric approach? > > What are the things that make this version (the page centric one) > not to fit > > the Wiki 3.0 specification? > > > What is missing basically boils down to the "Share your thoughts" box Yes, user updates should be mixed in the stream ultimately, I think. > > and the type of information we can convey with it. > > The "user centric" view, imho, is also useful because a "user" could > also be an application that sends events (e.g., meeting or deadlines > reminders, etc.) that can be shown in a more natural way in a user > centric view. Basically even applications might share their thoughts > through the activity stream ;) I completely agree with the last sentence. BUT I think it's not incompatible with a document/user mixed-approched (I don't think either full document-centric or full user-centric can embrace the versatility of XWiki) I see two types of entries : * Document updates. Basically what is currently in latest proposal (though I would add little user pictures here as well, even before the click). This is KM, collaboration, etc. * Users/applications updates. Those are less structured, more a-la facebook. I see something like http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamMixed (raw picture, would have to be refined) (Note I also have right-padded a bit more the comment/annotation/pencil/etc icons that are on top of user photos, I think they were a bit too masked by them) Jerome. > > > Jerome missed the avatars, so if you did too, please try to expand > the items > > in the prototype (when you hover the items an arrow appears in the > right > > part suggesting that the item can be expanded ). > > > Yes I missed them too, but then I saw it. > Still the previously mentioned types of information are not available > > anymore. > > Thanks, > Fabio > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

13 years, 10 months

[xwiki-devs] [proposal] Remove the old rights UI

by Alex Busenius

Hi devs, I propose to remove the old rights interface (called "stable"). This interface was replaced by the current version (the one with livetable) in XWiki 1.2 several years ago, but the old code is still there. The following files are affected: web/standard/**/templates/rightsUI.vm applications/administration/**/XWiki/AdminGroupsSheet.xml applications/administration/**/XWiki/AdminUsersSheet.xml applications/administration/**/XWiki/XWikiGroupSheet.xml applications/panels/**/Panels/GlobalRightsEditorWelcome.xml applications/panels/**/Panels/RightsEditorWelcome.xml core/xwiki-core/**/plugin/rightsmanager/RightsManagerPluginApi.java The Java file contains the method getDefaultUi() to read the xwiki.rights.defaultui configuration property, the rest has parts of the interface. WDYT? Alex

13 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs August 2010