Hi,
I have just made my first code commits. However, I had no code rules to go
by so I've tried to copy existing code. The problem is that the existing
code is not consistent itself!...
I would like us to define what are our coding rules. Questions such as:
- max number of characters on a ligne. 100? 120? More?
- indentation rules
- spacing rules, like "(SomeClass)myobject" or "(SomeClass) myobject"
- etc
We could of course have a wiki topic for describing the rules but I don't
think that's the right approach. I would prefer doing what I've done on my
other projects: have a checkstyle.xml file describing those rules and apply
them in the build.
ATM as we have lots of inconstancies, the build would not fail on checkstyle
error. However we should work towards eliminating checkstyle violations and
move the checks, one by one, from warning to error (error fails the build).
WDYT?
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 be sure I'm doing the right thing, hence this email. Are we
following any rule for deciding whether or not a proposal should be applied
or not?
For example, I've just sent an email about modifying the XWiki constructor
interface. Ludovic has answered but not other committers. Should I go ahead
or do I need to wait for others to chime in?
Are we following the ASF rules defined here:
http://apache.org/foundation/how-it-works.html#management? However this is
not enough.
Here's an additional rule followed on most Apache projects:
"
The development process is intentionally lightweight; like other
Apache projects, the committers decide which changes may be committed
to the repository. Three +1 ('yes' votes) with no -1 ('no' votes or
vetoes) are needed to approve a code change. For efficiency, some code
changes from some contributors (e.g. feature additions, bug fixes) may
be approved in advance, in which case they may be committed first and
changed as needed, with conflicts resolved by majority vote of the
committers.
"
Is this too heavyweight? Is it ok? What do you want?
Should I wait before committing the xwiki constructor change I have
proposed?
The reason I'm asking this is because I am a new member of the community and
I'm sure other newcomers may also have some doubt when they want to change
existing code.
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 add a default constructor to XWikiConfig so that config can be
added in java code:
XWikiConfig config = new XWikiConfig();
config.put("xwiki.store.class", "com.xpn.xwiki.store.XWikiHibernateStore");
config.put("xwiki.store.hibernate.path",
getClass().getResource(StoreHibernateTest.HIB_LOCATION).getFile());
WDYT?
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 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
