xwiki-devs February 2010

xwiki-devs@xwiki.org

42 participants
117 discussions

Re: [xwiki-devs] [xwiki-notifications] r26602 - in platform/core/trunk/xwiki-rendering: xwiki-rendering-api xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml xwiki-rendering-api/src/main/java/org/xwiki/rendering/renderer xwiki-rendering-api/src/main/resources/META-INF xwiki-rendering-tests/src/test/java/org/xwiki/rendering

by Vincent Massol

On Feb 2, 2010, at 4:25 PM, Sergiu Dumitriu wrote: > On 02/02/2010 03:51 PM, vmassol (SVN) wrote: >> Author: vmassol >> Date: 2010-02-02 15:51:13 +0100 (Tue, 02 Feb 2010) >> New Revision: 26602 >> >> Added: >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/AttachURILabelGenerator.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/MailtoURILabelGenerator.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/renderer/URILabelGenerator.java >> Modified: >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/DefaultLinkLabelGenerator.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/DefaultXHTMLLinkRenderer.java >> platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/resources/META-INF/components.txt >> platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/java/org/xwiki/rendering/SimpleRenderingTests.java >> Log: >> XWIKI-4839: Improve labels for mailto and attach links >> >> * Refactored to make the implementation more generic... >> >> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml >> =================================================================== >> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml 2010-02-02 14:38:44 UTC (rev 26601) >> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml 2010-02-02 14:51:13 UTC (rev 26602) >> @@ -132,6 +132,9 @@ >> **/rendering/internal/macro/*.java, >> **/rendering/internal/parser/*.java, >> **/rendering/internal/renderer/BasicLinkRenderer.java, > > It's a pity that we must manually list all the checked files... > >> + **/rendering/internal/renderer/DefaultLinkLabelGenerator.java, >> + **/rendering/internal/renderer/AttachURILabelGenerator.java, >> + **/rendering/internal/renderer/MailtoURILabelGenerator.java, >> **/rendering/listener/*.java, >> **/rendering/listener/chaining/AbstractChainingListener.java, >> **/rendering/listener/chaining/ChainingListener.java, > >> Added: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/MailtoURILabelGenerator.java >> =================================================================== >> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/MailtoURILabelGenerator.java (rev 0) >> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/MailtoURILabelGenerator.java 2010-02-02 14:51:13 UTC (rev 26602) >> +@Component("mailto") >> +public class MailtoURILabelGenerator implements URILabelGenerator >> +{ >> + /** >> + * The MAILTO URI prefix (the scheme followed by ":"). >> + */ >> + private static final String MAILTO = "mailto:"; >> + >> + /** >> + * {@inheritDoc} >> + * @see org.xwiki.rendering.renderer.URILabelGenerator#generateLabel(org.xwiki.rendering.listener.Link) >> + */ >> + public String generateLabel(Link link) >> + { >> + String label = link.getReference().substring(MAILTO.length()); > > StringUtils.removeStart(label, MAILTO) is safer. > >> + // Also remove the query string part from the label (we only want the email address). > > return StringUtils.substringBefore("?") is shorter. Fixed thanks -Vincent > >> + int queryStringPosition = label.indexOf("?"); >> + if (queryStringPosition> -1) { >> + label = label.substring(0, queryStringPosition); >> + } >> + return label; >> + } >> +}

14 years, 10 months

[xwiki-devs] [Proposal] JIRA strategy for issues we don't plan to fix

by Vincent Massol

Hi devs, We've had a quick discussion with Thomas on IRC regarding the strategy we want to adopt for issues we don't plan to fix. Here's my POV: * We should close issues that we know we won't fix. We might not want to fix them for several reasons but one of these reason is that the issue is for an old XE version. Especially since we said that we're only supporting the last 2 versions. We = xwiki committers, but if any committer wants to fix an old issue he's free to do it of course, it's just a general rule. * An option would be to leave them open and wait for a patch but I don't think it's a good idea, because: - it sends the wrong signals that we're going to fix the issue - the issue can still be found with a search even if closed - when we close it then the reporter can explain why it's so important for him, or not. Which we wouldn't know if we hadn't closed it - contributors could reopen them and attach a patch or just create a new issue - it means that for all other issues we plan to fix them at some point WDYT? Thanks -Vincent

