- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] Official application license ambiguity

by Sergiu Dumitriu

Hi devs, I just noticed that although we've been saying that "This wiki is licensed under a Creative Commons 2.0 license", all the source files for the wiki pages are actually under the LGPL, which contradicts the wiki. So, there are three possible choices: - change the default copyright notice - change the license of the applications - don't change anything, implying that the CC applies only to new content inserted by the user Personally I prefer to keep all the wiki content as CC, since LGPL is not exactly suited for content. However, since most of the default wiki pages are actually code pages, we could say that they consist mostly of code, which could go under the LGPL. As a side note, we should be more specific about which kind of Creative Commons is that, BY, SA, NC... -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 7 months

6
17
0 0

Re: [xwiki-devs] [xwiki-users] New blog entry overwrites old

by Sergiu Dumitriu

On 02/04/2010 06:02 PM, Guillaume Lerouge wrote: > Hi Daniel, > > On Thu, Feb 4, 2010 at 5:45 PM, Daniel Johansson<djohansson(a)haascnc.com>wrote: > >> >> Indeed, I just tried in 2.2M2 and it tells you the document exists. in 2.04 >> I >> did not delete the older post, it got overwritten so now I had 2 posts with >> the exact same title and content in the News category, it's still here in >> our wiki. And I actually updated the first post which updated both posts! >> They are identical, same date, title and content. >> >> The solution to tell user that document already exist is not very good. In >> time you may have hundreds of blog entries in one category, making it >> pretty >> hard to keep titles unique. In our case we wanted to use it to post what >> testing is to be done for the week. So each week you want to post an entry >> such as "Weekly testing". It'll be hard to come up with unique variants to >> that every week! >> > > You can modify the article creation form to add something like: > > $xwiki.getUniquePageName($space, $input) > > see > http://platform.xwiki.org/xwiki/bin/download/DevGuide/API/xwiki%2Dcore%2D2.… > details. > > Sergiu, I'm starting to think we could add this to most of the creation > forms to avoid duplicates, WDYT? > > I'm increasingly doing it for apps I write on my projects (almost all the > time now). I'm not quite fond of this idea, but something more complex would work. If the page already exists, offer a few options: - link to the page so that the user can go to it and edit it instead of creating a new page - let the user type another page name - use getUniquePageName, which appends a number at the end - append the current date at the end -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 7 months

2
2
0 0

[xwiki-devs] How to add a page with contents in xwiki through Rest api???

by Nithya Vembu

Hi All, I am very new to XWiki and also to rest api. I have gone through the link given by xwiki for rest api http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI. But i dont getting clear idea, how can i create a page under space with some contents.. and i am not getting any good samples for xwiki rest api. Normally through httpclient we can send the url with contents like eg :String url = "http://localhost:8080/jforum/jforum.page?" + "module=adminCategories" + "&action=insertSave" + "&category_name=" + categoryName + "&moderate=0" + "&groups=1" + "&groups=2" + "&groups=3" + "&groups=4"; using POST method in httpclient and the data get stored in the respective place. Kindly anyone give me idea how rest will get differentiate in xwiki manner.. Can anyone give me a code snippet for this requirement so that i can improve my progress in my project.. Any help greatly appreciated. Thanks in advance. Regards, Nithya. -- View this message in context: http://n2.nabble.com/How-to-add-a-page-with-contents-in-xwiki-through-Rest-… Sent from the XWiki- Dev mailing list archive at Nabble.com.

15 years, 7 months

1
0
0 0

[xwiki-devs] Invitation to connect on LinkedIn

by Jinath Sanjitha

LinkedIn ------------Jinath Sanjitha requested to add you as a connection on LinkedIn: ------------------------------------------ Guillaume, I'd like to add you to my professional network on LinkedIn. - Jinath Accept invitation from Jinath Sanjitha http://www.linkedin.com/e/9s_c-0fN05p6qjQq9meQgfVB/blk/I1785165164_2/1BpC5v… View invitation from Jinath Sanjitha http://www.linkedin.com/e/9s_c-0fN05p6qjQq9meQgfVB/blk/I1785165164_2/39vd3o… ------------------------------------------ DID YOU KNOW you can conduct a more credible and powerful reference check using LinkedIn? Enter the company name and years of employment or the prospective employee to find their colleagues that are also in your network. This provides you with a more balanced set of feedback to evaluate that new hire. http://www.linkedin.com/e/rsr/inv-27/ ------ (c) 2010, LinkedIn Corporation

15 years, 7 months

1
0
0 0

[xwiki-devs] [Proposal] Script Bridge

by Vincent Massol

