|
|
Posted by Rik on 04/22/06 11:55
robert wrote:
>>>> yeah it's pretty sweet, but ultimately i'd be looking for html
>>>> output, as i will need to make links out of events, etc. it looks
>>>> like i might have to alter a class that produces images and
>>>> customize it.
>>> consider how
>>> many browsers there are to support, how differently they render even
>>> simple html...then, how difficult it will be to manage it all with
>>> html?
>>>
>>> it can be done...but have you thought of perhaps simply altering the
>>> php classes that produce image based charts and tie in html to those
>>> key functions you need...say, using image mapping and javascript?
>>
>> Euhm.... saying HTML is rendered very differently on browsers and
>> then advising javascript? That's even more of a gamble in different
>> browsers.
>
> euhm's aside. the js is most likely going to handle a non-complex
> function like an onclick event. now that's vs. generating an entire
> html based gannt chart with all of it's elements and pieces...while
> maintaining it's visual aspects, then has to still deliver it's
> functionality...and that, probably a js handled onclick event. now,
> would you like to add more sarcasm?
Server delivers HTML -> you''re absolutely sure what HTML arrives at the
client
Page relies heavily on js -> let's hope it works, and scripting is even
enabled...
>> I say: if it's possible in HTML, go for it. Semantically logical
>> information, and keeping images / client-side script to a minimum
>> increases accessability (?... pff english..) and reduces bandwith
>> and probably server load.
>
> sure it's possible...probably not the best route to go though. you do
> realize your arg. for not using client-side code here is that it
> reduces bandwidth and server load?
Main argument here was accessability, not server load.
> let me bring it home...if the
> client is doing less of the processing...there must be something else
> doing more of the processing...i think that would be the server. ;^)
> as for bandwidth, if the server is picking up the load (since you
> don't want the client to), then any extra functionality beyond
> initial delivery of content will mean another trip to the server to
> get it...hmmm...let's forget "semantically" and just stick to the
> "logical" arguments...perhaps then, you'll grasp it and realize your
> above statement is less than well thought out.
My statement was delivered somewhat poorly in this case, because I wanted to
stress a few general preferences in webpages:
1. If you want a functional element on you're webpage, and it doesn't have
to be an image, don't make it an image.
2. If you want dynamical functionality that can either be done server side
or client side, I'd prefer serverside: you're sure about the outcome, and
you'll have to do very little in browser-specific coding.
That's the point I was trying to make: it increases accessability
(cross-browser, even browsers for the visually impaired, plain-text browsers
etc.), and reliability: you're absolutely sure what HTML code is sent to the
client, which is semantically sound.
Yes, it's clear I have no fondness for js, every time I'm forced to use it I
feel a little bit sad.....
> now if you can think outside of the "i'm smarter than you" mentality
> it seems you prefer,
Pardon? Maybe it's because English isn't my native language, but that wasn't
the way I intended to come across. I merely wanted to express my thorough
preference of complete HTML instead of js.
> you'd also know that image mapping doesn't have
> to be client-side and the server is fully capable of handling as much
> of this as you want it too.
I'm convinced that functionality shouldn't be in/behind/whatever images. You
can make it look like it by css, but everything on a website should work
with images disabled. Css is a wonderful method to make give it a nice
layout, in combination with logical HTML layout it makes a great page.
> if you're worried that js won't work in a
> browser...just have the server process it. either way, you can't say
> "have the client process this to reduce server load" and in the same
> breath say "client side processing is a bad idea".
Which reading back could be interpreted as such. Creating dynamical images
on server (unless they're cached in some way) is also a big server load.
"have the client process this to reduce server load" is something I'd rarely
say: For the client to process things it would have to get the information
from the server anyway, and I'd be curious what heavy load processing you'd
intended js to do. A few simple calculations while sending the information
wouldn't increase serverload that much, and I'm convinced complex processes
have no place in javascript.
> what i'm saying is
> that you can choose a simple solution without having to completely
> start from scratch...and it's flexible enough to work in more than
> one fashion.
Commercially correct, technically I have my doubts.
> aside from your patronization attempts, why not make yourself useful
> and address the op...because surely out of all your
> responses/criticisms, you must have more genius to display than "go
> for it".
Once again, I didn't mean to sound patronizing, I'm sorry. I have never
attempted to create Gantt-charts myself, so I'm not that much help in this
case. I applaud the op for wanting it in HTML though. And as far as I gather
he has a perfect solution now, with server sided code and plain HTML.
Still, I believe the statement:"Use javascipt, because HTML rendering in
browsers is unreliable." is utterly wrong, even backwards. I'd say:"Use
HTML, because javascript processing in browsers is unreliable."
In this particular case, could you tell me how the solution the op was
looking for and the answer he got for outputting HTML would be better, and
more reliable in javascript?
Grtz,
--
Rik
Navigation:
[Reply to this message]
|