[Proto-Scripty] Re: Appending a template evaluation to an HTML element.
As it turns out, I had to revise the program flow and, since the data
is available at the time I write the data for the innerHTML, I simply
incorporated it into the data with javascript as it is written. So
the result is nice and efficient, all html and no DOM.
I'm sure I'll wind up needing your tip anyway though. Thanks a lot.
On Aug 19, 12:12 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi,
Should the form elements of an innerHTML assignment be
addressable after its insertion?
Yes, but there are browser bugs around both forms and tables (mostly
but not entirely IE bugs). The good news is that Prototype includes
workarounds for them, so if you use Element#update rather than setting
innerHTML directly, you should be okay.
-- T.J. :-)
On Aug 18, 4:24 pm, ChrisH chris.hutch...@nthidta.org wrote:
I was using the innerHTML method to produce a table of forms. I had
to change to the DOM element method because I couldn't address the
form elements created by the innerHTML method and the whole purpose
was to be able to submit another ajax request with data from the
forms. Should the form elements of an innerHTML assignment be
addressable after its insertion? If so, how?
On Aug 17, 10:34 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi,
The original code:
$('vsNewUsers').update($('vsNewUsers').innerHTML +
tmpl_NewUser.evaluate({NewUserID : --i_NewUserID}));
...will require the browser to spin through the tree inside vsNewUsers
and create an equivalent HTML string to give you; then tear down that
tree, parse the HTML you give it back (including re-parsing the stuff
it just gave you), re-instantiate a lot of elements that look exactly
the same as the previous one (plus the new ones at the end), re-
calculate the layout of the previous elements (and then the additional
ones), etc. (Layout can be expensive with tables, too, so...)
Seems like unnecessary work. :-) Granted the browser's going to do it
really fast, but still. Also, you'd lose any event handlers you'd
hooked up to the elements in there and any other data you may have
stored on them. If your user is using IE, any elements that
Prototype's already extended will have to be re-extended (which takes
non-trivial time on big tables).
Fortunately, Element#insert[1] is for exactly this situation:
$('vsNewUsers').insert({
bottom: tmpl_NewUser.evaluate({NewUserID : --i_NewUserID})
});
[1]http://api.prototypejs.org/dom/element/insert/
Vis-a-vis using `new Element` rather than HTML: Parsing HTML and
showing the result on the page is fundamentally what browsers do, and
they do it really, _really_ fast. When rendering HTML, they can work
directly with their internal structures. When you use the DOM API, you
lose that benefit and have to work through the browser's DOM API -
internal structures mapping. And you're doing all of your work in an
interpreted (or at least compiled-on-the-fly) language.
Net result? Markedly slower -- like an order of magnitude -- to go
through the DOM API vs. using HTML. This isn't a Prototype thing at
all, it's just the nature of browsers and what they're optimized for.
I actually did a test page (not much of one) a little over a year back
when answering a question for someone that showed this in action, and
through the wonder that is 'net search:http://pastie.org/521342
HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / comwww.crowdersoftware.com
On Aug 17, 2:09 pm, Phil Petree phil.pet...@gmail.com wrote:
I would think that Creating elements is less limiting... but I have no
idea
what most developers do.
On Tue, Aug 17, 2010 at 8:29 AM, Richard Quadling
rquadl...@gmail.comwrote:
On 17 August 2010 12:59, Phil Petree phil.pet...@gmail.com wrote:
===
HTML save as index.html:
html
head
script src=prototype.js/script
/head
body
form id=myform
table id=keytable
trtdKeyword/tdtdinput type=text
name=keyword_1/td/tr
/table
/form
input type=button onclick=addkeyword() value=Add Keyword
input type=button onclick=dosubmit() value=Submit
div id=result style=padding:5px;
/div
script
var nextkeyid = 2;
function addkeyword()
{
var elTR = $('keytable').insertRow( -1 );
var elTitleTD = elTR.insertCell( -1 );
elTitleTD.appendChild( document.createTextNode( 'Keyword' ) );
var elInput = document.createElement( 'input' );
elInput.type = 'text';
elInput.name = 'keyword_'+nextkeyid;
nextkeyid++;
var elInputTD = elTR.insertCell( -1 );
elInputTD.appendChild( elInput );
}
function dosubmit( ) {
new Ajax.Updater( 'result', 'add.php', { method: 'post',
[Proto-Scripty] Re: Appending a template evaluation to an HTML element.
I was using the innerHTML method to produce a table of forms. I had
to change to the DOM element method because I couldn't address the
form elements created by the innerHTML method and the whole purpose
was to be able to submit another ajax request with data from the
forms. Should the form elements of an innerHTML assignment be
addressable after its insertion? If so, how?
On Aug 17, 10:34 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi,
The original code:
$('vsNewUsers').update($('vsNewUsers').innerHTML +
tmpl_NewUser.evaluate({NewUserID : --i_NewUserID}));
...will require the browser to spin through the tree inside vsNewUsers
and create an equivalent HTML string to give you; then tear down that
tree, parse the HTML you give it back (including re-parsing the stuff
it just gave you), re-instantiate a lot of elements that look exactly
the same as the previous one (plus the new ones at the end), re-
calculate the layout of the previous elements (and then the additional
ones), etc. (Layout can be expensive with tables, too, so...)
Seems like unnecessary work. :-) Granted the browser's going to do it
really fast, but still. Also, you'd lose any event handlers you'd
hooked up to the elements in there and any other data you may have
stored on them. If your user is using IE, any elements that
Prototype's already extended will have to be re-extended (which takes
non-trivial time on big tables).
Fortunately, Element#insert[1] is for exactly this situation:
$('vsNewUsers').insert({
bottom: tmpl_NewUser.evaluate({NewUserID : --i_NewUserID})
});
[1]http://api.prototypejs.org/dom/element/insert/
Vis-a-vis using `new Element` rather than HTML: Parsing HTML and
showing the result on the page is fundamentally what browsers do, and
they do it really, _really_ fast. When rendering HTML, they can work
directly with their internal structures. When you use the DOM API, you
lose that benefit and have to work through the browser's DOM API -
internal structures mapping. And you're doing all of your work in an
interpreted (or at least compiled-on-the-fly) language.
Net result? Markedly slower -- like an order of magnitude -- to go
through the DOM API vs. using HTML. This isn't a Prototype thing at
all, it's just the nature of browsers and what they're optimized for.
I actually did a test page (not much of one) a little over a year back
when answering a question for someone that showed this in action, and
through the wonder that is 'net search:http://pastie.org/521342
HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / comwww.crowdersoftware.com
On Aug 17, 2:09 pm, Phil Petree phil.pet...@gmail.com wrote:
I would think that Creating elements is less limiting... but I have no idea
what most developers do.
On Tue, Aug 17, 2010 at 8:29 AM, Richard Quadling
rquadl...@gmail.comwrote:
On 17 August 2010 12:59, Phil Petree phil.pet...@gmail.com wrote:
===
HTML save as index.html:
html
head
script src=prototype.js/script
/head
body
form id=myform
table id=keytable
trtdKeyword/tdtdinput type=text name=keyword_1/td/tr
/table
/form
input type=button onclick=addkeyword() value=Add Keyword
input type=button onclick=dosubmit() value=Submit
div id=result style=padding:5px;
/div
script
var nextkeyid = 2;
function addkeyword()
{
var elTR = $('keytable').insertRow( -1 );
var elTitleTD = elTR.insertCell( -1 );
elTitleTD.appendChild( document.createTextNode( 'Keyword' ) );
var elInput = document.createElement( 'input' );
elInput.type = 'text';
elInput.name = 'keyword_'+nextkeyid;
nextkeyid++;
var elInputTD = elTR.insertCell( -1 );
elInputTD.appendChild( elInput );
}
function dosubmit( ) {
new Ajax.Updater( 'result', 'add.php', { method: 'post', parameters:
$('myform').serialize() } );
}
/script
/body
/html
===
Serverside PHP save as add.php:
Post Result:br/
?php var_export( $_POST ) ?
===
On Tue, Aug 17, 2010 at 7:30 AM, Richard Quadling rquadl...@gmail.com
wrote:
On 17 August 2010 12:01, Phil Petree phil.pet...@gmail.com wrote:
That's in the expando example that comes with prototype.js 1.6x
On Tue, Aug 17, 2010 at 6:35 AM, Richard Quadling
rquadl...@gmail.com
wrote:
Hi.
I've implemented a simple add new user button to my amend users
page. The user list is only about 20 people, with
name/email/pin/contracts/delete options.
The button calls a template evaluation and that is within an update
...
$('vsNewUsers').update($('vsNewUsers').innerHTML +
tmpl_NewUser.evaluate({NewUserID : --i_NewUserID}));
All working fine.
[Proto-Scripty] Re: Appending a template evaluation to an HTML element.
Hi,
Should the form elements of an innerHTML assignment be
addressable after its insertion?
Yes, but there are browser bugs around both forms and tables (mostly
but not entirely IE bugs). The good news is that Prototype includes
workarounds for them, so if you use Element#update rather than setting
innerHTML directly, you should be okay.
-- T.J. :-)
On Aug 18, 4:24 pm, ChrisH chris.hutch...@nthidta.org wrote:
I was using the innerHTML method to produce a table of forms. I had
to change to the DOM element method because I couldn't address the
form elements created by the innerHTML method and the whole purpose
was to be able to submit another ajax request with data from the
forms. Should the form elements of an innerHTML assignment be
addressable after its insertion? If so, how?
On Aug 17, 10:34 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi,
The original code:
$('vsNewUsers').update($('vsNewUsers').innerHTML +
tmpl_NewUser.evaluate({NewUserID : --i_NewUserID}));
...will require the browser to spin through the tree inside vsNewUsers
and create an equivalent HTML string to give you; then tear down that
tree, parse the HTML you give it back (including re-parsing the stuff
it just gave you), re-instantiate a lot of elements that look exactly
the same as the previous one (plus the new ones at the end), re-
calculate the layout of the previous elements (and then the additional
ones), etc. (Layout can be expensive with tables, too, so...)
Seems like unnecessary work. :-) Granted the browser's going to do it
really fast, but still. Also, you'd lose any event handlers you'd
hooked up to the elements in there and any other data you may have
stored on them. If your user is using IE, any elements that
Prototype's already extended will have to be re-extended (which takes
non-trivial time on big tables).
Fortunately, Element#insert[1] is for exactly this situation:
$('vsNewUsers').insert({
bottom: tmpl_NewUser.evaluate({NewUserID : --i_NewUserID})
});
[1]http://api.prototypejs.org/dom/element/insert/
Vis-a-vis using `new Element` rather than HTML: Parsing HTML and
showing the result on the page is fundamentally what browsers do, and
they do it really, _really_ fast. When rendering HTML, they can work
directly with their internal structures. When you use the DOM API, you
lose that benefit and have to work through the browser's DOM API -
internal structures mapping. And you're doing all of your work in an
interpreted (or at least compiled-on-the-fly) language.
Net result? Markedly slower -- like an order of magnitude -- to go
through the DOM API vs. using HTML. This isn't a Prototype thing at
all, it's just the nature of browsers and what they're optimized for.
I actually did a test page (not much of one) a little over a year back
when answering a question for someone that showed this in action, and
through the wonder that is 'net search:http://pastie.org/521342
HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / comwww.crowdersoftware.com
On Aug 17, 2:09 pm, Phil Petree phil.pet...@gmail.com wrote:
I would think that Creating elements is less limiting... but I have no
idea
what most developers do.
On Tue, Aug 17, 2010 at 8:29 AM, Richard Quadling
rquadl...@gmail.comwrote:
On 17 August 2010 12:59, Phil Petree phil.pet...@gmail.com wrote:
===
HTML save as index.html:
html
head
script src=prototype.js/script
/head
body
form id=myform
table id=keytable
trtdKeyword/tdtdinput type=text
name=keyword_1/td/tr
/table
/form
input type=button onclick=addkeyword() value=Add Keyword
input type=button onclick=dosubmit() value=Submit
div id=result style=padding:5px;
/div
script
var nextkeyid = 2;
function addkeyword()
{
var elTR = $('keytable').insertRow( -1 );
var elTitleTD = elTR.insertCell( -1 );
elTitleTD.appendChild( document.createTextNode( 'Keyword' ) );
var elInput = document.createElement( 'input' );
elInput.type = 'text';
elInput.name = 'keyword_'+nextkeyid;
nextkeyid++;
var elInputTD = elTR.insertCell( -1 );
elInputTD.appendChild( elInput );
}
function dosubmit( ) {
new Ajax.Updater( 'result', 'add.php', { method: 'post', parameters:
$('myform').serialize() } );
}
/script
/body
/html
===
Serverside PHP save as add.php:
Post Result:br/
?php var_export( $_POST ) ?
===
On Tue, Aug 17, 2010 at 7:30 AM, Richard Quadling
rquadl...@gmail.com
wrote:
On 17 August 2010 12:01, Phil Petree phil.pet...@gmail.com wrote:
That's in the expando
Re: [Proto-Scripty] Re: Appending a template evaluation to an HTML element.
On 17 August 2010 16:34, T.J. Crowder t...@crowdersoftware.com wrote:
Hi,
The original code:
$('vsNewUsers').update($('vsNewUsers').innerHTML +
tmpl_NewUser.evaluate({NewUserID : --i_NewUserID}));
...will require the browser to spin through the tree inside vsNewUsers
and create an equivalent HTML string to give you; then tear down that
tree, parse the HTML you give it back (including re-parsing the stuff
it just gave you), re-instantiate a lot of elements that look exactly
the same as the previous one (plus the new ones at the end), re-
calculate the layout of the previous elements (and then the additional
ones), etc. (Layout can be expensive with tables, too, so...)
Seems like unnecessary work. :-) Granted the browser's going to do it
really fast, but still. Also, you'd lose any event handlers you'd
hooked up to the elements in there and any other data you may have
stored on them. If your user is using IE, any elements that
Prototype's already extended will have to be re-extended (which takes
non-trivial time on big tables).
Fortunately, Element#insert[1] is for exactly this situation:
$('vsNewUsers').insert({
bottom: tmpl_NewUser.evaluate({NewUserID : --i_NewUserID})
});
[1] http://api.prototypejs.org/dom/element/insert/
Vis-a-vis using `new Element` rather than HTML: Parsing HTML and
showing the result on the page is fundamentally what browsers do, and
they do it really, _really_ fast. When rendering HTML, they can work
directly with their internal structures. When you use the DOM API, you
lose that benefit and have to work through the browser's DOM API -
internal structures mapping. And you're doing all of your work in an
interpreted (or at least compiled-on-the-fly) language.
Net result? Markedly slower -- like an order of magnitude -- to go
through the DOM API vs. using HTML. This isn't a Prototype thing at
all, it's just the nature of browsers and what they're optimized for.
I actually did a test page (not much of one) a little over a year back
when answering a question for someone that showed this in action, and
through the wonder that is 'net search:
http://pastie.org/521342
HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com
On Aug 17, 2:09 pm, Phil Petree phil.pet...@gmail.com wrote:
I would think that Creating elements is less limiting... but I have no idea
what most developers do.
On Tue, Aug 17, 2010 at 8:29 AM, Richard Quadling rquadl...@gmail.comwrote:
On 17 August 2010 12:59, Phil Petree phil.pet...@gmail.com wrote:
===
HTML save as index.html:
html
head
script src=prototype.js/script
/head
body
form id=myform
table id=keytable
trtdKeyword/tdtdinput type=text name=keyword_1/td/tr
/table
/form
input type=button onclick=addkeyword() value=Add Keyword
input type=button onclick=dosubmit() value=Submit
div id=result style=padding:5px;
/div
script
var nextkeyid = 2;
function addkeyword()
{
var elTR = $('keytable').insertRow( -1 );
var elTitleTD = elTR.insertCell( -1 );
elTitleTD.appendChild( document.createTextNode( 'Keyword' ) );
var elInput = document.createElement( 'input' );
elInput.type = 'text';
elInput.name = 'keyword_'+nextkeyid;
nextkeyid++;
var elInputTD = elTR.insertCell( -1 );
elInputTD.appendChild( elInput );
}
function dosubmit( ) {
new Ajax.Updater( 'result', 'add.php', { method: 'post', parameters:
$('myform').serialize() } );
}
/script
/body
/html
===
Serverside PHP save as add.php:
Post Result:br/
?php var_export( $_POST ) ?
===
On Tue, Aug 17, 2010 at 7:30 AM, Richard Quadling rquadl...@gmail.com
wrote:
On 17 August 2010 12:01, Phil Petree phil.pet...@gmail.com wrote:
That's in the expando example that comes with prototype.js 1.6x
On Tue, Aug 17, 2010 at 6:35 AM, Richard Quadling
rquadl...@gmail.com
wrote:
Hi.
I've implemented a simple add new user button to my amend users
page. The user list is only about 20 people, with
name/email/pin/contracts/delete options.
The button calls a template evaluation and that is within an update
...
$('vsNewUsers').update($('vsNewUsers').innerHTML +
tmpl_NewUser.evaluate({NewUserID : --i_NewUserID}));
All working fine.
I like how it works, but I wonder how I can just append the result of
the evaluation.
How do I take a template and append the results to vsNewUsers.
vsNewUsers is a tbody element and the template is a tr element with
all the td's needed.
var tmpl_NewUser = new Template('trtdinput type=text
name=User[#{NewUserID}][Username] value= maxlength=200
size=50
//tdtdinput type=text
