Hi,
I'd like to attach an image to the current document but the image is
attached to another document. I couldn't find the answer in the FAQ.
It would be great if the {image:} radeox macro allowed for this.
Right now the only solution I'v found (which is a bit ugly) is to use an
HTML <img> tag as in:
<img src="/xwiki/bin/download/XWiki/Toolbar/image.gif" />
Any other solution I would have missed?
Thanks
-Vincent
___________________________________________________________________________
D�couvrez une nouvelle fa�on d'obtenir des r�ponses � toutes vos questions !
Profitez des connaissances, des opinions et des exp�riences des internautes sur Yahoo! Questions/R�ponses
http://fr.answers.yahoo.com
How can I turn off the "shortcut" URLs where /bin/Space/Page is
interpreted as /bin/view/Space/Page?
(Specifically, I'm using mod_redirect to clean up the URL
architecture and need to assume that anything prefixed /bin that
isn't /bin/view needs to be passed through as an action.)
- - -
Hans Gerwitz
http://phobia.com/
Hi,
Sergiu said in an email he wanted to modify the branching policy for
1.0. So I'm proposing 2 choices and let you vote about them:
Option 1 (current policy):
====================
* Work on trunk till we cut the RC. At that point in time create a
branch
Pros:
* Simple. Minimal merging from branch to trunk to do.
* No risk of forgetting something (like something is on trunk but not
in branch where it should be, and no risk of forgetting to merge back
on trunk something from the branch)
Cons:
* If someone introduces a big instability, we'll need to revert it
* Committers cannot commit something not working on trunk (in any
case nobody should ever do that)
* If a new feature is committed that impacts other features, it's
possible that it won't be stable enough. This is especially true as
we don't have lots of automated tests to discover regression. Note:
If we had strong automated tests we would never need to create a
branch (this is how I do it on the Cargo project and I've never had
any issue).
Option 2:
========
* Create a 1.0 branch right now. All work leading to 1.0 must go to
that branch. Trunk is for work for 1.1.
Pros:
* People working on 1.1 can do so on trunk
* Less stabilization risk issues
Cons:
* Requires more discipline. People must be careful to commit on the
right branch/trunk.
* We absolutely need to merge to trunk whenever someone commits to
the 1.0 branch as otherwise merging is a big pain later on.
Please cast your votes.
I'm +1 for Option 2 but provided all committers agree as it's a
little bit more work and more importantly requires discipline.
Thanks
-Vincent
___________________________________________________________________________
Yahoo! Mail r�invente le mail ! D�couvrez le nouveau Yahoo! Mail et son interface r�volutionnaire.
http://fr.mail.yahoo.com
I am a New user.
I have some previous experience with 0.9.840.
Just installed Xwiki 1.0 beta3 (requiring upgraded to java5)
The sql database is xwiki, user xwiki, pasword xwiki as before
Everything seems to work OK and I can edit content.
I have imported Panels, nothing else.
I have "Log-in", "Register", "Administration", "En" in the top right BUT ...
I cannot login as Admin - password "admin"
I cannot register a new user
When I try to register I just get a login screen.
Under Administration I can get to the "Users and groups" where it says ...
You can currently edit users using the wiki on the users page. (I can't)
You can currently edit groups using the wiki on the groups page. (I can't)
But if I go to those pages I can see nothing and do not see how to add users.
What am I missing?
Hi,
There doesn't seem to be a tag in xwiki corrisponding to the beta 3
release... should there be (I like to have the source so I can poke
around when things go wrong & the trunk will obviously, soon if not
already, be out of sync).
On 30/01/07, Vincent Massol <vincent(a)massol.net> wrote:
> Hi Mark,
>
> On Jan 30, 2007, at 5:17 AM, Marc Lijour wrote:
>
> > On Monday 29 January 2007 11:06, Vincent Massol wrote:
> >> Hi everyone,
> >>
> >> We're happy to announce the 1.0 Beta 3 release. It's a bug fix
> >> release.
> >>
> >> Release note on: http://www.xwiki.org/xwiki/bin/view/Main/
> >> ReleaseNotesXWiki10Beta3
> >>
> >> Thanks and enjoy
> >> -The XWiki Team
> >
> > Thank you.
> >
> > Curious, there is no WEB-INF directory under webapps/xwiki/ in the
> > tarball.
>
> You got me worried for a few minutes... Fortunately I've checked and
> it's there... :-)
>
> -Vincent
>
>
>
>
>
>
> ___________________________________________________________________________
> Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
> http://fr.mail.yahoo.com
>
>
>
>
> --
> You receive this message as a subscriber of the xwiki-users(a)objectweb.org mailing list.
> To unsubscribe: mailto:xwiki-users-unsubscribe@objectweb.org
> For general help: mailto:sympa@objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>
>
Hi Ed/Mac,
You wet our appetite with your plugin... Any progress?
Thanks
-Vincent
On Jan 6, 2007, at 1:54 AM, Ludovic Dubost wrote:
>
> Hi,
>
> This looks nice.. We are already using JTidy for the HTML -> XHTML
> conversion before we export to PDF.
> A good way to do this is indeed as an XWiki plugin.
> I would suggest 2 plugins:
>
> 1/ Importer
> It would be great if the importer have a generic part and a format
> specific part. We could use the base code as the code to import from
> other wiki formats.
> There is one case which is complex in importing is when you want to
> handle links. You might need to read multiple files to convert links
> from one format to another. For example if you have a set of HTML
> files
> with relative links you might want to convert them to wiki links.
> An importer framework which allows to handle this would be great.
>
> 2/ Validator/Cleaner
> It would be great to be able to use each part separately and have
> some
> options when calling it.
> Besides cross side scripting being able to allow/refuse tag lists
> would
> be great and also allow/refuse velocity and groovy
>
> I guess Vincent would like to see the plugin outside of the core, but
> I'll leave this to him.
>
> Ludovic
>
> Mac a écrit :
> > Hey there,
> > I was thinking about building a XWiki plugin that will import
> > (dynamically) another website, either whole or partial (A little XML
> > parsing of it), besides reading the one page Plugin Doc Is there any
> > thing else that I could use to help me speed up this development?
> Like
> > XML parser/HtmlTidy or something that XWiki may already uses?
> >
> >
> > Also,
> > While I am on this topic of html, since the Wiki will take
> > Html/xml in the normal editing of the page. I would be willing to
> > write a Validator that would strip out dangerious html (Cross site
> > scripting,...) I have already done this in a filter for a "Sudo
> wiki"
> > I was building from scratch, but would be willing to re-write it
> in a
> > way that would be helpful to the project, if someone could point
> me in
> > the right direction where this type of Class would fit in to the
> project.
> >
> > Thanks,
> >
> > Cant wait to see beta 2
> >
> >
> >
>
The new way to import/export wiki pages is very useful. However, I
think that using the .xar extension for the zip(!) archive is highly
confusing. This because there is already a XAR(eXtensible ARchiver)
archiving utility which uses the .xar extension for quite a while. And
while now XAR is standalone, it will be quite probable used by the
MacOSX package system in the future. Then download your archive will
yield an error like this (safari automatically expands archives):
"Error opening xar archive: xwiki-1.0-beta-1.xar"
Links:
http://www.opendarwin.org/projects/xar/http://www.nabble.com/xar-in-Mac-OS-X-t2081148.html
Hi,
For the Exhibit project, they're using a google spreadsheet to feed
there interface. So it should be possible to use the same API to feed
a table in a wikipage.
here is the explanation:
http://simile.mit.edu/wiki/Exhibit/How_to_make_an_exhibit_from_data_fed_dir…
if someone want to work on it, that could be great.
jeremi
Hi all !
http://jira.xwiki.org/jira/browse/XWIKI-524
Now we're going to rewrite the info, warning, error and floatingbox macros to make use of the style macro.
I'm proposing 2 choices:
Option 1 : we will use this syntax for info, warning, error and floatingbox macros :
{style:type=warning}
This is the warning !!
{style}
{style:type=info}
This is the Info !!
{style}
{style:type=error}
This is the Error !!
{style}
{style:type=floatingbox }
This is the floatingbox !!
{style}
Option 2 :
{warning}
This is the warning with multiple lines !!
This is the warning with multiple lines !!
{warning}
{info}
This is the info with multiple lines !!
This is the info with multiple lines !!
{info}
......
which syntax should we use for xwiki ! I need your opinions about this problem.
Thanks and best regards !
- Phung Nam.