xwiki-devs October 2010

xwiki-devs@xwiki.org

36 participants
89 discussions

[xwiki-devs] [Proposal]JavaScript console.log wrapper for our convenience

by Jerome Velociter

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

13 years, 10 months

[xwiki-devs] [Proposal] Adopt the JavaScript module pattern

by Jerome Velociter

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

13 years, 10 months

[xwiki-devs] Dennis Coonich wants to stay in touch on LinkedIn

by Dennis Coonich via LinkedIn

LinkedIn ------------Dennis Coonich requested to add you as a connection on LinkedIn: ------------------------------------------ Guillaume, I'd like to add you to my professional network on LinkedIn. - Dennis Coonich Accept invitation from Dennis Coonich http://www.linkedin.com/e/3vasf0-gftu99lf-2a/9s_c-0fN05p6qjQq9meQgfVB/blk/I… View invitation from Dennis Coonich http://www.linkedin.com/e/3vasf0-gftu99lf-2a/9s_c-0fN05p6qjQq9meQgfVB/blk/I… ------------------------------------------ DID YOU KNOW you can showcase your professional knowledge on LinkedIn to receive job/consulting offers and enhance your professional reputation? Posting replies to questions on LinkedIn Answers puts you in front of the world's professional community. http://www.linkedin.com/e/3vasf0-gftu99lf-2a/abq/inv-24/ -- (c) 2010, LinkedIn Corporation

13 years, 10 months

[xwiki-devs] [VOTE] XE 2.6 Roadmap

by Vincent Massol

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

13 years, 10 months

[xwiki-devs] [Proposal] Transformation activation

by Vincent Massol

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

13 years, 10 months

[xwiki-devs] [Proposal] Bundle the WikiWord transformation by default but not enabled

by Vincent Massol

Hi, I'd like to implement http://jira.xwiki.org/jira/browse/XWIKI-2957 (WikiWord transformation), now that we can control which transformation gets executed by default. I've done a first implementation of it here: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-transformation-wik… I'd like to move this to the rendering module as a new transformation module (next to the icon transformation). WDYT? Thanks -Vincent PS: This will allow to check the "CamelCase link" feature of the wikimatrix: http://www.wikimatrix.org/show/XWiki

13 years, 10 months

[xwiki-devs] Interesting calc/sum/summary macros for syntax 2.0

by Ludovic Dubost

Hi, I've published a macro allowing to do simple calculations inside a Wiki table in syntax 2.0. http://code.xwiki.org/xwiki/bin/view/Macros/CalcMacro Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r32196 - in platform/xwiki-plugins/trunk/activitystream: . src/main/java/com/xpn/xwiki/plugin/activitystream/api src/main/java/com/xpn/xwiki/plugin/activitystream/impl

by Vincent Massol

