Hi devs,
I'd like to commit a console.log wrapper in xwiki.js that does some
checking before logging, in the spirit of
http://paulirish.com/2009/log-a-lightweight-wrapper-for-consolelog/
Something like :
var XWiki = {
//snip
/**
* console#log wrapper for your developer own convenience
*/
log: function(){
if(typeof console != "undefined"){
console.log( Array.prototype.slice.call(arguments) );
}
},
// snip
}
WDYT ?
Jerome
Hi devs,
I'd like to propose we adopt the module pattern for our XWiki's
javascript modules.
The pattern and its variations is well described here :
http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth
I would follow the author advice and go for loose augmentation and
sub-modules. I don't think we need private states.
Main avantages I see over what we currently are doing are :
* It enforces namespacing and the use of a private scope versus manual
namespacing in the global window scope
* It easily supports global imports (can be useful for example when
using jQuery in addition to prototype)
* It's more elegant and easier to read. For example :
var XWiki = (function(XWiki, $j){
var mySubModule = XWiki.mySubModule = XWiki.mySubModule || {};
// my sub module code here
return XWiki;
})(XWiki, jQuery)
instead of the tedious :
if (typeof XWiki == "undefined") {
XWiki = new Object();
}
if (typeof XWiki.mySubModule == "undefined") {
XWiki.mySubModule = new Object();
}
// my sub module code here
I'm +1 to adopt it.
WDYT ?
Jerome
Hi,
I'd like to propose that we have a short XE 2.6 release. The rationale is that we've been developing lots of new features in the past releases and I think it's time to stabilize what we have. By stabilize I mean:
- fix bugs
- homogenize UI
- clean up stuff (refactoring, etc)
In addition we have 2 features we had planned for 2.5 which have slipped and we could finish them in 2.6 too (Sergiu said he was almost done with the "Email this page" feature and didn't have the time to slip it in the 2.5):
- Email this page: Sergiu
- Recent Activity (refactoring of Recent Changes based on the Activity Stream): Raluca + Caty + JV to apply the patch
The idea would be to have the following dates:
- 2.6RC1: 1st of November 2010 (there's no M1)
- 2.6 final: 18h of November
If we agree, is there anyone who'd like to be the release manager for this release? If nobody volunteers I can do it.
If we agree, I'll send another mail afterwards with some ideas for XE 2.7 and a potential XE 3.0 release. Note that XE 2.6 would be a first step in stabilizing XE for an upcoming 3.0 release :) But even without this vision doing a short stabilization release from time to time is always a good think I believe. It's also not too long so that people don't need to hold new stuff for too long.
Here's my +1
Thanks
-Vincent
Hi,
Requirement
==========
UC1: ability to package transformations in the platform that are not enabled by default (for ex WikiWordTransformation)
UC2: ability in the future to install a new transformation using the extension manager and make it active without restarting xwiki (and without complex operations to activate it)
UC3: ability to have a list of transformations active in a given part of the xwiki code and another list in another part of the code
Proposal
=======
* Introduce a XWikiTransformationManager implementation (hint = "xwiki"), located in xwiki-core/
* Make it use CoreConfiguration and introduce core.viewTransformations configuration properties (in some future we'll have a separate module to perform page rendering - The rendering module is about rendering content not pages). Ex: core.transformations = macro, icon (values are role hints)
* Default property value would be: macro, icon
* DefaultTransformationManager will continue to exist and be part of the rendering module (and runs all transformation it can find). We could decide to remove it at some point if we don't see any value although it could stay as an example implementation in the rendering module (which can be used standalone).
This proposal solves UC1 and UC3. It's less clear how it can solve UC2.
When the extension manager is available we could simply remove this configuration property and simply "deactivate" a given transformation, thus making it inactive. I believe this will be the best practice in the future for activating/deactivating (set of) components. There could be 2 ways: making it not part of the classloader and/or telling the component manager to unregister/register a component.
Thus I believe this proposal is good enough for now.
WDYT?
Thanks
-Vincent
We need to decide where to put events but I think it's wrong to put them in the observation-api package.
Thanks
-Vincent
On Oct 26, 2010, at 6:01 PM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2010-10-26 18:01:34 +0200 (Tue, 26 Oct 2010)
> New Revision: 32192
>
> Added:
> platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AbstractAnnotationEvent.java
> platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AbstractAttachmentEvent.java
> platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AbstractCommentEvent.java
> platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AnnotationAddEvent.java
> platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AnnotationDeleteEvent.java
> platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AnnotationUpdateEvent.java
> platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AttachmentAddEvent.java
> platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AttachmentDeleteEvent.java
> platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/AttachmentUpdateEvent.java
> platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/CommentAddEvent.java
> platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/CommentDeleteEvent.java
> platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event/CommentUpdateEvent.java
> Log:
> XWIKI-5622: New event types: add/update/delete comment/annotation/attachment
> Done.
> Patch from Stefan Abageru applied with a bit of changes.