On Fri, Jun 26, 2009 at 18:38, Asiri
Rathnayake<asiri.rathnayake(a)gmail.com> wrote:
  Hello Devs,
 This is about implementing support for creating rendering macros by editing
 wiki pages! The corresponding JIRA issue is
 
http://jira.xwiki.org/jira/browse/XWIKI-3213.
 Introduction
 ------------
 There are two main xwiki classes involved: XWiki.WikiMacro &
 XWiki.WikiMacroParameter. Fields of these classes are as below: 
AFAIK the rule is to put Class at the end of the name of a wiki class
(XWiki.WikiMacroClass, XWiki.WikiMacroParameterClass)
 XWiki.WikiMacro
 |
 |-> name (Name of the macro)
 |
 |-> description (Short description about the macro - for display purposes)
 |
 |-> content (Macro content, this is what will be executed when the macro is
 invoked, can be any xwiki/2.0 content) 
It should be any content depending of the document syntax not forced
to xwiki/2.0 syntax.
 XWiki.WikiMacroParameter
 |
 |-> name (Name of the parameter)
 |
 |-> macro (Name of the macro to which this parameter applies to)
 |
 |-> description (Description of this macro parameter - for display purposes)
 |
 |-> mandatory (boolean value indicating if this parameter is mandatory)
 So the basic idea is, when a user saves (or updates) a page containing an
 Object of XWiki.WikiMacro type, we will dynamically register (or
 re-register) a macro as defined by that object.
 Question:
 1. What about macro name conflicts? Should we ask macro name to be unique?
 (This can be done if we introduce a document sheet and a template for
 creating macros) 
We don't have much choice, macros names has to be unique anyway so the
best to to provide sheet/template which help to manage this constrain
and print warning for example.
Now i'm not sure we need specific conflict management rules (the last
registered will be the winner then), we could think about that later
if it's becoming strongly needed.
 Implementation steps
 --------------------
 1. The original idea was to create XWiki.WikiMacro &
 XWiki.WikiMacroParameter classes upon XE startup (if those classes are not
 present). But I would like to start a little different here, we create
 xwiki-application-wikimacro application to host these two documents and
 later remove this app and add the initialization code. This will allow me to
 focus on other more important tasks upfront and meanwhile i can make any
 changes easily to these wiki pages if they are kept inside an application.
 2. Document update / save event listening & Macro registration can be
 implemented using the ObservationManager and dynamic component registration
 mechanisms.
 - Currently ObservationManager can only send general document save / update
 events. We can either use these events and filter only those we are
 interested (ones where an XWiki.WikiMacro object is saved / updated) OR we
 can introduce a new event like ObjectChangedEvent (which would be
 constructed given a class name) that is fired by xwiki-core appropriately.
 - This document event listening & dynamic macro component registration code
 will be put inside xwiki-rendering/xwiki-rendering-macro-wikibridge
 3. Finally DefaultMacroManager needs to be updated so that it listens to
 ComponentManager events and filters out those events corresponding to Macro
 component registrations and updates the internal macro cache.
 So, above is the approach I have in mind for implementing the wiki-macro
 bridge. If you have any comments, please let me know. 
You are not speaking about security here but it's a very important
subject. With what you described any user could be able to register
any macro usable by anyone in which he can do whatever he want with
the rigths of the user of the macro.
The best would be that a macro created by a user is usable only by
himself until this macro is promoted as standard macro in some admin
UI. But this mean we can't just register the macro as standard
component when it's saved, we would need at least the standard list
and the users list of macros in the DefaultMacroManager or support
this standard component VS users component in a more generic way like
the component realms suggested by Vincent.
Maybe the first step only register the macro if the users which
modified it has programming rights.
 Thanks.
 - Asiri
 _______________________________________________
 devs mailing list
 devs(a)xwiki.org
 
http://lists.xwiki.org/mailman/listinfo/devs
 
--
Thomas Mortagne