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.
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
