Hi Sergiu,
Thanks for fixing my javadoc :)
However our automated refactoring has some shortcomings which I've
pointed below. I don't know if we can improve the IDE configuration
but it would be nice to try since it generates some code that is less
readable than the one we generate by hand.
[snip]
On Jun 4, 2008, at 3:27 AM, sdumitriu (SVN) wrote:
[snip]
> -public class DefaultVelocityContextFactory extends AbstractLogEnabled
> - implements VelocityContextFactory, Initializable, Composable
> +public class DefaultVelocityContextFactory extends
> AbstractLogEnabled implements
> + VelocityContextFactory, Initializable, Composable
IMO it's better to keep implements on the same line as the interfaces
it implements and not break it.
> // Instantiate Velocity tools
> if (this.properties != null) {
> - for (Enumeration< ? > props =
> this.properties.propertyNames();
> - props.hasMoreElements();)
> - {
> + for (Enumeration< ? > props =
> this.properties.propertyNames(); props
> + .hasMoreElements();) {
This is way less readable than the version I had. Also remember that
we agreed to use a curly brace on the next line for this case (i.e.
when the conditions wraps).
In addition I don't like how props.hasMoreElements() is cut.
> // Call all components implementing the
> VelocityContextInitializer's role.
> try {
> - for (Object interceptor
> - :
> this.componentManager.lookupList(VelocityContextInitializer.ROLE))
> - {
> + for (Object interceptor : this.componentManager
> + .lookupList(VelocityContextInitializer.ROLE)) {
> ((VelocityContextInitializer)
> interceptor).initialize(context);
> }
same here for the curly brace.
> // Ensure that initialization has been called
> if (this.engine == null) {
> - throw new XWikiVelocityException("This Velocity Engine
> has not yet been initialized. "
> - + " You must call its initialize() method before
> you can use it.");
> + throw new XWikiVelocityException(
> + "This Velocity Engine has not yet been initialized. "
> + + " You must call its initialize() method
> before you can use it.");
I think my version is better and takes only 2 lines.
Hi devs,
Vincent said that he wanted to propose increasing the maximum line width
for a while, but didn't get to do it yet. And since I want the same
thing, I'm writing the proposal.
So, the idea is to increase the line width to 128 (or 120? I like 128
better), since:
- nice code uses descriptive variable/method names, which tend to be
quite long, so many method calls span 2 or more lines
- we're past the stage where developers have small displays that can
only display 80 (or 100) characters at a time
- right now the eclipse settings are at 98 chars, which is quite a silly
number, and changing to only 100 is not worth the effort, so while we're
increasing it, we can use a larger value
Migration plan:
- first, change the xwiki-verification-tools (next Tuesday)
- we don't want to do a massive update, since it will probably create
conflicts with the local changes for each developer, and break existing
patches
- whenever someone changes a file, he should first do a cleanup and
commit the file without code changes, then a second commit with the
actual behavior fix
- never mix cosmetic changes with actual code affecting the behavior, as
it will be hard to review that change
- the copyright notice doesn't need to be updated
So, everybody agrees? Do we use 120 or 128?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
First, I upload a file named "the open grid service architecture.pdf" to
xwiki page.
Then I download it from the page. The default target file name change to
"theopengridservicearchitecture.pdf" which is not friendly file name.
I wonder if we can improve this. Are there big difficulties with attachment
store components to do so?
Thanks.
--
Sincerely,
Wang Ning
Hi all,
I see that Ludovic has started this page
http://platform.xwiki.org/xwiki/bin/view/DevGuide/Best+Practices+XWiki+Appl…
However I think it should be moved to the Draft area. Right now it's
very misleading and readers will think that it represents best
practices that the xwiki dev team is recommending while it's not.
It'll become those when we agree on them and that hasn't been done
AFAIK.
We could move it to the Draft area or we could start a vote on its
content...
WDYT?
Thanks
-Vincent
Hi
If i try to add a property of type "List of Groups", i get the followng
error. Is this a known issue?
XWiki XE 1.4 running on Windows XP.
Thanks,
Shiva
A problem occured while trying to service your request. Please contact the
support if this happens again.
Detailed information:
Error number 0 in 11: Uncaught exception
Wrapped Exception: com.xpn.xwiki.objects.meta.GroupsMetaClass
com.xpn.xwiki.XWikiException: Error number 0 in 11: Uncaught exception
Wrapped Exception: com.xpn.xwiki.objects.meta.GroupsMetaClass
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:230)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:616)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
at
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1565)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1517)
at org.mortbay.http.HttpServer.service(HttpServer.java:954)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Wrapped Exception:
java.lang.ClassCastException: com.xpn.xwiki.objects.meta.GroupsMetaClass
at com.xpn.xwiki.web.PropAddAction.action(PropAddAction.java:56)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:204)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:616)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
at
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1565)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1517)
at org.mortbay.http.HttpServer.service(HttpServer.java:954)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
--
View this message in context: http://www.nabble.com/%22List-of-Groups%22-property-error-tp17574276p175742…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi,
I've been thinking a lot about the Container component I introduced
and while writing unit tests for some of the new rendering classes I
realized there was something not right: it's not normal that the HTML
exporter or the rendering module depend on the Container object, and
especially on the Request.
Thus I'd like to introduce the notion of Execution Context (EC in
short).
The idea is that the xwiki entry points depend on the environment
(Servlet, Portlet, etc) but those entry points create an Execution
Context which is then used by the core components, independently of
the environment. For example the VelocityContext is now put in the EC
and not in the Request object.
The Container objects still exist and can be used where required but
it's expected that they should not be used since that makes the code
dependent on the environment.
This solves issue I had with code that don't have a request.
I have it done on my machine. WDYT? Ok to commit?
Thanks
-Vincent
PS: BTW this makes it very similar to the current XWikiContext (which
is good) with the exception that the Container objects are not located
inside the EC but as separate threadsafe variables.
Hi,
I want to develop a component to handle office documents in xwiki. As we
discussion before, I want to use openoffice api. I set a openoffice develop
environment in my pc running ubuntu 8.04, and learn how to use openoffice
api. Yes, The oo sdk is powerful to address office documents, MS doc, MS
excel...
But there's a problem. AFAIK, openoffice api need a openoffice local runtime
or a remote server running openoffice. The whole openoffice runtime is 356M,
more or less, so we shouldn't contain it in xwiki release. Hense, I think if
we want the office importer run in a computer, the computer should have
installed openoffice or configurate a remote openoffice server.
WDYT?
I need some suggestion.
Thanks.
--
Sincerely,
Wang Ning
Hello devs,
XWS 1.1 M2 was originally planned for May 26th. Unfortunately, I have been
taken by other projects and could not stick to that date. I give you here
a status on what needs to be achieved and new dates proposal.
For me, the consequent tasks left to be done for us to be feature closed
for M2 are the following:
* XWS-7 (Manage groups of administrators & power users). It has been
started by Florin. For me it's 80% complete today. Florin will continue to
work on it.
* XWS-79 (Invitation management). About 50% complete.
* XWS-23 Support public registration
As for dates, here is my proposal :
* 1.1 M2 next Monday (June 9th)
* 1.1 RC1 on June 19th
* 1.1 RC2 or 1.1 final on June 30th.
wdyt ?
Regards,
Jerome.
Good day community.
I want to ask again about XWIKI-2006 issue.
http://jira.xwiki.org/jira/browse/XWIKI-2006
Now I find the way to change initialization of hibernate (instead calling of
setDatabase in the beginning of each session) for non-virtual mode. [attached
as configurated_db_schema_07.patch] Can I ask committers to review one ?
(See previous discussion in this mail list
http://markmail.org/message/6mtyxwff4ccmn3lk)
We have 2 votes for previous patch. We need three [as I remember rules of this
game] -- yet one vote, please ;)
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua