Hello,
I need to be able to include a Servlet or JSP from inside of
/templates/*.vm files (specifically header and footer).
I tried things like:
$request.getRequestDispatcher("/xxx.jsp").include( $request, $response )
But for some reason (buffering in Velocity I guess) it renders included
page before anything else, no matter where it's actually placed. Is
there some workaround? If not, I think I have an idea how to implement a
kind of "#includeServlet" directive, could it be included in XWiki then?
Greetings, Lilianne E. Blaze
Hi everyone,
Do you really want to keep the following which is part of most file headers:
* Created by
* User: Ludovic Dubost
* Date: 26 nov. 2003
* Time: 13:52:39
This seems to me information that can be retrieved from the SCM. And if we
want to store SCM information in the file then it is only fair that whoever
modifies the file should also get credit there. In addition usually we would
use the @author tag for storing this kind of information. Having it in an
undefined format like above is a bit strange... ;-)
So I think there are 2 options:
Option 1:
---------
- We do not store author information in the file
- We have a credits Wiki page that lists all contributors and what they have
done. Something like:
- http://jakarta.apache.org/cactus/participating/contributors.html
- http://cargo.codehaus.org/Credits
- It's still a good idea to have a @version tag in the file, as in:
* @version $Id: Container.java 348 2005-04-26 23:03:22Z vmassol $
The content of this tag is generated automatically by the SCM upon commit.
Option 2:
---------
- We save author information in the file using @author tags. For example
@author <a href="mailto:...@...">Ludovic Dubost</a>
@author <a href="mailto:...@...">Vincent Massol</a>
[...]
There have been *lots* of debates (which I'll spare you here but you can
google it) between these 2 options and the one chosen @ Apache is option 1.
I have done the same for Cargo.
I don't mind the chosen solution but I think the current option is not good
enough.
Thanks
-Vincent
_____________________________________________________________________________
D�couvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vid�os !
Cr�ez votre Yahoo! Mail sur http://fr.mail.yahoo.com
Hi,
I'm trying to fix some unit tests and by doing so I'm working my way in the
XWiki API. I have thousands of ideas to improve the design but honestly I
don't know where to start from; it's a bit overwhelming ;-)
We need to start somewhere, so we might as well start with the XWiki class
constructor. ATM, the constructor is:
public XWiki(String xwikicfgpath, XWikiContext context)
public XWiki(String xwikicfgpath, XWikiContext context,
XWikiEngineContext engine_context, boolean noupdate)
public XWiki(InputStream is, XWikiContext context,
XWikiEngineContext engine_context)
The first parameter is used to pass a location of a config file. Actually
this parameter is only used to create a XWikiConfig object.
I believe we should delegate the creation of a XWikiConfig object to the
XWikiConfig object itself so that our API can resist to change. Imagine that
tomorrow I want to store a XWiki config in a database. Today the API would
not cope with this because it's rigid and unflexible. It violates IOC.
Here's my proposal for the XWiki class:
- Deprecate the current constructors
- add 2 new constructors:
public XWiki(XWikiConfig config, XWikiContext context)
public XWiki(XWikiConfig config, XWikiContext context,
XWikiEngineContext engine_context, boolean noupdate)
Thus the "user" must start by creating a XWikiConfig, then a XWikiContext,
possibly an EngineContext and then only he can create a XWiki object. The
idea is that the creation of a config should be left to the config object
and NOT to the Wiki class (it's not its role).
This leads to a better design. In addition to being more flexible this will
allow for easier unit testing as we will not need a xwiki.cfg file anymore
(it will still be used for functional testing though).
Obviously the next step would be to transform XWikiConfig into an interface.
What do you think?
Thanks
-Vincent
_____________________________________________________________________________
D�couvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vid�os !
Cr�ez votre Yahoo! Mail sur http://fr.mail.yahoo.com
Hello,
I am trying to use XWiki in conjunction with Selenium to enable any user to write application tests through xwiki and run them on selenium.
I have been quite succesful but require a way of accessing an xwiki page in completelly plain formatting. I.e. without the side bars, google add bar etc.
What would be a good way of doing this? I've attempted using skins but to limited effect.
Thanks
Alex
Hi,
I'm still struggling to fix the tests that I have broken with my last
refactoring (the generation of the hibernate config file tests.build.dir and
its retrieval through the classpath). Sorry about that...
I'm not sure what's the reason. Here's attached the test report of a test
class that now fails. If you have any idea let me know.
Also, I've noticed that the test/wiki.cfg file has:
xwiki.store.hibernate.path=hibernate-test.cfg.xml
Is that used anywhere? I thought that the config file was passed by the Java
classes.
Thanks
-Vincent
> -----Original Message-----
> From: Vincent Massol [mailto:vincent@massol.net]
> Sent: mardi 31 mai 2005 09:58
> To: 'xwiki-dev(a)objectweb.org'
> Subject: RE: [xwiki-dev] [Build] About to move tests
>
> Hi,
>
> It seems that the tests are generating some files during their execution.
> They seem to generate:
>
> - test/velocity.log
> - test/xwiki.log
> - test/hibernate-test.cfg.xml
> - test/rcs/Test/*
>
> Could someone tell me how I can update the test files so that these
> generated files go into the build/ directory instead of going into a
> source directory?
This is pre-requisite before I can make any modification to the directory
structure. Actually what should be done is remove the dependency on paths.
ATM, I've noticed that several tests are using path to find test resources.
I believe this is not right and should be improved by using the classpath to
locate the test resources.
In other words, instead of doing something like:
public static final String hibpath = "hibernate-test.cfg.xml";
XWikiHibernateStore hibstore = new XWikiHibernateStore(hibpath);
We should be doing:
public static final String hibLocation = "/hibernate-test.cfg.xml";
URL hibURL = getClass().getResource(hibLocation);
XWikiHibernateStore hibstore = new XWikiHibernateStore(hibURL);
And we add src/test/resources to the JUnit execution CP.
What's wrong with paths?
- they are system dependent
- they can be absolute or relative and the result will depend from where you
execute the code. Thus they are brittle
WDYT?
I don't know the code well so I would need your help in fleshing out the
places where paths are used. I've noticed one in AllTests.java (see attached
"patch" - I've also added some other comments).
Once we don't rely any more on paths then we'll be able to move /test in
src/test/resources.
Thanks for your help
-Vincent
>
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: Vincent Massol [mailto:vincent@massol.net]
> > Sent: mardi 31 mai 2005 09:47
> > To: xwiki-dev(a)objectweb.org
> > Subject: [xwiki-dev] [Build] About to move tests
> >
> > Hi developers,
> >
> > This is a heads up as I'm about to move test sources and resources as
> > planned in a previous email (see also XWIKI-12).
> >
> > The following changes will happen:
> >
> > - trunk/test will go in src/test/resources
> > - trunk/src/test will go in src/test/java
> > - trunk/src/test-cactus will go in src/test/cactus
> >
> > This means that you'll need to add the src/test/resources directory to
> > your
> > execution classapath in your IDE project files. You'll also need to
> change
> > src/test to src/test/java and src/test-cactus to src/test/cactus.
> >
> > Please shout if you have an issue with this. I'll be doing it in about 1
> > hour.
> >
> > Thanks
> > -Vincent
> >
> >
> >
> >
> >
> >
> >
> __________________________________________________________________________
> > ___
> > Dicouvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos
> > mails, photos et vidios !
> > Criez votre Yahoo! Mail sur http://fr.mail.yahoo.com
Hi developers,
This is a heads up as I'm about to move test sources and resources as
planned in a previous email (see also XWIKI-12).
The following changes will happen:
- trunk/test will go in src/test/resources
- trunk/src/test will go in src/test/java
- trunk/src/test-cactus will go in src/test/cactus
This means that you'll need to add the src/test/resources directory to your
execution classapath in your IDE project files. You'll also need to change
src/test to src/test/java and src/test-cactus to src/test/cactus.
Please shout if you have an issue with this. I'll be doing it in about 1
hour.
Thanks
-Vincent
_____________________________________________________________________________
D�couvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vid�os !
Cr�ez votre Yahoo! Mail sur http://fr.mail.yahoo.com
Hi,
I'd like to change the page's title for
http://mavenbook.xwiki.com/xwiki/bin/view/Main/WebHome. It says "Wiki - Web
- WebHome". How can I do that easily?
Thanks
-Vincent
_____________________________________________________________________________
D�couvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vid�os !
Cr�ez votre Yahoo! Mail sur http://fr.mail.yahoo.com
> -----Original Message-----
> From: Vincent Massol [mailto:vincent@massol.net]
> Sent: dimanche 29 mai 2005 21:27
> To: 'xwiki-dev(a)objectweb.org'
> Subject: RE: [xwiki-dev] [build] Test not better than before...
[snip]
> Only a few tests are failing now. The LDAP one seems to be blocking (it's
> been stuck there for several minutes - I hope it'll timeout).
It did after 388 seconds... hrmmm... Something needs to be done there. I
think we should exclude all tests that are not working in the default build
(they can run on the CC install).
There are 12 test failures and 1 test error when using the default build
setup (i.e. nothing installed). I'm only talking about the client side
tests.
[snip]
-Vincent
_____________________________________________________________________________
D�couvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vid�os !
Cr�ez votre Yahoo! Mail sur http://fr.mail.yahoo.com
