Browser support

#1

Thought this should be a new thread
"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

Quote:

murthi wrote:
"Tom deL" <ted (AT) blackflute (DOT) com> wrote in message
news:1122494165.330747.122120 (AT) g44g2000cwa (DOT) googlegroups.com...
Hi Dawn,

The number of hoops you
have to jump through just to support both IE and Firefox current
versions is a headache. Supporting other browsers and older versions
of these is an expense that might not be worth the benefits.

Can you give me an example of the sort of specs that require you to
use such bleeding edge technology that you intentionally reduce your
clients' target audience? In my experience, doing the 'fancy stuff'
on the server and using widely supported technology to deliver it to
as many browsers as possible has been the best approach.

And for the record, 'fancy stuff' isn't used here in the sense of
'Wohoo, I just got a Flash compiler', it is used more in the sense of
delivering meaningful and dynamic content.

Having dealt with browser delivered solutions for the past 4 years, I
absolutely agree with Dawn. It's not that you're using "bleeding edge
technology", it's just that you have to be acutely aware of the quirks of
the browsers. Just as you may inadvertently use LOOP WHILE READNEXT ID
FROM LIST DO... in UV BASIC (my all-time favorite extension) and thereby
make it non-compilable on most other Pick systems, it's easy to use
javascript or html syntax that may not work on, say, Firefox. Something
as simple as not using id='xx' *in addition to* name='xx' in tags causes
problems in non-IE browsers. Iframes may not work. Netscape uses layer
instead of div tags. Style sheet property references are different. Etc
etc. Of course, you could argue that a RAD is simple enough to fix for
these quirks, it's certainly simpler than hand coding.

It's good to know it isn't just me! When I was developing pages,
FireFox worked more often than IE for me, but every time I fixed a
problem with the IE version, FireFox would stop working. I take all of
my optimism about developing big-bang-for-the-buck s/w into these
adventures, but man-o-man it used to be easier to write quality
software -- I'm not even up to the data persistence part this time
around.

I think it's been mentioned before in this list that the way to go is (imsr)
active-x components that can be "packaged" with the html (wow do I need a
memory refresh). The problem is that I look at the probably 25 person-years
(being PC, still mostly a male world) in the web RAD I'm working with and,
frankly, it's still easier to continue to go the route we've been going.
Maybe it's my advanced years, but it seems every time I do something
"radical" rather than evolutionary, I get bitten badly. So I trudge along,
continuing with javascript (which I love-hate) and nothing else, unlike,
say, Tony G, who would advocate using the latest and greatest.

An example: we've tried using the (barely-documented) fso interface within
IE to transfer files (thereby making that module IE-specific). There is
apparently no way to transfer in binary as opposed to text, so you can't
transfer jpegs. Even escape() or replace() of "bad" characters does not work
So we've going to use a custom FSO to do this deed, which has been in the
works for months. I'm sure there's an open-source off-the-shelf component
that would work, but that still takes time and effort to research. And I'm
bad at that.

Another example: We have probably the best UI for related ("grid")
multivalues, where you can insert, delete, rotate, page etc; parts of the
grid can be popups with tabs within the popup (so you can get more fields);
you can call the server on any or all of these actions; you can select the
display and entry properties of each individual field etc. All this code, is
probably about 1000 lines of javascript, which isn't much. So do I want to
redo this in some Active X component? Hell, no! It's taken me 3 years to get
it right. But that's the basic inertia inherent in any complex system. It's
why there are still millions of Cobol programs. It works. Don't fix it.

Oh, and define "data persistence" and what your problem is?

Quote:

It always puts a smile on my face when you agree with me, Chandru. If
you look at what you guys did with the MultiValue query language (that
language with too many names, so we can't talk about it or market it
outside of the scope of a particular vendor), and you look at the
XQuery spec, the MV Query language is still impressive, roughly 40
years now since it was specified. Have you been working with PICK for
35 years now? Unless I have my facts wrong, that would make you the
single most experienced person in the PICK work, right?

Thanks, perhaps a dubious distinction. Dinosaurs, as my 7-year old would
say, did go extinct. But yes, I started with Dick Pick in Sep '70.

Quote:

Pick/MultiValue products still provide the most productive software
development environment of anything I've seen, but are challenged when
it comes to the web/UI, with as many solutions are there are
developers, it seems. Since AJAX doesn't restrict the database
options, it sure would be nice if pick/MV products could interface with
that strategy in a consistent way and compete with the LAMP/MySQL
approach. That would require an open source offering and perhaps a
common non-SQL API across products. Just thinking out loud.
--dawn

