xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] Bug Fixing Day Results for 02 July 2008

by Jean-Vincent Drean

Yesterday was our 4th bug fixing day. The following bugs were fixed: http://tinyurl.com/5evc9r - Artem * XWIKI-1976 : Importing attachments will increase the attachment version - Evelina * XAADMINISTRATION-4 : New Administration UI doesn't display nicely under the Albatross skin - Jean-Vincent * XWIKI-2536 : French translation is outdated * XWIKI-2535 : Patch to English translation - Thomas * XWIKI-2495 : LDAP Authentication re-create global user locally So that's a total of 5 bugs fixed. Well done everybody and thanks to all who participated. JV.

16 years, 7 months

[xwiki-devs] New Comments & Ratings design proposal

by raluca.morosan＠xwiki.com

Hi devs, Due to the fact that we have to extend the platform features, a proposal would be to extend the current comment feature, and add 2 new ones: annotations and ratings. Here are the design proposals for comments and ratings: http://dev.xwiki.org/xwiki/bin/view/Design/RatingSystem http://dev.xwiki.org/xwiki/bin/view/Design/NewCommentsPlugin You can review them and give feedbacks. Thank you, Raluca.

16 years, 7 months

[xwiki-devs] XWiki - User ID

by Prathap Pandian

Hi, How to print the user id in xwiki pages.(Like this:XWiki.Admin). *$!xwiki.getUserName($context.user, false) This one is to print the user name. *-- Prathap* *

16 years, 7 months

[xwiki-devs] [discussion] configuration files loading

by Artem Melentyev

Hi, devs. I would like to discuss about How we should load external configuration files (such as hibernate.cfg.xml, repository.xml and others) AFAIK, we agreed the following algorithm to load external config files: 1. filesystem 2. ServletContext 3. classpath. But we still lack some implementation for it. So we duplicate code in store, cache and others modules. How can it be implemented right? (Spring fwk for example have nice Resource classes: http://static.springframework.org/spring/docs/2.5.x/reference/resources.html and Resource classes injected simply by string path.) I see 2 ways: 1. Add InputStream getResourceAsStream(String) method to our Utils class. +: simple but I'm not sure it is right in V2 arch. 2. Implement Chained, FileSystem and ClassPath application contexts and provide one chained application context which tries to load resource from filesystem, servlet and classpath contexts in this order. -: I think it is overhead for now. I'm +1 for 1. now. Another question is How we should configure config file path. I think we should provide default path in component class (String somepath = "some/path") and we can override it in components.xml So no more "xwiki.store.hibernate.path" and others params in xwiki.cfg. Use components.xml instead. xwiki.cfg should contain more useful and global params. WDYT? -- Artem Melentyev

16 years, 7 months

[xwiki-devs] Releasing xwiki-spacemanager 1.0.2 and xwiki-invitation manager 1.0.1

by Jerome Velociter

Hello devs, I'm about to release the following plugins : * xwiki-spacemanager 1.0.2 (with this changelog: http://tinyurl.com/4adfuq) * xwiki-invitationmanager 1.0.1 (with this changelog: http://tinyurl.com/4xtqw7) Both are bugfixe releases, mainly for the curriki project. Regards, Jerome.

16 years, 7 months

[xwiki-devs] Renaming translated pages

by Vincent Massol

Hi, In order to fix issue http://jira.xwiki.org/jira/browse/XWIKI-1325 (Renaming a web page only updates backlinks in one language version) we need to store the language in the XWikiLink object/table. One solution then it modify XWikiHibernateStore from List loadBacklinks() which just return doc names to List<XWikiLink> loadBacklinks(). I have it almost done here but I wanted to ask you what you think. Another solution (but might be too complex for now) would be to include the language in doc full name by inventing a new syntax. For example: "wiki:Space.doc:language" In this case there's no change required to XWikiLink object/DB, nor for the loadBacklinks() method. The change is either in the code that calls getBackLinks() or in XWiki.getDocument(documentName) so that documentName supports language. WDYT? Thanks -Vincent

16 years, 7 months

[xwiki-devs] Single Sign-On project

by Markus Lanthaler

Hi! I just created the page http://dev.xwiki.org/xwiki/bin/view/Design/SingleSignOn where I'll document everything regarding my Single Sign-On project. Since I didn't get any feedback the last time I asked this question I'll ask it again: Another question. Just looking at OpenID now. What are the plans for it? Should it be enabled by default? Should it be possible to turn it off? I would like to see OpenID support out of the box. I don't know if it makes sense to turn it off.. What happens with existing OpenID users if someone turns it off? Should we really start with the integration of a big framework like OpenSSO? Wouldn't it be better to implement OpenID support for example with a dedicated OpenID library? We should also consider the fact that ESOE for example simple uses the OpenID4Java library and OpenSSO doesn't support OpenID (authentication) at all. I think it's much easier for the user if everything is bundled with XWiki so that he doesn't need to install any other component or complex service like ESOE or OpenSSO. If it's OK for you I would start creating the architecture and describe detailed how I would like to implement OpenID support with a OpenID library the next days. Then ask for some feedback on that and finally begin to implement this. My last exam is next Monday (July, 7th) so afterwards I'm finally free to work exclusively for XWiki :-) Cheers, Markus

16 years, 7 months

[xwiki-devs] [Reminder] Bug Fixing Day - 4th edition

by Jean-Vincent Drean

Today is the .. Bug Fixing Day ! :) Rules for picking bugs: a) bugs with patches available b) bugs with High Development Priority defined. For Core: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=1… c) bugs planned for the current release d) bugs with Medium Development Priority defined. For Core: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=1… Everyone is invited to help out and not just committers: * contributors can send patches * users can vote for their most important issues * bug reporters should be ready to verify that the fix does solve their problem JV.