Hi, This is following the proposal done here some time ago: http://markmail.org/message/nnybto3mluvp2rov Since we now have a generic Script notion we need to revisit it in that light. Also we really need to implement it now since more and more components are put in the velocity context (office importer, syntax factory, etc) and we need to bring some order. Here's a new generic proposal: Short term ======== * The variable "services" is bound in the script context. For ex in Velocity: $services * The Services object (ScriptServiceManager) has a ScriptService get(String serviceName) method which returns the service * We use the namespace: services.<module name>.<method>. Each module provides only one service entry point. * ScriptService interface (empty interface) represents a service to be bound in the context * ScriptServiceManager.get() looks for all components of role ScriptService and returns the component matching the the name as the component hint. Ex: @Component("mymodule") public class MyModuleScriptService implements ScriptService, MyModuleBusinessInterface { public void myMethod() {} } In script: {{velocity}} $services.mymodule.myMethod {{/velocity}} Medium term ========== * We handle @authorization(Authorization.PROGRAMMING) annotations to check for access rights. To do this in ScriptServiceManager.get() we use a Dynamic Proxy to implement MyModuleBusinessInterface (we probably need a ScriptService.getInterface() method to make it unambiguous). The Dynamic Proxy checks the annotation before proxying to the real object. WDYT? Thanks -Vincent PS: This is to answer Sergiu's question about where is getAvailableParserSyntaxes() from my other mail... ;) Answer: It would be in RenderingScriptService.

15 years, 7 months

5
17
0 0

[xwiki-devs] best way to set-up test for the tuned lucene plugin?

by Paul Libbrecht

