When I was looking for places where hasProgrammingRights is called, I found calls to
c.x.x.api.Context.get() in the templates. I discovered that there is code in the templates which
implicitly calls $xcontext.get('something') by calling $xcontext.something where there is no
function Context.getSomething(). Since this is so easy and there is no way to know that anything is
wrong since Context.get() returns null if you don't have PR, I am proposing that we do away with the
practice of implicitly referring to functions in $context entirely.
I used the following command to find implicit context references and I have filled in the mappings
which I determined manually
user@debo8:~/wrk/xwiki.clone/xwiki/platform/web/trunk/standard/src/main/webapp/templates$ find ./
-name '*.vm' -exec grep '$xcontext\.[a-zA-Z0-9]*[^a-zA-Z0-9\(]' {} \; | sed -n -e
's/\($xcontext\.[a-zA-Z0-9]*[^a-zA-Z0-9(]\)/\n\1\n/p' | grep '^$xcontext' | sort
$xcontext.action=
$xcontext.action=
$xcontext.action=
$xcontext.action
$xcontext.action
$xcontext.action
$xcontext.action
$xcontext.action
$xcontext.action
$xcontext.action
$xcontext.action,
$xcontext.action,
$xcontext.action,
$xcontext.action,
$xcontext.action,
$xcontext.action,
$xcontext.action,
$xcontext.action,
$xcontext.action,
$xcontext.action,
$xcontext.action,
$xcontext.action,
$xcontext.action.
$xcontext.action)
^-- maps to Context.getAction()
$xcontext.database
$xcontext.database)
$xcontext.database)
$xcontext.database)
$xcontext.database)
$xcontext.database)
$xcontext.database)
^-- maps to Context.getDatabase()
$xcontext.language"
$xcontext.language"
$xcontext.language"
^-- maps to Context.getLanguage()
$xcontext.tocData
^-- this line is broken entirely, it maps to context.get('tocData') but the line is:
#set ($xcontext.tocData = $tocData) which is simply invalid and I can't even figure
out what it would do.
$xcontext.user
$xcontext.user
$xcontext.user
$xcontext.user
$xcontext.user
$xcontext.user
$xcontext.user
$xcontext.user
$xcontext.user
$xcontext.user
$xcontext.user
$xcontext.user,
$xcontext.user,
$xcontext.user,
$xcontext.user,
$xcontext.user,
$xcontext.user,
$xcontext.user,
$xcontext.user,
$xcontext.user,
$xcontext.user,
$xcontext.user,
$xcontext.user,
$xcontext.user,
$xcontext.user.
$xcontext.user.
$xcontext.user.
$xcontext.user"
$xcontext.user"
$xcontext.user)
$xcontext.user)
$xcontext.user)
$xcontext.user)
$xcontext.user)
^-- Maps to $xcontext.getUser()
$xcontext.wiki,
$xcontext.wiki,
$xcontext.wiki,
^-- Maps to $xcontext.get('wiki') I think this is the source of most of the messages and since it
appears to be relatively new code, it convinces me that the $context.blah pattern is simply
unsafe and should be abandoned at least for the xcontext object.
I would like to fix these now and establish a best practice of avoiding the use of these in the
future for $xcontext. I myself avoid this pattern entirely but I do not have a compelling reason to
propose it as a best practice except for $context.
WDYT?
Caleb
Hi Thomas,
FYI the build is failing on the xwiki10 parser syntax tests (links3.test):
junit.framework.ComparisonFailure: null
Expected :[[http:~~/~~/reference>>reference]] [[*not bold*>>reference]]
Actual :[[http:~~/~~/reference>>reference]] [[**not bold**>>reference]]
at org.xwiki.rendering.scaffolding.RenderingTestCase.runTestInternal(RenderingTestCase.java:159)
at org.xwiki.rendering.scaffolding.RenderingTestCase.runTest(RenderingTestCase.java:106)
at org.jmock.core.VerifyingTestCase.runBare(VerifyingTestCase.java:39)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
Seems like non bold is transformed into bold now.
Any ide?
Thanks
-Vincent
Hi Sergiu,
On Feb 26, 2011, at 12:00 AM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2011-02-26 00:00:44 +0100 (Sat, 26 Feb 2011)
> New Revision: 34960
>
> Added:
> platform/core/trunk/xwiki-eventstream/
> platform/core/trunk/xwiki-eventstream/pom.xml
> platform/core/trunk/xwiki-eventstream/src/
> platform/core/trunk/xwiki-eventstream/src/main/
> platform/core/trunk/xwiki-eventstream/src/main/java/
> platform/core/trunk/xwiki-eventstream/src/main/java/org/
> platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/
> platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/
> platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/Event.java
> platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventFactory.java
> platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventGroup.java
> platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/EventStream.java
> platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/
> platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/DefaultEvent.java
> platform/core/trunk/xwiki-eventstream/src/main/java/org/xwiki/eventstream/internal/DefaultEventFactory.java
> platform/core/trunk/xwiki-eventstream/src/main/resources/
> platform/core/trunk/xwiki-eventstream/src/main/resources/META-INF/
> platform/core/trunk/xwiki-eventstream/src/main/resources/META-INF/components.txt
> platform/core/trunk/xwiki-eventstream/src/test/
> platform/core/trunk/xwiki-eventstream/src/test/java/
> platform/core/trunk/xwiki-eventstream/src/test/java/org/
> platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/
> platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/
> platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/EventAndFactoryTest.java
> platform/core/trunk/xwiki-eventstream/src/test/java/org/xwiki/eventstream/EventGroupTest.java
> Modified:
> platform/core/trunk/pom.xml
> Log:
> XWIKI-6047: New EventStream component
That was new to me. Was this discussed (it's possible I missed a mail on the list)?
From the jira it seems this module is meant to be a replacement of the ActivityStream plugin, right? If so what's the strategy to replace it (timing, backward compat, etc)?
There seems to be a notion of Event similar to that of the Observation module.
Maybe Event is not the right term here seems the javadoc says "A recorded event that happened at some point in the wiki". Maybe something like ArchiveEvent, PastEvent, SavedEvent, etc And maybe these events should extend the Observation Event and add new fields (date, etc)? Or maybe it's better to not extend but have a field that is the original Observation Event object? Or maybe not and it's better to have no relationship to the Observation module to be independent? In any case this should probably be discussed/explained.
Maybe the Obervation module should be split in one more submodule called xwiki-observation-store or xwiki-observation-history? It seems to me this could be about historizing the events sent by the Observation managed.
To be honest, I haven't really thought about it enough (would need to load the code in my IDE).
I find that this commit happens quite late in the release cycle (3 days before end of milestone) and would have warranted some earlier discussion.
It's ok, I'm not asking to rollback, just saying that something this important from an architecture point of view should rather be done earlier and discussed.
Thanks
-Vincent
Hi devs,
I'd like to make the XWiki Rendering module a top level project.
Rationale
========
* Make it more visible in order to get more outside visibility/contributions (it'll have its own wiki and can be advertised separately from the rest, see below)
* Ensure that we keep the rendering module independent from xwiki's core model
* Prepare it for a potential (no plans yet) future step which would be to either merge it with some other projects (such as Eclipse's WikiText) or move it to a forge with more visibility should we want that
* Allow releasing it separately from the rest of XWiki with minimal dependencies which means it would be possible to use an oldish version of XE with the latest rendering module, allowing to provide features on an older platform.
* Allows better controlling backward compatibility
* Allows better and cleaner documentation (since it would be on a wiki of its own)
* This module has grown large and has a life of its own now that warrants being a top level project
The only cons I can see is that it means one more module to release separately and thus a little bit more time during the release process but I don't think that's a good enough reason to not do it (compared to the listed advantages above).
Implementation details
==================
* Name: XWiki Rendering (I hesitated giving it a code name such a XWiki Babel but in the end I think using a descriptive name is more inline with other names we have and clearer for the end users - it also allows us to not change existing package names this not breaking backward compatibility)
* SVN: http://svn.xwiki.org/svnroot/xwiki/rendering
* JIRA: http://jira.xwiki.org/jira/browse/XRENDERING
* Wiki: http://rendering.xwiki.org
* Package: org.xwiki.rendering
* Versioning strategy: Start at 3.0-SNAPSHOT and release XWiki Rendering 3.0 final just before we release XE 3.0 final. Then let it have its own life: 3.1, 3.2, etc, independently of platform/XE (although in practice it can be released at the same time as we release platform)
* Directory structure:
http://svn.xwiki.org/svnroot/xwiki/rendering/
|_ tags
|_ branches
|_ trunk
|_ xwiki-rendering-api
|_ xwiki-rendering-macros
|_ (move here all macros that don't depend on XWiki's model - it's ok to depend on XWiki's WikiModel's interface though)
|_ xwiki-rendering-standalone
|_ xwiki-rendering-syntaxes
|_ (all syntaxes submodules moved here)
|_ xwiki-rendering-tests
|_ xwiki-rendering-transformations
|_ (all transformation submodules)
* We leave in platform/xwiki-rendering/* the macros that depend on XWiki's model + the xwiki-rendering-xwiki module.
* In the future, the idea will be to separate xwiki-rendering-api into several parts (rendering-block, rendering-renderers, etc) but that's a second step.
I'm on holidays right now (for a week) but that's something I'd be keep on implementing on and off during this week should we agree on it.
Here's my +1
Thanks
-Vincent
Hi
Having a discussion in our company about wiki's and LDAP support
We had some issues getting LDAP working and a person made a comment that LDAP was not really a key focus and that some of the issues we encountered are in other classes that are used and therefore the problems are not in Xwiki
Is there plans to improve Xwiki LDAP support and and will configuration come into the front end?
Will its configuration be simplified?
Cheers
Peter
Hi,
I'm trying to set rights over a document automatically.
In my wiki i have the "Publication" concept. Each Publication has one or
more authors. Each author is an "Researcher" that is directly related to an
XWikiUser. What I want to do is to set editing rights only for the authors
of that publication. If I add (or remove) an author he should be able (not
able) to edit the document.
What i thought first was to check and add user rights every time the
document was loaded. However this didn't worked because, initially, users
don't have rights to add new rights (lol). That doesn't seemed a good
practice anyway.
What is the best way to do this? Maybe after every change in editing mode,
system may apply the rights? How can I do that?
Btw, I'm using this snippet to add the user rights:
http://extensions.xwiki.org/xwiki/bin/view/Extension/Setting+Rights
Thanks in advance,
Luís Braga
--
View this message in context: http://xwiki.475771.n2.nabble.com/Dynamically-set-rights-over-document-tp60…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi,
This is probably a newbie question but I didn't find any clear answer for
me.
Could someone explain to me how to use "xpage"? For example, when trying to
modify user avatar this code is used:
$doc.getURL('edit', 'xpage=changemyavatar')
I really don't know how this works or where I can find the piece of code
related to this action.
Thanks,
Luís Braga
--
View this message in context: http://xwiki.475771.n2.nabble.com/How-to-use-xpage-tp6056768p6056768.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi Thomas,
I think it could be a good idea to remove (deprecate?) the current BlockFilter interface/implementations and instead use the newly introduced BlockMatcher. WDYT?
Thanks
-Vincent
Hi,
Just a notice that I'll remove the following branches from jira since we (open source xwiki developers) only support 2 branches (trunk + latest stable):
• xwiki-core-1.5-curriki/
• xwiki-core-1.8/
• xwiki-core-1.9/
• xwiki-core-2.1/
• xwiki-core-2.2/
• xwiki-core-2.3/
• xwiki-core-2.4/
Please shout quickly if you have a good reason to keep one of these (also note that they'll always be in the svn history).
Thanks
-Vincent
Hi,
Would be very nice to have a development wiki in order to get things going
on the new XWiki.org proposal:
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2
Maybe Vincent can help with this? :)
Since the redesign is quite big and lots of spaces|panels|styles need to be
changed, morphing the current xwiki.org on the go would be quite difficult.
So, having the development wiki would be much easier to work decentralized
on different parts of it when people have time.
There are lot of areas of the proposal that are not covered and would be
really great to receive proposals and help from other members of the
community.
Also the implementation needs volunteers :) so any help is appreciated. We
will also use the new xwiki.org logo proposed by the community, so having
all this ideas come together and be put into action is very exciting.
Thanks for the support,
Caty
Resources:
- Original Proposal mail: http://markmail.org/message/4erqdhwuzvmtts6p
- Logo Challenge mail: http://markmail.org/thread/bze35tdm4iojnafa
Hi guys,
I've taken the liberty to refine the notion of active committer on http://dev.xwiki.org/xwiki/bin/view/Community/Committership
Basically the idea is that active means having at least 1 commit in a period of 1 year (rolling period).
We had discussed this and it was hinted in the text I rewrote.
Just wanted to make sure we all agree about it.
This notion can be useful on:
* the hall of fame page
* the new download page where companies can list their number of active committers
Thanks
-Vincent
Hi,
We have several places where we need to display a document reference; for ex:
- rename page
- copy page
etc
One solution is to not display the reference and break it into discrete parts, for ex:
Source wiki:
<wiki name>
Source space:
<space name>
Source page:
<page name>
However there are drawbacks:
1) it takes space
2) when we introduced nested spaces it's going to be even more complex to do so...
I was wondering if instead we couldn't go another way which is to have a visual way to display a reference.
Two ideas:
http://tinycoke.com/_6rGYY9JXqpvD6/screen_shot_2011-02-10_at_12.29.24_pm.png
WDYT?
Any more ideas?
Thanks
-Vincent
Hi devs,
While designing the xwiki-action and xwiki-url modules I've realized that we need a general way to represent an xwiki resource and an action on that resource.
This will allow every resource in XWiki to be addressable and offer a generic action mechanism.
What is an xwiki resource?
=====================
Examples:
* an Entity (Document, XObject, XProperty, Attachment, etc)
* A Page (i.e. an Entity rendered with a skin)
* a resource file on the filesystem (image, css, js, icon, etc)
* something on which a REST call will operate (which may or may not be an Entity)
Note that a resource has a type, a reference and optional generic parameters. It's very much similar to a URI in the JDK but represented differently.
What is an action done on a resource?
=====================
Examples:
* For an Entity: view it in XHTML (or in any other syntax)
* For an Entity: view it with the skin applied, in XHTML (or in any other syntax)
* Generate a URL for it
* Create a link to it
* For an Entity: Create it, modify it, delete it
Where would it be used:
=====================
Examples:
* To transform any XWiki URL into a resource object. Any XWiki URL would be transformed internally into a resource. Note: The current XWikiURL class located in the xwiki-url module would disappear
* In the Rendering to represent the reference of a link or an image. Ex: [[label>>reference]]. We currently have a ResourceReference class that would be removed and replaced by the new generic resource class.
* More generically Resource and Resource Actions will be used at entry points of XWiki and internally XWiki will only manipulate Resources.
String representation:
=====================
<resource type>:<action>:<resource reference>
Examples:
=====================
* view a document with skin applied
page:view:wiki:space1.space2.page
<==> ViewAction
* view a document
entity:view:wiki:space1.space2.page
params: context=new
<==> No equiv or {{include document="wiki:space1.space2.page" context="new"/}}
ex: link to attachment
entity:link:wiki:space.page@my.png
<==> [[attach:wiki:space.page@my.png]]
ex: link to a document
entity:link:wiki:space1.space2.page
<==> [[doc:wiki:space1.space2.page]]
ex: view icon
icon:view:accept
<==> image:icon:accept
ex: view image stored in document
entity:view:wiki:space.page@my.png
<==> image:doc:wiki:space.page@my.png
ex: view image located at external URL
url:view:http://server/my.png
<==> image:url:http://server/my.png
API
===
* ResourceReference
* ResourceAction (extends ResourceReference by adding an action field)
* ResourceReferenceSerializer
* ResourceReferenceResolver
* ResourceExecutor(ResourceReference). Hint = <executor type>/<resource type>/<resource action>
Example: View "entity:view:wiki:space.page@my.png" in XHTML
Algorithm:
- lookup ResourceExecutor (hint = "xhtml/entity/view")
- cast ref = ResourceReference.getReference() to EntityReference
- if ref.type == ATTACHMENT
- get attachment URL
=> <img src="..../my.png"/>
Example: Generate URL for "entity:view:wiki:space.page@my.png"
Algorithm:
- lookup ResourceExecutor (hint = "url/entity/view")
- cast ref = ResourceReference.getReference() to EntityReference
=> http://wiki/xwiki/bin/view/space/page/my.png
OR simply:
ResourceExecutor(ResourceAction). Hint = <executor type>
ex: "xhtml", "url", etc.
And it's up to the executor to have sub components for the various actions, resource types....
Conclusion
===========
The API is not completely finished and I'd need to explore it (ie start implementing it) to refine it.
Right now I'd just like to discuss whether you see the idea as interesting and whether I should start spending some time working on it.
I'll post refinements as I progress.
Thanks
-Vincent
Hi devs,
I committed XWIKI-5938 but I think we should discuss the default source
of the dashboard macro, namely where does it pick the gadget objects to
display on the dashboard, e.g. in the case of a dashboard macro call in
an included document.
It is very easy to add a "source" parameter to the dashboard macro,
which would tell the dashboard where should it read the objects from
(and render in the context of the current document), but now the
question is what should {{dashboard /}} without parameters do?
1/ read the objects from the current document, which means, in the case
of an include, it will depend on the context of the include. Note that,
if an include is done in a new context, then all the gadgets on that
dashboard will be also relative to the included document (e.g. if they
use $doc, the $doc will be the included document, not the including doc).
2/ read the objects from the closest MetaData.SOURCE, which means the
document from which the content that contains the {{dashboard /}} call
comes from. E.g. in the case of an include, the included document.
WDYT?
There are a lot of possible situations to discuss, I will just present a
few usecases below, to be taken into account when analyzing:
A. The current Main.Dashboard is included in all the WebHomes by
default, but its gadgets refer to the current document (the _including_
document)
B. Users want to be able to easily customize their WebHomes, without
affecting other people (not change the wiki general dashboard, but only
their space dashboard)
C. There is a dashboard somewhere on the wiki, Main.CoolDashboard, and
users want to be able to include that dashboard as a copy, without
having to re-create the dashboard objects on their including page
D. User dashboards: at one point we will want each user to have their
own dashboard on their profile page, which is rendered by a sheet.
Ideally we should have the same user sheet for all users.
E. Also, the user dashboard should be include-able on the Main.WebHome
of a logged in user (a "Home").
F. Since the include doesn't make too much sense for a dashboard
document (since the dashboard document is only a call to a {{dashboard
/}} macro), users will replace its usage with {{dashboard /}} macro
calls, with a source parameter to pick gadget objects from another
document ('reuse' a dashboard definition).
If you can think of more cases that could involve include issues, please
fill them in.
Thanks,
Anca