Changes for page Writing XWiki Rendering Macros in wiki pages

Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.VincentMassol
	1	+XWiki.ThomasMortagne

Content

...	...	@@ -26,9 +26,10 @@
26	26	* **Default category**: Default category under which this macro should be listed
27	27	* **Supports inline mode**: Whether the macro can be used in an inline context or not
28	28	* **Macro Content availability**: {{warning}}before 11.5RC1 this was called **Macro Content Type**{{/warning}} whether this macro should support a body or not
29		-* **Macro content type**: {{warning}}this field has been renamed **Macro Content Availability** since 11.5RC1{{/warning}} the type of accepted content: two values are proposed, ##WIKI## if this content should be editable like a wiki content, or ##UNKNOWN## if it should be displayed like a plain text. It's also possible to specify a custom java type such as {{code language='java'}}java.util.List<java.lang.String>{{/code}}. Leaving the field blank is equivalent to ##UNKWOWN## value.
	29	+* **Macro content type**: {{warning}}this field has been renamed **Macro Content Availability** since 11.5RC1{{/warning}} the type of accepted content: two values are proposed, ##WIKI## if this content should be editable like a wiki content, or ##UNKNOWN## if it should be displayed like a plain text. It's also possible to specify a custom java type such as {{code language="java"}}java.util.List<java.lang.String>{{/code}}. Leaving the field blank is equivalent to ##UNKWOWN## value.
30	30	* **Content description**: A short description about the macro's content to be displayed on the WYSIWYG editor
31	31	* **Macro code**: The actual wiki code that will be evaluated when the macro is executed, can be any xwiki content (should be in the same syntax as the document)
	32	+* **Priority**: {{info}}Since 13.1{{/info}} The priority of execution relative to the other Macros. The lowest values have the highest priorities and execute first. For example a Macro with a priority of 100 will execute before one with a priority of 500. The default value is 1000.
32	32	* **Asynchronous rendering**: {{info}}Since 10.10{{/info}} Enabled or disable asynchronous rendering of the panel. Disabled by default.
33	33	* **Cached**: {{info}}Since 10.10{{/info}} Indicate if the result of the execution of the element should be cached. Disabled by default.
34	34	* **Context elements**: {{info}}Since 10.10{{/info}} The context information required during the execution of the extension (current user, current document, etc.). It's also used to generate the cache key.
...	...	@@ -41,7 +41,7 @@
41	41
42	42	A wiki macro can be invoked just like any other macro is invoked. Since we are writing a xwiki/2.0 wiki macro, we can invoke our **hello macro** as below:
43	43
44		-{{code language='none'}}
	45	+{{code language="none"}}
45	45	{{hello/}}
46	46	{{/code}}
47	47
...	...	@@ -49,7 +49,7 @@
49	49
50	50	== Content ==
51	51
52		-{{version since='11.4RC1'}}
	53	+{{version since="11.4RC1"}}
