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