Hello developers, what's the best way for me to setup tests for the lucene plugin? Is there an easy way for me to create an xwiki content-store with all the documents of this xar directory? That'd be my favourite. Alter natively, I could create XWikiDocument from xml by hand in the editor (but then I'm missing the callback "also add this and that"). thanks for hints. paul

15 years, 7 months

2
4
0 0

[xwiki-devs] [Proposal] Deprecate more remaining methods with "web" in their name

by Sergiu Dumitriu

Hi devs, I'd like to further the move from web to space by deprecating all the methods that still use Web in their name. These are: - in XWiki: getWebCopyright, getWebPreference*, copyWikiWeb, getDefaultWeb, useDefaultWeb - in Document: getCurrentMonthWebStats - in objects.BaseClass: get/setDefaultWeb (should we keep the element name in the XML?) As per our official deprecation strategy, these methods will continue to be present in the generated classes via the deprecation aspect, for at least 2 major releases. WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 7 months

6
6
0 0

[xwiki-devs] foaf+ssl on XWiki

by Story Henry

Hi, foaf+ssl [1] is a very simple protocol for distributed authentication. It essentially does what OpenId does, but in a RESTful manner. It works with most desktop browsers since X509v3 came out (which is a long time ago). It only uses open standards and protocols - it just uses them in a more distributed way. It is also very easy to implement, and here is what would be needed to implement in XWiki. I can help out here. 1. Profile Creation ------------------- Take any user home page URL. 1. You can either have that page link to an rdf/xml representation of a foaf graph, or you can add RDFa directly to the home page by marking up the page with foaf. It depends on how much those pages are templated. If they are very templated then the rdfa solution can be very neat, as there is less risk that the user will mess something up. 2. Add a certification creation servlet that knows how to deal with the keygen tag, and the microsoft activeX component. We have the code for this available open source in Java. What we need in addition is a little database to keep track of the different public keys used by the profile owner, so that he can delete a key if he looses his computer, or add a new one if he wishes to use someone else's. The above should be very little work, and should allow people to log into other services in one click. You can try a test case out by going to http://foaf.me/ but clearly generating rdf/xml for users to play around with is not a good idea. Also foaf.me only allows one to have one certificate per profile. Ok, so you will say there are not a lot of services for the moment. True. We are in boot strapping mode. But with one tiny little trick you can get one useful service going. http://openid4.me/ gives anyone an openid automatically and allows them to log in using foaf+ssl. (There are just a few lines of code that you need to add to get that to work at the top of the profile page) 2. Authentication ----------------- There is one super easy way to get authentication working and that is to use https://foafssl.org/srv/idp The details of how that works is explained there. (and the source code is also available at https://sommer.dev.java.net/ ) With that service you can get someone's WebID in a few lines of code. See the login link at the top of http://foaf.me/ . Setting up an xwiki server so that it asks the user for his Client certificate is a bit more advanced, as it requires a hack to the SSL layer on the server (so that authentication does not fail if it cannot find the Certificate Authority). (By the way this should not be the only means of authentication. OpenId and username passwords are good fallback solutions) 3. Possible services to build ------------------------------ With the previous pieces in place some very nice services should be buildable. But those could be left to groovy developers. 1. Improve comment management on blogs. (if someone logs in with an OpenId that points to a foaf, or with a webid, you can get links to images of the person, their blog, and other accounts, friends perhaps, etc... This can help the person who is going to validate the post to get some contextual information on the person posting the blog (and perhaps add him to a contact list). Verification can be done automatically by the server by GETing a blog page and finding a link there back to the foaf) 2. Allow people from other XWiki instances (and indeed any foaf file) access to another wiki. So one could specify things like: allow only my friends or friends of my friends access to this wiki page. Or the colleagues of my friends, ... ) But one should start simple... We have written out a list of use cases here: http://esw.w3.org/topic/foaf+ssl/UseCases There are bound to be a lot more. But for us and everyone to try them, we need to have some basics in place. Henry [1] see the introductory material here http://esw.w3.org/topic/foaf+ssl Social Web Architect http://bblfish.net/

15 years, 7 months

3
5
0 0

[xwiki-devs] [ANN] XWiki Enterprise 2.2 Release Candidate 1 Released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise 2.2 Release Candidate 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the first and hopefully last release candidate for the 2.2 version. This release is mostly a bugfix and stabilization release. Changes from XWiki Enterprise 2.2 Milestone 2: * Bug fixes and improvements on new XAR Import UI and User Profile UI * UI improvements on tag applications * WYSIWYG and Rendering bugfixes and improvements * Fixed files handlers leak on Lucne plugin * Many other bugfixes and improvements For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise22RC1 Thanks -The XWiki dev team

15 years, 7 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r26638 - in platform: core/trunk/xwiki-core/src/main/resources web/trunk/wysiwyg/src/main/resources/com/xpn/xwiki/wysiwyg/client/editor

by Vincent Massol

For the French language since we're a lot here to speak French I think we should only import validated translations. After looking for 10 seconds I found the following problems: +core.importer.documentSelected=Documents selectionn\u00E9s. +core.importer.importHistory=Hostorique import\u00E9 +core.importer.replaceDocumentHistory=Remplacer l'historique du document par l'historique issue de l'archive. +core.importer.resetHistory=R\u00E9initialiser l'historique pour la version 1.1 +core.importer.securitySettingsChanged=Les conditions de s\u00E9curit\u00E9 ont chang\u00E9 durant l''import. Vous allez avoir besoin de <ahref\="{0}"> pour authentifier </a> dans le but de continuer \u00E0 administrer le wiki. +core.importer.select=Selectionner +core.importer.selectThisPackage=Selectionner cette archive. +core.importer.selectionEmptyWarning=Selectionnez au moins un document \u00E0 importer s'il vous plait I'm sure there are more obvious problems. These need to be fixed before we release at least since they're easy to spot and fix. Thanks -Vincent On Feb 3, 2010, at 1:55 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2010-02-03 13:55:05 +0100 (Wed, 03 Feb 2010) > New Revision: 26638 > > Modified: > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources_de.properties > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources_fr.properties > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources_lv.properties > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources_nl.properties > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources_ro.properties > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources_sk.properties > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources_sv.properties > platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources_zh.properties > platform/web/trunk/wysiwyg/src/main/resources/com/xpn/xwiki/wysiwyg/client/editor/Strings_sk.properties > Log: > XWIKI-4846: Update translations [snip]

15 years, 7 months

2
2
0 0

[xwiki-devs] [VOTE] Don't include the JavaScript extensions when rendering a document in WYSIWYG edit mode

by Marius Dumitru Florea

Hi devs, Right now JavaScript extensions are included when a document is rendered in WYSIWYG edit mode. This has both advantages and disadvantages. Pro: If the output of a macro depends on a JavaScript extension, then the result of rendering that macro will be the same in view mode and (WYSIWYG) edit mode. Con: If the JavaScript extension is not aware of the edit mode then it can modify the DOM document outside of the read-only macro markers which leads to unwanted changes in the content of the edited document (i.e. the modifications done by the JavaScript extension are saved). Such an example is http://jira.xwiki.org/jira/browse/XWIKI-4665 . WDYT? Should we limit the WYSIWYG in order to make the editing safer? I'm +0. Thanks, Marius

15 years, 7 months

5
15
0 0

[xwiki-devs] [VOTE] Add get/setSyntax and deprecate get/setSyntaxId() in Document/XWikiDocument

by Vincent Massol

Hi, I'd like to make this change for 2.2RC1 (since I don't see any danger about it, although that's subjective and if we don't agree I could wait for 2.3M1). <explanation> The story behind this is because we need to get access to the Syntax object from templates in a few places order to check the syntax used. Right now for example we do the following in macros.vm for the livetable macro: #if($doc.syntaxId == "xwiki/2.0") The pb is that this is going to fail in the future when we introduce the XWiki 2.1 syntax (which we're preparing with Thomas). To fix this we'll need to check that syntax.getType == "xwiki" && syntax.getVersion > 1.0 instead. I also wanted to convert some panels to 2.0 syntax for 2.2 final but that requires to convert macros.vm's #panelheader to work fine with all syntaxes rather than adding ugly checks in panel code itself... (or wrapping them all with unnecessary html macros). </explanation> Here's my +1 for doing it now (although I'm also +1 for doing it but in 2.3M1). Note that doing now has one advantage: In order to implement it cleanly we need to break an API, namely: CoreConfiguration.getDefaultDocumentSyntax would return Syntax instead of returning String now. Since this API isn't used from Velocity and is pretty new there's little risk to break lots of people but better modify it ASAP than wait. Thanks -Vincent

