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:
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)
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)
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.
Thanks.
- Asiri
I seem to recall some discussion about automatic plugin startup being planned. One of the really nice things about confluence is that you can add plugins with just a jar file and don't have to edit .xml configuration files. This also makes upgrades of either the plugin or wiki easier as everything is in the jar.
Was anything like this added for 2.0 or possibly planned in the near future?
--
Glenn
All,
I'm new to XWiki so go easy on me! I'm having two issues with my wiki. My first issue is with the Log-In link on the Main page above the Registration link. For some reason, it prompts visitors for the credentials to access my server instead of directing them to the log-in page. Is there any way I can modify the Main page's source so that I can point this link to the log-in page instead?
Also, I'm having difficulty using the calendar application. When I navigate to it the following lines of code appear:
$cparams.put("categories", $rqcategories)
$cview.getHTMLCalendar($cparams, "")
I read somewhere that this happens when the calendar plug-in isn't enabled. I tried enabling it by modifying xwiki.cfg but the calendar still won't appear. Is there something I've overlooked? I didn't find very much documentation on the subject but would be more than happy to contribute it once I get this issue resolved. I'm somewhat of a documentation nut. ^_^
Any help would be greatly appreciated.
Respectfully,
Joe Lawry
Hello,
I'm creating Wiki from XwikiManager and I want to set the option "SSL
enabled" but I don't see any difference when it is enabled or not...
Can anyone give some info about this feature because I may have missed
something?
Pascal
Hi devs,
We need to decide something for http://jira.xwiki.org/jira/browse/XWIKI-3413
I propose to take Vincent's proposal and have a parameter "outputType"
in the URL which provide the syntax identifier of the renderer to use.
Also since syntax identifier contains "/" which i never remember the
escaped version when i need it i propose to support short names by
looking at available renderers and take the last version of the asked
syntax (which mean the only renderer of this syntax most of the time
anyway but I prefer having something in case of).
So for example you could ask for the page Space.Page printed as plain
text and without UI with the URL:
http://host/xwiki/bin/view/Space/Page?outputType=plain&xpage=plain
or the full form
http://host/xwiki/bin/view/Space/Page?outputType=plain%2F1.0&xpage=plain
I don't like xpage=plain but it already exists and is doing exactly
this, printing the content of the document without UI. We can decide
latter if we want a new parameter for this.
Feel free to propose another name, I'm not sure of "outputType" but i
could not find a better one and "renderer" seems too technical.
On Mon, May 4, 2009 at 13:15, Vincent Massol<vincent(a)massol.net> wrote:
>
> On May 4, 2009, at 12:46 PM, Jean-Vincent Drean wrote:
>
>> On Mon, May 4, 2009 at 11:29 AM, Thomas Mortagne
>> <thomas.mortagne(a)xwiki.com> wrote:
>>> Hi devs,
>>>
>>> In 2.0 architecture we have no way currently to print a strongly
>>> formatted text (like JSON) or simply a plain text without XHTML which
>>> we are doing generally using xpage=plain in XWiki 1.0
>>
>> With the 1.0 syntax xpage=plain was mainly used to:
>> 1/ Output data in special format (JSON, xls, etc). In those cases
>> {pre} was used to avoid xhtml transformations.
>> 2/ Output xhtml content without the XWiki UI, I can think of one use
>> case where this content was put in ajax tooltips.
>>
>> Is 2/ covered ? Do we need a xpage=xhtml for it ?
>> Note that xpage=xpart&vm=contentview.vm can be used as a workaround.
>
> If you we want to have something clean for the future it seems to me
> that having a parameter called outputType (or simply output, or type,
> or contentType) which can take all renderer values would be best.
>
> For ex outputType=xhtml, xwiki, text, pdf, rtf, etc
>
> And when not specified it would default to outputType=xhtml.
>
> For removing the UI I'd use another parameter since it's orthogonal.
> Something like showUI=true|false
>
> Thanks
> -Vincent
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
Thanks,
--
Thomas Mortagne