xwiki-devs June 2010

xwiki-devs@xwiki.org

34 participants
97 discussions

[xwiki-devs] Create User in XWiki from REST Api

by xManish

Hello, I was able to create a wiki page through API but got stuck while trying to create a wiki user following same way. Here is the code on how I created the wiki page. Can you advise me how to create the wiki user in the similiar manner? public void myAddMethod() { final String CONTENT = "Content 101"; final String TITLE = "Title 101"; final String PARENT = "Private.WebHome"; ObjectFactory objectFactory = new ObjectFactory(); Page page = objectFactory.createPage(); page.setContent(CONTENT); page.setTitle(TITLE); page.setParent(PARENT); HttpClient httpClient = new HttpClient(); httpClient.getState().setCredentials(AuthScope.ANY, new UsernamePasswordCredentials("admin", "admin")); httpClient.getParams().setAuthenticationPreemptive(true); JAXBContext context; try { context = JAXBContext.newInstance("org.xwiki.rest.model.jaxb"); Marshaller marshaller = context.createMarshaller(); Unmarshaller unmarshaller = context.createUnmarshaller(); PutMethod putMethod = new PutMethod("http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Private/pages/NewPage01"); putMethod.addRequestHeader("Accept", MediaType.APPLICATION_XML.toString()); StringWriter writer = new StringWriter(); marshaller.marshal(page, writer); RequestEntity entity; entity = new StringRequestEntity(writer.toString(), MediaType.APPLICATION_XML.toString(), "UTF-8"); putMethod.setRequestEntity(entity); httpClient.executeMethod(putMethod); } catch (JAXBException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (UnsupportedEncodingException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (HttpException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } } -- View this message in context: http://xwiki.475771.n2.nabble.com/Create-User-in-XWiki-from-REST-Api-tp5209… Sent from the XWiki- Dev mailing list archive at Nabble.com.

14 years, 2 months

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

by Marius Dumitru Florea

On 06/22/2010 08:15 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-06-22 19:15:28 +0200 (Tue, 22 Jun 2010) > New Revision: 29639 > > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js > Log: > XWIKI-5300: Start writing a Javascript mirror of the XWiki data model: Document.getURL > Done. The code below won't work in portlet mode because: * portlet URL format is an implementation detail for portlet containers * portlet URL parameters are not included in clear but rather encoded as a single query string parameter (checked in GateIn and WebSphere) * query string parameters appended to a portlet URL are not accessible to the targeted portlet My question is: do we really need to compute URLs on the client? (even if compute = string replace) Thanks, Marius > > 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-06-22 16:51:34 UTC (rev 29638) > +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js 2010-06-22 17:15:28 UTC (rev 29639) > @@ -1295,6 +1295,69 @@ > } > var browser = new BrowserDetect(); > > +/** > + * XWiki Model access APIs. > + */ > +XWiki.Document = Class.create({ > + /** > + * Constructor. All parameters are optional, and default to the current document location. > + */ > + initialize : function(page, space, wiki) { > + this.page = page || XWiki.Document.currentPage; > + this.space = space || XWiki.Document.currentSpace; > + this.wiki = wiki || XWiki.Document.currentWiki; > + }, > + /** > + * Gets an URL pointing to this document. > + */ > + getURL : function(action, queryString, fragment) { > + action = action || 'view'; > + var url = XWiki.Document.URLTemplate; > + url = url.replace("__space__", encodeURIComponent(this.space)); > + url = url.replace("__page__", (this.page == 'WebHome') ? '' : encodeURIComponent(this.page)); > + url = url.replace("__action__/", (action == 'view') ? '' : (encodeURIComponent(action) + "/")); > + if (queryString) { > + url += '?' + queryString; > + } > + if (fragment) { > + url += '#' + fragment; > + } > + return url; > + }, > + /** > + * Gets an URL which points to the REST location for accessing this document. > + */ > + getRestURL : function(entity, queryString) { > + entity = entity || ''; > + var url = XWiki.Document.RestURLTemplate; > + url = url.replace("__wiki__", this.wiki); > + url = url.replace("__space__", this.space); > + url = url.replace("__page__", this.page); > + if (entity) { > + url += "/" + entity; > + } > + if (queryString) { > + url += '?' + queryString; > + } > + return url; > + } > +}); > + > +/* Initialize the document URL factory, and create XWiki.currentDocument. */ > +document.observe('dom:loaded', function() { > + XWiki.Document.currentWiki = ($$("meta[name=wiki]").length> 0) ? $$("meta[name=wiki]")[0].content : "xwiki"; > + XWiki.Document.currentSpace = ($$("meta[name=space]").length> 0) ? $$("meta[name=space]")[0].content : "Main"; > + XWiki.Document.currentPage = ($$("meta[name=page]").length> 0) ? $$("meta[name=page]")[0].content : "WebHome"; > + XWiki.Document.URLTemplate = "$xwiki.getURL('__space__.__page__', '__action__')"; > + XWiki.Document.RestURLTemplate = "${request.contextPath}/rest/wikis/__wiki__/spaces/__space__/pages/__page__"; > + XWiki.Document.RestSearchURLStub = "${request.contextPath}/rest/wikis/__wiki__/search"; > + XWiki.Document.getRestSearchURL = function(wiki) { > + wiki = wiki || XWiki.Document.currentWiki; > + return XWiki.Document.RestSearchURLStub.replace("__wiki__", wiki); > + }; > + XWiki.currentDocument = new XWiki.Document(); > +}); > + > /* > * Small JS improvement, which automatically hides and reinserts the default text for input fields, acting as a tip. > * > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

14 years, 2 months

[xwiki-devs] [VOTE] Put XWiki Invitation Manager Plugin jira project in XWiki Retired Projects section

by Thomas Mortagne

Hi devs, Since the new invitation application is not based on it doubt we will ever work on this plugin. WDYT ? Here is my +1 -- Thomas Mortagne

14 years, 2 months

[xwiki-devs] Modify page creation details without causing an update.. :S

by JoannaD

Hi all Is there any way of modifying the creation details (or any other property) of a page/doc without really causing/trigerring an update? What I intend to do is modify the creator and the creation date as they were messed up during import but I need the author and the date to remain unchanged.. Any ideas? Thank you! Joanna D. ----- Joanna -- Please consider the environment -- -- View this message in context: http://xwiki.475771.n2.nabble.com/Modify-page-creation-details-without-caus… Sent from the XWiki- Dev mailing list archive at Nabble.com.

14 years, 2 months

Re: [xwiki-devs] [VOTE] (Results) Apply code style to imports

by Denis Gervalle

4 +1, 1 +0, 0 -1; applied XTVERIFICATIONS-10 in r29627 Denis On Tue, Jun 22, 2010 at 10:07, Vincent Massol <vincent(a)massol.net> wrote: > +0 > > Thanks > -Vincent > > On Jun 22, 2010, at 9:17 AM, Denis Gervalle wrote: > > > Well, > > > > Based on your feedback, the easiest and probably best solution is to keep > > the default for Eclipse (so, no need for a special config file) and to > > configure IntelliJ code style (it is the same file for all) to do the > same > > as Eclipse, which will avoid confusion: > > > > import java.* > > > > import javax.* > > > > import org.* > > > > import com.* > > > > This choice already have a +1 from Marius, a +1 from Sergiu and here is > my > > +1. > > I do not think we need long discussion on this, just an agreement, please > > could you cast your vote on this. > > > > Denis > > > > On Mon, Jun 21, 2010 at 16:13, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > > > >> On 06/21/2010 04:04 PM, Marius Dumitru Florea wrote: > >>> On 06/21/2010 02:36 PM, Denis Gervalle wrote: > >>>> On Mon, Jun 21, 2010 at 13:24, Marius Dumitru Florea< > >>>> mariusdumitru.florea(a)xwiki.com> wrote: > >>>> > >>>>> Hi Denis, > >>>>> > >>>>> On 06/21/2010 01:55 PM, Denis Gervalle wrote: > >>>>>> Hi Devs, > >>>>>> > >>>>>> Currently we do not have any code style specification for imports. > To > >>>>>> improve clarity of our commits, I propose that we decide once for > all > >> how > >>>>> we > >>>>>> would like to have imports. Of course, normalisation of existing > code > >>>>> will > >>>>>> come with normal commit, I do not intend to update it only for that. > >>>>> > >>>>> Are you saying that > >>>>> > >>>>> > >> > http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-tools/trunk/xwiki-verific… > >>>>> doesn't include information about import styles? > >>>>> > >>>> > >>>> Sorry, I do not have Eclipse, maybe Thomas could precise this point. > >>>> What I am saying is that we do not have any written code style for > that, > >> and > >>>> we use the default of the IDE. > >>>> > >>>>> > >>>>>> > >>>>>> Currently, > >>>>>> > >>>>>> Eclipse does java.*, org.*, com.* separated by blank lines > >>>>>> IntelliJ IDEA does com.*,org.* together, than a blank line and > java.* > >>>>> > >>>>> So you're saying that codestyle-eclipse.xml and codestyle-idea.xml > are > >>>>> not consistent? > >>>>> > >>>> > >>>> There are not, probably because we have never look at it and their > >> defaults > >>>> differ. > >>> > >>> I see. It's clear now. > >>> > >>>> > >>>> > >>>>> > >>>>>> Old existing code has there own ordering... > >>>>>> > >>>>>> I propose the following style: > >>>>>> > >>>>>> import java.* > >>>>>> > >>>>>> import org.* > >>>>>> import com.* > >>>>>> import<anything else> > >>>>>> > >>> > >>>>>> import org.xwiki.* > >>>>>> import com.xpn.* > >>> > >>> I don't think separating this imports from org.* and com.* makes them > >>> much more visible. Also, for classes that don't depend on the old core > >>> (com.xpn.*) moving org.xwiki.* out of org.* breaks the order. Since > >>> we'll eventually drop the com.xpn.* package in favor of org.xwiki.* I > >>> think we should keep XWiki's imports under org.* and com.* . > >>> > >>> I'm +1 for enforcing a style for imports. I'm -0 for separating > >>> org.xwiki.* and com.xpn.* from org.* and com.* respectively. > >>> > >> > >> Same as Marius. > >> > >>> > >>>>>> > >>>>>> import static<any> > >>>>>> > >>>>>> If we agree on this, necessary IDE setup for both Eclipse and > IntelliJ > >>>>>> should be prepare/updated. I will take IntelliJ in charge, a > volunteer > >>>>> for > >>>>>> Eclipse is welcome (Thomas?) > >>>>> > >>>>> You mean update codestyle-eclipse.xml and codestyle-idea.xml ? > >>>>> > >>>> > >>>> Yes, and if this is not part of codestyle-eclipse, provide what is > >> required > >>>> to have both IDE in sync. > >>>> > >>>> Denis > >>>> > >>>> > >>>>> > >>>>> Thanks, > >>>>> Marius > >>>>> > >>>>>> > >>>>>> WDYT ? > >>>>>> > >>>>>> Denis > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

14 years, 2 months

[xwiki-devs] [VOTE] Templates Administration Icon

by Jean-Vincent Drean

Hi, For the moment the templates administration section [1] uses the default icon. Ciprian made a bunch of proposals for it and I'd like to commit one of them asap: http://incubator.myxwiki.org/xwiki/bin/view/Ciprian/Template%20icon Here's my +1 for 5a. [1] http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication… Thanks, JV.

14 years, 2 months

[xwiki-devs] [Idea] "Modern" skin for "modern" browsers

by Ecaterina Valica

Hi, When the CSS3 fever began, Raluca Stavro came to me and asked me what I think about making a HTML5+CSS3 skin. My first answer was that is not gonna happen. We invest very much in making our skins have cross-browser support (especially old versions of IE). This is one of our strengths, but also the reason we limit ourselves from innovation. When I'm talking about a "modern" skin I'm not only referring about HTML, JS, CSS (having transparency, corners, multiple backgrounds, shadows without having to triple the code and the number of hacks), but it's about all cool/experimentation features, that boosts productivity, minimize code lines, etc. but lack all/old browser support (SVG, location awareness, CSS3 calc etc). So, in my opinion this would be an experimentation/shiny skin that by comparison would make old browsers supporters and lovers to quit their old behaviors and embrace the future :) :p So, the questions I have are: 1) would this be possible? would anyone want to do this sort of thing? I know the biggest problem is gonna be the maintenance, but could bring lots of innovation and productivity. 2) what feature/improvement/thing do you think it would be the most needed for a new "modern" "skin" (the topic somehow go beyond the skin boundaries)? Thanks, Caty

14 years, 2 months

[xwiki-devs] [PROPOSAL] Use openoffice server when its enabled to do PDF/RTF export

by Thomas Mortagne

Hi devs, Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO. So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently. That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4. The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more. WDYT ? We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover. -- Thomas Mortagne

14 years, 2 months

Re: [xwiki-devs] [Idea] "Modern" skin for "modern" browsers

by Jerome Velociter

----- "Ecaterina Valica" <valicac(a)gmail.com> wrote: > Hi, > > When the CSS3 fever began, Raluca Stavro came to me and asked me what > I > think about making a HTML5+CSS3 skin. My first answer was that is not > gonna > happen. We invest very much in making our skins have cross-browser > support > (especially old versions of IE). This is one of our strengths, but > also the > reason we limit ourselves from innovation. > > When I'm talking about a "modern" skin I'm not only referring about > HTML, > JS, CSS (having transparency, corners, multiple backgrounds, shadows > without > having to triple the code and the number of hacks), but it's about > all > cool/experimentation features, that boosts productivity, minimize > code > lines, etc. but lack all/old browser support (SVG, location awareness, > CSS3 > calc etc). > > So, in my opinion this would be an experimentation/shiny skin that by > comparison would make old browsers supporters and lovers to quit their > old > behaviors and embrace the future :) :p > > So, the questions I have are: > > 1) would this be possible? would anyone want to do this sort of thing? > I > know the biggest problem is gonna be the maintenance, but could bring > lots > of innovation and productivity. For lot of cases (that is at least everything that includes JS, and maybe more) we should be able to add such new features on top of the existing UI, i.e. without the need to create a dedicated skin. Take for example attachment Drag & Drop in the attachment footer tab. We just detect the feature and offer it if supported (do nothing if not). > > 2) what feature/improvement/thing do you think it would be the most > needed > for a new "modern" "skin" (the topic somehow go beyond the skin > boundaries)? Right now I think of - attachments D&D - upload with progress bar - growl-like client notifications (w/ WebSocket) - local drafts (with localStorage) - a profile picture sizing/cropping tool using canvas - ... I'm sure a lot more :) Jerome. > > Thanks, > Caty > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

14 years, 2 months

[xwiki-devs] [VOTE] Apply code style to imports

by Denis Gervalle

Hi Devs, Currently we do not have any code style specification for imports. To improve clarity of our commits, I propose that we decide once for all how we would like to have imports. Of course, normalisation of existing code will come with normal commit, I do not intend to update it only for that. Currently, Eclipse does java.*, org.*, com.* separated by blank lines IntelliJ IDEA does com.*,org.* together, than a blank line and java.* Old existing code has there own ordering... I propose the following style: import java.* import org.* import com.* import <anything else> import org.xwiki.* import com.xpn.* import static <any> If we agree on this, necessary IDE setup for both Eclipse and IntelliJ should be prepare/updated. I will take IntelliJ in charge, a volunteer for Eclipse is welcome (Thomas?) WDYT ? Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

14 years, 2 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs June 2010