Re: Browser support

murthi wrote:
<snip>
> >
> > 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.

> 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.

> 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>
> I started with *** Pick in Sep '70.

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

> > 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 *** 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.

> 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

> 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/publications/essays/archives/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

.

Loading