Hi,
After discussing the Model I'd now like to discuss the architecture
for request handling. I propose the following:
General Architecture:
* A Request Manager component to handle incoming requests.
* Action classes called by the Request Manager
Details:
* In web.xml we define a ServletContextListener for initializing the
Component Manager (CM) the first time XWiki is started. This puts the
component manager as an attribute in ServletContext. For Plexus this
means registering PlexusServletContextListener.java
* In web.xml we define the main XWiki Servlet. It depends on the CM.
For Plexus this means extending the PlexusServlet class. The main
thing that Servlet does it use the CM to find the Request Manager
component and to call it. The other thing it does is create a
XWikiRequest component and a Session component so that the CM can
inject them in components requiring them.
* The request manager is configured using the Component Manager
configuration mechanism. For Plexus this is through a component.xml
file located in META-INF/plexus. The configuration defines the
different components to use for the different actions. For example:
<components>
<component>
<role>org.xwiki.request.Action</role>
<implementation>org.xwiki.request.ViewAction</implementation>
<configuration>
<action>view</action>
<order>100</order>
</configuration>
</component>
...
</components>
Note: The order is there so that it's possible for non-core
components to contribute Actions. For example this is useful for the
ZipExplorer component which will contribute a
ZipExplorerDownloadAction which should be executed before the default
DownloadAction.
* Other details: We'll have a XWikiRequest and a XWikiResponse
classes and a URL Handler component and a XWikiURL class.
* Here's an example of how an Action will be coded:
public class MyAction implements Action
{
private XWikiRequest request;
private XWikiSession session;
public XWikiResponse execute()
{
...
}
}
The request and session object in this example are being injected
automatically by the CM.
* There are 2 kinds of configuration: static configuration like the
one shown above for registering action names and order for Actions
and user configuration (the one we currently have in xwiki.cfg). For
user configuration we can have a Configuration component or even
better have the config properties automatically injected in the
component so that the component writer would one write:
private List plugins;
(in that case the mapping between "plugins" and the xwiki.plugins
property would be defined in components.xml)
* For logging, we can have define our own LoggerManager component and
tell the CM to use it by registering it in plexus.xml. This will
allow not to depend on any specific CM for logging (otherwise we
would get a org.plexus.logger.Logger object).
To summarize, with this proposal there are only 2 classes that depend
on the CM:
- the servlet context initializer
- the main servlet which is just using the CM to call the Request
Manager.
WDYT?
For OSGi lovers, how would you implement this in OSGi?
Thanks
-Vincent
Hi All,
I implemented the Boolean removeSpace(String token, String
spaceKey)<http://confluence.atlassian.com/display/DOC/Remote+API+Specification>
XML-RPC
and executed that method. Then I got
get an exception saying, "No such handler: confluence1.removePage". It seems
like that removePage XMLRPC does not seem to be implemented on the server.
Any help for this concern is highly appriciated.
Here is the full stack-trace.....................
org.apache.xmlrpc.XmlRpcException: No such handler: confluence1.removePage
at org.apache.xmlrpc.client.XmlRpcStreamTransport.readResponse(
XmlRpcStreamTransport.java:184)
at org.apache.xmlrpc.client.XmlRpcStreamTransport.sendRequest(
XmlRpcStreamTransport.java:145)
at org.apache.xmlrpc.client.XmlRpcHttpTransport.sendRequest(
XmlRpcHttpTransport.java:94)
at org.apache.xmlrpc.client.XmlRpcSunHttpTransport.sendRequest(
XmlRpcSunHttpTransport.java:39)
at org.apache.xmlrpc.client.XmlRpcClientWorker.execute(
XmlRpcClientWorker.java:53)
at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java
:166)
at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java
:157)
at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java
:146)
at org.xwiki.plugins.eclipse.rpc.impl.XWikiRPCHandler.rpcCall(
XWikiRPCHandler.java:79)
at org.xwiki.plugins.eclipse.rpc.impl.XWikiRPCHandler.removePage(
XWikiRPCHandler.java:146)
at org.xwiki.plugins.eclipse.model.impl.XWikiSpace.removeChildPage(
XWikiSpace.java:408)
at org.xwiki.plugins.eclipse.model.wrappers.XWikiSpaceWrapper$3.run(
XWikiSpaceWrapper.java:271)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(
ModalContext.java:113)
Thanks
-Tharindu
Hi,
Just wanted to remind everyone that 1.1M4 is the last release planned
before the 1.1 RCs. Thus if you have some code you wish to see in 1.1
you'll need to get it before end of July (1.1M4 release date).
Thanks
-Vincent
For some reason this mail didn't go through. Sorry if you receive it twice..
- Tharindu
---------- Forwarded message ----------
From: tharindu jayasuriya <djtharindu(a)gmail.com>
Date: Jul 13, 2007 1:37 PM
Subject: XWiki-Eclipse Plug-in Source Code Review.
To: xwiki-dev(a)objectweb.org
Hi Vincent,
We have cleaned up our source code and we're ready for a review.
I have attached the eclipse project at,
http://jira.xwiki.org/jira/browse/XECLIPSE-11
Looking forward to hear from you.
Any comments that would help us improve our code are really appreciated.
We'll start to implement the rest of the features allocated for R!.0M1 from
now on.
Thank you all.
- Tharindu & Asiri
Hi everyone,
Just wanted to let you know I have completely rewritten the XWiki
Syntax Guide.
It's available at:
http://www.xwiki.org/xwiki/bin/view/UserGuide/XWikiSyntax
Please let me know if you think anything is missing or not correct.
That'll help improve it.
Thanks
-Vincent
Hi,
Yesterday, we had a discussion on IRC about removing the Navigation
panel from right menu in the default XE menu. We all (Sergiu, Marta,
Catalin and me) agree to remove it and thus I've gone ahead with it
and it's now removed. With this email I'd like to make sure this is
ok with everyone.
I have added a new Panel called Quick Links which presents links to
the most important pages on the wiki.
Now I'm having some second thoughts. The Quick Links is great to
navigate in the default wiki. The issue I have is the following:
- We have a Create Panel and thus users are going to use it to create
pages. This means their pages are not going to be linked from an
existing page and thus the only way to browse them will be either
though the Search or through the Index page/Treeview page.
I think this is not enough as it's too long to require users to click
on Index and search for their pages to access them. Of course they
should create a navigation (as we're doing on xwiki.org for example)
but they might need some practices before realising this.
I think I'd be ok to add again the Navigation panel but we should
exclude by default all the pages that have a quick links.
WDYT? Any better idea?
<some time pass/>
Ah I have another idea. We could have a Navigation Panel showing
pages that have no link to them (we need that anyway and we need to
add that to the AllDocs page too). In that way any page that is
linked could be accessed through their navigation and pages that are
not linked can still be accessed easily. This should try to encourage
users to create navigations without penalizing them . WDYT?
Thanks
-Vincent
PS: I've just had an idea and I think it would be a killer
feature... :) What about adding a shortcut so that on any page you
can type ctrl+P (or ctrl+D or whatever other shortcut) and it would
present a text field in the middle of the page allowing you to enter
the name of the page you want to navigate to. It would work exactly
as it works on IntelliJ IDEA (Ctrl+N) so you can type some letters
and it'll propose pages. Even better, if the user hits the right
arrow key, it would provide some actions for that page: view, edit,
rename, delete with view being the default action so ctrl+P + Enter
opens the page in view mode and ctrl+P + right arrow + down arrow +
Enter opens the page in edit mode, etc. I'm very excited by the
idea... WDYT?
Hi,
I've noticed that the curriki and xem project duplicate a lot of
content from the XE wiki. Just to give an example:
- XWiki.Results
- Admin.CopyDocument
XE is being improved almost daily and as these are copy XEM and
Curriki are not improved on their side. Also if they make
improvements to these pages XE won't benefit from them either.
I think we should not duplicate pages unless they are modified by XEM
or Curriki. And even when there are modifications we should discuss
how we could refactor the page to have common parts shared. This
could be achieved by splitting the page in 2, or by creating
templates or by creating new APIs for example.
WDYT?
Thanks
-Vincent
For the last week or so, the build hasn't been working for me. I keep
getting errors around the GWT Curriki part of the build. I thought it was
something I did (I ctrl+c-ed out of the mvn install once), so I deleted the
whole trunks-users from my drive, and svn co again. Tried mvn install then,
and a new error pops up at about the same place:
[INFO] Building XWiki Products - Curriki - Database
[INFO] task-segment: [install]
[INFO]
----------------------------------------------------------------------------
[INFO] [remote-resources:process]
[INFO] [xwiki-build-xar:unxar]
[INFO] [xwiki-packager:import]
---------------------------------------------------
constituent[0]: file:/maven2/lib/maven-embedder-2.1-SNAPSHOT-ueber.jar
constituent[1]:
file:/Users/rhadoo/.m2/repository/com/xpn/xwiki/platform/xwiki-build-xar-handlers/1.1-SNAPSHOT/xwiki-
build-xar-handlers-1.1-SNAPSHOT.jar
---------------------------------------------------
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
and it just freezes there, i have to force quit out of the terminal. I've
updated the settings.xml to the latest version, and at this point I'm
completely out of ideas.
Help? Please?
Radu
