On Thursday, March 20, 2003, at 07:59 AM, Raymond Irving wrote:
--- Benoit Marchant <[EMAIL PROTECTED]> wrote:
Hello,
First of all, that generateBlueprint(0 feature is
really cool and very
valuable !
I have some questions about the inline stuff.
We tried to avoid having to do an
insertInlineLayers() in the thread
round about inline layers, so I'm not sure what the
benefit is ?
I had orginally used insertAllchildren() with two new
params: asInline and ignoreInline which would look
like:
insertAllchildren(asInline,ignoreInline)
This however would cause me to add much overhead to
the existing insertAllChildren() function.
I later then deceided to use insertBluePrint(src),
insertAllChildrenAsBlueprints(src) or
insertInlineLayers(src);
The BluePrint usage is slightly different than a dynamic server side generation of divs. It help inline what dynapi generate to speed things up for static pages, right ?
My worries with the way insertInlineLayers is currently implemented is that it loops on all children of the document and consider each of them a "blueprint" client. If you happens to mix regular dynamic layers and layers using inline divs as child of the document and call insertInlineLayers, it would cause issues with the non inline children. So something must check within insertInlineLayers, as it loop on the children that a child is inline, before going on and do:
c.isInline=true;
c._noInlineValues=true;
DynElement._flagEvent(c,'precreate');
as a child might not be inlined at all. in insertAllChildren, there's a test to not process inline layers, the opposite should be checked in insertInlineLayers.
And again, I don't see the need for insertInlineLayers().
There's 1 benefit of using insertAllChildren() I see: with NS4 english version, the browser loose the encoding of the page after the document is done loading, so if your page is in SHIFT_JIS, and you layers contains Kanji text, you better have them generated in the document, otherwise, if you create them after, the encoding is lost and your text isn't right.
There's another finding I made and used with dynapi2 and IE, on the mac at least, is that if you create top layers in individual <script> blocks, and have the divs created there (I used a modified create()) then it looks like the browser is running different blocks in different threads as they are non related, and it really made a big difference in heavy pages.
But for inline layers, when the document receive create(), the inline layers will receive _createInline. So basically, if you add
this ._noInlineValues=true; along this.isInline = isInline;
to setID(id,isInline)
You get the same result without having to call insertInlineLayers(), and we should.
(everyone) Which method do you prefer?
Blueprints are similar to inline layers. The only
difference is that you don't have to set the id of the
layers. It uses the same id structure generated by
dynapi plus it does not _importInlineValues as they
already exist within the dynlayer objects.
One other advantage of blueprint is that it does not
require the user to alter there existing code. They
can design the pages as the normally would with
dynlayers, widgets, etc. When finsihed with the design
they can then generate a blueprint and use that
blueprint improve the page's loading time.
Blueprints are not meant for widget
designers/developers, it is meant for
application/webpage developers. It can however be used
to aid in the creation of widgets.
Plus the way it is, if you mixed inline layers and
non inline layers,
then it would lead to issues.
In insertInlineLayers:
what is the purpose of sending
DynElement._flagEvent(c,'precreate'); ?
Many widgets uses this flag to create last minute
values and objects just before the layers are created.
I had thought about removing it but I them decided
that it's will be of some use to other developers and
to some widgets.
I agree, my main concern is that if you do setHTML in your onprecreate, then you would have to test in each widget not to do this if you're inline, othewise you would end up with twice the same divs. I would prefer not to worry about that as a widget developer as it makes more things to think about. So the solution might be to add some code in setHTML to not do it precisely when a layer is inline, and is about to be inlineCreated.
And if want to invoke precreate event for inline layers, then it should be invoked from _createInline too.
what is the purpose of the
dynapi.frame.document.write ?
In my preliminary test I found out that <layers> are
much faster than <divs> when used inside ns4. So I
wanted a way to get the most out of ns4. for this
reason I added the src agrument to allow a user to
insert a javascript which would contain the necessary
codes for either ns4 or dom/ie browsers:
if(!dynapi.ua.ns4)
dynapi.document.insertInlineLayers('speedtest.dynlayer.inline-basic-blueprint_def.js');
else
dynapi.document.insertInlineLayers('speedtest.dynlayer.inline-basic-blueprint_ns4.js');
So in truth and in fact users can
generateBlueprints(true) for ns4 or dom/ie browsers,
save it to a javascript file and then use
insertInlineLayers() to load the script for the
specified browser.
So the javascript file would contains only a big string containing the html ?
Ok, that make sense.Then, I don't see a way to call _importInlineValues
later on if needed.
_importInlineValues is not used when blueprints are
created. The _noInlineValues property is set to true
for all child layers, thus bypassing the
_importInlineValues() function. We can however modify
insertInlineLayers() to bypass layers that already
have an inline is assign to them.
I have a question about keeping variables for
x,y,width etc ... past
creation in the dynlayers as these values are in the
dom anyway. Is it
because it is a fact that accessing this.x is faster
than
this.elm.style.offsetLeft ?
Yes
I think it might be better to take the route of
lazily mapping the
values, if there's really a benefit to map.
The 2 benefit I see is first speed, you don't pay
the price of
initializing values of layers that the user might
not use, and second
it's transparency to the developer.
And for the layers created by dynapi code, it
doesn't make a difference
since in that scenario, the variables would be
mapped anyway.
Then it means that we don't use this.elm anymore,
but this.getElm()
instead to ensure proper loading.
For example for the dom case :
p.getDoc=function() {
if(!this.doc) {
this.doc = this.parent.getDoc();
}
return this.doc;
}
p.getElm=function() {
if(!this.elm && this.id && this.isInline) {
this.elm = this.getDoc().getElementById(this.id);
}
return this.elm;
};
p.getCSS=function() {
if(!this.css) {
this.css = this.getElm().style;
}
return this.css;
};
p.getX=function() {
if(!this.x) {
this.x = this.getElm().offsetLeft;
}
return this.x||0
};
Well, I have tested the scripts without calling
DynLayer._assignElemnts() and it's of little or no
benifit at all. It's kinda like "6 of one" and
"half-dozen of the other". The code found in
dyndocument line 106 offers major improvements when
assigning the elms after the page loads, making it as
fast as if they were they where never assing. For
example we can assing hundreds of elm within a few
milliseconds.
AgreedSkipping the _importInlineValues part really does
speed thing up. So
what do we do ?
Based on a suggestion you've made some time ago I've
added an ignoreInlineValues() function to dynlayers,
but I guess we could add this to setID(), correct?
A shortcut method would be to do the following:Naahh, that should be transparent to you !
var lyr=new DynLayer(null,100,100,100,100,'blue');
lyr._noInlinevalues=true;
Benoit
--
Raymond Irving
Benoithttp://www24.brinkster.com/dyntools/next/dynapi3x.zip
On Monday, March 17, 2003, at 09:24 PM, Raymond
Irving wrote:
Hello Everyone,you're
I'm very happy to present to you the results of a
recent test I've done with a new inline feature I
called blueprint. The results are nothing but
fantastic:
IE (Basic) = 200 @ 250ms, average 180ms
IE (Deep_Nest) = 100 @ 180ms, average 140ms
How it works:
The trick is to have dynapi generate the entire
blueprint or inline layers for the application
going to load. To do this you'll have to use theit
dynapi.document.generateBlueprint() function. This
will display the inline layers inside the debugger
window. You must however remember to remove the
dynapi.document.generateBlueprint() and the debug
library once you're finshed.
Now that you have the inline code you can insert
into the document or a .js script. The next stepis to
use dynapi.document.insertInlineLayers() functionto
load the inline layers.
New/modified functions:
DynLayer._importInlineValues
DynLayer.prototype.ignoreInlineValues
dynapi.document.generateBlueprint
dynapi.document.insertInlineLayers
You can download the files here:
-------------------------------------------------------See the online examples here:
http://www24.brinkster.com/dyntools/next/examples/
speedtest.dynlayer.inline-basic.html
http://www24.brinkster.com/dyntools/next/examples/
speedtest.dynlayer.inline-basic-dom.html
http://www24.brinkster.com/dyntools/next/examples/
speedtest.dynlayer.inline-deep_nest-dom.htmllive on your desktop!
Any comments?
Benoit,
I hope this will solve the speed issue with inline
automation. Correct?
--
Raymond Irving
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness,
http://platinum.yahoo.com
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031enThis SF.net email is sponsored by:Crypto Challengeis now open!
Get cracking and register here for some mindboggling fun and
the chance of winning an Apple iPod:
http://www.mail-archive.com/[EMAIL PROTECTED]/_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.
Does your code think in ink? You could win a Tablet PC.
Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/