53	53	There are two ways to insert the content of the wiki macro.
54	54
55	55	* The easiest way is to use a dedicated macro in the body of the wikimacro:(((
...	...	@@ -85,7 +85,7 @@
85	85
86	86	A macro parameter defined this way can be accessed from any scripting language within the macro code. For example, we are going to utilize our //greetUser// parameter within **hello macro** as shown below:
87	87
88		-{{code language='none'}}
	89	+{{code language="none"}}
89	89	{{velocity}}
90	90	#if ($wikimacro.parameters.greetUser && "XWiki.XWikiGuest" != "$xcontext.user")
91	91	Hello $xwiki.user.email!
...	...	@@ -98,17 +98,17 @@
98	98	As you might have realized already, direct binding of parameters is not supported at the moment. That is, you cannot access //greetUser// parameter with **$greetUser**. Instead you must use **$wikimacro.parameters.greetUser**. We plan to introduce some form of direct parameter binding in near future.
99	99
100	100	Since {{info}}11.5RC1{{/info}}, it is also possible to display the content of a macro parameter by using a dedicated macro:
101		-{{code language='none'}}Hello {{wikimacroparameter name="greeUsers" /}}{{/code}}
	102	+{{code language="none"}}Hello {{wikimacroparameter name="greeUsers" /}}{{/code}}
102	102
103	103	Finally, we can test our new version of **hello macro** with the following invocation:
104	104
105		-{{code language='none'}}
	106	+{{code language="none"}}
106	106	{{hello greetUser="true"/}}
107	107	{{/code}}
108	108
109	109	If you want to call the new version of the **hello macro** with a parameter from a variable you will need to wrap the call in a velocity macro like this:
110	110
111		-{{code language='none'}}
	112	+{{code language="none"}}
112	112	{{velocity}}
113	113	#set ($greet = true)
114	114	{{hello greetUser="$greet"/}}
...	...	@@ -119,7 +119,7 @@
119	119
120	120	When your macro is ready, you might want to provide the description of the macro and its parameters in different languages. For that, you need to create a set of translation keys and values (as described [[here>>platform:DevGuide.InternationalizingApplications]]) and then just use the following convention for the keys you add in this storage (no modification is needed on the macro itself, the association of the translations to the macro is done based on a convention of the form of the translation keys):
121	121
122		-{{code language='properties'}}
	123	+{{code language="properties"}}
123	123	rendering.macro.<macro id>.name=Name of the macro, displayed in the macros list in the macros wizard
124	124	rendering.macro.<macro id>.description=Description of the macro, displayed as a help in the macros list in the macros wizard
125	125
...	...	@@ -131,7 +131,7 @@
131	131
132	132	In our example, french translations would be something like this:
133	133
134		-{{code language='properties'}}
	135	+{{code language="properties"}}
135	135	rendering.macro.hello.name=Macro pour dire bonjour
136	136	rendering.macro.hello.description=Ceci est une macro qui va dire "Bonjour" a l'utilisateur
137	137	rendering.macro.hello.parameter.greetUser.name=Personnaliser le message
...	...	@@ -168,7 +168,7 @@
168	168
169	169	Even in edit mode, the WYSIWYG editor will execute the macro and feed the result back into the document. If your macro use some JSX, these will not be loaded. But, if your macro produce some Javascript that use those JSX or manipulate the document's DOM (injecting new elements, moving existing elements, removing elements, etc.), you may want to protect the content in WYSIWYG edit mode in order to prevent the performed transformation to get saved. Here is how you can prevent this behavior:
170	170
171		-{{code language='velocity'}}
	172	+{{code language="velocity"}}
172	172	{{velocity}}
173	173	#if("$xcontext.action" != "edit")
174	174	{{html}}
...	...	@@ -186,7 +186,7 @@
186	186
187	187	== WYSIWYG editing of macro content or parameter ==
188	188
189		-As specified above you can use the dedicated macros {{code language='none'}}{{wikimacrocontent/}}{{/code}} and {{code language='none'}}{{wikimacroparameter name="foo"/}}{{/code}} to allow the users of your macro to be able to edit the values of the macro directly in the WYSIWYG editor once the macro is inserted.
	190	+As specified above you can use the dedicated macros {{code language="none"}}{{wikimacrocontent/}}{{/code}} and {{code language="none"}}{{wikimacroparameter name="foo"/}}{{/code}} to allow the users of your macro to be able to edit the values of the macro directly in the WYSIWYG editor once the macro is inserted.
190	190	Note that this is currently only possible if you specified that the macro content (or parameter) type is ##WIKI## type.
191	191
192	192	{{info}}
...	...	@@ -198,7 +198,7 @@
198	198	Following are a few useful hints if you plan to do advanced scripting inside your wiki macros:
199	199
200	200	* Since 2.4M1, it's possible to directly return the desired list of rendering blocks without having to render them first to let them be parsed back by the macro transformation. The benefits are that it could be a lots quicker and most of all it means supporting syntax which does not provide any renderer. It also makes it possible to generate some XDOM which is impossible to write in any some syntax. For example the following wiki macro is generating a LinkBlock targeting a relative URL:(((
201		-{{code language='groovy'}}
	202	+{{code language="groovy"}}
202	202	{{groovy}}
203	203	import java.util.Collections;
204	204	import org.xwiki.rendering.listener.Link;
...	...	@@ -218,7 +218,7 @@
218	218	{{/code}}
219	219	)))
220	220	* If you are using ##$wikimacro.content## in your velocity macro, that content will not be able to support scripting, since nested scripting is not supported. To workaround that limitation, thanks to the above, you may do the parsing yourself using the rendering service. Here is a small sample:(((
221		-{{code language='velocity'}}
	222	+{{code language="velocity"}}
222	222	{{velocity output="no"}}
223	223	## get the macro content in a velocity string
224	224	#set($wikiresult = $wikimacro.content)
...	...	@@ -240,7 +240,7 @@
240	240
241	241	There is a common pitfall for using optional paramters. The following macro code contains a not so obvious bug:
242	242
243		-{{code languege='velocity'}}
	244	+{{code languege="velocity"}}
244	244	{{velocity}}
245	245	#set($greetUser=$xcontext.macro.params.greetUser)
246	246	#if ("true" == $greetUser && "XWiki.XWikiGuest" != "$xcontext.user" )
...	...	@@ -253,7 +253,7 @@
253	253
254	254	If we invoke it twice in a row:
255	255
256		-{{code language='none'}}
	257	+{{code language="none"}}
257	257	{{hello greetUser="true" /}}
258	258	{{hello /}}
259	259	{{/code}}
...	...	@@ -265,6 +265,6 @@
265	265
266	266	So in order to get around it, you can use:
267	267
268		-{{code language='none'}}
	269	+{{code language="none"}}
269	269	#set($greetUser="$!xcontext.macro.params.greetUser")
270	270	{{/code}}