I would not agree with the "challenged..web/UI" part---I see that as solely
a lack of expertise among the Pick vendors who cannot, apparently,
collectively distinguish their UI from their you-know-what. Probably the
persistent (ha) influence of Dick who thought (way back when) that formatted
screens were a flash-in-the-pan, and scrolling (a-la Update processor) was
the way to go. It's pretty pathetic that no-one has come out with a usable
tool over, what, the last 15 years? And, given the right circumstances, it's
so easy. The hard part, of course, is convincing their developers that it's
usable. But that's marketing, an area I have no expertise in, and,
apparently, neither has any Pick vendor.

Finally, pardon my ignorance--what's AJAX?

Chandru Murthi

#2

murthi wrote:

Quote:

Finally, pardon my ignorance--what's AJAX?

"Asynchronous JavaScript and XML". See...

http://en.wikipedia.org/wiki/AJAX

Luke

#3

murthi wrote:
<snip>

Quote:

When I was developing pages,
FireFox worked more often than IE for me, but every time I fixed a
problem with the IE version, FireFox would stop working. I take all of
my optimism about developing big-bang-for-the-buck s/w into these
adventures, but man-o-man it used to be easier to write quality
software -- I'm not even up to the data persistence part this time
around.

I think it's been mentioned before in this list that the way to go is (imsr)
active-x components that can be "packaged" with the html (wow do I need a
memory refresh). The problem is that I look at the probably 25 person-years
(being PC, still mostly a male world) in the web RAD I'm working with and,
frankly, it's still easier to continue to go the route we've been going.
Maybe it's my advanced years, but it seems every time I do something
"radical" rather than evolutionary, I get bitten badly. So I trudge along,
continuing with javascript (which I love-hate) and nothing else, unlike,
say, Tony G, who would advocate using the latest and greatest.

I tell people that I like to use something old, something new,
something borrowed, something blue.

Quote:

An example: we've tried using the (barely-documented) fso interface within
IE to transfer files (thereby making that module IE-specific). There is
apparently no way to transfer in binary as opposed to text,

I haven't tried moving anything other than text. I shouldn't even guess
since I'm off my turf on this, but I would think you could use
SOAP-based web services and DIME (MIME without headers IIRC) types.

Quote:

so you can't
transfer jpegs. Even escape() or replace() of "bad" characters does not work
So we've going to use a custom FSO to do this deed, which has been in the
works for months. I'm sure there's an open-source off-the-shelf component
that would work, but that still takes time and effort to research. And I'm
bad at that.

Another example: We have probably the best UI for related ("grid")
multivalues, where you can insert, delete, rotate, page etc; parts of the
grid can be popups with tabs within the popup (so you can get more fields);
you can call the server on any or all of these actions; you can select the
display and entry properties of each individual field etc. All this code, is
probably about 1000 lines of javascript, which isn't much. So do I want to
redo this in some Active X component? Hell, no! It's taken me 3 years to get
it right. But that's the basic inertia inherent in any complex system. It's
why there are still millions of Cobol programs. It works. Don't fix it.

Oh, and define "data persistence" and what your problem is?

Just simple data storage, you know, like with PICK. Students will
learn MySQL anyway, so I'm not gonna. I really should use something
else since I have been advocating for data modeling using a PICK-like
data model or XML-data model ( that I sometimes call a di-graph or
functional data model). I've been noisy in my interest in retiring SQL
as a language.

So, what are my options? Here are some requirements I have for data
management for my web site and/or my AJAX+database framework:

1) Can be used without changing my ISP. My only current option if
hosted by my ISP: My SQL if I were to pay more to use it.
Possibilities: a) Use another ISP for the data store, such as
easyco.com and put U2 or some other database there. b) Work with my
ISP to have a virtual server so I can install a database there. c) Use
the file system of the web server platform (linux) rather than a dbms
and store data in xml files (lousy performance, but perhaps OK for
small amounts of data)

2) Open Source or Free. Not a drop-dead requirement but if I want
students to think it is worthwhile, it really has to be open source,
not just an educational license, or else have an open source
counter-part with the same API.

3) Fast, easy queries. I've been looking at XQuery, a dog of a spec,
but it is based on xpath which is reasonable. XQuery is positioning to
become the SQL for XML and non-SQL-DBMS tools. It should be easier for
these products to implement at least a subset of XQuery than for
SQL-DBMS's, it seems.
Although after listening to Adam Bosworth today, I might want to look
at RSS 2.0. I posted this link on cdt today too, but I really liked
his talk at
http://rdscon.vo.llnwd.net/o1/_downloads/itc/mp3/2005/
ITC.MySQL2005-AdamBosworth-2005.04.21.mp3

<snip>

Quote:

I started with Dick Pick in Sep '70.

Perhaps we should throw a 35th anniversary party for you?

