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