> about that the simplest thing to do is to put all your development pages in
> a /view/Dev/ space, and then use #includeTopic("Dev.ScriptPage") to display
> them in usual content-only wiki pages while preserving the ability to use
> the WYSIWYG editor for basic users...
>
> Once you do this the WY
not think
> about it when you start working on a wiki site.
>
>
>
> Anyway I don't regret using XWiki because it's a great wiki IMO, and I
> really appreciate the way it evolves
>
>
>
> Jeremie
>
>
> ----------
>
> *From:* [E
XWiki Users
Subject: Re: [xwiki-users] XWiki scripting for end user (not Groovy)
I'm happy to hear that. I hope I didn't seem to harsh on the
feedback.
I do think xwiki is a nice product!
> then we hope you'll keep using it :-)
> Feedba
>
>
>
> I'm happy to hear that. I hope I didn't seem to harsh on the feedback.
> I do think xwiki is a nice product!
> then we hope you'll keep using it :-)
> Feedback isn't too harsh, it's important for us to be aware of how XWiki
users feel about our software. And hopefully you'll be bringing i
> A specification is currently written by xwiki developers to refactor
> the use of xwiki forms (objects&classes). I hope we'll be able to
> implement it soon.
I'm happy to hear that. I hope I didn't seem to harsh on the feedback.
I do think xwiki is a nice product!
William
__
On Nov 20, 2007 10:18 AM, William Lesguillier <[EMAIL PROTECTED]> wrote:
> As I said before some features are too complicated, forms and template
> for example. TWiki and Deki Wiki have dead simple mechanisms to make
> templates. I think it's because they're slightly different. XWiki
> templates al
> BTW, I'd be interested to know how you found about XWiki and what are your
> impressions about it (besides its user guide... :-)
I first discovered XWiki two years ago and it seemed a bit raw, I was
looking for a corporate wiki and the features proposed fit my needs
but the interface and user ex
Hi,
yep, in the end macros are exactly what your were looking for. They are
designed to let people create quick ways to access features they use a lot
(a nice css display for a floating box for instance). They leverage XWiki's
scripting ability and make them available to end-users to perform simple
Regarding the user guide, I'd split the feature presentation part
(aimed to be a commercial content) and the real user guide. It
confuses a bit (both users and prospectors) and doesn´t give the user
a presentation of the features and how to use them in a step by step
manner. Macros for instance are
> > I'm no dev, but I would argue that even if velocity or groovy are a
> > little awkward, it's better to learn a standardized scripting language
> > than have to pick up a new proprietary scripting syntax for every wiki
> > project (or any other application that stands to benefit from scripting)
Power user guide sounds good to me.
Guillaume
On 16/11/2007, Vincent Massol <[EMAIL PROTECTED]> wrote:
>
>
> On Nov 16, 2007, at 6:03 PM, Paul Grodt wrote:
>
> >> Hi,
> >>
> >> First: I am rather new to XWiki.
> >>
> >> I am checking XWiki's scripting capabilities. The possibility of
> >> using
>
On Nov 16, 2007, at 6:03 PM, Paul Grodt wrote:
>> Hi,
>>
>> First: I am rather new to XWiki.
>>
>> I am checking XWiki's scripting capabilities. The possibility of
>> using
>> Groovy and Velocity directly within pages is a nice feature. But I
>> was
>> wondering if there was an easier way to
> Hi,
>
> First: I am rather new to XWiki.
>
> I am checking XWiki's scripting capabilities. The possibility of using
> Groovy and Velocity directly within pages is a nice feature. But I was
> wondering if there was an easier way to integrate dynamic contents
into
> wiki pages. Groovy is easier t
Hi,
First: I am rather new to XWiki.
I am checking XWiki's scripting capabilities. The possibility of using
Groovy and Velocity directly within pages is a nice feature. But I was
wondering if there was an easier way to integrate dynamic contents into wiki
pages. Groovy is easier than Java but you
14 matches
Mail list logo
