I use the addObject method to create new annotation, my plugin.
When a user submit the form to add an annotation, i call
addObject('annotationClass') .
But, to invoke this method, user might have the edit right.
And i'd like to have possibility to annotate with only comment right.
How to create a method addAnnotation that need only comment right to be
called?
Thank for your time.
Antoine
All,
Ludovic asked me to write this up on the wiki, but the page says that
I should post it on the mailing list first (hopefully to get some
initial feedback).
There are a few difficulties that we run into when developing in xwiki:
- Collision issues when having multiple editors dealing with a single
page (it seems that most people tend to copy the code from the
browser, edit it locally, then paste it back when dealing with larger
code changes -- sometimes forgetting to copy again in case someone
else changes something, sometimes xwiki forgets that the page is being
edited by someone else).
- Branching/deployment issues when moving from our development server
to a staging server and finally to a production server (all files?
how can one tell what files changed between them? etc.).
- Branching/deployment issues when working with "fixes" to a current
issue to be deployed to a "current version" production server vs. new
implementations to go to a "next version" of the production server
(various branching issues here).
- Merging changes between different xwiki deployments (such as
translation lookup page changes in production where the development
page has been updated with new translation strings)
In discussing some of this with Ludovic, he was intrigued by the idea
of using a file system directory to hold non-data wiki pages
("application" pages) and asked me to write up a proposal describing
the idea.
The general idea would be to have a method (plugin?) where application
wiki pages could be maintained outside of the wiki database.
There would be a directory where wiki pages would be stored.
- This directory could be maintained with any version control tool
(eases issues with different branches where export/import has a number
of issues)
- xwiki would pull pages from this directory instead of the database
when a page exists there.
I think this could be done as a plugin that wraps the default plugin.
A number of issues would have to be solved, some very similar to
issues with other proposals such as the WebDAV Service:
- File naming conventions
- Current proposal (somewhat derived from WebDAV Service proposal) is:
Space/
Page/
wiki.txt (maybe something more like Space.Page.vm to make
editing multiple pages easier when you don't see the directory name
like in most editors)
attributes.xml (or could be split for some things title.txt,
parent.txt, possibly in a subdirectory attributes/)
attachments/
attach1.png
objects/
object1.xml
class/
class.xml
lang_xx/ (for translated versions)
wiki.txt
attributes.xml
attachments/ (?)
attach1.png
objects/ (?)
object1.xml
- Priority of stores
- If there is a page on the file system and in the database, which
takes priority?
- One option here is to just have a configurable rule.
- Another option is to have a thread doing one-way or bi-directional
copying of the files if they are added/deleted/updated.
- Queries
- Right now the use of $xwiki.searchDocuments() (at least in our
usage) assumes that it is talking to a hibernate query backend, which
may be difficult to make work with a file store.
- Possibly the option of having pages copied to the DB when they
change on the filesystem resolves this as well.
Feedback is more than welcome,
David
--
Hi everybody,
On the mailing lists, we noticed several people trying to use XWiki in
academic environments, requesting features such as support for
mathematical equations or support for LaTeX.
We took some time to design a product that would be great for writing
scientific papers, identifying some important features, and some "would
be nice to have" features. You can see the current design proposal at
http://dev.xwiki.org/xwiki/bin/view/Design/SPAWN (feel free to send
comment on the mailing list).
Given the fact that this is not a product which can easily be sold, and
that there are other more critical projects to work on for the moment,
the core XWiki developers cannot dedicate much time on it. This is why
we need help from the community. Whoever would like to use this product,
and has the power and knowledge to work on in, please help us.
If you are in an university as a student, you can propose one of the
sub-applications as a project for one of your classes. If you are a
teacher, you can propose some sub-applications as student projects. We
can help with coordination, more detailed description/requirements,
question answering, code review, etc.
Some of the features require mostly programming skills, while others
require more advanced research skills, like the positioned comments in a
dynamic text (adapting some sequence alignment algorithms from
bioinformatics seems the best idea for the moment, but also some fuzzy
systems theory could be applied), or an automatic merge algorithm based
on Operational Transformations, so some publications can come out of
this, too.
If we gather a few volunteers, I'll make the necessary Jira setup and
mark the product as active.
Regards,
The XWiki dev team
Hi,
I'd like to do a XE 1.2.2 release today or tomorrow. This is a bug fix
release fixing 2 important areas:
1) automatic migration from old database (1.0 and pre 1.0)
2) Rights Mgmt issues with IE6
Here's the full release notes for the moment:
Release Notes - XWiki Core - Version 1.2.2
** Bug
* [XWIKI-2064] - DBListClass and DBTreeListClass are building
invalid SQL statements
* [XWIKI-2065] - XWikiHibernateStore.deleteWiki don't works
* [XWIKI-2066] - Migrator fails to upgrade sub wiki databases
* [XWIKI-2074] - Database Migration fails when migrating from 1.0
or older directly to 1.2 without going through a 1.1 upgrade
* [XWIKI-2076] - "Content is not allowed in prolog" error while
migrating a database to 1.2
* [XWIKI-2078] - Missing translation entry for the title of the
Group Admin page
* [XWIKI-2079] - Fails to save document after migrating from a
1.0 or before database to 1.2
* [XWIKI-2080] - Server hangs while rendering certain pages
** New Feature
* [XWIKI-2088] - Add a method to retrieve the e-mail address of a
user
** Task
* [XWIKI-2084] - Use the new Skins modules and package Dodo,
Finch and Albatross in XE 1.2 branch
I say "for the moment" since we have the following bugs fixed on trunk
and not committed in the branch.
Could the person in parenthesis please tell me whether their fix
should also be on the 1.2 branch please:
http://jira.xwiki.org/jira/browse/XWIKI-1621 (Artem)
http://jira.xwiki.org/jira/browse/XWIKI-299 (Artem)
http://jira.xwiki.org/jira/browse/XWIKI-1949 (Artem)
http://jira.xwiki.org/jira/browse/XWIKI-2068 (Thomas)
http://jira.xwiki.org/jira/browse/XWIKI-2097 (Sergiu)
http://jira.xwiki.org/jira/browse/XWIKI-2056 (Sergiu)
http://jira.xwiki.org/jira/browse/XWIKI-2052 (Jerome)
http://jira.xwiki.org/jira/browse/XWIKI-2040 (Sergiu)
Thanks
-Vincent
Hi all,
I have tried to compile xwiki-platform with maven-2.1-SNAPSHOT. But faced difficulty compling xwiki-core and xwiki-patchservice.
The error messages is as follow:
[INFO] For artifact {com.xpn.xwiki.platform.tools:xwiki-verification-resources:null:jar}: The version cannot be empty.
Thanks in adv,
Colin
______________________________________________________________________
Search, browse and book your hotels and flights through Yahoo! Travel.
http://sg.travel.yahoo.com
The XWiki development team is pleased to announce the release of
XWiki Watch 1.0 Milestone 3.
You can go grab it here :
http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiWatch
This release include both bug fixes and new features, among which you can
find :
- Date range filter: you can select the date range (start date and end
date) for the articles displayed in the list.
- Email press review : the same press review you used to view as html or
as pdf can now be sent over through email
- other UI improvements and bugfixes.
You can read the full release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesWatch10M3
And the installation guide :
http://code.xwiki.org/xwiki/bin/view/Applications/WatchApplication
Have fun!
The XWiki Watch development team
Hi,
Very recently I update the source and built again and after I tried to
access xwiki it failed with following stack trace:
2008-02-10 23:33:40,218 [] [http-9080-Processor25] WARN
action.RequestProcessor - Unhandled Exception thrown: class
java.lang.NullPointerException
2008-02-10 23:33:40,234 [] [http-9080-Processor25] ERROR [/xwiki].[action]
- Servlet.service() for servlet action threw exception
java.lang.NullPointerException
at java.util.Hashtable.put(Unknown Source)
at com.xpn.xwiki.web.Utils.prepareContext(Utils.java:266)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:111)
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.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:117)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve.java:346)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)
In the code of Utils.java I see the following code added:
// This is a temporary bridge so that non XWiki component classes
can lookup XWiki
// components. A ComponentManager instance has been set up in the
Servlet Context and
// we now populate the XWiki Context with it so that code can then
use it to look up
// components.
// This is of course not necessary for XWiki components since they
just need to implement
// the Composable interface to get access to the Component Manager
or better they simply
// need to define the Components they require as field members and
configure the Plexus
// deployment descriptors (components.xml) so that they are
automatically injected.
ComponentManager componentManager =
(ComponentManager)
engine_context.getAttribute(ComponentManager.class.getName());
context.put(ComponentManager.class.getName(), componentManager);
I debugged and checked that componentManager is being fetched as null. Can
you please help me what I may be doing wrong.
I have updated the jars xwiki-core-plexus-1.3-SNAPSHOT.jar and
xwiki-core-component-1.3-SNAPSHOT.jar so I don't think it may be related to
some old source.
Thanks
Sachin
-----
http://www.assembla.com/wiki/show/sachin_mittal about me:
--
View this message in context: http://www.nabble.com/latest-deployment-from-source-failing-tp15399312p1539…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi All,
I have a small confusion.
Currently I see that both tiny_mce and wiki_editor javascript files are
included in the vm pages to render wysiwug text area (ie the wiki editor).
Are both required?
If yes then what are the roles these two play in wiki editor rendering?
In the code say textarea_wysiwyg.vm I only see wiki editor getting
initialized.
So if someone can can give me some insight in these two javascript modules
we import then it would be very helpful. If one of the module is redundant
than can we exclude it from our deployment? Also in this case what about
excluding from the svn itself.
Thanks
Sachin
-----
http://www.assembla.com/wiki/show/sachin_mittal about me:
--
View this message in context: http://www.nabble.com/tiny_mce-and-wiki_editor-%28what-are-both-used-for%29…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
The idea is to keep Albatross the default skin in 1.3M2 but package
the Toucan skin so that users can easily use it and test it more.
Then in 1.3RC1 we would make Toucan the default skin. We should keep
the Albatross skin too I think and only remove it in 1.4 (i.e. users
would download it from code.xwiki.org to get it).
WDYT?
Thanks
-Vincent
Right now this interface isn't used anywhere. It's a burden. It has
lots of cruft methods, etc.
I hereby propose to send it to the guillotine!
In the future it'll be reborn as component interface when we split
that mammoth XWiki java class into components.
Here's my +1
Thanks
-Vincent