Hi all,
I would like to go ahead with committing
http://jira.xwiki.org/jira/browse/XWIKI-4775 before the 2.2 final release
(because I would like annotations to work as clean as possible on 2.2 final).
In order to do that, we need to agree on a set of separators for the object name
and property name.
There have been the following proposals so far:
A wiki:Space.Page^objectName#property
B wiki:Space.Page^objectName$property
which has received some votes in http://markmail.org/thread/uihq4mmwgaufbcz6 but
I personally would stay away from # and $ separators since they're reserved
characters in velocity scripting language and it might be uncomfortable for
using refs in scripts.
Also, we had:
C wiki:Space.Page^objectName;property
and also:
D wiki:Space.Page:objectName.property
Which one would you prefer? Any other proposals?
Any separator should be easy to implement, and roughly anything could be used as
a separator (so feel free to propose).
Note that there is an alternative to this, to make annotations implementable on
2.2: only add the two entity types (Object and Object Property) along with
making the string serializer and string resolver extensible so one could add its
own separators for the 2 new types.
WDYT?
Thanks,
Anca
Users should be able to invite other people to join their wiki by sending email
made with a template.
They should be able to add a message.
There should be a template message which tells what the invitation is about.
They should be taken to the registration application
(their email address can be filled in as long as <> " ' \ characters are
escaped to prevent XSS)
There should be a mechanism to store the ip addresses/user names of those who
send the email and a link in the email to report spam so the service is not abused.
I would like to make it an application if possible.
Your thoughts?
Caleb
Hi,
Since we introduce document footer informations view statistics are
store several time for the same user view of a page.
See http://jira.xwiki.org/jira/browse/XWIKI-4590
The issue is that theses tabs are loaded asynchronously in ajax and
make a call using view action.
Here are some solutions:
1/ introduce a new action "viewinternal", "service" or anything else
that would be a "view" action without UI and not taken into account by
statistics (that register for "view" action events)
2/ pretty much the same thing that 1/ but based on a URL parameter
3/ use an additional AJAX request similar to a google analytics call
to record statistics
As i said in jira I'm against 3/
2/ seems too big for a URL parameter to me and it makes statistics
depends on URL parameters where 1/ fix the issue without touching
anything in the statistics module
+1 for 1/
+0 for 2/
-1 for 3/
--
Thomas Mortagne
Hi,
Time again for defining the roadmap, this time for XE 2.3. Here's the result of a quick brainstorming between Guillaume and me.
Proposed dates
=============
- XE 2.3M1: 8 March 2010 (1 month after XE 2.2 final)
- XE 2.3M2: 29 March 2010
- XE 2.3RC1: 12 April 2010
- XE 2.3 RC2/Final: 26 April 2010
Proposed Roadmap
================
Must have:
* Work on improving performances in general (could be a cache macro, object handling improvements, etc). Any taker?
* Finish xwiki-localization. Suggestion: Thomas (or Sergiu)?
* Continue Lucene fixing and improvements. Suggestion: Thomas
* Fix some security issues. Any taker? Caleb? Sergiu?
* Color Theme Improvement. Sergiu/Marta
* Edit Mode UI Changes: JV/Sergiu/Marta
* Continue the Model Reference refactoring - Vincent
Should have:
* Annotations - Anca
* Google Gadget Integration - AnaMaria
* Office preview - Asiri
* Livetable macro - Asiri
* Invitation Manager - Caleb
* Add captcha for comments (when guests can comment) - Caleb
* Rights UI improvement to make rights easy to use at last - Suggestion: Caty + JV?
* Selective Export UI - Suggestion: Jerome, JV?
Nice to have:
* Continue work on Model. Suggestion: Vincent
* Velocity bridge - Suggestion: Vincent
WDYT? Could people listed confirm they're interested (or not) to work on the issue mentioned or volunteer?
Any other idea?
Thanks
-Vincent
Hi devs,
Caty suggested a while ago to allow the users to set custom logos in the
color theme. At first I thought this was not OK, since normally the logo
should be the same regardless of the site colors, but now I realize it's
a pretty good idea, because it ensures more flexibility, and, more
importantly, it allows to workaround transparency issues that appear in
some browsers (yes, I'm talking about IE6) by setting logos with the
same background color as the header.
The necessary changes would be:
- in "ColorThemes.ColorThemeClass" add a property called 'logo' whose
values are names of files attaches to the ColorTheme document
- in "global.vm", when searching for the wiki logo, start by looking in
the current ColorTheme, and, if not found, continue as before.
WDYT?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
This is following the proposal done here some time ago:
http://markmail.org/message/nnybto3mluvp2rov
Since we now have a generic Script notion we need to revisit it in
that light. Also we really need to implement it now since more and
more components are put in the velocity context (office importer,
syntax factory, etc) and we need to bring some order.
Here's a new generic proposal:
Short term
========
* The variable "services" is bound in the script context. For ex in
Velocity: $services
* The Services object (ScriptServiceManager) has a ScriptService
get(String serviceName) method which returns the service
* We use the namespace: services.<module name>.<method>. Each module
provides only one service entry point.
* ScriptService interface (empty interface) represents a service to
be bound in the context
* ScriptServiceManager.get() looks for all components of role
ScriptService and returns the component matching the the name as the
component hint.
Ex:
@Component("mymodule")
public class MyModuleScriptService implements ScriptService,
MyModuleBusinessInterface
{
public void myMethod() {}
}
In script:
{{velocity}}
$services.mymodule.myMethod
{{/velocity}}
Medium term
==========
* We handle @authorization(Authorization.PROGRAMMING) annotations to
check for access rights. To do this in ScriptServiceManager.get() we
use a Dynamic Proxy to implement MyModuleBusinessInterface (we
probably need a ScriptService.getInterface() method to make it
unambiguous). The Dynamic Proxy checks the annotation before proxying
to the real object.
WDYT?
Thanks
-Vincent
PS: This is to answer Sergiu's question about where is
getAvailableParserSyntaxes() from my other mail... ;) Answer: It would
be in RenderingScriptService.
Hi devs,
I'd like to further the move from web to space by deprecating all the
methods that still use Web in their name. These are:
- in XWiki: getWebCopyright, getWebPreference*, copyWikiWeb,
getDefaultWeb, useDefaultWeb
- in Document: getCurrentMonthWebStats
- in objects.BaseClass: get/setDefaultWeb (should we keep the element
name in the XML?)
As per our official deprecation strategy, these methods will continue to
be present in the generated classes via the deprecation aspect, for at
least 2 major releases.
WDYT?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
WDYT? Should we limit the WYSIWYG in order to make the editing safer?
I'm +0.
Thanks,
Marius