[ Sorry, I meant to cc the fluid-work list on this thread, so I'm doing that now. ]
As a quick recap: On 2011-04-21, at 5:26 PM, Cheetham, Anastasia wrote: >> If I use a "UIVerbatim" component type to render a string that is actually >> markup, it works for me, generally (e.g. a <ul> will actually end up looking >> like a nice list, a <style> tag will actually result in styles being >> applied, etc.). >> >> However, if the verbatim string includes a <script> tag, the contained >> script doesn't seem to be executed. Should I expect it to be executed, or is >> what I'm seeing the correct behaviour? >> >> I know there is the "InitBlock" component type, but that seems to be >> intended for a single function. I have an actual short script, of unknown >> length (it will be different in different scenarios, of course). >> >> If the Verbatim component type can't be expected to result in the execution >> of my <script> tag, do you have any suggestions for how to accomplish my >> goal? On 2011-04-21, at 9:10 PM, Antranig Basman responded: > Hi, Anastasia - I think as our experience proved on Fluid Engage, trying to > dynamically inject scripts into > a page at the markup level is an unstable and hazardous process :) I would > recommend that you just load all > the scripts you require up front in the page header, and distinguish > dynamically between different > implementations using IoC resolution. Can you describe a bit more what > application you are working on, and > where the markup is coming from? Hi, Antranig, Thanks for your email, and I'm sorry for the delay in responding: I was home sick yesterday. The use case for this is the "instructional demos" that will be used in our documentation. The source code for the demos will live in the main code base (as with the showcase demos now), and we want some JS to pull the demos into the website pages. You can see a mock-up of what this will look like here: http://wiki.fluidproject.org/display/fluid/Infusion+documentation+redesign+%28April+2011%29#Infusiondocumentationredesign%28April2011%29-Demos%3AComponent%3AVariation One thing to note is that we're showing both a working demo as well as a viewable text version of the code/markup/css used for that demo. We want to create a component that will extract the code/markup/css from the demo in the main source tree and build the content of the docs page with it. Another thing to note in the mock-up is the navigational list on the sidebar. The plan is to have almost a one-to-one mapping between each integrator-configurable option of each component and the instructional demos: One demo per option. As you can imagine, this will be a lot of demos. I like your idea of loading all the scripts up-front and switching dynamically, but obviously the planned number of demos might be an issue. Because these demos are for instructional purposes, we want them to be as simple and succinct as possible. Each script should stand alone: it should not be a small part of a single large script that obfuscates what's going on with the actual option being demonstrated. Grouping the scripts by component (i.e. one JS file per component) could help alleviate the issues with the number of demos. The body of the docs page could be re-rendered based on the option that was selected in the sidebar: the option selection could adjust the IoC context appropriately, so that the correct script/markup/css blocks are selected and rendered... Does that sound feasible to you? Do you have any other thoughts? 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? -- Anastasia Cheetham Inclusive Design Research Centre [email protected] Inclusive Design Institute OCAD University _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