On Oct 26, 2010, at 6:12 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-10-26 18:12:09 +0200 (Tue, 26 Oct 2010) > New Revision: 32196 > > Modified: > platform/xwiki-plugins/trunk/activitystream/pom.xml > platform/xwiki-plugins/trunk/activitystream/src/main/java/com/xpn/xwiki/plugin/activitystream/api/ActivityEventType.java > platform/xwiki-plugins/trunk/activitystream/src/main/java/com/xpn/xwiki/plugin/activitystream/impl/ActivityStreamImpl.java > Log: > XPAS-19: New event types for create, edit and delete comment > XPAS-20: New event types for create, edit and delete attachment > XPAS-21: New event type for create, edit and delete annotation > Done. > Patch from Stefan Abageru applied without changes. [snip] > @@ -87,6 +96,15 @@ > add(new DocumentSaveEvent()); > add(new DocumentUpdateEvent()); > add(new DocumentDeleteEvent()); > + add(new CommentAddEvent()); > + add(new CommentDeleteEvent()); > + add(new CommentUpdateEvent()); > + add(new AttachmentAddEvent()); > + add(new AttachmentDeleteEvent()); > + add(new AttachmentUpdateEvent()); > + add(new AnnotationAddEvent()); > + add(new AnnotationDeleteEvent()); > + add(new AnnotationUpdateEvent()); hmm this doesn't look right. I don't think the activity stream should know about all modules. Also this won't work when you add a new module which offers new events. There's a design problem. > } > }; > > @@ -875,21 +893,61 @@ > if (!Utils.getComponent(RemoteObservationManagerContext.class).isRemoteState()) { > String eventType; > String displayTitle; > - > + String additionalIdentifier = null; > + > if (event instanceof DocumentSaveEvent) { > eventType = ActivityEventType.CREATE; > displayTitle = currentDoc.getDisplayTitle(context); > } else if (event instanceof DocumentUpdateEvent) { > eventType = ActivityEventType.UPDATE; > displayTitle = originalDoc.getDisplayTitle(context); > - } else { // event instanceof DocumentDeleteEvent > + } else if (event instanceof DocumentDeleteEvent) { > eventType = ActivityEventType.DELETE; > displayTitle = originalDoc.getDisplayTitle(context); > + } else if (event instanceof CommentAddEvent) { > + eventType = ActivityEventType.ADD_COMMENT; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((CommentAddEvent) event).getComment(); > + } else if (event instanceof CommentDeleteEvent) { > + eventType = ActivityEventType.DELETE_COMMENT; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((CommentDeleteEvent) event).getComment(); > + } else if (event instanceof CommentUpdateEvent){ > + eventType = ActivityEventType.UPDATE_COMMENT; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((CommentUpdateEvent) event).getComment(); > + } else if (event instanceof AttachmentAddEvent){ > + eventType = ActivityEventType.ADD_ATTACHMENT; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((AttachmentAddEvent) event).getName(); > + } else if (event instanceof AttachmentDeleteEvent){ > + eventType = ActivityEventType.DELETE_ATTACHMENT; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((AttachmentDeleteEvent) event).getName(); > + } else if (event instanceof AttachmentUpdateEvent){ > + eventType = ActivityEventType.UPDATE_ATTACHMENT; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((AttachmentUpdateEvent) event).getName(); > + } else if (event instanceof AnnotationAddEvent){ > + eventType = ActivityEventType.ADD_ANNOTATION; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((AnnotationAddEvent) event).getIdentifier(); > + } else if (event instanceof AnnotationDeleteEvent){ > + eventType = ActivityEventType.DELETE_ANNOTATION; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((AnnotationDeleteEvent) event).getIdentifier(); > + } else { // update annotation > + eventType = ActivityEventType.UPDATE_ANNOTATION; > + displayTitle = currentDoc.getDisplayTitle(context); > + additionalIdentifier = ((AnnotationUpdateEvent) event).getIdentifier(); This also looks like a design issue. It's a lot of "if"s and duplicated code. [snip] In general this whole commit really smells like some code that was done without refactoring in mind. It shows problems but the time wasn't taken to refactor the issues IMO. Let's do that now since otherwise we're introducing technical debt. Thanks -Vincent

13 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r32192 - platform/core/trunk/xwiki-observation/xwiki-observation-api/src/main/java/org/xwiki/observation/event

by Vincent Massol

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.

13 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r32194 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki

by Vincent Massol

On Oct 26, 2010, at 6:01 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-10-26 18:01:43 +0200 (Tue, 26 Oct 2010) > New Revision: 32194 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/XWiki.java > Log: > XWIKI-5624: Send observation events for adding/editing/deleting comments, annotations, and attachments > Done. > [snip] > > + for (AttachmentDiff diff : doc.getAttachmentDiff(originalDoc, doc, context)) { > + if (StringUtils.isEmpty(diff.getOrigVersion())) { > + om.notify(new AttachmentAddEvent(reference, diff.getFileName()), source, data); > + } else if (StringUtils.isEmpty(diff.getNewVersion())) { > + om.notify(new AttachmentDeleteEvent(reference, diff.getFileName()), source, data); > + } else { > + om.notify(new AttachmentUpdateEvent(reference, diff.getFileName()), source, data); > + } > + } > + } catch (XWikiException ex) { > + // TODO Auto-generated catch block > + ex.printStackTrace(); This is definitely wrong and needs to be fixed. > + } > + } > + > + private static final List<Event> LISTENER_EVENTS = new ArrayList<Event>() > + { > + { > + add(new DocumentSaveEvent()); > + add(new DocumentUpdateEvent()); > + add(new DocumentDeleteEvent()); > + } > + }; > + > + public List<Event> getEvents() > + { > + return LISTENER_EVENTS; > + } > + > + public String getName() > + { > + return "xwiki-core"; I don't think this is a good name, at least it's not following current practices. Thanks -Vincent

13 years, 10 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2010