|
|
Posted by ^reaper^ on 10/14/78 11:23
While sipping absinthe, Onideus Mad Hatter heard a loud sucking noise
coming from alt.2600, and hastily inscribed the following unintelligible
Sanskrit in <news:v61ef1hklf65uralcpef1m2gd7rmb5jtvo@4ax.com>:
> On Sun, 7 Aug 2005 03:20:35 -0700, "^reaper^" <knocking@deaths.door>
> wrote:
>
>>Btw, I note you're using multiple divs as fillers. For those elements that
>>won't change (e.g., lines, etc), why not set the graphics to a background
>>on teh div, and set the background-repeat to repeat-x or repeat-y? You
>>should be able to accomp the same effect, with less overhead on the client.
>
> Because of a significant increase in page rendering times. It's
> especially noticeable if you try and animate/change such a property.
Except that, you would only use a background image for the static pieces
(e.g., your container border, etc).
>>> As opposed to using this:
>>
>>[large doc write lits snecked]
>>
>>I detest document.writes but anyway... The code examples I psoted in the
>>other message creates doc objects. Once those are created, it's a matter of
>>appending them to the body (and they magically appear). Everything is
>>driven from the database (which contains such things as image names,
>>filetypes, id names, layout info, event info, etc. The obj creation files
>>are not completed, as I have some other things I need to finish in the next
>>few weeks. However, I figured the examples might give you some ideas, and
>>potentially save you some time in teh long run.
>
> I'll take a look at them and do some experimentation.
Heh. Well, it's finished (at least as much as I have time for atm). The
layout is wonky. But that's prolly cuz I screwed up the db data, as I used
a macro to lift the values from your code. Additionally, I mod'd your
functions (see hatterfns), to include preloading the images, thereby
cutting procs/time for the flyover/flipper bit. And finally, I decided to
go with your doc write proposal. Esp considering there is no need to do
clientside proc'ing when the thing is autogen'd serverside. Here are the
final results:
====================================================
Serverside
====================================================
http://www.spyderware.net/source/fix0red.css
http://www.spyderware.net/source/fix0red.js
http://www.spyderware.net/source/hattercss.inc
http://www.spyderware.net/source/hatterobjs.inc
http://www.spyderware.net/source/hatterfns.inc
http://www.spyderware.net/source/hatterdb.inc
Total Lines: 364
Total Size: 14K
mySql Data: 3K
Proc time: 4us
====================================================
Clientside (autogen'd files)
====================================================
http://www.spyderware.net/source/fix0redIEresult.js
http://www.spyderware.net/source/fix0redIEresult.css
Total Lines: 314
Total Size: 17K
Proc time: 1s (as opposed to your 12s)
Computes: 2% peak (as opposed to your 75% peak)
What the above figures do not account for are gen'ing the graphics on the
fly (assuming you're using the gd lib v simply serving up the images).
>>> As you can see, your method cuts the code by a significant factor,
>>> however the difference in loading times is about SEVEN SECONDS!
>>> o_O
>
>>Well, I'm not sure what you mean by 'my method'.
>
> Well, it was derived from a code example that you put up.
Not surprising. Though, iirc, the example I originally provided was for
straight-through proc'ing v the if-then-else scenario. Recall, when we
discussed the array bit, I pointed out that it works fine if you're simply
running through the array and assuming it's not too large.
>>Which is why (imho), it's better to go the db route. Even if you choose to
>>do the doc writes over the object creation (as in my examples), you can set
>>it up so the serverside creates your doc write statements on the fly from
>>the db. Though I would still suggest gen'ing the css and simply setting it
>>up so the result is:
>>
>>: document.write("<div id='menu0'><img src='0.png'></div>");
>>
>>with the corresponding css style in your gen'd css file(s)
>>
>>: #menu0 {position:absolute; left:55px; top:32px; width:156px; height:26px}
>>
>>Also, if you plan it carefully, you can set up this approach in a way that
>>you only need to gen the js / css files when the db changes.
>>
>>By saving your db data in, say a csv file, you can easily manip teh data
>>via ms excel or some other spreadsheet proggie, then simply upload it.
>
> ...how does that affect manipulation of style properties though? And
> again, is there a difference in speed?
(see above)
> I think overall I'm gonna have to do a lot more testing. You've got
> some real good ideas, but more often than not I usually find a lot of
> peoples good ideas only work with vanilla structures, when you start
> trying to do something outside of the box that's when an enormity of
> problems suddenly crop up.
The key, of course, is not to take teh code verbatim, rather consider the
ideas put forth and add your own touches to meet your particular goals. As
it stands, the examples I've provided involve quite a bit of acrobatics
(brute force v finesse). Or put another way, the example code is far from
robust. Even so, the end result is reduced clientside overhead and
increased maintainability/extensibility. Dep upon where you want to go with
your project, there are all sorts of things you can do. The question you'll
need to answer for yourself is whether you prefer writing repetive code v
intelligent agents that gen your code for you. ^_~
--
"When a person can no longer laugh at himself, it is time for others to
laugh at him." -- Thomas Szasz, The Second Sin, 1973
Navigation:
[Reply to this message]
|