Hi devs,
Currently we are unable to insert what we want in list item or table
for example.
One way to support it is to introduce "embedded document", meaning a
syntax which act like we are including another document.
See http://jira.xwiki.org/jira/browse/XWIKI-2890 for details.
Wikimodel is using (((....))) in it's own syntax.
Since we don't use this currently, I propose to use the same syntax in
XWiki 2.0 syntax.
Here is my +1.
Thanks,
--
Thomas Mortagne
Hello,
in the new Servlet Component, there is the Container which contains the
global environment.
When it receives an action request, it gets the right Action from the
ComponentManager and launch the handleRequest function.
Should the Container be injected into Action components to retrieve local
Request/Response objects or may I misunderstand the model?
regards
Pascal
Hello,
I am studying the component model and its impact on the whole architecture
and naturally I have been thinking about OSGI and the possibility to deliver
component bundles and load dynamically components into a running XWiki
server etc... I'm not an OSGI expert and speak about OSGI because this seems
to be the most supported standard around these "dynamic service bundles
management with classloader isolation blablabla" questions...
I've seen OSGI is already in your thoughts and I would like to know the
status of your studies.
The question of the OSGI runtime is not quite a problem to my mind...
The new component model is well fitted to the OSGI approach IMO...
The real question is how to mix the IOC model with the OSGI bundle...
Plexus is a pretty IOC container but has no OSGI extension (there seems to
be some works around classworlds but not clear and classworlds is not OSGI
anyway...).
Would you keep Plexus and add the required extensions so that it can be
easily used with OSGI without adding too much code each time you want to
create a new OSGI service bundle?
Would you think about using another IOC container which propose OSGI
extensions (Spring DM or other)?
Pascal
Hi everyone,
This is something some of us have discussed offline but I'd like to
propose it officially to everyone. As you may know we'd like to bring
the XWiki Workspaces (XWS) features (invitation, user directory,
private wikis, etc) into the main product, i.e. XE/XEM so that we
don't have 2 platforms to maintain and so that we have a single main
product and several add-ons (xwiki watch, etc).
So the idea here is to add the following social features to XEM and
not to XE, thus mapping the notion of XWS spaces to wikis (XE wikis):
* Invitation manager
* User Directory
* Social network (people I follow, people following me)
* My dashboard (see all my wikis, their activities, etc)
* Wiki dashboard (stats on wikis)
The idea is that XEM is for the enterprise and thus it makes sense to
have the user directory in there rather than in XE. Same for all the
other social features.
Thanks
-Vincent
http://xwiki.comhttp://xwiki.orghttp://massol.net
The XWiki development team is pleased to announce the release of XWiki
Enterprise 1.8 Milestone 1.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
First milestone of the XWiki Enterprise 1.8 version.
Main changes:
* Syntax API to convert a document from one syntax to another +
first beta of the XWiki 1.0 syntax to XWiki 2.0 syntax.
* New Office Importer.
* REST API
* Make it easier to disable footer information (comments, history, etc)
* New blog
Important bug fixes:
* Errornous rendering of links to page anchors
* If a macro fail it breaks the whole rendering process
Note that general goals for XWiki Enterprise 1.8 are:
* Office Importer
* New Blog
* REST API
* Finish new rendering/syntax
* Finish new WYSIWYG
* French XE
* MediaWiki import
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise18M1
Thanks, The XWiki dev team
On Sun, Jan 18, 2009 at 4:34 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
> Asiri Rathnayake wrote:
> >>> + #set($fragments=$attachmentUrl.split($attachmentSignature))
> >>> + #if($listtool.size($fragments) == 2)
> >>> + #set($prefix=$listtool.get($fragments, 0))
> >>> + #set($suffix=$listtool.get($fragments, 1))
> >>> + #set($davUrl="$prefix$webdavSignature$suffix")
> >>> + <span class="xwikibuttonlinks"><a class="deletelink"
> >>
> href="javascript:davEdit('$davUrl')">$msg.get("webdaveditattachment")</a></span>
> >>
> >> You should escape $davUrl, because if it contains ' or " it will break.
> >
> >
> > I tried to do this but for some reason the url got changed to an invalid
> one
> > once i escaped it. It's kind of weird, the local application tried to
> open
> > some url like /home/asiri/http://..... I'm still not sure why this
> happens.
> >
>
> How exactly did you try to escape it? A simple .replaceAll('"',
> '"').replaceAll("'", ''') should do it.
Fixed.
Thanks.
- Asiri
Hello Xwiki-Devs,
I am not quite sure if this one is just a stupid question I haven't been
able to find an answer for, or if it is just impossible.
Situation is this: If you hava a link in a page e.g. "[GrannySmith]" and
and this page doesn't exist yet (so it'll get a questionmark as marker),
as soon as somebody clicks on that link xwiki will suggest to create a
new Page or go straight to the editor. So far so clear. Now for instance
I have a xwiki class called "Apple" can I create a link that mandates
that the newly created page should be of the class "Apple" (respectively
should have an object of "Apple")? Or is there any other way to
accomplish this?
thanks and greetings
Jonas
---------- Forwarded message ----------
From: Asiri Rathnayake <asiri.rathnayake(a)gmail.com>
Date: Fri, Jan 16, 2009 at 12:37 PM
Subject: Re: [xwiki-notifications] r15438 - enterprise/trunk
enterprise/trunk/wiki platform/core/trunk/xwiki-core/src/main/resources
platform/web/trunk/standard/src/main/webapp/templates
platform/xwiki-applications/trunk platform/xwiki-applications/trunk/webd
To: XWiki Notifications <notifications(a)xwiki.org>
Hi Segiu,
> > + #set($documentUrl=$doc.getExternalURL("download"))
> > + #set($attachmentUrl="$documentUrl/$attach.filename")
> > + #set($attachmentSignature="/xwiki/bin/download/")
> > + #set($webdavSignature="/xwiki/webdav/spaces/")
>
> This isn't safe. It is possible to change this completely. Better use:
>
>
> #set($attachmentSignature="${request.contextPath}${request.servletPath}/download/")
> #set($webdavSignature="${request.contextPath}/webdav/spaces/")
>
Fixed.
Also, this doesn't work with the new "virtualwiki-as-path" URLs.
I don't think webdav supports "virtualwiki-as-path" configuration yet. I'll
have to look into it.
> > + #set($fragments=$attachmentUrl.split($attachmentSignature))
> > + #if($listtool.size($fragments) == 2)
> > + #set($prefix=$listtool.get($fragments, 0))
> > + #set($suffix=$listtool.get($fragments, 1))
> > + #set($davUrl="$prefix$webdavSignature$suffix")
> > + <span class="xwikibuttonlinks"><a class="deletelink"
> href="javascript:davEdit('$davUrl')">$msg.get("webdaveditattachment")</a></span>
>
> You should escape $davUrl, because if it contains ' or " it will break.
I tried to do this but for some reason the url got changed to an invalid one
once i escaped it. It's kind of weird, the local application tried to open
some url like /home/asiri/http://..... I'm still not sure why this happens.
> Added: platform/xwiki-applications/trunk/webdav/pom.xml
> > ===================================================================
> > --- platform/xwiki-applications/trunk/webdav/pom.xml
> (rev 0)
> > +++ platform/xwiki-applications/trunk/webdav/pom.xml 2009-01-15 10:00:35
> UTC (rev 15438)
> > @@ -0,0 +1,14 @@
>
> Don't forget to add our License header (for all files in this app).
>
Fixed.
> > + InstallTrigger.install( {"FoXWiki" :"
> https://addons.mozilla.org/en-US/firefox/downloads/file/39674/foxwiki-1.0b-…
> "});
>
> Isn't there a version-independent URL, so that we don't have to release
> application-webdav each time we release foxwiki?
Unfortunately no, the url has to point to an xpi file. But this is not a
problem since Firefox automatically detects extension updates. And since
FoXWiki is hosted in addons.mozilla.org this is done automatically. All we
have to do is release the new version in addons.mozilla.org and users will
be notifed of the existance of a newer version.
Thanks.
- Asiri
Hi,
Just realized that our new WYSIWYG editor will only work fine with our
xwiki 2.0 syntax since other wiki syntaxes are less powerful and won't
be able to express some complex structures (like embedding a document
inside a table cell) or simply like styling a portion of text.
Of course this is not a problem of the wysiwyg editor per see but in
practice it means that users using it for other syntaxes when they
save will get a different rendered result.
So I"m tempted to say that our GWT editor will only work for the xwiki
2.0 syntax and that for the other syntaxes users will have to use the
wiki editor.
WDYT?
Thanks
-Vincent
