June 2010 - xwiki-devs@xwiki.org

[xwiki-devs] Create User in XWiki from REST Api
by xManish 22 Jun '10

22 Jun '10

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.

1 1

Re: [xwiki-devs] [xwiki-notifications] r29639 - platform/web/trunk/standard/src/main/webapp/resources/js/xwiki
by Marius Dumitru Florea 22 Jun '10

22 Jun '10

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

2 2

[xwiki-devs] [VOTE] Put XWiki Invitation Manager Plugin jira project in XWiki Retired Projects section
by Thomas Mortagne 22 Jun '10

22 Jun '10

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

5 5

[xwiki-devs] Modify page creation details without causing an update.. :S
by JoannaD 22 Jun '10

22 Jun '10

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.

2 3

Re: [xwiki-devs] [VOTE] (Results) Apply code style to imports
by Denis Gervalle 22 Jun '10

22 Jun '10

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

1 0

[xwiki-devs] [VOTE] Templates Administration Icon
by Jean-Vincent Drean 22 Jun '10

22 Jun '10

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.

11 11

[xwiki-devs] [Idea] "Modern" skin for "modern" browsers
by Ecaterina Valica 22 Jun '10

22 Jun '10

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

4 3

[xwiki-devs] [PROPOSAL] Use openoffice server when its enabled to do PDF/RTF export
by Thomas Mortagne 22 Jun '10

22 Jun '10

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

9 16

Re: [xwiki-devs] [Idea] "Modern" skin for "modern" browsers
by Jerome Velociter 22 Jun '10

22 Jun '10

----- "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

1 0

[xwiki-devs] [VOTE] Apply code style to imports
by Denis Gervalle 22 Jun '10

22 Jun '10

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

6 10