15 years, 7 months

6
11
0 0

[xwiki-devs] Which skins do we want to support?

by Vincent Massol

Hi, We need to decide which skins we want to support/maintain. By support/maintain I mean fixing bugs and improving them. Right now we have 3 skins in the platform: - Albatross - Toucan - Colibri We still need to keep it in platform for now since others depend on it but the question of knowing if we support it or not is independent IMO. Several questions: * Are we still supporting the Albatross skin? * Same question for Toucan? * We could decide not to support it but to apply contributor patches for it. * We could also decide that we don't support it and close jira issues related to it with won't fix. My feeling: - Keep it in platform for now, keep jira issues, apply patches, don't break what exists (when we change template files or CSS files for ex). WDYT? Thanks -Vincent

15 years, 7 months

3
3
0 0

Re: [xwiki-devs] [xwiki-notifications] r26554 - platform/web/trunk/standard/src/main/webapp/templates

by Sergiu Dumitriu

On 01/29/2010 10:04 PM, vmassol (SVN) wrote: > Author: vmassol > Date: 2010-01-29 22:04:01 +0100 (Fri, 29 Jan 2010) > New Revision: 26554 > > Modified: > platform/web/trunk/standard/src/main/webapp/templates/copy.vm > Log: > XWIKI-4817: Allow to copy a document's default language + all translations in the copy menu action > > * Template part > > Modified: platform/web/trunk/standard/src/main/webapp/templates/copy.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/copy.vm 2010-01-29 19:58:17 UTC (rev 26553) > +++ platform/web/trunk/standard/src/main/webapp/templates/copy.vm 2010-01-29 21:04:01 UTC (rev 26554) > @@ -19,7 +19,7 @@ > <div id="document-title"><h1>$msg.get('core.copy.copydoc')</h1></div> > #set($sourcedoc = "$!{request.sourcedoc}") > #set($targetdoc = "$!{request.targetdoc}") > - #if("$!request.language" != "") That's wrong, fragile. Localized messages should not be used as select values. <option value="ALL">$msg.get('core.copy.allTranslations')</option> + "$!{request.language}" != 'ALL' > + #if("$!request.language" != ""&& "$!request.language" != $msg.get("core.copy.allTranslations")) > #set($language = $request.language) > #end > #set($sourcewiki = $context.database) > @@ -48,8 +48,11 @@ > <td>$msg.get("language"):</td> > <td> > <select name="language"> > + ## Add a special "All Translations" combo box entry to copy all translations. > +<option selected="selected">$msg.get("core.copy.allTranslations")</option> > + ## Add all the existing translations > #foreach ($docTranslation in $docTranslations) > -<option #if($docTranslation == "$!{context.language}")selected="selected"#end>$docTranslation</option> > +<option>$docTranslation</option> > #end > </select> -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 7 months

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r26284 - platform/skins/trunk/colibri/src/main/resources/colibri

by Vincent Massol

First commit! Yeah :) Champagne! Some questions below (hey I couldn't left the first commit go without questions ;)) On Jan 21, 2010, at 4:24 PM, evalica (SVN) wrote: > Author: evalica > Date: 2010-01-21 16:24:22 +0100 (Thu, 21 Jan 2010) > New Revision: 26284 > > Modified: > platform/skins/trunk/colibri/src/main/resources/colibri/colibri.css > Log: > XSCOLIBRI-180: Scroll and width problems on Stats space > > Modified: platform/skins/trunk/colibri/src/main/resources/colibri/colibri.css > =================================================================== > --- platform/skins/trunk/colibri/src/main/resources/colibri/colibri.css 2010-01-21 14:52:45 UTC (rev 26283) > +++ platform/skins/trunk/colibri/src/main/resources/colibri/colibri.css 2010-01-21 15:24:22 UTC (rev 26284) > @@ -1316,7 +1316,7 @@ > } > > div.panellayoutcontainer-2col .panellayoutcol { > - width: 50%; > + width: 49%; Where does this magic number come from? Is the 1% important? If so maybe this warrants some comment? > } > > div.panellayoutcontainer-3col .panellayoutcol { > @@ -1324,11 +1324,11 @@ > } > > div.panellayoutcontainer-4col .panellayoutcol { > - width: 25%; > + width: 24%; same > } > > div.panellayoutcontainer-5col .panellayoutcol { > - width: 20%; > + width: 19%; same > } > > div.panellayoutcontainer-1col, div.panellayoutcontainer-2col, div.panellayoutcontainer-3col, div.panellayoutcontainer-4col, div.panellayoutcontainer-5col { > @@ -1339,15 +1339,13 @@ > .panellayoutcol { > float: left; > height: 1%; > - overflow: auto; > - > } > > .panellayoutcol .panel { > - border: 1px solid #ddd; > - margin: 0 0 20px 5%; > + border: 1px solid $theme.borderColor; > + margin: 0 0 5% 5%; > + overflow-x: auto; > width: 90%; > - > } > > #xwikicontent .panel ul { Thanks -Vincent

15 years, 7 months

3
14
0 0

Re: [xwiki-devs] [xwiki-notifications] r26619 - platform/web/trunk/standard/src/main/webapp/templates

by Vincent Massol

On Feb 2, 2010, at 8:13 PM, vmassol (SVN) wrote: > Author: vmassol > Date: 2010-02-02 20:13:03 +0100 (Tue, 02 Feb 2010) > New Revision: 26619 > > Modified: > platform/web/trunk/standard/src/main/webapp/templates/javascript.vm > Log: > XWIKI-4841: Section editing links should not appear on pages for which users don't have edit rights > > * More improvement (this time from Marius Florea!) oops that was from Sergiu Dumitriu... sorry :) -Vincent > > Modified: platform/web/trunk/standard/src/main/webapp/templates/javascript.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/javascript.vm 2010-02-02 18:58:01 UTC (rev 26618) > +++ platform/web/trunk/standard/src/main/webapp/templates/javascript.vm 2010-02-02 19:13:03 UTC (rev 26619) > @@ -36,7 +36,7 @@ > XWiki.docisnew = $!doc.isNew(); > XWiki.docsyntax = "$!doc.getSyntaxId()"; > XWiki.blacklistedSpaces = [ #foreach($space in $blacklistedSpaces)#if($velocityCount > 1),#end"$space"#end ]; > -XWiki.hasEdit = #if($hasEdit) true #else false #end; > +XWiki.hasEdit = $hasEdit; > window.docviewurl = "${doc.getURL('view')}"; > window.docediturl = "${doc.getURL('edit')}"; > window.docsaveurl = "${doc.getURL('save')}";

15 years, 7 months

1
0
0 0

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

by Sergiu Dumitriu

On 02/02/2010 04:46 PM, Thomas Mortagne wrote: > On Tue, Feb 2, 2010 at 16:25, Sergiu Dumitriu<sergiu(a)xwiki.com> 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... > > Actually we don't need to list checked files, we list here because we > don't want to check all files. I know, it's not "we need because we can't", but "we need because we do". In this project we're using both includes and excludes, when we could be using only excludes. >> >>> + **/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. >> >>> + int queryStringPosition = label.indexOf("?"); >>> + if (queryStringPosition> -1) { >>> + label = label.substring(0, queryStringPosition); >>> + } >>> + return label; >>> + } >>> +} -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 7 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r26615 - in platform/web/trunk/standard/src/main/webapp: resources/js/xwiki templates

by Sergiu Dumitriu

On 02/02/2010 07:13 PM, vmassol (SVN) wrote: > Author: vmassol > Date: 2010-02-02 19:13:59 +0100 (Tue, 02 Feb 2010) > New Revision: 26615 > > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js > platform/web/trunk/standard/src/main/webapp/templates/javascript.vm > Log: > XWIKI-4841: Section editing links should not appear on pages for which users don't have edit rights > > * Use boolean (good suggestion from Jerome Velociter) > > Modified: platform/web/trunk/standard/src/main/webapp/templates/javascript.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/javascript.vm 2010-02-02 18:02:33 UTC (rev 26614) > +++ platform/web/trunk/standard/src/main/webapp/templates/javascript.vm 2010-02-02 18:13:59 UTC (rev 26615) > @@ -36,7 +36,7 @@ > XWiki.docisnew = $!doc.isNew(); > XWiki.docsyntax = "$!doc.getSyntaxId()"; > XWiki.blacklistedSpaces = [ #foreach($space in $blacklistedSpaces)#if($velocityCount> 1),#end"$space"#end ]; > -XWiki.hasEdit = "$hasEdit"; > +XWiki.hasEdit = #if($hasEdit) true #else false #end; Why not simply XWiki.hasEdit = ${hasEdit}; since it is a boolean and will be printed as a boolean. -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years, 7 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r26614 - in platform/web/trunk/standard/src/main/webapp: resources/js/xwiki templates

by Vincent Massol

On Feb 2, 2010, at 7:06 PM, Jerome Velociter wrote: > On 2/2/10 7:02 PM, vmassol (SVN) wrote: >> Author: vmassol >> Date: 2010-02-02 19:02:33 +0100 (Tue, 02 Feb 2010) >> New Revision: 26614 >> >> Modified: >> platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js >> platform/web/trunk/standard/src/main/webapp/templates/javascript.vm >> Log: >> XWIKI-4841: Section editing links should not appear on pages for which users don't have edit rights >> >> Modified: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js >> =================================================================== >> --- platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js 2010-02-02 17:19:46 UTC (rev 26613) >> +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js 2010-02-02 18:02:33 UTC (rev 26614) >> @@ -337,7 +337,7 @@ >> */ >> insertSectionEditLinks: function() { >> // Insert links only in view mode and for xwiki/2.0 documents. >> - if (XWiki.docsyntax == "xwiki/2.0"&& XWiki.contextaction == "view") { >> + if (XWiki.docsyntax == "xwiki/2.0"&& XWiki.contextaction == "view"&& XWiki.hasEdit == "true") { >> >> // Section count starts at one, not zero. >> var sectioncount = 1; >> >> Modified: platform/web/trunk/standard/src/main/webapp/templates/javascript.vm >> =================================================================== >> --- platform/web/trunk/standard/src/main/webapp/templates/javascript.vm 2010-02-02 17:19:46 UTC (rev 26613) >> +++ platform/web/trunk/standard/src/main/webapp/templates/javascript.vm 2010-02-02 18:02:33 UTC (rev 26614) >> @@ -36,6 +36,7 @@ >> XWiki.docisnew = $!doc.isNew(); >> XWiki.docsyntax = "$!doc.getSyntaxId()"; >> XWiki.blacklistedSpaces = [ #foreach($space in $blacklistedSpaces)#if($velocityCount> 1),#end"$space"#end ]; >> +XWiki.hasEdit = "$hasEdit"; > > why not using a boolean ? > > XWiki.hasEdit = #if($hasEdit) true #else false #end; Done Thanks -Vincent > Jerome. > >> window.docviewurl = "${doc.getURL('view')}"; >> window.docediturl = "${doc.getURL('edit')}"; >> window.docsaveurl = "${doc.getURL('save')}";

15 years, 7 months

1
0
0 0

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

by Thomas Mortagne

On Tue, Feb 2, 2010 at 15:51, vmassol <platform-notifications(a)xwiki.org> 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, > + **/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/AttachURILabelGenerator.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/AttachURILabelGenerator.java (rev 0) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/AttachURILabelGenerator.java 2010-02-02 14:51:13 UTC (rev 26602) > @@ -0,0 +1,58 @@ > +/* > + * See the NOTICE file distributed with this work for additional > + * information regarding copyright ownership. > + * > + * This is free software; you can redistribute it and/or modify it > + * under the terms of the GNU Lesser General Public License as > + * published by the Free Software Foundation; either version 2.1 of > + * the License, or (at your option) any later version. > + * > + * This software is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this software; if not, write to the Free > + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA, or see the FSF site: http://www.fsf.org. > + */ > +package org.xwiki.rendering.internal.renderer; > + > +import org.xwiki.component.annotation.Component; > +import org.xwiki.component.annotation.Requirement; > +import org.xwiki.rendering.listener.Attachment; > +import org.xwiki.rendering.listener.Link; > +import org.xwiki.rendering.parser.AttachmentParser; > +import org.xwiki.rendering.renderer.URILabelGenerator; > + > +/** > + * Generate link labels for ATTACH URIs. > + * > + * @version $Id$ > + * @since 2.2RC1 > + */ > +@Component("attach") > +public class AttachURILabelGenerator implements URILabelGenerator > +{ > + /** > + * The ATTACH URI prefix (the scheme followed by ":"). > + */ > + private static final String ATTACH = "attach:"; > + > + /** > + * Used to extract the attachment name from the reference. > + */ > + @Requirement > + private AttachmentParser attachmentParser; > + > + /** > + * {@inheritDoc} > + * @see org.xwiki.rendering.renderer.URILabelGenerator#generateLabel(org.xwiki.rendering.listener.Link) > + */ > + public String generateLabel(Link link) > + { > + Attachment attachment = this.attachmentParser.parse(link.getReference().substring(ATTACH.length())); > + return attachment.getAttachmentName(); > + } > +} > > > Property changes on: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/AttachURILabelGenerator.java > ___________________________________________________________________ > Name: svn:keywords > + Author Id Revision HeadURL > Name: svn:eol-style > + native > > Modified: 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/DefaultLinkLabelGenerator.java 2010-02-02 14:38:44 UTC (rev 26601) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/DefaultLinkLabelGenerator.java 2010-02-02 14:51:13 UTC (rev 26602) > @@ -32,6 +32,10 @@ > @Component > public class DefaultLinkLabelGenerator implements LinkLabelGenerator > { > + /** > + * {@inheritDoc} > + * @see org.xwiki.rendering.renderer.LinkLabelGenerator#generate(org.xwiki.rendering.listener.Link) > + */ > public String generate(Link link) > { > return link.getReference(); > > 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) > @@ -0,0 +1,54 @@ > +/* > + * See the NOTICE file distributed with this work for additional > + * information regarding copyright ownership. > + * > + * This is free software; you can redistribute it and/or modify it > + * under the terms of the GNU Lesser General Public License as > + * published by the Free Software Foundation; either version 2.1 of > + * the License, or (at your option) any later version. > + * > + * This software is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this software; if not, write to the Free > + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA, or see the FSF site: http://www.fsf.org. > + */ > +package org.xwiki.rendering.internal.renderer; > + > +import org.xwiki.component.annotation.Component; > +import org.xwiki.rendering.listener.Link; > +import org.xwiki.rendering.renderer.URILabelGenerator; > + > +/** > + * Generate link labels for MAILTO URIs. > + * > + * @version $Id$ > + * @since 2.2RC1 > + */ > +@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()); > + // Also remove the query string part from the label (we only want the email address). > + int queryStringPosition = label.indexOf("?"); > + if (queryStringPosition > -1) { > + label = label.substring(0, queryStringPosition); > + } Since it's an URI why don't you use new URI(link.getReference()) to parse it ? > + return label; > + } > +} > > > Property changes on: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/MailtoURILabelGenerator.java > ___________________________________________________________________ > Name: svn:keywords > + Author Id Revision HeadURL > Name: svn:eol-style > + native > > Modified: 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/java/org/xwiki/rendering/internal/renderer/xhtml/DefaultXHTMLLinkRenderer.java 2010-02-02 14:38:44 UTC (rev 26601) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/internal/renderer/xhtml/DefaultXHTMLLinkRenderer.java 2010-02-02 14:51:13 UTC (rev 26602) > @@ -36,6 +36,7 @@ > import org.xwiki.rendering.listener.LinkType; > import org.xwiki.rendering.parser.AttachmentParser; > import org.xwiki.rendering.renderer.LinkLabelGenerator; > +import org.xwiki.rendering.renderer.URILabelGenerator; > import org.xwiki.rendering.renderer.printer.XHTMLWikiPrinter; > import org.xwiki.rendering.renderer.xhtml.XHTMLLinkRenderer; > import org.xwiki.rendering.wiki.WikiModel; > @@ -70,11 +71,6 @@ > private static final String ATTACH = "attach:"; > > /** > - * The link reference prefix indicating that the link is targeting a mail address. > - */ > - private static final String MAILTO = "mailto:"; > - > - /** > * The class attribute 'wikilink'. > */ > private static final String WIKILINK = "wikilink"; > @@ -276,23 +272,26 @@ > if (link.getType() == LinkType.DOCUMENT) { > getXHTMLWikiPrinter().printXML(this.linkLabelGenerator.generate(link)); > } else if (link.getType() == LinkType.URI) { > + > + // Look for a component implementing URILabelGenerator with a role hint matching the URI scheme. > + // If not found then use the full reference as the label. > + int schemeSeparator = link.getReference().indexOf(":"); > + > + // If there's no scheme separator then use the full reference as the label. Note that this can happen > + // when we're not in wiki mode (since all links are considered URIs when not in wiki mode). > String label; > - // Special handling for MAILTO and ATTACH URIs for which we don't want to print the scheme in the label > - // (so that they appear displayed a nicer way for users). > - if (link.getReference().startsWith(ATTACH)) { > - // Only display the attachment name. > - Attachment attachment = this.attachmentParser.parse(link.getReference().substring(ATTACH.length())); > - label = attachment.getAttachmentName(); > - } else if (link.getReference().startsWith(MAILTO)) { > - label = link.getReference().substring(MAILTO.length()); > - // For MAILTO also remove the query string part from the label (we only want the email address). > - int queryStringPosition = label.indexOf("?"); > - if (queryStringPosition > -1) { > - label = label.substring(0, queryStringPosition); > + if (schemeSeparator > -1) { > + String scheme = link.getReference().substring(0, schemeSeparator); > + try { > + URILabelGenerator uriLabelGenerator = this.componentManager.lookup(URILabelGenerator.class, scheme); > + label = uriLabelGenerator.generateLabel(link); > + } catch (ComponentLookupException e) { > + label = link.getReference(); > } > } else { > label = link.getReference(); > } > + > getXHTMLWikiPrinter().printXML(label); > } else { > getXHTMLWikiPrinter().printXML(link.getReference()); > > Added: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/renderer/URILabelGenerator.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/renderer/URILabelGenerator.java (rev 0) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/renderer/URILabelGenerator.java 2010-02-02 14:51:13 UTC (rev 26602) > @@ -0,0 +1,40 @@ > +/* > + * See the NOTICE file distributed with this work for additional > + * information regarding copyright ownership. > + * > + * This is free software; you can redistribute it and/or modify it > + * under the terms of the GNU Lesser General Public License as > + * published by the Free Software Foundation; either version 2.1 of > + * the License, or (at your option) any later version. > + * > + * This software is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this software; if not, write to the Free > + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA, or see the FSF site: http://www.fsf.org. > + */ > +package org.xwiki.rendering.renderer; > + > +import org.xwiki.component.annotation.ComponentRole; > +import org.xwiki.rendering.listener.Link; > + > +/** > + * Generate link labels for URIs. For example an implementation for MAILTO URIs would remove the scheme part and the > + * query string part. > + * > + * @version $Id$ > + * @since 2.2RC1 > + */ > +@ComponentRole > +public interface URILabelGenerator > +{ > + /** > + * @param link the link pointing to a URI for which we want to generate a label > + * @return the URI label to display when rendering links > + */ > + String generateLabel(Link link); > +} > > > Property changes on: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/java/org/xwiki/rendering/renderer/URILabelGenerator.java > ___________________________________________________________________ > Name: svn:keywords > + Author Id Revision HeadURL > Name: svn:eol-style > + native > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/resources/META-INF/components.txt > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/resources/META-INF/components.txt 2010-02-02 14:38:44 UTC (rev 26601) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/resources/META-INF/components.txt 2010-02-02 14:51:13 UTC (rev 26602) > @@ -9,6 +9,8 @@ > org.xwiki.rendering.internal.configuration.DefaultRenderingConfiguration > org.xwiki.rendering.internal.parser.DefaultSyntaxFactory > org.xwiki.rendering.internal.renderer.DefaultLinkLabelGenerator > +org.xwiki.rendering.internal.renderer.AttachURILabelGenerator > +org.xwiki.rendering.internal.renderer.MailtoURILabelGenerator > org.xwiki.rendering.internal.macro.DefaultMacroManager > org.xwiki.rendering.internal.transformation.DefaultTransformationManager > org.xwiki.rendering.internal.renderer.xwiki.XWikiSyntaxRenderer > > Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/java/org/xwiki/rendering/SimpleRenderingTests.java > =================================================================== > --- platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/java/org/xwiki/rendering/SimpleRenderingTests.java 2010-02-02 14:38:44 UTC (rev 26601) > +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-tests/src/test/java/org/xwiki/rendering/SimpleRenderingTests.java 2010-02-02 14:51:13 UTC (rev 26602) > @@ -37,6 +37,7 @@ > public static junit.framework.Test suite() throws Exception > { > RenderingTestSuite suite = new RenderingTestSuite("Rendering tests not requiring the wiki notion"); > + suite.addTestsFromResource("link/links24", false); > > // Embedded documents > suite.addTestsFromResource("group/group1", false); > @@ -210,7 +211,7 @@ > suite.addTestsFromResource("encoding/encoding1", false); > > // Links without WikiModel > - suite.addTestsFromResource("link/links24", false); > +// suite.addTestsFromResource("link/links24", false); > > return new ComponentManagerTestSetup(suite); > } > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications > -- Thomas Mortagne

15 years, 7 months

2
1
0 0

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; >> + } >> +}

15 years, 7 months

1
0
0 0

[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

15 years, 7 months

8
15
0 0

[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

15 years, 7 months

2
5
0 0

[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

15 years, 7 months

4
6
0 0

[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!

15 years, 7 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs