1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/docs/XSLForms-resource.html Sun Oct 09 00:47:30 2005 +0000
1.3 @@ -0,0 +1,193 @@
1.4 +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
1.5 +<html xmlns="http://www.w3.org/1999/xhtml"><head>
1.6 + <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type" />
1.7 +
1.8 + <title>Using the XSLFormsResource API</title><meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
1.9 + <link href="styles.css" rel="stylesheet" type="text/css" /></head>
1.10 +<body>
1.11 +<h1>Using the XSLFormsResource API</h1>
1.12 +<p>The XSLForms toolkit provides a special WebStack resource class (described in the <a href="Web-resource.html">"Creating Applications: Write a Web Resource"</a>
1.13 +document), and
1.14 +from this class, <code>XSLFormsResource</code>,
1.15 +you can derive your own application-specific resources and use the
1.16 +class's API to obtain, manipulate and present form data. Although the
1.17 +supplied <a href="../apidocs/index.html">API documentation</a> provides details of the class's API, specifically in the <code><a href="../apidocs/public/XSLForms.Resources-module.html">XSLForms.Resources</a></code><a href="../apidocs/public/XSLForms.Resources-module.html"></a> module, this document attempts to explain how the API is used in practice.</p><h2>Resource Structure</h2><p>The structure of a Web resource derived from <code>XSLFormsResource</code> should look like this:</p><pre>class MyResource(XSLForms.Resources.XSLFormsResource):<br /><br /> [Resource definitions]<br /><br /> def respond_to_form(self, trans, form):<br /> [Examine the form data, see if the user has added or removed anything.]<br /> [Perform additional processing and initialise the form data.]<br /> [Produce some kind of response to show the user the updated form data.]</pre><p>Since <code>XSLFormsResource</code> builds on WebStack's resource mechanisms, we do have the transaction object, <code>trans</code>, available. However, most of the information we need to access and manipulate is generally available through the <code>form</code> object.</p><h2>Defining Resources</h2><p>Classes derived from <code>XSLFormsResource</code>
1.18 +support the concept of resources which are used to produce output,
1.19 +support processing and to provide access to useful information. At the
1.20 +class level it is essential to define at least some of these resources
1.21 +in order to make a working application.</p><h3>The Resource Directory</h3><p>Since
1.22 +XSLForms relies on template files residing in the filesystem, along
1.23 +with other files, we need to define where such files can be found (as
1.24 +described in the <a href="directory.html">"Creating Applications: Create
1.25 +a Directory"</a> document). Consequently, it is the convention that all resource classes define such information as follows:</p><pre>class ConfiguratorResource(XSLForms.Resources.XSLFormsResource):<br /><br /> resource_dir = os.path.join(os.path.split(__file__)[0], "Resources")</pre><p>All
1.26 +filenames, defined in the various resource sections (as described
1.27 +below) must be stated without leading path information - in other
1.28 +words, as "leafnames" rather than "pathnames". Thus, an example of
1.29 +an incorrect filename would be <code>/home/paulb/templates/my_template.xhtml</code>, whereas an example of a correct filename would be just <code>my_template.xhtml</code> when correcting the incorrect example.<br /></p><h3>Character Encoding</h3><p>It
1.30 +is also the convention to define the character encoding of the output
1.31 +produced by an application and the way ambiguous or
1.32 +insufficiently-specified input should be interpreted; this is done as
1.33 +follows:</p><pre> # Continuing from above...<br /><br /> encoding = "utf-8"</pre><h3>Template Resources</h3><p>The
1.34 +main purpose of XSLForms is to produce Web page output containing a
1.35 +visual representation of a form. Therefore, we need to define templates
1.36 +(as described in the <a href="design.html">"Creating Applications: Design a Template"</a> document) to express the representation of each kind of form, along with any intermediate files that may be produced. A special class-level <code>template_resources</code> dictionary is used to hold such definitions.</p><p>To
1.37 +define a template resource, we first choose a name (which need not have
1.38 +any special significance); we then associate with that name a
1.39 +template filename and an output filename. Finally, we make an
1.40 +entry for the name and its associated details in the special
1.41 +class-level <code>template_resources</code> dictionary as follows:</p><pre> # Continuing from above...<br /><br /> template_resources = {<br /> "configuration" : ("config_template.xhtml", "config_output.xsl"),<br /> # More entries go here...<br /> }</pre><p>The purpose
1.42 +of the output filename is to define where the intermediate
1.43 +output-producing stylesheet is to be written, since the template itself
1.44 +is not actually used to produce output, but knowing where the
1.45 +intermediate stylesheet can be found is sometimes useful when debugging
1.46 +templates and is thus defined explicitly to avoid confusion.</p><h3>Initialisation Resources</h3><p>The
1.47 +XSLForms toolkit also support the initialisation of form data
1.48 +documents. This document initialisation is useful when preparing a
1.49 +document for output since some parts of a template may not be produced
1.50 +unless certain elements are present in the form data document. For
1.51 +example, a template may contain something like this:</p><pre><div template:element="hard-disks"><br /> <input template:selector-field="add-hard-disk,hard-disk" type="submit" name="..." value="Add hard disk"/><br /> <p template:element="hard-disk"><br /> ...<br /> </p><br /></div></pre><p>In the above example, if no <code>hard-disks</code> element exists, the selector will not be displayed and there will be no way of adding <code>hard-disk</code> elements. With document initialisation, certain measures can be taken to ensure that the <code>hard-disks</code> element is added before output is generated.</p><p>At the class level, the <code>init_resources</code>
1.52 +dictionary is used to hold definitions mapping initialiser names (which
1.53 +need not have any special significance) to the initialiser details: the
1.54 +filename of the template which defines the structure of the form data,
1.55 +and an intermediate filename similar to the output filename described
1.56 +in the context of template resources above. An example of this is as
1.57 +follows:</p><pre> # Continuing from above...<br /><br /> init_resources = {<br /> "configuration" : ("config_template.xhtml", "config_input.xsl"),<br /> # More entries go here...<br /> }</pre><p>Note
1.58 +that initialiser and template resources may (and should) share the same
1.59 +template filename. As with the output filename for template resources,
1.60 +the input filename provides firm information about the location of the
1.61 +stylesheet which actually performs the initialisation process.</p><h3>Document Resources</h3><p>Since
1.62 +it is the XSLForms convention to access files using a simple name, any
1.63 +other document resources should be defined in the <code>document_resources</code>
1.64 +dictionary at the class level. Such document resources may be used in
1.65 +the initialisation process or in other transformations (as described
1.66 +below), and are defined as entries mapping names to filenames such as
1.67 +in the following example:</p><pre> # Continuing from above...<br /><br /> document_resources = {<br /> "accessories" : "config_accessories.xml",<br /> "base-system" : "config_base_system.xml",<br /> # More entries go here...<br /> }</pre><p>There is no particular limitation on the types of files which can be referenced in the <code>document_resources</code>
1.68 +dictionary, nor any insistence in the XSLForms toolkit to define such
1.69 +files as resources - the dictionary is merely a convenience for
1.70 +accessing files in the resources directory.</p><h3>Transform Resources</h3><p>It is sometimes the case that initialisation of a document
1.71 +is not sufficient and that additional processing needs to be done.
1.72 +Whilst various techniques exist for the processing of XML-based
1.73 +information, since XSLForms is part of a wider toolkit based on XSL
1.74 +transformations, it seems reasonable to provide certain facilities for
1.75 +the usage of such transformations. Thus, stylesheet processing
1.76 +pipelines may be defined at the class level in the <code>transform_resources</code> dictionary.</p><p>Entries in the <code>transform_resources</code>
1.77 +dictionary map simple names (which need not have any special
1.78 +significance) to collections of stylesheet filenames as in the
1.79 +following example:</p><pre> # Continuing from above...<br /><br /> transform_resources = {<br /> "filter" : ["filter.xsl"],<br /> # More entries go here...<br /> }</pre><p>Where
1.80 +more than one stylesheet filename is specified, the stylesheets are
1.81 +applied from first to last in the transformation. Additional
1.82 +information, such as stylesheet parameters and referenced documents,
1.83 +are mentioned when the transformation is acquired and invoked, as
1.84 +described below.</p><h3>In-Page Update Resources</h3><p>In certain
1.85 +applications, a technique referred to within XSLForms as "in-page
1.86 +updates" is employed to provide updates of details within a Web page
1.87 +without refreshing the entire page itself (and this is described in the
1.88 +<a href="in-page-updates.html">"Creating Applications: In-Page Updates"</a>
1.89 +document). When such updates are requested, applications have to
1.90 +identify the kind of update requested and then to select the correct
1.91 +part of the Web page to generate as output. Consequently, the
1.92 +application has to have some kind of record of the different kinds of
1.93 +updates and the corresponding parts of the whole page template to use,
1.94 +and this information is recorded in the class-level <code>in_page_resources</code> dictionary.</p><p>The form of an entry in the <code>in_page_resources</code>
1.95 +dictionary is that of a mapping from a name identifying the kind of
1.96 +update to the details of the part of the template to be employed in
1.97 +producing the final output for the update: an intermediate filename
1.98 +(distinct from that associated with the whole page template), and a
1.99 +node identifier used to isolate the pertinent part of the whole page
1.100 +template. Here is an example of an in-page resource definition:</p><pre> # Continuing from above...<br /><br /> in_page_resources = {<br /> "cpu" : ("config_output_cpu.xsl", "cpu-node"),<br /> # More entries go here...<br /> }</pre><h4>Update Names</h4><p>It
1.101 +is important to note that, unlike other resources, the name identifying
1.102 +the kind of update is significant: consider an application available at
1.103 +the following location:</p><pre>http://localhost/configurator/</pre><p>An in-page update called <code>cpu</code> would be accessed through the following location:</p><pre>http://localhost/configurator/cpu</pre><p>Thus,
1.104 +the availability of such an update "service" depends on the proper
1.105 +configuration of the Web application to let such updates be handled by
1.106 +the resource.</p><h4>Update Nodes</h4><p>The node identifier mentioned
1.107 +in an in-page update resource definition must be a valid node
1.108 +identifier in the whole page template document. Thus, if we wished to
1.109 +use the identifier in the above example together with <code>config_template.xhtml</code>, we would have to ensure that the identifier appeared as a value of an <code>id</code>
1.110 +node in that template document. Note that the choice of template
1.111 +document is not defined here, but is instead made when handling an
1.112 +in-page update request.</p><h2>Examining the Form Data</h2><p>The form data is available through the <code>form</code> object which exposes the <code><a href="../apidocs/public/XSLForms.Fields.Form-class.html">XSLForms.Fields.Form</a></code> API. The most interesting operations are as follows:</p><h3>Obtain the Form Data Documents</h3><p>Since
1.113 +XSLForms is an XML-based toolkit, the form data is available as XML
1.114 +documents which can be accessed and manipulated using a DOM-style API.
1.115 +Upon receiving submitted form data, XSLForms converts the data to such
1.116 +documents and then makes it available through the <code>form</code>
1.117 +object by associating certain document names with the actual documents
1.118 +themselves in a dictionary; this dictionary can be obtained as follows:</p><pre>documents = form.get_documents()</pre><p>Imagine that a template document has been written with <code>items</code> as the root (or topmost) element; such a document will consequently be made available via the <code>form</code> object's documents dictionary using the name <code>items</code>, and can be accessed as follows:</p><pre>items = documents["items"]</pre><p>However,
1.119 +it may be the case that no form data has been submitted. To avoid
1.120 +causing an exception, we should really test for the presence of such a
1.121 +document first:</p><pre>if documents.has_key("items"):<br /> items = documents["items"]</pre><p>Since
1.122 +it is likely that we will want to work with such a document regardless
1.123 +of whether one existed before - we must after all prepare such a
1.124 +document in the first place in order to show it to the user and have it
1.125 +submitted back to us - we really want to create it if it does not exist:</p><pre>if documents.has_key("items"):<br /> items = documents["items"]<br />else:<br /> items = form.new_document("items")</pre><p>The resulting <code>items</code> object is a genuine DOM-style document containing the form data.</p><h3>Obtain the Form Data Selectors</h3><p>As described in the <a href="selectors.html">"Creating Applications: Add Selectors"</a>
1.126 +document, XSLForms templates may define selectors - special form fields
1.127 +which select parts of the form data documents and make those parts
1.128 +available to applications; such selector information can be obtained as
1.129 +follows:</p><pre>selectors = form.get_selectors()</pre><p>If a selector was defined with the name <code>remove</code>, then any selected elements that are associated with this selector may be obtained as follows:</p><pre>removed_elements = selectors.get("remove") # which will return None if no such selector was defined</pre><p>Since
1.130 +the collection contains DOM-style elements, various XML libraries and
1.131 +tools may be used to manipulate the data. However, XSLForms also
1.132 +provides convenience functions to add and remove elements.</p><h3>Obtaining Other Parameters</h3><p>Sometimes,
1.133 +there is a need to obtain the "raw" request parameters submitted by the
1.134 +Web client or browser which sent the form data in to the application.
1.135 +Such parameters could be obtained using the <code>trans</code> object, but it is also possible to use the following approach:</p><pre>parameters = form.get_parameters()<br />some_parameter = parameters.get("something") # which returns None if no such parameter exists; a list otherwise<br />another_parameter = parameters.get("another", [""])[0] # which will always return a string, empty if no such parameter was found</pre><h2>Performing Additional Processing</h2><p>To take advantage of the defined <code>transform_resources</code>, we can call a method on the resource itself to prepare such resources:</p><pre>filter_stylesheets = self.prepare_transform("filter")</pre><p>Then,
1.136 +with the result of this call (a list of stylesheet filenames), we can
1.137 +then perform a transformation on a document, producing a new document
1.138 +from the results:</p><pre>configuration_document = self.get_result(filter_stylesheets, configuration_document)</pre><p>This new document is different from the document supplied to the <code>get_result</code>
1.139 +method. It should therefore be noted that any references to elements in
1.140 +the old document will not affect the new document; thus selectors
1.141 +previously obtained from the <code>form</code> object will not refer to elements in the new document. However, by setting the new document in the <code>form</code> object, new selectors may be obtained referring to elements in the new document:</p><pre>form.set_document("configuration", configuration_document)<br />selectors = form.get_selectors()</pre><p>Care
1.142 +must be taken doing this, however, since the selectors may now not
1.143 +refer to valid elements - the transformation may have removed or moved
1.144 +elements previously referred to by the selectors.</p><p>The <code>get_result</code>
1.145 +method also supports stylesheet parameters, document references and
1.146 +stylesheet expressions; these are described in the "Additional
1.147 +Stylesheet Parameters" section below.</p><h2>Document Initialisation</h2><p>The initialisation of a document, using information defined in the <code>init_resources</code>
1.148 +attribute, is similar to the transformation of a document as described
1.149 +above. First, we obtain a reference to an initialisation stylesheet:</p><pre>init_stylesheet = self.prepare_initialiser("configuration")</pre><p>Note
1.150 +that only a single stylesheet is returned. With the result of the call,
1.151 +we then perform a transformation similar to the above activity,
1.152 +although we have to supply the returned stylesheet in a list to be
1.153 +compatible with the <code>get_result</code> method:</p><pre>configuration_document = self.get_result([init_stylesheet], configuration_document)</pre><p>In practice, the above call will probably not suffice: if <a href="multiple.html">multiple-choice fields</a>
1.154 +are used in the template, there will be a need to initialise such
1.155 +elements using references to other documents containing the values of
1.156 +such fields; for example:</p><pre>configuration_document = self.get_result([init_stylesheet], configuration_document,<br /> references={<br /> "cpu" : self.prepare_document("cpu")<br /> })</pre><p>The
1.157 +use of document references and other stylesheet parameter information
1.158 +is described in the "Additional Stylesheet Parameters" section below.</p><h2>Preparing Responses</h2><p>The process of preparing a response involves three main steps:</p><ol><li>Setting a content type.</li><li>Defining an output stylesheet and parameter information.</li><li>Sending the output to the user.</li></ol><h3>Setting a Content Type</h3><p>In
1.159 +the examples supplied with XSLTools, the content type is generally
1.160 +defined as that of XHTML, meaning that the resulting output should be
1.161 +accessible to most modern Web browsers. When writing resources based
1.162 +on <code>XSLFormsResource</code>, we can just use the WebStack API to set the content type:</p><pre>trans.set_content_type(WebStack.Generic.ContentType("application/xhtml+xml", self.encoding))</pre><p>Note that the <code>encoding</code> attribute is used here to make the character encoding clear to the user's Web browser or client.</p><h3>Defining an Output Stylesheet</h3><p>In most cases, the output stylesheet can be chosen by selecting a template name and invoking a method on the resource:</p><pre>output_stylesheet = self.prepare_output("configuration")</pre><p>However,
1.163 +where in-page updates are handled, we may need to check to see if we
1.164 +should be sending a fragment of the whole page instead. First, we must
1.165 +check to see if an in-page update is being requested:</p><pre>in_page_resource = self.get_in_page_resource(trans)</pre><p>The
1.166 +result of calling the above method should be a string identifying an
1.167 +"in-page resource" - that is, a kind of in-page update related to part
1.168 +of the whole page - if such a "resource" is actually being
1.169 +requested. We can thus check to see if such a request is taking place:</p><pre>if in_page_resource in self.in_page_resources.keys():<br /> [Handle the in-page update request]</pre><p>If
1.170 +so, instead of getting a stylesheet which produces output for the whole
1.171 +page, we get a "fragment" which produces output only for the part of
1.172 +the page being updated:</p><pre> # Continued from above...<br /><br /> output_stylesheet = self.prepare_fragment("configuration", in_page_resource)<br /> stylesheet_parameters = self.prepare_parameters(parameters) # from form.get_parameters()</pre><p>An
1.173 +additional step when handling in-page updates is the usage of
1.174 +stylesheet parameters to send in some required information about the
1.175 +location of the update in the page. The <code>prepare_parameters</code>
1.176 +method on the resource is used to discover this information and return
1.177 +it as a dictionary to be passed to the final output generation activity.</p><h3>Sending the Output to the User</h3><p>Given
1.178 +an output stylesheet reference and possibly some parameters, the output
1.179 +is sent to the user with a single call to a method on the resource
1.180 +object:</p><pre>self.send_output(trans, [output_stylesheet], configuration_document, stylesheet_parameters)</pre><p>This method should, using the <code>encoding</code>
1.181 +attribute on the resource class, ensure that the generated output is
1.182 +correct and consistent for the user's Web browser or client.</p><h2>Additional Stylesheet Parameters</h2><p>In addition to a collection of stylesheets and a document to process, the <code>get_result</code> and <code>send_output</code> methods can accept a number of possible sources of information:</p><ul><li>Stylesheet parameters</li><li>Document references</li><li>Stylesheet expressions</li></ul><p>Generally,
1.183 +stylesheet parameters are used to configure the output in some way,
1.184 +whilst document references and stylesheet expressions typically offer a
1.185 +means of accessing additional information that is to be merged in or
1.186 +included in the processed document. The most common need to introduce
1.187 +additional information arises from the use of multiple-choice elements;
1.188 +consider the list of values given in the <a href="multiple.html">"Creating Applications: Adding Multiple-Choice Fields and Values"</a> document:</p><pre><?xml version="1.0"?><br /><type><br /> <type-enum value="(Not selected)"/><br /> <type-enum value="Important"/><br /> <type-enum value="Not important"/><br /> <type-enum value="Personal"/><br /></type></pre><p>Such
1.189 +information needs to reside somewhere and then be referenced in order
1.190 +to be included in the processing operation being performed, which would
1.191 +either be a document initialisation or just a normal transformation.</p><h3>Document References</h3><p>To refer to an externally-defined information, we define the document resource as described above:</p><pre> # At class attribute level...<br /><br /> document_resources = {<br /> "types" : "types.xml",<br /> # Other documents...<br /> }</pre><p>Then, we access the resource, getting a reference to the document:</p><pre>types_xml = self.prepare_document("types")</pre><p>To bring this document into the processing operation, we add an entry to a dictionary passed as the <code>references</code> parameter to <code>get_result</code> (or <code>send_output</code>, if appropriate). In the above example, the information is referenced as follows in the template document:</p><pre> <select template:multiple-choice-field="type,value" name="..."><br /> <option template:multiple-choice-value="type-enum,value,selected" value="..." /><br /> </select></pre><p>Therefore, we take the element name, <code>type</code>, from the field and use it to refer to the external document in the dictionary of references:</p><pre>structure = self.get_result([structure_xsl], structure, references={"type" : types_xml})</pre><p>This should result in the stylesheet incorporating the information from the types document into the transformation.</p><h3>Stylesheet Expressions</h3><p>In
1.192 +more advanced cases, referencing external documents does not provide
1.193 +enough flexibility when introducing additional information into a
1.194 +transformation. An alternative approach involves copying data into the
1.195 +document to be processed and then to supply references to the data in
1.196 +its new location within the document.</p></body></html>
1.197 \ No newline at end of file
2.1 --- a/docs/in-page-updates.html Sun Oct 09 00:46:35 2005 +0000
2.2 +++ b/docs/in-page-updates.html Sun Oct 09 00:47:30 2005 +0000
2.3 @@ -4,7 +4,6 @@
2.4
2.5 <title>Creating Applications: In-Page Updates</title><meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
2.6 <link href="styles.css" rel="stylesheet" type="text/css" /></head>
2.7 -
2.8 <body>
2.9 <h1>Creating Applications: In-Page Updates</h1>
2.10 <p>One fashionable avenue in Web application design has been that of
2.11 @@ -191,13 +190,11 @@
2.12 <pre> # Ensure the presence of a document.<br /><br /> if documents.has_key("structure"):<br /> structure = documents["structure"]<br /> else:<br /> structure = form.new_instance("structure")<br /><br /> # Add and remove elements according to the selectors found.<br /><br /> selectors = form.get_selectors()<br /> XSLForms.Utils.remove_elements(selectors.get("remove2"))<br /> XSLForms.Utils.add_elements(selectors.get("add2"), "subitem")<br /> XSLForms.Utils.remove_elements(selectors.get("remove"))<br /> XSLForms.Utils.add_elements(selectors.get("add"), "item")<br /><br /> # Initialise the document, adding enumerations/ranges.<br /><br /> structure_xsl = self.prepare_initialiser("structure")<br /> types_xml = self.prepare_document("types")<br /> structure = self.get_result([structure_xsl], structure, references={"type" : types_xml})<br /><br /> # Add the comments.<br /><br /> comments_xsl_list = self.prepare_transform("comments")<br /> structure = self.get_result(comments_xsl_list, structure)<br /></pre>
2.13 <p>The significant changes begin when presenting the result of the
2.14 request processing:</p>
2.15 -<pre> # Start the response.<br /><br /> trans.set_content_type(WebStack.Generic.ContentType("application/xhtml+xml", self.encoding))<br /><br /><span style="font-weight: bold;"> # Define the stylesheet parameters.</span><br style="font-weight: bold;" /><br style="font-weight: bold;" /><span style="font-weight: bold;"> stylesheet_parameters = {}</span><br style="font-weight: bold;" /><br style="font-weight: bold;" /><span style="font-weight: bold;"> # Ensure that an output stylesheet exists.</span><br style="font-weight: bold;" /><br style="font-weight: bold;" /><span style="font-weight: bold;"> if in_page_resource in self.in_page_resources.keys():</span><br style="font-weight: bold;" /><span style="font-weight: bold;"> trans_xsl = self.prepare_fragment("structure", in_page_resource)</span><br style="font-weight: bold;" /><span style="font-weight: bold;"> element_path = parameters.get("element-path", [""])[0]</span><br style="font-weight: bold;" /><span style="font-weight: bold;"> stylesheet_parameters["element-path"] = element_path</span><br style="font-weight: bold;" /><span style="font-weight: bold;"> else:</span><br style="font-weight: bold;" /><span style="font-weight: bold;"> trans_xsl = self.prepare_output("structure")</span></pre>
2.16 +<pre> # Start the response.<br /><br /> trans.set_content_type(WebStack.Generic.ContentType("application/xhtml+xml", self.encoding))<br /><br /><span style="font-weight: bold;"></span><span style="font-weight: bold;"> # Ensure that an output stylesheet exists.</span><br style="font-weight: bold;" /><br style="font-weight: bold;" /><span style="font-weight: bold;"> if in_page_resource in self.in_page_resources.keys():</span><br style="font-weight: bold;" /><span style="font-weight: bold;"> trans_xsl = self.prepare_fragment("structure", in_page_resource)</span><span style="font-weight: bold;"></span><br style="font-weight: bold;" /><span style="font-weight: bold;"> stylesheet_parameters = self.prepare_parameters(parameters)</span><br style="font-weight: bold;" /><span style="font-weight: bold;"> else:</span><br style="font-weight: bold;" /><span style="font-weight: bold;"> trans_xsl = self.prepare_output("structure")<br /></span> <span style="font-weight: bold;"></span><span style="font-weight: bold;"> stylesheet_parameters = {}</span></pre>
2.17 <p>Instead of just obtaining a stylesheet for the <code>structure</code>
2.18 document, we instead check to see if an in-page update is being
2.19 requested and, if so, prepare the stylesheet representing the fragment
2.20 -of the Web form to be presented. Additionally, we obtain a special <code>element-path</code>
2.21 -parameter directly from the request parameters; this parameter is added
2.22 -to a collection of parameters that will be used to control the
2.23 +of the Web form to be presented. Additionally, we obtain special stylesheet parameters using the raw request parameters; this introduces information that will be used to control the
2.24 stylesheet when making the final Web page output.</p>
2.25 <p>Finally, we send the output to the user but employing the additional
2.26 stylesheet parameters to configure the result:</p>