Quote:

Pick/MultiValue products still provide the most productive software
development environment of anything I've seen, but are challenged when
it comes to the web/UI, with as many solutions are there are
developers, it seems. Since AJAX doesn't restrict the database
options, it sure would be nice if pick/MV products could interface with
that strategy in a consistent way and compete with the LAMP/MySQL
approach. That would require an open source offering and perhaps a
common non-SQL API across products. Just thinking out loud.
--dawn

I would not agree with the "challenged..web/UI" part---I see that as solely
a lack of expertise among the Pick vendors who cannot, apparently,
collectively distinguish their UI from their you-know-what. Probably the
persistent (ha) influence of Dick who thought (way back when) that formatted
screens were a flash-in-the-pan, and scrolling (a-la Update processor) was
the way to go.

I think Mark Pick showed me an update tool with D3 a couple of years
ago, but I don't recall whose tool it was. Is there a MV Query-like
tool for update that has been implemented by any pick vendors? The
XQuery update specification is rather mind-boggling IMO.

Quote:

It's pretty pathetic that no-one has come out with a usable
tool over, what, the last 15 years? And, given the right circumstances, it's
so easy. The hard part, of course, is convincing their developers that it's
usable. But that's marketing,

you still need a sweet solution to back up the marketing

Quote:

an area I have no expertise in, and,
apparently, neither has any Pick vendor.

Finally, pardon my ignorance--what's AJAX?
Asynchronous JavaScript + XML

It is probably close to what you have been doing with JavaScript if you
are using HttpRequest. It was named in February of this year at
http://www.adaptivepath.com/publicat...ves/000385.php
and the name took off. Google for these two words:

AJAX JavaScript

All of those pages were either created or modified in the last six
months. AJAX isn't anything new -- it is just that XMLHttpRequest is
coming of age to be supported by most browsers. Putting a name to it
was great marketing.

Google is the poster child for AJAX, even though it is not their term.
maps.google.com is considered AJAX, for example.

--dawn

#4

Thanks much, Luke, very enlightening.Well well, to think I've been using
this "technique" for over 3-1/2 years without knowing it! Maybe that
qualifies me as one of those who's willing to use "cutting-edge" technology
rather than a hammer?

But, being ever the critic: you have a dhtml page (which you don't have to
do anything special to create); you have javascript (a very straightforward,
non-compiled, free, in-browser language), and you marry the two--what's not
obvious about this? But bingo, now you're **AJAX-enabled**. No wonder I'm
not in marketing, I hate these overblown acronyms.
..
Chandru Murthi

"Luke Webber" <luke (AT) webber (DOT) com.au> wrote

Quote:

murthi wrote:

Finally, pardon my ignorance--what's AJAX?

"Asynchronous JavaScript and XML". See...

http://en.wikipedia.org/wiki/AJAX

Luke

#5

murthi wrote:

Quote:

Thanks much, Luke, very enlightening.Well well, to think I've been using
this "technique" for over 3-1/2 years without knowing it! Maybe that
qualifies me as one of those who's willing to use "cutting-edge" technology
rather than a hammer?

Are you actually using XML? Not me, though I've certainly used the
"asynchronous Javascript" side of the equation.

Quote:

But, being ever the critic: you have a dhtml page (which you don't have to
do anything special to create); you have javascript (a very straightforward,
non-compiled, free, in-browser language), and you marry the two--what's not
obvious about this? But bingo, now you're **AJAX-enabled**. No wonder I'm
not in marketing, I hate these overblown acronyms.
.

Me too. When I first saw "Ajax", I thought "Axis", which an
Apache-based, non-Javascript XML-RPC technology. Ho-hum. For me, it's
something of an insult to name such a clusterfsck after the legendary
hero of the Trojan Wars.

Luke

#6

"Luke Webber" <luke (AT) webber (DOT) com.au> wrote

Quote:

murthi wrote:
Thanks much, Luke, very enlightening.Well well, to think I've been using
this "technique" for over 3-1/2 years without knowing it! Maybe that
qualifies me as one of those who's willing to use "cutting-edge"
technology rather than a hammer?

Are you actually using XML? Not me, though I've certainly used the
"asynchronous Javascript" side of the equation.

No, a little poetic license. AJAX page says XML or dhtml.... C

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Browser support

comp.databases.pick comp.databases.pick

Browser support - 07-27-2005 , 07:32 PM

Re: Browser support - 07-27-2005 , 08:32 PM

Re: Browser support - 07-27-2005 , 10:25 PM

Re: Browser support - 07-28-2005 , 08:28 AM

Re: Browser support - 07-28-2005 , 06:16 PM

Re: Browser support - 07-29-2005 , 09:23 AM