Thread: Re: Application using PostgreSQL as a back end (experien

I've been doing web apps for about 8 years now and just to add to some of
what William said.

One of the key benefits of a web app is that as long as you stick with W3
compliance, your web app will work on any browser/OS.

Also you can't beat the ease of maintenance with a web app.  When you need
to make fundamental changes to your app, you don't need to push out an
install to the user, you only need to worry about the server.  Which is just
an immense savings in terms of user maintenance.

On another note.  AJAX has made the responsiveness of the web interface more
comperable with a desktop app. There is a point of overdoing AJAX though
where you need to be careful.  For example there is a lot you can do with
plain old javascript and DHTML (e.g. writing tables on the screen, drag and
drop which don't require a trip back to the server to get data).  If your
dataset is for example small - it would be pointless to query back to the
server for every keystroke.  A simple javascript autofill drop down list
will do.  In those cases you would just use javascript and DHTML.

Generation of web apps has also become much simpler than it was way back
when I started.  A lot of toolkits exist out there that do all the messy
javascript, AJAX stuff for you.  For example PHP has PHPSmarty with built in
validators, html boxes etc. , SAJAX which compartmentalizes a lot of the
wizardry of these technologies for very common repetitive tasks.  ASP.NET
has AJAX.net, atlas, tons of commercial and free controls etc.





-----Original Message-----
From: William Yu [mailto:wyu@talisys.com]
Sent: Wednesday, November 16, 2005 11:03 AM
To: pgsql-novice@postgresql.org
Subject: Re: [NOVICE] Application using PostgreSQL as a back end
(experienced programmers


Bill Dika wrote:
> Furthermore, I think that if it did use a web interface, it would not
> be
> nearly as responsive as it is. That is why I was thinking of not using a
> browser. I use SQL-Ledger for my own bookkeeping. It is written in Perl,
> uses PostgreSQL as a backend and a browser for a front end. While I like
> the program very much and enjoy the freedom of using it as compared to
> something like say, Quickbooks, there is a noticeable delay when loading
> a form. This delay seems to be much less in stand alone programs that do
> not use a browser. Or am I wrong about this? In any case your

Basically, the issue with web-based is more of a perception/workflow
problem than performance. Everything is submit->server does
stuff->return results. While you can sprinkle a little Javascript to
make the UI more responsive, using too much Javascript tends to make
your programs hard to maintain.

At least that is how it was before. Now with AJAX, you can background
submit data the moment your user clicks/types something and while
they're still doing their data entry, the server is already processing
their work to either return results faster or update the screen realtime.

A good example of this is comparing Mapquest to Google maps. Mapquest
uses the old paradigm. You click on a map, the mapquest server
resizes/zooms/whatever and creates a new gif for you to download. Google
maps on the otherhand is constantly generating new data while you
navigate allowing what appears a "windows-like" interface.

You definitely have to do much better planning to write AJAX web apps
though. I'm still learning the nuances myself -- trying to figure out
where's the best place to use it in my web apps. I.e. don't go overboard
immediately and try to implement it everywhere. Just use it where the
user perceives UI delays.

Of course, there's the idea of not bothering with AJAX and just living
with the perceived delays. It ends up not being a big deal because (1)
users expect such delays on the web and (2) users get used to such
delays on the web. It was a bit of a concern when we developed our
insurance app as 100% web-based -- users accustomed to switching to
different pages of info instantaneously going to 1 second just for the
browser/submit/return latency. But it ended up being not an issue. Users
adapt, especially if you take advantage of what web apps can do. For
example, use linking so users can go from a page of info/form entry to
multiple ones to either lookup reference info or fill out data needed
beforehand. Users appreciate slower single-click functionality versus an
extremely responsive UI that requires multiple clicks to get into
different areas and back.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

--- "Obe, Regina     DND\\MIS"
<robe.dnd@cityofboston.gov> wrote:

> One of the key benefits of a web app is that as long
> as you stick with W3
> compliance, your web app will work on any
> browser/OS.

i wanted to add that is not my experience.  there are
so many hacks required to achieve cross browser
compatibility it is AMAZING.

i've literally burned weeks of time getting my
html/css right - and just spent a few days reqriting
my entire html/css infrastructure b/c ie doesn't
support the w3c standard of min-width.  i could hack
it, but then ie broke other parts of the site...
hence the total rewrite.

in fact, if i had to list the most difficult thing
i've faced in web based database development to date,
cross browser html/css compatibility is #1 on my list.
 using cygwin to install pgsql 7.4.x when i first
started (total newbie) is a close second...  after
that, nothing is even close.

after blowing 60+ hours fighting numerous cross
browser compatibility issues, i think i finally have a
template that is sufficient to display what i want in
firefox, ie and opera.  konquerer still doesn't play
nice.  i don't know if mac's broser displays it fine,
although it likely does.

the #1 problem, by far, is that not all browsers
support w3c specifications...  ie being the worst.

at least in my experience.




__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

On Thu, November 17, 2005 2:06 pm, operationsengineer1@yahoo.com said:
> --- "Obe, Regina     DND\\MIS"
> <robe.dnd@cityofboston.gov> wrote:
>
>> One of the key benefits of a web app is that as long
>> as you stick with W3
>> compliance, your web app will work on any
>> browser/OS.
>
> i wanted to add that is not my experience.  there are
> so many hacks required to achieve cross browser
> compatibility it is AMAZING.

I just wanted to but in that I've done enough web development to have had
both experiences.

In general I've found that if you don't mind a little bit 'loose'
structure it is quite easy.  The tighter your tolerances for placement,
the harder it gets.

(Then of course there are things that just aren't possible on one browser
or another.)

> the #1 problem, by far, is that not all browsers
> support w3c specifications...  ie being the worst.
>
> at least in my experience.

True that.  ;)  The next version of IE is apparently *much* improved in
that regard, so in five-ten years when it has replaced enough of the
current browsers we'll be in good shape.

To the original poster: While you could do this in a web interface (and,
as I said, Ruby on Rails looks great for trying it...), I'd suggest you
not, unless you really are thinking of this as a client-server model, with
mutiple clients using it at the same time.

Daniel T. Staal

---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------

operationsengineer1@yahoo.com wrote:
> i've literally burned weeks of time getting my
> html/css right - and just spent a few days reqriting
> my entire html/css infrastructure b/c ie doesn't
> support the w3c standard of min-width.  i could hack
> it, but then ie broke other parts of the site...
> hence the total rewrite.

Heh, I actually get great cross-browser compatibility by ignoring CSS
for everything except final output type documents. (I.e. stuff that
actually has to be printed out and mailed.)

This means using tables inside of tables, repetitive formatting tags and
other prehistoric techniques. The HTML ends up being much bloated but
then I turn on gzip encoding so the impact isn't that big. I also avoid
too much formatting because I believe in letting the user choose
whatever font type/size he's comfortable with.

This means the stuff not only works in todays browser but also looks the
same in freaking Netscape 4. Although I no longer test in Netscape 4. :)
I know my pages used to work a few years ago but with almost no users on
NS4 nowadays, it's not worth the effort to check new features.

On Thu, November 17, 2005 3:49 pm, William Yu said:

> This means using tables inside of tables, repetitive formatting tags and
> other prehistoric techniques. The HTML ends up being much bloated but
> then I turn on gzip encoding so the impact isn't that big. I also avoid
> too much formatting because I believe in letting the user choose
> whatever font type/size he's comfortable with.

The biggest problem with pages like that isn't the size: it is the
maintenance.  A large CSS site can be redesigned by changing one file, but
using old-style formatting you'll end up having to change every page.
(And hope you don't make a mistake, or forget one.)

Still, they are nice if you only need a few pages.

But this isn't a webdesign list.  ;)

Daniel T. Staal

---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------

Daniel T. Staal wrote:
> On Thu, November 17, 2005 3:49 pm, William Yu said:
>
>
>>This means using tables inside of tables, repetitive formatting tags and
>>other prehistoric techniques. The HTML ends up being much bloated but
>>then I turn on gzip encoding so the impact isn't that big. I also avoid
>>too much formatting because I believe in letting the user choose
>>whatever font type/size he's comfortable with.
>
>
> The biggest problem with pages like that isn't the size: it is the
> maintenance.  A large CSS site can be redesigned by changing one file, but
> using old-style formatting you'll end up having to change every page.
> (And hope you don't make a mistake, or forget one.)
>
> Still, they are nice if you only need a few pages.
>
> But this isn't a webdesign list.  ;)

I'll clarify more in terms of relevance to developing webapps using
PostgreSQL. I readily use CSS and/or server-side includes for static web
pages. It's a no brainer for HTML maintained by hand.

But for dynamically-generated websites, I stick with old-school HTML.
While the final output source looks ugly, the code itself is just a
series of variables defining the various look & feel aspects + overrides
of those variables based on who's viewing the page and what they're
viewing. Maintenance is roughly the same as with CSS -- alter a single
client_ABC_config.pl that contains all the look & feel variables (versus
altering a single client_ABC_config.css with all the element properties).