16 years, 7 months

[xwiki-devs] [Rendering] Handling rendering errors

by Vincent Massol

Hi, I'd like to tackle the error rendering part of the new rendering module. Right now there are several locations where the rendering can fail: * a Macro can fail to be located * a Macro can fail during execution * a link can fail to be resolved. For example if the access to the database fails when looking up the document corresponding to the link name. Or if the link has an invalid format. WikiModel will normally not generate any exception while parsing so we shouldn't have any exception to handle there. Haven't checked Doxia yet on this. In any case I see 2 options to handle the cases listed above: Solution 1: Generate an ErrorBlock =========================== This means replacing the original block (MacroBlock or LinkBlock) by an ErrorBlock which will then get rendered accordingly (with some kind of error box in the XHTML renderer for example). Pros: Shows exactly where the problem is in the document and render the rest of the document. Cons: It's possible to overlook the fact that there's a rendering error since it doesn't blow up when an error happens Solution 2: Fail the rendering process with an exception =========================================== We'll then need some error handling code in XWiki to handle exceptions thrown by the XDOM.traverse() method. Pros: Not possible to avoid the fact that there's an error in the document somewhere Cons: Makes rendering process more "fragile" and possibly make it harder to find out where the problem is located. Note that to alleviate this we would need to implement some code to tell the user where the problem happened exactly in the code (this could be done by adding some offset/length attributes to the Blocks). Personally I'm still hesitating but I think maybe the best would be to combine both solutions, i.e. do the following: * Generate the rendered document with rendered ErrorBlocks * Throw an exception which contains the rendered document, thus allowing the error handling the ability display the rendered document with its errors displayed inline. WDYT? Thanks -Vincent

16 years, 7 months

[xwiki-devs] Java functions as macro

by MikhaelSantos

Hi guys! I'm trying to add my own macros on xwiki but they are functions made in java. for example if I had to edit a xwiki page and added xwiki.myplugin.function("Mikhael") on the preview my function would show the following Text : "Hello Mikhael your plugin is working!". Now what I want to know is how do a turn xwiki.myplugin.function("Mikhael") into for example " $hi("Mikhael") "? Give it a more macro look. I look foward to your answers and thank you for helping out Mikhael -- View this message in context: http://www.nabble.com/Java-functions-as-macro-tp18214356p18214356.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

16 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs