xwiki-devs March 2010

xwiki-devs@xwiki.org

45 participants
125 discussions

Re: [xwiki-devs] [xwiki-notifications] r27636 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki

by Sergiu Dumitriu

On 03/15/2010 12:36 PM, vmassol (SVN) wrote: > Author: vmassol > Date: 2010-03-15 12:36:08 +0100 (Mon, 15 Mar 2010) > New Revision: 27636 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java > Log: > XWIKI-4902: Introduce new APIs based on Entity Reference (public APIs) > > * Better implementation > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java 2010-03-15 11:04:29 UTC (rev 27635) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java 2010-03-15 11:36:08 UTC (rev 27636) > @@ -1493,8 +1493,11 @@ > public DocumentReference getDocumentReferenceFromPath(String path, XWikiContext context) > { > // TODO: Remove this and use XWikiURLFactory instead in XWikiAction and all entry points. > + > + // Make sure the path is URL-decoded > + String decodedPath = Util.decodeURI(path, context); No, this breaks encoded / (%2B) in document names. > List<String> segments = new ArrayList<String>(); > - for (String segment : path.split("/", -1)) { > + for (String segment : decodedPath.split("/", -1)) { > segments.add(segment); > } > // Remove the first segment if it's empty to cater for cases when the path starts with "/" > @@ -1505,18 +1508,7 @@ > XWikiEntityURL entityURL = (XWikiEntityURL) this.entityXWikiURLBuilder.build( > new WikiReference(context.getDatabase()), segments); > > - // URL-unencode the parsed document reference parts since the path we get as input can contain URL-encoded > - // path segments. > - // TODO: When we move to using XWikiURLFactory this won't be needed anymore. > - DocumentReference documentReference = > - new DocumentReference(entityURL.getEntityReference().extractReference(EntityType.DOCUMENT)); > - documentReference.setName(Util.decodeURI(documentReference.getName(), context)); > - documentReference.getLastSpaceReference().setName( > - Util.decodeURI(documentReference.getLastSpaceReference().getName(), context)); > - documentReference.getWikiReference().setName( > - Util.decodeURI(documentReference.getWikiReference().getName(), context)); > - > - return documentReference; > + return new DocumentReference(entityURL.getEntityReference().extractReference(EntityType.DOCUMENT)); > } > -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 9 months

[xwiki-devs] XE 2.2.3 preparation

by Vincent Massol

Hi devs, We need to start releasing XE 2.2.3 ASAP (there was a big regression re creation of subwikis for XEM). The idea is to release Wednesday if that's ok for everyone. Please let me know if you know of an important bug that should go in 2.2.3 and that's not already there. Same if you're working on something for 2.2.3 Thanks -Vincent

14 years, 9 months

[xwiki-devs] two ideas

by Beibei Yang

Hello All, I'd like to contribute to the XWiki project through the GSoC 2010. I just spent the evening to try out XWiki. It's really a cool app. I love it! I have a couple ideas to make it even better but I'm not 100% sure if they are implemented. Please enlighten me. 1. Import blog entries from RSS feeds: The XWiki Blog allows users to add blog entries. It would be useful to implement the feature to allow users to import blog entries from RSS feeds. 2. Add Feedburner to all the feeds in XWiki. Thank you, Beibei (Betty) Yang

14 years, 9 months

[xwiki-devs] [Proposal] Add support for PostgreSQL

by Caleb James DeLisle

Hello, Postgres works quite well with XWiki as it is (I use it on localhost without issue). The only feature missing right now is virtual wiki support, this is because Hibernate demands that everything take place inside of a transaction and Postgres demands that databases be created outside of a transaction. Recently I have found that I can open a single connection and switch it to "autoCommit" mode create a database then close the session. A test case: {{groovy}} session = xcontext.getContext().getWiki().getHibernateStore().getSessionFactory().openSession(); connection = session.connection(); try { connection.setAutoCommit(true); statement = connection.createStatement(); statement.execute("create database subwiki"); } finally { connection.setAutoCommit(false); session.close(); } {{/groovy}} I am proposing we add a method to XWikiHibernateStore: executeWithAutoCommit(String sql) which does what is shown in the above code. This should open the door to postgres support. WDYT? Caleb

14 years, 9 months

[xwiki-devs] Regex validation of password on registration page

by Caleb James DeLisle

Guillaume Lerouge asked me on IRC if one could choose a regex for validating a password which a user chooses. This was the question: CalebJamesDeLisl: do you know whether it's possible to specify a regex for the password check in the new registration screen? <glerouge> like, if the password does not have at least 3 numbers, 3 lowecase letters and 3 uppercase letters refuse it Since he was gone when I woke up, I decided to answer here. The answer is yes it is quite possible, in fact there is a regex being used already at the moment the regex only forces the user to choose a password longer than 5 characters but it can be changed in the configuration at the top of the registration page. The configuration looks like this: ## ##The password field, mandatory and must be at least 6 characters long. #set($field = {'name' : 'register_password', 'label' : $msg.get('core.register.password'), 'params' : { 'type' : 'password', 'size' : '10' }, 'validate' : { 'mandatory' : { 'failureMessage' : $msg.get('xe.admin.registration.fieldMandatory') }, 'regex' : { 'pattern' : '/.{6,}/', 'failureMessage' : $msg.get('xe.admin.registration.passwordTooShort') } } }) and where it says /.{6,}/ is where you would put the expression (and you would probably want to change the failure message) Note that you may not add another regular expression below the one already existing because the data is stored as a map and a map can only have one value for the key 'regex'. Caleb

14 years, 9 months

[xwiki-devs] [Proposal] Allow users to send mail inviting their friends to join a wiki.

by Caleb James DeLisle

Users should be able to invite other people to join their wiki by sending email made with a template. They should be able to add a message. There should be a template message which tells what the invitation is about. They should be taken to the registration application (their email address can be filled in as long as <> " ' \ characters are escaped to prevent XSS) There should be a mechanism to store the ip addresses/user names of those who send the email and a link in the email to report spam so the service is not abused. I would like to make it an application if possible. Your thoughts? Caleb

14 years, 9 months

[xwiki-devs] http://webid.myxwiki.org/

by Story Henry

A very basic implementation of foaf+ssl is up here: http://webid.myxwiki.org/ We put it up at its own wiki to allow us more freedom to try out new ideas. You can currently create an account there, then create your X509 certificate in one click which you can use to login to other sites. Some things that would be fun to put there: 1- cool homepage URLs ------------------- For example: http://webid.myxwiki.org/id/bblfish would be nice, and a lot better than http://webid.myxwiki.org/xwiki/bin/view/XWiki/hjs This would then allow us later to all have URLs like http://xwiki.org/id/bblfish Which makes for good OpenIds. 2- Add OpenId to the home pages ------------------------------ This is extremely easy. Just add <link rel="openid2.provider openid.server" href="http://openid4.me/index.php"/> to the header of the profile page. http://OpenId4.me/ automatically logs one in then if one has a WebId 3- Add Foaf+ssl login to xwiki ------------------------------ - using https://foafssl.org/srv/idp to start off with to get the basics right - by developing a module that fits into xwiki (more setup costs, but speeds things up a lot) 4- Somewhat more clever authentication policies ----------------------------------------------- Using foaf+ssl one can develop rules to give access to parts of the wiki to all the friends of one's friends, to all people working on a project (described by DOAP), etc... Many more ideas. But I'll be happy if the above work. I think that should get everyone here interested enough to develop more such cool examples. Social Web Architect http://bblfish.net/ Social Web Architect http://bblfish.net/

14 years, 9 months

[xwiki-devs] [Proposal] Add support for Default Values for XWiki Wiki Macros

by Anamaria Stoica

Hi, I would like to add support for Default Values for XWiki Wiki Macros. It's not very difficult, as the XWiki Java Macros already have it. The required changes would be: - add default value property to XWiki.WikiMacroParameterClass - update DefaultWikiMacroFactory#buildMacro() to parse the new parameter - update WikiMacroParameterDescriptor with a new property for default value parameter, a new constructor and also update the getDefaultValue method Thanks, Anamaria

14 years, 9 months

[xwiki-devs] Revamp the invitation manager: restore, or rewrite? application or module?

by Caleb James DeLisle

Hello all, I would like to get the email invitation manager up and working again but I'm not sure how to do it. 1. Get the plugin working and write a small application as a front end for it. This is fast and reliable but the plugin system is deprecated and it wouldn't be that cool to be perpetuating dependency on a deprecated system. 2. Rewrite the invitation manager. I think this could be done within the 2.3 timeframe but I can't be sure of it. 2A. Rewrite as an application. This was my first thought, my reasons are because while sending email is a generic need deserving of an API, sending invitation mail is a specific need and if we are to include a public function for each need as specific as invitation email then we will surely end up with a monstrous and unmaintainable API. The problem with an application is that it is harder to maintain and keep clean, we have more systems in place such as checkstyle, advanced IDEs and the strict java compiler which are unavailable in groovy and especially unavailable in velocity. 2B. Rewrite as a module. This has the distinct advantage of the code being easier to manage, but carries the risk of bloated API. At the moment I can't think of any way to make the module available to the application/presentation end without adding to the API. How do you think this should be done? Any other options to avoid growing the api? Caleb

14 years, 9 months

[xwiki-devs] considering integration of XWiki with Sakai

by Adam Hocek

Hello, I am a developer at Marist College. We are an active member of the Sakai (sakaiproject.org). Sakai is an open source Collaboration and Learning Environment that supports many tools for collaboration. There is currently a wiki in Sakai called rWiki based on Radeox wiki. rWiki is somewhat limited and there is interest to investigate an alternative wiki option that we might integrate with. XWiki is an option that we are considering and wanted to reach out to the XWiki community to see if this was something of interest. Sakai is also developed in Java and makes sense to use XWiki's Java API. I think at this point in time we would like to see if a similar integration with another product has been done before and also to see if we could get support from the XWiki community for issues that arise during the integration process. Any feedback would be appreciated. - Adam Adam Hocek Information Technology Marist College tel: 845-575-3948

14 years, 9 months

← Newer
1
...
6
7
8
9
10
11
12
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs March 2010