Short note to let you know that I committed a notification plugin to the
sandbox under the xwiki-sandbox/plugins/notification folder. The plugin
uses the scheduler plugin (the version used is the one under
xwiki-sandbox/plugins/tasks/ , currently being reviewed and completed by
Vincent), and the mailsender plugin (see my previous email). I'm aware
this will raise issues since we already have the notification plugin
"net.jkraemer.xwiki.plugins.emailnotify", but I needed the following
behaviour:
- retrive the recent changes by querying the database (as opposed to
emailnotify, which uses the in memory notifications caught by
XWikiDocChangeNotificationInterface),
- use mail templates as provided by the mailsender plugin for sending
customized messages,
- scheduling tasks that can be managed through the scheduler plugin.
The plugin currently comes with a XWiki.NotificationRule class
consisting of the following fields:
- watched documents (comma separated)
- watched spaces (comma separated)
- watched documents query
Users wishing to be notified have to attach one or several rule objects
to their account page.
The message used for sending the notifications is an instance of
XWiki.Mail attached to the document XWiki.NotificationMessage (this
should be configurable later on).
Here's the current API of the plugin, comments are welcome:
==========
int registerNotificationRuleForUser(String userFullName, String
watchedSpaces, String watchedDocuments, String watchedDocumentsQuery)
int addWatchedDocumentForUser(String userFullName, String watchedDocument)
int addWatchedSpaceForUser(String userFullName, String watchedSpace)
==========
Pending: draw a sound plan for a unified notification plugin and merge
the API with the emailnotify one, add support for group notification,
let users choose the notification frequency they wish, write tests and
XWiki documents..
Here's the JIRA issue that relates to this plugin:
http://jira.xwiki.org/jira/browse/XPEMAIL-2
Cheers
Stéphane
Hi everyone,
I've refactored some code contributed by Fabrice and Jérome into a
plugin that I committed to the xwiki-sandbox, under the
plugins/mailsender folder (I'm using the sandbox since I find it handy
for progressive refactoring and integration, but Vincent, please let me
know if I should use JIRA attachments instead!).
The plugin currently has the following API:
===========
int sendTextMessage(String from, String to, String subject, String message)
int sendTextMessage(String from, String to, String cc, String bcc,
String subject,String message, List<Attachment> attachments)
int sendHtmlMessage(String from, String to, String cc, String bcc,
String subject, String body, String alternative, List<Attachment>
attachments)
int sendMessageFromTemplate(String from, String to, String cc, String
bcc, String language, String documentFullName, VelocityContext vcontext)
===========
The plugin creates its own "XWiki.Mail" class that has the following fields:
- subject
- language
- text part
- optional html part
The class XWik.Mail is used by the method "sendMessageFromTemplate":
this method evaluates the fields of the XWiki.Mail objects attached to
the template document for building a custom message by using a
VelocityRenderer.
What do you think of the API? Any refactoring or enhancement remarks?
Can we proceed with test and documentation writing, and submission for
integration into 1.1M4?
Related JIRA thread: http://jira.xwiki.org/jira/browse/XWIKI-1473
Cheers
Stéphane
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
