aboutsummaryrefslogtreecommitdiff
path: root/mod/ecml/README.txt
blob: 67d4522413c9c4668d93e1fd04aa60248bb2f2f4 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
ECML - Elgg Customizable Markup Language

CONTENTS:
	1.  Overview
	2.  Security
	3.  Using ECML Keywords
		3.1  Utility keywords 'entity' and 'view'
		3.2  Embedded 3rd party media
	4.  Custom ECML Keywords
	5.  Hints and Quirks


1.  OVERVIEW

	ECML adds support for an extensible keyword	system that allows users
	to quickly add elements and embed media in their content.  The ECML
	control panel can be used to granularly allow ECML keywords in certain
	contexts and views.


2.  SECURITY

	From the ECML control panel in the administration section the
	administrator can select which sections of the site support
	ECML.  For each section registered to display ECML, the administrator
	can select which keywords to deny.  For example, this is useful to
	prevent users from inserting an Elgg view into a blog page.

3.  USING ECML KEYWORDS

	All ECML keywords are surrounded by two square brackets: [[ and ]].
	Some keywords, like views and entity lists, take optional parameters.

	Examples:
		[[userlist]] -- Display up to 10 newest users.
		[[youtube src="http://www.youtube.com/watch?v=kCpjgl2baLs"]] -- Embed a YouTube video.
		[[view src="input/text"]] -- Display a textarea


3.1  UTILITY KEYWORDS 'entity' AND 'view'

	ECML includes a few built-in keywords to get you started.  They are
	mainly for embedding content from 3rd party sites, but also include
	two utility views to help non-programmers quickly display content.

	The two utility keywords available are [[entity]] and [[view]].

	[[entity]] - Displays a list of entities using similar arguments to the
	elgg_get_entities() function.  See documentation for that function for
	the full list of supported arguments and default values.

	Additional / changed parameters supported by keywords:
		* owner: The username owner. (You can still use owner_guid)

	Example: Displays a list of all blog posts by the user named 'admin':
		[[entity type=object subtype=blog owner=admin]]

	Example: Displays newest group created:
		[[entity type=object subtype=group limit=1]]


	[[view]] - Displays a valid Elgg view passing any optional parameters to
	the view.

	Example: Display a text input:
		[[view src="input/text"]]

	Example: Display a textarea with a default value:
		[[view src="input/longtext" value="This is an example of a quoted value!"]]


3.2  EMBEDDED 3RD PARTY MEDIA

	ECML provides support for embedding media from a few of the most common
	media sites:

	* Youtube -- [[youtube src="URL"]]
	* Vimeo -- [[vimeo src="URL"]]
	* Slideshare -- [[slideshare id="ID"]] (NB: Use the "wordpress.com" embed
	link surrounded by two [[s and ]]s.)


4  CUSTOM ECML KEYWORDS (AKA "THE 'C' in ECML)

	Plugins can add their own ECML keywords.  Each keyword must be bound to
	a valid view.  Almost all functionality in custom keywords could be
	implemented using the 'view' keyword, but custom keywords provide a
	simple way for non-techy users to include ready-made views without
	the fuss of knowing what they're doing.

	To register your own ECML keywords, reply to the 'get_keywords'
	hook of type 'ecml' and append to the passed array with a key that is
	your keyword name and a value that is an array of a view, a description,
	and usage instructions.

	Optionally, the array can pass a 'restricted' => array() value of views
	that this keyword is valid in.  This is not overrideable by the admin
	interface and is useful for forcing security on possibly dangerous
	keywords.

	Arguments passed to the keyword are accessible to the keyword view via
	the $vars array.  It is	the responsibility of the custom view to parse
	these arguments.

	The below example creates the 'buttonizer' keyword that turns the user's
	text into an HTML button.  It uses the view at 'buttonizer/ecml/buttonizer.'

	How a user will call the keyword:

		[[buttonizer text="This is my button!"]]

	How to implement this in a plugin:

		buttonizer/start.php:
			register_plugin_hook('get_keywords', 'ecml', 'buttonizer_ecml_keywords');

			function buttonizer_ecml_keywords($hook, $type, $value, $params) {
				$value['buttonizer'] = array(
					'view' => 'buttonizer/ecml/buttonizer',
					'description' => 'Makes your text a button!  What could be better?',
					'usage' => 'Use [[buttonizer text="My text"]] to make "My text" a button!'
				);

				return $value;
			}

		buttonizer/views/default/buttonizer/ecml/buttonizer.php:
			$text = $vars['text'];

			echo elgg_view('input/button', array(
				'value' => $text,
				'type' => 'button'
			));

	This is exactly the same as saying:

		[[view src="buttonizer/ecml/buttonizer" text="This is my button!"]]

	or even:

		[[view src="input/button" value="This is my button!" type="button"]]

	but is much simpler for the user.


5.  HINTS AND QUIRKS

	* A custom keyword is slightly more complicated to implement, but is
	much simpler for the end user to use.

	* A custom keyword is safer.  Since ECML can be disabled for certain
	views, many administrators disable the entity and view keywords in
	user-accessible pages like blogs, pages, and files.

	* Custom keywords can contain only alphanumeric characters.

	* To pass a complex argument to a keyword, quote the value.

	* If making a custom keyword, avoid underscores in your params.  They
	look funny.

	* Are disabled keywords in comments still working?  This is probably
	because a parent view is including comments directly.  For example:

	blog page handler:
		...logic...
		echo elgg_view_entity($blog);
		...logic...

	view object/blog:
		...logic...
		echo $blog;
		echo elgg_view_comments($blog);

	The output of object/blog includes the output of the comments, so if
	the view object/blog allows the youtube the comments will also be parsed
	for ECML.  The solution is to keep views for the object and comments
	separate.

	blog page handler:
		echo elgg_view_entity($blog);
		...logic...
		echo elgg_view_comments($blog);

	view object/blog:
		...logic...
		echo $blog

	Alternatively, you can keep the blog and comments in the object view, but
	pull out the blog into its own view to register with ECML.

	view object/blog:
		...logic...
		elgg_view('blog/blog', array('blog' => $blog);
		...logic...
		elgg_view_comments($blog);

	view blog/blog:
		...logic...
		echo $blog