Want to add a script or a project? Upload it and a half million people will see it and your name here this year.
|Viewer 2||DESCRIPTION: ::Bootstrapping_HTML_on_a_prim|
|Viewer 2||The browser will add scroll bars if the rendered HTML doesn't fit within the specified PRIM_MEDIA_* size.|
|Viewer 2||Tali Rosca made this code to render the output of HTTP-In directly. Kelly Linden wrapped her magic into the build_url and build_response functions in the example below. This example renders a page that is around 3.5k bytes - well past the 1k limit of urls. // Pros: // // * Navigation is much smoother and feels more natural // * Only limited by script memory // // Cons: // // * Links are extremely large: 296 bytes for a link to just the base http-in url.|
|Viewer 2||Method #1 — using CSS in a style element in|
|Viewer 2||Method #2 — using background attribute in|
|Viewer 2||Method #3 — using style attribute in|
|Viewer 2||Press enter to accept Project Name or type a new descriptionDisplay_plain_text__XyText_replacement|
|Viewer 2||The text of the data URI will be %-hex-escaped automatically for you, so there's no need to use llEscapeURL(). All you need in the data URI is the prefix data:text/html, plus your HTML.|
|Viewer 2||Example notecard, text copied from Wiki (http://en.wikipedia.org/wiki/Second_Life), adjusted to fit 255 characters per line, with some HTML tags added.|
// * 1024 bytes per url
// * llEscapeURLs means non-alphanumeric characters are 3 bytes (ouch)
// o I'm actually not clear on if this is really needed. I seem to sometimes get blank pages if I don't but some pages render fine with out it. Maybe there is a subset of symbols that must be escaped and escaping only those would ease some of the space constraints?
// * Must force another page view after form submission since HTTP-In can't generate HTML
// * No real way of knowing which avatar is interacting with the HTML
// The Tricks
|Viewer 2||This script puts the data in the URL, and can render the HTML tags from the notecard. Note, the URL limit is 1024 characters. This script below does not need HTTP-IN to work, and is much simpler.|
|Viewer 2||Notecard text I used to render the text in the image:|
Paste the below into your browser's address bar.
This is a test
This is a test
This is a test// // llSetPrimMediaParams for data: urls // // * Thus you can build arbitrary html in your LSL script and display it on the face of the prim
|Viewer 2||* Any URL or data URI can be mapped to a TinyURL. The example above reduces an assigned HTTP-in URL, which is a long one such as: // http://sim4605.agni.lindenlab.com:12046/cap/2b9f06f7-431e-5b0f-9271-2d03bd15370b // // into a TinyURL this size: // http://tinyurl.com/y9etul3|
|Viewer 2||For people who want to play with the Shared Media feature in LSL, I have developed a script that basically reads a Notecard and outputs the text on a side of a prim. It uses the new "llSetPrimMediaParams" function, plus HTTP-In. So its like a basic in-world mini web server! // // This script is only for demo purposes, so if things like the Region Restarts, the script would need to be reset to get a new HTTP-In URL. // // To set this up you need to do the following: // // * Rez a normal prim on the ground. // * Create a Notecard with some text and place it inside the prim. // * Create a New Script. // * Copy the code below and paste it into the New Script. // * Save and run. // * The web page will appear on Face 0, which on top of the prim. If you do not see the page, click on the top side and it will render. // * If you still do not see the page after a while, try setting the Texture > Media functionality on the top side of the prim. // * If you edit the notecard inside the prim, the script will re-read it, and refresh the URL. // // I added a "?rand=" (with time value) parameter to the URL so that it makes the prim think its a new page and refreshes. // // This new LL function is not officially released, so things may change on it. // // Shared Media does open up many possibilities.|
// sendMessage( "alert()" );
// # In the LSL listing above, the yellow highlighting shows the most important parts of the HTTP long-polling mechanism. The green highlighting shows the message buffering on top of that. The blue highlighting is the application code that uses long-polling. To use long-polling for a different application, replace the blue parts. The rest is glue.
// # To avoid some subtle WebKit problems when dynamically appending or replacing the first-level child nodes in or , we've made two special