14 years, 10 months

[xwiki-devs] approaching mild optimizations of Lucene plugin

by Paul Libbrecht

Hello devs, I'm trying a few optimizations of the Lucene plugin and try to keep this flexible and not too intergeo or curriki specialized. The fact is that this plugin uses Lucene in a very blind and heavy fashion, which gives a lot of power (but which is not used). Mostly, I'd like, in a configurable way: - to decide to store and/or index or not some objects or object properties - to decide to exclude some documents - to decide to use particular analyzers for particular fields (in particular the "token fields") I know it would be almost possible by replacing lucene by solr and letting users tune solr. But maybe it is simple to have the configurability done in xwiki. Probably the nicest way I see this would be the way the notifications are done: a central field indicates the page of a groovy source which should implement such an interface as "LuceneIndexProfile" which would add such questions (maybe even including some more such as the Data classes). Is the nicest above easy? Do we prefer and xml configuration? paul

14 years, 10 months

[xwiki-devs] [Proposal] Split the wysiwyg module in order to make the editor reusable outside XWiki

by Marius Dumitru Florea

Hi devs, I'd like to split the wysiwyg module in two: xwiki-gwt-editor : All the client side except the editor initialization code. This module should depend only on xwiki-gwt-dom and xwiki-gwt-user. As a consequence, anyone should be able to inherit this module and reuse the editor outside XWiki. All the editor plugins are included but we don't enforce their use. This means that external parties can assemble whichever plugins they want and only those plugins will be compiled into JavaScript. Some plugins use services. External parties have to implement this services if they want to use the plugin. xwiki-gwt-editor-xwiki : XWiki-specific client initialization code plus all the server side (i.e. the XWiki implementation of plugin services). This module will depend on xwiki-gwt-editor and XWiki platform. All this is quite easy to do, except one thing. Plugin services are treated as components by XWiki which means service interfaces have to be annotated as component roles. This adds a dependency on xwiki-component-api to xwiki-gwt-editor. I see two options: (1) Keep the annotations and thus the dependency. This requires no effort but will make the editor less reusable for those who want to implement the services in a different way, using a different component manager for instance. (2) Remove the component role annotations and add some code to xwiki-gwt-editor-xwiki that dynamically registers as component roles at XWiki startup all the interfaces extending RemoteService (all GWT services must extend this interface). I'm not sure this is possible because components defined in components.txt are looked up earlier. Vincent, WDYT? We can improve later the organization and maybe split xwiki-gwt-editor in multiple modules, but for now this is the quickest way to make the editor reusable. I'm ready to do the split as soon as we agree on the details. WDYT? Thanks, Marius

14 years, 10 months

[xwiki-devs] Attachment file name truncation

by rushero＠inbox.ru

Hello, XWiki team! i saw this topic: http://www.xwiki.org/xwiki/bin/view/FAQ/Whenuploadtheaccessoriesatthexwiki13 versionallChinesewillbedeletedinfilename and i have the same problem, but with russian characters. When i'm adding the file with name, like "russian_word123.txt" - it is adds like "123.txt". All russian symbols are truncated. With english and numbers - all fine. Please help asap... All encoding are sets t oUTF-8 and hole Xwiki don't have problem with russian characters, except attachment thing. I'm really need russian characters in file names, how I can get this, or disable the truncation function??? BTW - my environment are: XWiki Enterprise 2.1.25683 Oracle 10gR2 Thanks!

14 years, 10 months

[xwiki-devs] l10n layout idea

by Vincent Massol

Hi, Why not have panels on the right too (for the home page at least) and have 3 panels on the right: - Create an Account - Add a language - Supported Languages This would free up space for the main view so that more of the latest translations can be seen without scrolling. I also think it would make the page more balanced. WDYT? Thanks -Vincent

14 years, 10 months

[xwiki-devs] hbm.xml files don't appear to be in the war files

by Peter McLarty

Hi All I am trying to install the war file and get it working with Oracle I have followed the instructions resolved a number of issues I still have a problem at present and it appears that the war file for configuring with its own database and container does not contain any of teh hbm.xml files I have tried the stable and latest and scanning them I cannot locate them in teh war file Could someone confirm this for me and what is the best approach in the sort term should I just download from the svm repository? Thanks Cheers Peter

14 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 February 2010