Hello xwiki developpers
Imagine you had to powerful applications.
First xwiki, then discourse engine for deliberative decision making.
Lets call the latter 'dito'.
Imagine how nice it would be,
1: if these two applications could use the same authentication, and if
2: signing into one aplication would sign you into the second, too.
3: registering a new account in dito would add a new user to xwiki with
the appropriate rights (edit) without admin interaction (explicitly
setting rights) needed
@1: Done!
Fortunately, as far as *authentication* is concerned, xwiki makes a
geeks life easier, as it provides a XWikiAuthService interface.
Which I implemented for my needs and which works fine.
@2: Hm, solve 3 first
@3: Stuck!
Unfortunately, as far as *authorisation* is concerned, I did not yet get
the point.
My approach is to make an xml-rpc, that logs into the wiki (with a user
that i added manually and that has admin rights) and calls the
XWiki.createUser() method.
In order to achieve that, i extended the ConfluenceRpcHandler and added
a method createUserFromExternal
Suddenly, I get an error in Xwiki, approx. line 2570(i.e. methods
system.out.println("xwiki create user :
!context.getUtil().match"+xwikiname);returns -4 :)
try {
if (!context
.getUtil()
.match(
this.Param(
"xwiki.validusername", "/^[a-zA-Z0-9_]+$/"),
xwikiname))
{
return -4;
}
}
As i am calling from external, the context object (and the request, it
is carrying) are not as complete as they are, when i register via the
xwiki web page.
My questions are:
- is it a good idea to do xwiki user registration automatically and from
external *that* way? do you know alternatives?
- is there an implementation of the mehtod:
/**
* {@inheritDoc}
* @see ConfluenceRpcInterface#addUser(String, java.util.Map, String)
*/
public void addUser(String token, Map user, String password) throws
XWikiException {
throw new XWikiException(XWikiException.MODULE_XWIKI_XMLRPC,
XWikiException.ERROR_XWIKI_NOT_IMPLEMENTED, "Not implemented");
}
?
- If you integrate xwiki into other environments or vice versa, what is
the best practice to wire the two different registration and login
processes of both, xwiki and some_app ?
Of course, i searched the archives, but no solution for this so far...
Any hints?
Best regards
Thomas K.
--
ontopica
Thomas Krämer
Krämer&Okpue GbR
Kurfürstenstr. 66
53115 Bonn
Fon 0228 - 180 99 737
Fax 0228 - 242 78 60
Email tk(a)ontopica.de
Hi,
I'd like to propose setting up the JIRA Calendar plugin (http://
confluence.atlassian.com/display/JIRAEXT/JIRA+Calendar+Plugin) so
that we can show the release dates of the different versions as
planned. Currently these dates are only visible in the JIRA admin
section and on http://www.xwiki.org/xwiki/bin/view/Main/Roadmap but
it's a pain to maintain that page.
In this manner we can make it visible and ensure we are all aligned
on those dates.
WDYT?
Thanks
-Vincent
PS: I don't have admin access to JIRA so we might have to wait till
Raffaello is back from holidays at the end of next week.
The XWiki development team team is pleased to announce the
availability of the 1.0 RC 1 release.
Go grab it on http://www.xwiki.org/xwiki/bin/view/Main/Download
This release is planned to the last before the final 1.0 release
(unless we find some important bugs in which case there'll be a RC2
release). The 1.0 release is still planned for end of April.
New in this release:
* Lots of bugs fixed
* Updated French translation
* New translation: Simplified Chinese and Russian
* Search is now case insensitive in the default Wiki for all
DBMS (it was working fine for MySQL previously)
* Ability to navigate backlinks documents on the Rename page
* Lucene plugin is now working
* Fixed #skype macro which is now using Skype's Presence Service
(was previously using jyve.com which is not working anymore)
* New #pagedViewLinks macro that displays links to the first,
previous, next and last pages in a paged view
* Lots of Macros have been documented on the Macro page in the
Code Zone
* Non ASCII chars can now be used in document names and
attachments (This requires correct encoding configuration)
* Superadmin is set to use the Advanced editing mode by default
(was in Simple mode)
* {style} macro now supports border and icon attributes
* Added support for Oracle
See the full release notes on http://www.xwiki.org/xwiki/bin/view/
Main/ReleaseNotesXWiki10RC1
Enjoy
-The XWiki development team
Hi,
I've installed a XWiki in a Tomcat with a external database (MySQL). I want
to use xwiki-beta3 release, but i've only found a beta-1 Script for MySQL
(xwiki-mysql-1.0-beta-1.sql). Has someone know where i could found a MySQL
script for xwiki-beta3 release??
Thanks,
meni.-
--
View this message in context: http://www.nabble.com/MySQL-Script-for-xwiki-beta3-release-tf3601210.html#a…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi everyone,
I've staged the RC1 release on http://www.xwiki.org/10rc1/
It would be nice if some of you could quickly try it out and let us
know if it's working as expected. Once we get a few confirmations
we'll officially release it.
Thanks a lot
-Vincent (on behalf of the XWiki dev team)
Hi all,
For a particular project, I have a plugin that reads data from an
external database using some JDBC queries.
For each row of my JDBC ResultSet, the plugin creates an XWiki document,
the associated objects, and fill these objects.
All is running fine except that I have around 50.000 objects to import :-D.
Then I get a Java Heap Space exception.
I re-re-re-re-re-read my source code, I don't keep any reference to the
documents created.
Every 200 document creation, I do the following calls :
context.getWiki().flushCache();
context.getWiki().getStore().cleanUp(context);
System.gc();
Anyway, the amount of memory used doesn't go down after flushing the caches.
And I still get my Heap Space exception.
Does anybody has an idea for me ?
Who thinks that I could be a XWiki memory leak ?
Thanks,
--
Arnaud Thimel
Société Code Lutin - http://www.codelutin.com
Hi committers,
We've already discussed this before but I've seen that we're not all
following this (even though we agreed to do it on this list).
I have now put it in http://www.xwiki.org/xwiki/bin/view/Community/
DevelopmentPractices#HApplyingacontributor27spatch
The idea is to give proper recognition to contributors by:
1) Naming them using the specified commit log template
2) Adding them on the contributor's page on xwiki.org
It would be nice if all committers could follow this and help each
other follow it (I know I'm also forgetting it from time to time).
Thanks
-Vincent
Hi,
I'm proposing a new category: Anti Patterns!
Here's one:
Instead of writing:
#set($obj = $doc.getObject("XWiki.XWikiUsers"))
#if ($obj.avatar == "...")
...
Write:
#set($obj = $doc.getObject("XWiki.XWikiUsers"))
#if ($obj.getProperty("avatar") && $obj.getProperty("avatar").getValue
() == "...")
...
Reason:
$obj.avatar actually is equivalent to: $doc.display("avatar", $obj)
And the display() method renders differently when in view mode, in
inline mode, etc. For example in inline mode it generates an HTML
form INPUT element...
WDYT?
Thanks
-Vincent
Hi,
Here's another one best practice I'd like to propose:
Instead of writing:
#set($obj = ...)
#if ($obj.getSomething() == "...")
Write:
#if($obj && $obj.getSomething() == "...")
This prevents the following error in logs:
11:54:04,777 ERROR P1-19 ... SimpleLog4JLogSystem:logVelocityMessage:
154 - Left side ($obj.getSomething()) of '==' operation has null
value. If a reference, it may not be in the context. Operation not
possible. [line 1, column 21]
WDYT?
Thanks
-Vincent
Hi,
I'd like to propose the following best practice: to test for Object
existence in class sheets. For example:
#set($obj = $doc.getObject("XWiki.XWikiUsers"))
#if($obj)
...
#else
This stylesheet must be applied on a document containing a
XWiki.XWikiUsers object.
#end
If you're all ok I'll add it to the dev guide on http://www.xwiki.org/
xwiki/bin/view/DevGuide/BestPractices (I'll remove what's in there
and send each best practice separately to this list for agreement as
this is old stuff).
Thanks
-Vincent
Hi All,
I'm Tharindu Jayasuriya from Sri-Lanka. My application on IDE Editor
Integration project was accepted for SOC this year.I followed up the
things mentioned by the The XWiki SOC mentor team, for the students
who got accepted for SOC . I look forward to collaboratively work with
all.
Best Regards,
Tharindu Jayasuriya.
On 4/16/07, Vincent Massol <vincent(a)massol.net> wrote:
>
>
> On Apr 16, 2007, at 10:32 AM, Ludovic Dubost wrote:
[snip]
>
> The reason I did not propose XClass is because even though we've
> agree to use this name when we talk about it, this is not a name
> currently used in the code and introducing a new concept in only one
> place in the code is, I think, a bad idea.
If we are going to use these names, then the best places to start is in the
JavaDoc and the documentation on xwiki.org. APIs should not be modified for
the moment. Maybe when we define the components for the 2.0 architecture.
Sergiu
--
http://purl.org/net/sergiu
Hello,
My name is Evelina Slatineanu and I participate at GSoC for XWiki - Ajax Interface Improvements, mentored by Mr. Sergiu Dumitriu.
1. The address I use frequently is: Evelyne24(a)gmail.com
2. Short introduction:
I am a 2nd year student at Computer Science Faculty in Iasi, Romania.
I chose to participate to GSoC this summer because I am interested in Open Source community and I consider it to be a very good opportunity for people to collaborate and let other people benefit from their work and their experience.
I choose XWiki because I think it has great potential and I want to take part in the development of a software that has such a promising future. More over, I was told that XWiki community is very reliable and supportive and as I am a beginner in this field, I would very much appreciate that.
3. Project milestones:
- I want to completely understand and familiarize with XWiki architectural pattern (MVC) and coding rules
- I want to be able to learn how XWiki classes work, its layout and structure
- I already picked 3 issues on Jira and by the end of May I want to solve them all as good as possible, to prove that I am ready to move on to the next step of coding
- I want to start writing the code, under the guidance of my mentor
- I want to finish this project as good as possible by the end of August (including a lot of testing to make sure everything is in order)
And, of course, I would very much like to become a "permanent" member of XWiki community and a happy contributor to Open Source software and to participate to the next editions of GSoC.
That is all, I guess...
Happy coding for all! :)
Hello,
Following the recent discussion on using SVN as a backend for Xwiki, I'd
like to discuss something symetrical, i.e. to use SVN and Eclipse as a
front-end. The idea is to write Xwiki pages containing Groovy code in
Eclipse (or Emacs), store it in SVN and deploy it automatically on an Xwiki.
My idea is to use Ant as a deployment tool, with the Ant POST task for
instance:
http://antelope.tigris.org/nonav/docs/manual/bk03ch17.html
This way, the project can be easily integrated into Eclipse. I'm
wondering how the Groovy Eclipse plug-in can be used:
http://groovy.codehaus.org/Eclipse+Plugin
My guess is that the editing part can be usefull, but that running
Groovy inside Eclipse wont do it for now.
Best,
François
Hi Stephane,
This sounds cool. Could you please send a short email explaining what
this is for, what you're planning to do with this, who's going to
work on this, architecture decisions taken, etc?
Also I've see you've imported sources from org.semanticdesktop.*. I
have some questions regarding this:
1) Why do we need this library?
2) Why don't we depend on a JAR version of it rather than on source?
3) What is the license of it?
4) It looks like JDK 1.5 code... but I guess we're going to
standardize on JDK 1.5 now...
A general comment: while this sounds cool, I think you're dumping a
LOT of files and this makes it almost impossible for anyone else to
participate in this refactoring which isn't good for you as it may
mean you'll have to do the whole coding yourself... ;-) I would have
rather had a discussion first explaining what you wanted to do, what
architecture, how does it fit with the 2.0 architecture, etc. Of
course we can and should do that now but still it's hard to review
that huge commit... at least for anyone not having 3-4 full days
ahead of him... :)
All that said, I'm happy we're getting traction on this :)
Thanks
-Vincent
On Apr 15, 2007, at 10:10 PM, St??phane Lauri??re wrote:
> Author: slauriere
> Date: 2007-04-15 22:10:22 +0200 (Sun, 15 Apr 2007)
> New Revision: 2817
>
> Added:
> xwiki-sandbox/com.xpn.xwiki.wikimodel/
> Log:
> XWIKI-1088: Put wikimodel integration prototype available in the
> xwiki-sandbox
>
>
>
> --
> You receive this message as a subscriber of the xwiki-
> commits(a)objectweb.org mailing list.
> To unsubscribe: mailto:xwiki-commits-unsubscribe@objectweb.org
> For general help: mailto:sympa@objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/
> wws
On Apr 15, 2007, at 2:43 AM, Ludovic Dubost wrote:
> Author: ludovic
> Date: 2007-04-15 02:43:21 +0200 (Sun, 15 Apr 2007)
> New Revision: 2809
>
> Modified:
> xwiki/trunk/core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java
> xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/lucene/
> IndexUpdater.java
> Log:
> XWIKI-966 Fix lucene indexing not correctly deleting and reindexing
> in some cases
> XWIKI-21 Fix rename regression using copydocument which does not
> clean up the attachment list before copying the source attachment list
[snip]
You can't do that as XWIKI-21 is already closed and released as part
of XWiki 1.0 Beta 6.... So this fix won't show up in the release
notes of RC1...
I've created XWIKI-1085 for this but I need your help to describe the
problem from a user point view. I need the answer to: "what happens
when a user renames a document with attachments?".
Thanks
-Vincent
Hi,
Sometimes it's hard to make the distinction (in a conversation) between
XWiki classes/objects/properties and the java terms. Thus, we should call
them XClass, XObject and XProperty. Of course, class/object/property are
still valid, when everybody knows what we're talking about.
Sergiu
--
http://purl.org/net/sergiu
Hi,
I'd like to propose a new subproject on JIRA, called XWiki Flavors.
What is a Flavor? A flavor is a custom XWiki-based site, with one specific
goal in mind. The XPN team creates such flavors when working for client
project. As it is said on http://jira.xwiki.org/jira/browse/XWIKI-356 , by
default XWiki comes with a collection of pages, panels, classes, a
pre-selected skin, etc, which gives it a "flavor". Right now, it looks like
a nice site where you can put some pages (content), articles, documentation,
etc. It is a weak flavor, since it's a mixture of different ingredients put
all together.
An example of a "strong" flavor is a blog-wiki. When you install XWiki and
choose the blog-flavor, you will get the full functionality of any blog app
(for example blogger or wordpress) without having to customize anything,
without having to import one or several xar-s, editing the main page or
anything. Of course, after the user gets used to the blog (and XWiki) he can
customize the skin (using a friendly skin browser and a skin wizard), the
displayed panels (using the panel wizard), and many other things (actually
anything a user can change in XWiki, which is everything).
Other strong flavors could be content management, OpenSource project website
(about, developer guide, user guide, download, ...), or just the
documentation for such a project (many projects use wikis now), Social
Networking site (link and photo sharing, tagging, reviews), project
management, and so many more.
Why are flavors necessary? Because XWiki is too powerful. Put it in the
hands of some who-knows-what "haskel model checker" developer who only knows
about axioms, theorems, proving, model checking and functional programming,
and he will run away very fast to a simple wiki engine, or worse, a CMS. But
hide all the power behind a simple interface, with only what he needs in
order to publish some info about his project, and we have a happy XWiki
user.
Why do we need a new subproject? Because:
- putting all the flavor-specific issues in the "Default database" component
is not efficient
- neither is putting them in a new "Flavors" component
- we don't know how many flavors we will create, so making an XWiki
component for each flavor will bloat the component list
- flavors don't follow the XWiki platform release plan; they get shipped
when they are ready
What is the relation between flavors, default database, and
xwiki-applications?
The default database should be almost empty. It should contain mainly the
setup wizard, which can be used to install a flavor.
A flavor contains some applications bundled together. It is not enough to
put only the individual applications in JIRA, because a flavor is more than
that: a custom skin, configuration for the applications, rights setup, other
documents outside of applications, java plugins, XWiki configuration, and
even more.
What should the subproject contain? First, a "global" component, regarding
flavor development, deployment, integration, installation. Then a component
for each flavor we are currently supporting (or starting to work on).
WDYT?
Sergiu
--
http://purl.org/net/sergiu
Hi,
I think it's high time we get a powered by XWiki logo! :)
Laurent Lunati has created 5 variations attached.
Does anyone have any feedback in term of size, color, look, etc?
The idea is that once we get an agreement on the logo we publish it
on xwiki.org and we ask that people using XWiki display this badge on
their web site if they want to be good open source citizens :) (and
thus we'll also use it on xwiki.org itself).
My preference goes to the 80X15.png logo. What about you?
Thanks
-Vincent
Does anybody have any hint on where I might get some Google Docs API
Developer documentation? (tried google already, nothing relevant came up for
several well thought search strings).
Thanks in advance,
Radu Danciu
Hi XWiki committers,
We need to better handle patch contributions. It's really important
that when someone submits a patch we review it quickly and apply it
or ask for modifications. Providing a fast answer means that we'll
get more contributions and XWiki will soar even higher...
Right now we're doing a poor job at handling patches. The first step
in improving is in detecting issues with patches.
I have thus started tagging issues with patches with "patch" in the
keyword field. I propose that we all do this whenever we see an issue
with a patch attached.
I have also modified the default JIRA dashboard on http://
jira.xwiki.org/ so that the list of issues with patches attached are
listed in the right column.
If you agree I propose we make it our priority to review and fix
issues with patches attached.
WDYT?
Thanks
-Vincent