Instructional Demo builder (was Re: renderer question)

[Antranig Basman]

On 26/04/2011 11:14, Cheetham, Anastasia wrote:
>
> Antranig et al.,
>
> I have pushed what I've been working on to the FLUID-4145 branch of my github repo. Hopefully, this will help you understand what I'm trying to accomplish, though all I have so far are sketches:
>
>      https://github.com/acheetham/infusion/tree/FLUID-4145
>
> The work is in the demos folder, in a subfolder called "instructional" (with tests in "tests/demo-tests").
>
> The file jQTest.js is my experimentation with the techniques used by jQuery for their demos. InstructionalDemo.js is the beginning of a proper RendererComponent.
>
> Some of the HTML files in the instructional subfolders are just older mock-ups. The main files are:
>    "html/inlineEdit-default.html" - an example of a working demo that would be used as the source material
>    "InstructionalDemoTemplate.html" - the template for the RendererComponent version
>
> The HTML files indemo-tests/html stand in for a page in the website that would be built from the source material.
>

Hi Anastasia - first off, I would say a big risk is that the code for our demos is not properly namespaced 
so that it can all coexist in the same global object. I have been leading a push for our test cases at least 
to get this way but it would require a big initiative and sweep to make sure that all of our demo code is 
written to the same standards as framework code. Until then, I think the best option is to load the demo 
code in an iframe or single dedicated document as we do now. I think there was some conversation in IRC 
today also, distinguishing between "snippet code" and "best practices" code for demos.

To answer your earlier question:

> And regarding my original question, so that I can understand the Renderer better: I know that simply inserting a
 > <script> tag into a page can result in the script being executed (that's how jQuery works their UI widget
 > demos, and I've replicated it with our demos). Is the Renderer deliberately doing something to avoid
> this?


The behaviour you describe here isn't reliable. As you say, inserting a <script> tag into a document *can* 
result in the script being executed, with the operative word being "can" :) Depending on the exact 
circumstances of injecting it, and the particular browser in question, it may or may not execute, or may 
execute at some later time. Consult our Fluid Engage codebase for our best research into dynamically 
executing scripts in a reliable way, as part of the component we called the "Screen Navigator".

Looking at the codebase, the renderer doesn't do anything particularly special to treat <script> blocks 
differently as part of the markup - it's just that the underlying injection behaviour can't be relied upon.

You could look at the jQuery.globalEval function - collect together the scripts and script blocks you 
require, separate from the markup, and send them to this function. It may work better than it did in the 
Fluid Engage days.