Wed, 31 Dec 2014 06:09:35 +0100
Cloned upstream origin tor-browser at tor-browser-31.3.0esr-4.5-1-build1
revision ID fc1c9ff7c1b2defdbc039f12214767608f46423f for hacking purpose.
michael@0 | 1 | /* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */ |
michael@0 | 2 | /* This Source Code Form is subject to the terms of the Mozilla Public |
michael@0 | 3 | * License, v. 2.0. If a copy of the MPL was not distributed with this |
michael@0 | 4 | * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ |
michael@0 | 5 | |
michael@0 | 6 | #include "domstubs.idl" |
michael@0 | 7 | |
michael@0 | 8 | interface nsIAtom; |
michael@0 | 9 | interface nsIContent; |
michael@0 | 10 | interface nsIXULBuilderListener; |
michael@0 | 11 | interface nsIXULTemplateResult; |
michael@0 | 12 | interface nsIXULTemplateRuleFilter; |
michael@0 | 13 | interface nsIXULTemplateQueryProcessor; |
michael@0 | 14 | interface nsIRDFResource; |
michael@0 | 15 | interface nsIRDFCompositeDataSource; |
michael@0 | 16 | interface nsIDOMDataTransfer; |
michael@0 | 17 | |
michael@0 | 18 | /** |
michael@0 | 19 | * A template builder, given an input source of data, a template, and a |
michael@0 | 20 | * reference point, generates a list of results from the input, and copies |
michael@0 | 21 | * part of the template for each result. Templates may generate content |
michael@0 | 22 | * recursively, using the same template, but with the previous iteration's |
michael@0 | 23 | * results as the reference point. As an example, for an XML datasource the |
michael@0 | 24 | * initial reference point would be a specific node in the DOM tree and a |
michael@0 | 25 | * template might generate a list of all child nodes. For the next iteration, |
michael@0 | 26 | * those children would be used to generate output for their child nodes and |
michael@0 | 27 | * so forth. |
michael@0 | 28 | * |
michael@0 | 29 | * A template builder is attached to a single DOM node; this node is called |
michael@0 | 30 | * the root node and is expected to contain a XUL template element as a direct |
michael@0 | 31 | * child. Different template builders may be specialized in the manner in |
michael@0 | 32 | * which they generate and display the resulting content from the template. |
michael@0 | 33 | * |
michael@0 | 34 | * The structure of a template is as follows: |
michael@0 | 35 | * |
michael@0 | 36 | * <rootnode datasources="" ref=""> |
michael@0 | 37 | * <template> |
michael@0 | 38 | * <queryset> |
michael@0 | 39 | * <query> |
michael@0 | 40 | * </query> |
michael@0 | 41 | * <rule> |
michael@0 | 42 | * <conditions>...</conditions> |
michael@0 | 43 | * <bindings>...</bindings> |
michael@0 | 44 | * <action>...</action> |
michael@0 | 45 | * </rule> |
michael@0 | 46 | * </queryset> |
michael@0 | 47 | * </template> |
michael@0 | 48 | * </rootnode> |
michael@0 | 49 | * |
michael@0 | 50 | * The datasources attribute on the root node is used to identify the source |
michael@0 | 51 | * of data to be used. The ref attribute is used to specify the reference |
michael@0 | 52 | * point for the query. Currently, the datasource will either be an |
michael@0 | 53 | * nsIRDFDataSource or a DOM node. In the future, other datasource types may |
michael@0 | 54 | * be used. |
michael@0 | 55 | * |
michael@0 | 56 | * The <queryset> element contains a single query and one or more <rule> |
michael@0 | 57 | * elements. There may be more than one <queryset> if multiple queries are |
michael@0 | 58 | * desired, and this element is optional if only one query is needed -- in |
michael@0 | 59 | * that case the <query> and <rule>s are allowed to be children of the |
michael@0 | 60 | * <template> node |
michael@0 | 61 | * |
michael@0 | 62 | * The contents of the query are processed by a separate component called a |
michael@0 | 63 | * query processor. This query processor is expected to use this query to |
michael@0 | 64 | * generate results when asked by the template builder. The template builder |
michael@0 | 65 | * then generates output for each result based on the <rule> elements. |
michael@0 | 66 | * |
michael@0 | 67 | * This allows the query processor to be specific to a particular kind of |
michael@0 | 68 | * input data or query syntax, while the template builder remains independent |
michael@0 | 69 | * of the kind of data being used. Due to this, the query processor will be |
michael@0 | 70 | * supplied with the datasource and query which the template builder handles |
michael@0 | 71 | * in an opaque way, while the query processor handles these more |
michael@0 | 72 | * specifically. |
michael@0 | 73 | * |
michael@0 | 74 | * Results implement the nsIXULTemplateResult interface and may be identified |
michael@0 | 75 | * by an id which must be unique within a given set of query results. |
michael@0 | 76 | * |
michael@0 | 77 | * Each query may be accompanied by one or more <rule> elements. These rules |
michael@0 | 78 | * are evaluated by the template builder for each result produced by the |
michael@0 | 79 | * query. A rule consists of conditions that cause a rule to be either |
michael@0 | 80 | * accepted or rejected. The condition syntax allows for common conditional |
michael@0 | 81 | * handling; additional filtering may be applied by adding a custom filter |
michael@0 | 82 | * to a rule with the builder's addRuleFilter method. |
michael@0 | 83 | * |
michael@0 | 84 | * If a result passes a rule's conditions, this is considered a match, and the |
michael@0 | 85 | * content within the rule's <action> body is inserted as a sibling of the |
michael@0 | 86 | * <template>, assuming the template builder creates real DOM content. Only |
michael@0 | 87 | * one rule will match a result. For a tree builder, for example, the content |
michael@0 | 88 | * within the action body is used to create the tree rows instead. A matching |
michael@0 | 89 | * result must have its ruleMatched method called. When a result no longer |
michael@0 | 90 | * matches, the result's hasBeenRemoved method must be called. |
michael@0 | 91 | * |
michael@0 | 92 | * Optionally, the rule may have a <bindings> section which may be used to |
michael@0 | 93 | * define additional variables to be used within an action body. Each of these |
michael@0 | 94 | * declared bindings must be supplied to the query processor via its |
michael@0 | 95 | * addBinding method. The bindings are evaluated after a rule has matched. |
michael@0 | 96 | * |
michael@0 | 97 | * Templates may generate content recursively, using the previous iteration's |
michael@0 | 98 | * results as reference point to invoke the same queries. Since the reference |
michael@0 | 99 | * point is different, different output will typically be generated. |
michael@0 | 100 | * |
michael@0 | 101 | * The reference point nsIXULTemplateResult object for the first iteration is |
michael@0 | 102 | * determined by calling the query processor's translateRef method using the |
michael@0 | 103 | * value of the root node's ref attribute. This object may be retrieved later |
michael@0 | 104 | * via the builder's rootResult property. |
michael@0 | 105 | * |
michael@0 | 106 | * For convenience, each reference point as well as all results implement the |
michael@0 | 107 | * nsIXULTemplateResult interface, allowing the result objects from each |
michael@0 | 108 | * iteration to be used directly as the reference points for the next |
michael@0 | 109 | * iteration. |
michael@0 | 110 | * |
michael@0 | 111 | * When using multiple queries, each may generate results with the same id. |
michael@0 | 112 | * More than one of these results may match one of the rules in their |
michael@0 | 113 | * respective queries, however only the result for the earliest matching query |
michael@0 | 114 | * in the template becomes the active match and generates output. The |
michael@0 | 115 | * addResult, removeResult, replaceResult and resultBindingChanged methods may |
michael@0 | 116 | * be called by the query processor to indicate that the set of valid results |
michael@0 | 117 | * has changed, such that a different query may match. If a different match |
michael@0 | 118 | * would become active, the content for the existing match is removed and the |
michael@0 | 119 | * content for the new match is generated. A query processor is not required |
michael@0 | 120 | * to provide any support for updating results after they have been generated. |
michael@0 | 121 | * |
michael@0 | 122 | * See http://wiki.mozilla.org/XUL:Templates_Plan for details about templates. |
michael@0 | 123 | */ |
michael@0 | 124 | [scriptable, uuid(A583B676-5B02-4F9C-A0C9-CB850CB99818)] |
michael@0 | 125 | interface nsIXULTemplateBuilder : nsISupports |
michael@0 | 126 | { |
michael@0 | 127 | /** |
michael@0 | 128 | * The root node in the DOM to which this builder is attached. |
michael@0 | 129 | */ |
michael@0 | 130 | readonly attribute nsIDOMElement root; |
michael@0 | 131 | |
michael@0 | 132 | /** |
michael@0 | 133 | * The opaque datasource object that is used for the template. This object |
michael@0 | 134 | * is created by the getDataSource method of the query processor. May be |
michael@0 | 135 | * null if the datasource has not been loaded yet. Set this attribute to |
michael@0 | 136 | * use a different datasource and rebuild the template. |
michael@0 | 137 | * |
michael@0 | 138 | * For an RDF datasource, this will be the same as the database. For XML |
michael@0 | 139 | * this will be the nsIDOMNode for the datasource document or node for |
michael@0 | 140 | * an inline reference (such as #name). Other query processors may use |
michael@0 | 141 | * other types for the datasource. |
michael@0 | 142 | */ |
michael@0 | 143 | attribute nsISupports datasource; |
michael@0 | 144 | |
michael@0 | 145 | /** |
michael@0 | 146 | * The composite datasource that the template builder observes |
michael@0 | 147 | * and uses to create content. This is used only for RDF queries and is |
michael@0 | 148 | * maintained for backwards compatibility. It will be the same object as |
michael@0 | 149 | * the datasource property. For non-RDF queries, it will always be null. |
michael@0 | 150 | */ |
michael@0 | 151 | readonly attribute nsIRDFCompositeDataSource database; |
michael@0 | 152 | |
michael@0 | 153 | /** |
michael@0 | 154 | * The virtual result representing the starting reference point, |
michael@0 | 155 | * determined by calling the query processor's translateRef method |
michael@0 | 156 | * with the root node's ref attribute as an argument. |
michael@0 | 157 | */ |
michael@0 | 158 | readonly attribute nsIXULTemplateResult rootResult; |
michael@0 | 159 | |
michael@0 | 160 | /** |
michael@0 | 161 | * The query processor used to generate results. |
michael@0 | 162 | */ |
michael@0 | 163 | [noscript] readonly attribute nsIXULTemplateQueryProcessor queryProcessor; |
michael@0 | 164 | |
michael@0 | 165 | /** |
michael@0 | 166 | * Force the template builder to rebuild its content. All existing content |
michael@0 | 167 | * will be removed first. The query processor's done() method will be |
michael@0 | 168 | * invoked during cleanup, followed by its initializeForBuilding method |
michael@0 | 169 | * when the content is to be regenerated. |
michael@0 | 170 | * |
michael@0 | 171 | */ |
michael@0 | 172 | void rebuild(); |
michael@0 | 173 | |
michael@0 | 174 | /** |
michael@0 | 175 | * Reload any of our RDF datasources that support nsIRDFRemoteDatasource. |
michael@0 | 176 | * |
michael@0 | 177 | * @note This is a temporary hack so that remote-XUL authors can |
michael@0 | 178 | * reload remote datasources. When RDF becomes remote-scriptable, |
michael@0 | 179 | * this will no longer be necessary. |
michael@0 | 180 | */ |
michael@0 | 181 | void refresh(); |
michael@0 | 182 | |
michael@0 | 183 | /** |
michael@0 | 184 | * Inform the template builder that a new result is available. The builder |
michael@0 | 185 | * will add this result to the set of results. The query node that the |
michael@0 | 186 | * new result applies to must be specified using the aQueryNode parameter. |
michael@0 | 187 | * |
michael@0 | 188 | * The builder will apply the rules associated with the query to the new |
michael@0 | 189 | * result, unless a result with the same id from an earlier query |
michael@0 | 190 | * supersedes it, and the result's RuleMatched method will be called if it |
michael@0 | 191 | * matches. |
michael@0 | 192 | * |
michael@0 | 193 | * @param aResult the result to add |
michael@0 | 194 | * @param aQueryNode the query that the result applies to |
michael@0 | 195 | * |
michael@0 | 196 | * @throws NS_ERROR_NULL_POINTER if aResult or aQueryNode are null |
michael@0 | 197 | */ |
michael@0 | 198 | void addResult(in nsIXULTemplateResult aResult, in nsIDOMNode aQueryNode); |
michael@0 | 199 | |
michael@0 | 200 | /** |
michael@0 | 201 | * Inform the template builder that a result no longer applies. The builder |
michael@0 | 202 | * will call the remove content generated for the result, if any. If a different |
michael@0 | 203 | * query would then match instead, it will become the active match. This |
michael@0 | 204 | * method will have no effect if the result isn't known to the builder. |
michael@0 | 205 | * |
michael@0 | 206 | * @param aResult the result to remove |
michael@0 | 207 | * |
michael@0 | 208 | * @throws NS_ERROR_NULL_POINTER if aResult is null |
michael@0 | 209 | */ |
michael@0 | 210 | void removeResult(in nsIXULTemplateResult aResult); |
michael@0 | 211 | |
michael@0 | 212 | /** |
michael@0 | 213 | * Inform the template builder that one result should be replaced with |
michael@0 | 214 | * another. Both the old result (aOldResult) and the new result |
michael@0 | 215 | * (aNewResult) must have the same id. The query node that the new result |
michael@0 | 216 | * applies to must be specified using the aQueryNode parameter. |
michael@0 | 217 | * |
michael@0 | 218 | * This method is expected to have the same effect as calling both |
michael@0 | 219 | * removeResult for the old result and addResult for the new result. |
michael@0 | 220 | * |
michael@0 | 221 | * @param aOldResult the old result |
michael@0 | 222 | * @param aNewResult the new result |
michael@0 | 223 | * @param aQueryNode the query that the new result applies to |
michael@0 | 224 | * |
michael@0 | 225 | * @throws NS_ERROR_NULL_POINTER if either argument is null, or |
michael@0 | 226 | * NS_ERROR_INVALID_ARG if the ids don't match |
michael@0 | 227 | */ |
michael@0 | 228 | void replaceResult(in nsIXULTemplateResult aOldResult, |
michael@0 | 229 | in nsIXULTemplateResult aNewResult, |
michael@0 | 230 | in nsIDOMNode aQueryNode); |
michael@0 | 231 | |
michael@0 | 232 | /** |
michael@0 | 233 | * Inform the template builder that one or more of the optional bindings |
michael@0 | 234 | * for a result has changed. In this case, the rules are not reapplied as |
michael@0 | 235 | * it is expected that the same rule will still apply. The builder will |
michael@0 | 236 | * resynchronize any variables that are referenced in the action body. |
michael@0 | 237 | * |
michael@0 | 238 | * @param aResult the result to change |
michael@0 | 239 | * |
michael@0 | 240 | * @throws NS_ERROR_NULL_POINTER if aResult is null |
michael@0 | 241 | */ |
michael@0 | 242 | void resultBindingChanged(in nsIXULTemplateResult aResult); |
michael@0 | 243 | |
michael@0 | 244 | /** |
michael@0 | 245 | * Return the result for a given id. Only one such result is returned and |
michael@0 | 246 | * is always the result with that id associated with the active match. |
michael@0 | 247 | * This method will return null is there is no result for the id. |
michael@0 | 248 | * |
michael@0 | 249 | * @param aId the id to return the result for |
michael@0 | 250 | */ |
michael@0 | 251 | nsIXULTemplateResult getResultForId(in AString aId); |
michael@0 | 252 | |
michael@0 | 253 | /** |
michael@0 | 254 | * Retrieve the result corresponding to a generated element, or null is |
michael@0 | 255 | * there isn't one. |
michael@0 | 256 | * |
michael@0 | 257 | * @param aContent element to result the result of |
michael@0 | 258 | */ |
michael@0 | 259 | nsIXULTemplateResult getResultForContent(in nsIDOMElement aElement); |
michael@0 | 260 | |
michael@0 | 261 | /** |
michael@0 | 262 | * Returns true if the node has content generated for it. This method is |
michael@0 | 263 | * intended to be called only by the RDF query processor. If aTag is set, |
michael@0 | 264 | * the content must have a tag name that matches aTag. aTag may be ignored |
michael@0 | 265 | * for builders that don't generate real DOM content. |
michael@0 | 266 | * |
michael@0 | 267 | * @param aNode node to check |
michael@0 | 268 | * @param aTag tag that must match |
michael@0 | 269 | */ |
michael@0 | 270 | boolean hasGeneratedContent(in nsIRDFResource aNode, in nsIAtom aTag); |
michael@0 | 271 | |
michael@0 | 272 | /** |
michael@0 | 273 | * Adds a rule filter for a given rule, which may be used for specialized |
michael@0 | 274 | * rule filtering. Any existing filter on the rule is removed. The default |
michael@0 | 275 | * conditions specified inside the <rule> tag are applied before the |
michael@0 | 276 | * rule filter is applied, meaning that the filter may be used to further |
michael@0 | 277 | * filter out results but not reaccept results that have already been |
michael@0 | 278 | * rejected. |
michael@0 | 279 | * |
michael@0 | 280 | * @param aRule the rule to apply the filter to |
michael@0 | 281 | * @param aFilter the filter to add |
michael@0 | 282 | */ |
michael@0 | 283 | void addRuleFilter(in nsIDOMNode aRule, in nsIXULTemplateRuleFilter aFilter); |
michael@0 | 284 | |
michael@0 | 285 | /** |
michael@0 | 286 | * Called to initialize a XUL content builder on a particular root |
michael@0 | 287 | * element. This element presumably has a ``datasources'' |
michael@0 | 288 | * attribute, which the builder will parse to set up the template |
michael@0 | 289 | * builder's datasources. |
michael@0 | 290 | */ |
michael@0 | 291 | [noscript] void init(in nsIContent aElement); |
michael@0 | 292 | |
michael@0 | 293 | /** |
michael@0 | 294 | * Invoked lazily by a XUL element that needs its child content built. |
michael@0 | 295 | * If aForceCreation is true, then the contents of an element will be |
michael@0 | 296 | * generated even if it is closed. If false, the element will only |
michael@0 | 297 | * generate its contents if it is open. This behaviour is used with menus. |
michael@0 | 298 | */ |
michael@0 | 299 | [noscript] void createContents(in nsIContent aElement, |
michael@0 | 300 | in boolean aForceCreation); |
michael@0 | 301 | |
michael@0 | 302 | /** |
michael@0 | 303 | * Add a listener to this template builder. The template builder |
michael@0 | 304 | * holds a strong reference to the listener. |
michael@0 | 305 | */ |
michael@0 | 306 | void addListener(in nsIXULBuilderListener aListener); |
michael@0 | 307 | |
michael@0 | 308 | /** |
michael@0 | 309 | * Remove a listener from this template builder. |
michael@0 | 310 | */ |
michael@0 | 311 | void removeListener(in nsIXULBuilderListener aListener); |
michael@0 | 312 | }; |
michael@0 | 313 | |
michael@0 | 314 | /** |
michael@0 | 315 | * nsIXULTreeBuilderObserver |
michael@0 | 316 | * This interface allows clients of the XULTreeBuilder to define domain |
michael@0 | 317 | * specific handling of specific nsITreeView methods that |
michael@0 | 318 | * XULTreeBuilder does not implement. |
michael@0 | 319 | */ |
michael@0 | 320 | [scriptable, uuid(57CED9A7-EC0B-4A0E-8AEB-5DA32EBE951C)] |
michael@0 | 321 | interface nsIXULTreeBuilderObserver : nsISupports |
michael@0 | 322 | { |
michael@0 | 323 | const long DROP_BEFORE = -1; |
michael@0 | 324 | const long DROP_ON = 0; |
michael@0 | 325 | const long DROP_AFTER = 1; |
michael@0 | 326 | /** |
michael@0 | 327 | * Methods used by the drag feedback code to determine if a drag is allowable at |
michael@0 | 328 | * the current location. To get the behavior where drops are only allowed on |
michael@0 | 329 | * items, such as the mailNews folder pane, always return false whe |
michael@0 | 330 | * the orientation is not DROP_ON. |
michael@0 | 331 | */ |
michael@0 | 332 | boolean canDrop(in long index, in long orientation, in nsIDOMDataTransfer dataTransfer); |
michael@0 | 333 | |
michael@0 | 334 | /** |
michael@0 | 335 | * Called when the user drops something on this view. The |orientation| param |
michael@0 | 336 | * specifies before/on/after the given |row|. |
michael@0 | 337 | */ |
michael@0 | 338 | void onDrop(in long row, in long orientation, in nsIDOMDataTransfer dataTransfer); |
michael@0 | 339 | |
michael@0 | 340 | /** |
michael@0 | 341 | * Called when an item is opened or closed. |
michael@0 | 342 | */ |
michael@0 | 343 | void onToggleOpenState (in long index); |
michael@0 | 344 | |
michael@0 | 345 | /** |
michael@0 | 346 | * Called when a header is clicked. |
michael@0 | 347 | */ |
michael@0 | 348 | void onCycleHeader(in wstring colID, in nsIDOMElement elt); |
michael@0 | 349 | |
michael@0 | 350 | /** |
michael@0 | 351 | * Called when a cell in a non-selectable cycling column (e.g. |
michael@0 | 352 | * unread/flag/etc.) is clicked. |
michael@0 | 353 | */ |
michael@0 | 354 | void onCycleCell(in long row, in wstring colID); |
michael@0 | 355 | |
michael@0 | 356 | /** |
michael@0 | 357 | * Called when selection in the tree changes |
michael@0 | 358 | */ |
michael@0 | 359 | void onSelectionChanged(); |
michael@0 | 360 | |
michael@0 | 361 | /** |
michael@0 | 362 | * A command API that can be used to invoke commands on the selection. |
michael@0 | 363 | * The tree will automatically invoke this method when certain keys |
michael@0 | 364 | * are pressed. For example, when the DEL key is pressed, performAction |
michael@0 | 365 | * will be called with the "delete" string. |
michael@0 | 366 | */ |
michael@0 | 367 | void onPerformAction(in wstring action); |
michael@0 | 368 | |
michael@0 | 369 | /** |
michael@0 | 370 | * A command API that can be used to invoke commands on a specific row. |
michael@0 | 371 | */ |
michael@0 | 372 | void onPerformActionOnRow(in wstring action, in long row); |
michael@0 | 373 | |
michael@0 | 374 | /** |
michael@0 | 375 | * A command API that can be used to invoke commands on a specific cell. |
michael@0 | 376 | */ |
michael@0 | 377 | void onPerformActionOnCell(in wstring action, in long row, in wstring colID); |
michael@0 | 378 | }; |
michael@0 | 379 | |
michael@0 | 380 | [scriptable, uuid(06b31b15-ebf5-4e74-a0e2-6bc0a18a3969)] |
michael@0 | 381 | interface nsIXULTreeBuilder : nsISupports |
michael@0 | 382 | { |
michael@0 | 383 | /** |
michael@0 | 384 | * Retrieve the RDF resource associated with the specified row. |
michael@0 | 385 | */ |
michael@0 | 386 | nsIRDFResource getResourceAtIndex(in long aRowIndex); |
michael@0 | 387 | |
michael@0 | 388 | /** |
michael@0 | 389 | * Retrieve the index associated with specified RDF resource. |
michael@0 | 390 | */ |
michael@0 | 391 | long getIndexOfResource(in nsIRDFResource resource); |
michael@0 | 392 | |
michael@0 | 393 | /** |
michael@0 | 394 | * Add a Tree Builder Observer to handle Tree View |
michael@0 | 395 | * methods that the base builder does not implement. |
michael@0 | 396 | */ |
michael@0 | 397 | void addObserver(in nsIXULTreeBuilderObserver aObserver); |
michael@0 | 398 | |
michael@0 | 399 | /** |
michael@0 | 400 | * Remove an Tree Builder Observer. |
michael@0 | 401 | */ |
michael@0 | 402 | void removeObserver(in nsIXULTreeBuilderObserver aObserver); |
michael@0 | 403 | |
michael@0 | 404 | /** |
michael@0 | 405 | * Sort the contents of the tree using the specified column. |
michael@0 | 406 | */ |
michael@0 | 407 | void sort(in nsIDOMElement aColumnElement); |
michael@0 | 408 | }; |
michael@0 | 409 |