Thread: web-based front end development
Hi. There is interest at work in doing some fairly simple inventory
control using a database. We've already got Postgres up and running
(for obvious reasons) and I was wondering if anyone had suggestions
for a good approach to app development for brower-based user
interfaces.
There are other applications which would be of interest, so something
with some growth potential would be helpful.
We have a bit of expertise in Java servlets, etc, so that is one
option via the jdbc interface.
Are there any options which are particularly "approachable" which
would allow newbies to get something working if they have some
existing code to look at?
TIA
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas - I'd suggest you have a look at the Zope system (www.zope.org). It's a through-the-web development environment, designed for ease of partitioning the development and maintanence of web-based apps. One could think of it as a cross of Cold Fusion and PHP on steroids. It's actively being developed in an Open Source way, with Digitial Creations, Inc. as lead developers (only fair, it's their code they donated to us all). The partitioning allows you to write the SQL parts (as ZSQL methods), and have someone else use them in a 'blackbox' fashion to design the app. using DTML, the Zope HTML scripting language. It's relatively easy to extend this to having 'content' people do just that, content. Not an HTML tag in sight (for them). At first glance, it may look a little heavyweight for 'simple' app., but we all know that those simple apps grow, and you never get a chance to rewrite from scratch untill you have too. Now the bad news. The current beta has lots of nice new features, but in the process of adding some of them (better concurrency, and a new implementation of their transaction system), all the database adaptors broke. They still work fine for the current stable, 1.10.2, however. It's just that there are major features (ZClasses, XML support) in the beta that could affect fundamental design decisions for any app you'd start now. I think it'd be a major win for both systems to have such a core member of the PostgreSQL development using Zope. Give me 'till Monday and I'll see if I can't get the ZPyGreSQLDA (ow, painful name!) working acceptably with Zope 2.0. (I need it anyway, even if you don't go with Zope) Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
On Thu, 29 Jul 1999, Thomas Lockhart wrote:
> Hi. There is interest at work in doing some fairly simple inventory
> control using a database. We've already got Postgres up and running
> (for obvious reasons) and I was wondering if anyone had suggestions
> for a good approach to app development for brower-based user
> interfaces.
>
> There are other applications which would be of interest, so something
> with some growth potential would be helpful.
>
> We have a bit of expertise in Java servlets, etc, so that is one
> option via the jdbc interface.
>
> Are there any options which are particularly "approachable" which
> would allow newbies to get something working if they have some
> existing code to look at?
Dmitry was working on something like that; I couldn't wait and wrote
one in C. His is in perl. Handles inventory, invoice printing (one at a
time on demand), special prices and a few other minor things. Probably
could use to be cleaned up some tho. This one runs with Apache, but one
day I'll probably rewrite it to use my micro-webserver so a full web
server wouldn't be a requirement.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================
Thomas Lockhart wrote: > (for obvious reasons) and I was wondering if anyone had suggestions > for a good approach to app development for brower-based user > interfaces. > There are other applications which would be of interest, so something > with some growth potential would be helpful. > Are there any options which are particularly "approachable" which > would allow newbies to get something working if they have some > existing code to look at? My recommendation is AOLserver 3. If you know any tcl, you can deal with AOLserver's tcl. AOLserver is a complete, lightweight, multithreaded, industrial-strength, open source powerhouse of a web server, available from www.aolserver.com. There are many examples available. AOL runs their www.aol.com and www.digitalcity.com sites on AOLserver -- this thing is a performance beast! Postgres is well supported under the older 2.3 series and the newer 3.0 series. 2.3 is not open source, though. In fact, AOLserver's support of Postgres is why I got started with PostgreSQL in the first place -- the seamless db connectivity was just too tempting. Database connections are pooled and throttled, so that only as many backends as your server can support can be loaded at any time. Connection threads share pooled connections -- a new backend is not spawned for each an every page request -- AOLserver was the first web server with this capability, BTW. AOLserver will cooexist with other web servers on the same box -- you can have it listen to any port you desire, on any interface. AOLserver allows embedded tcl inside HTML pages -- and the tcl has complete run of the database. For administration, a telnet control port is available that allows execution of operating system commands, tcl commands, and direct entry of SQL -- like having its own psql built-in. Version 3 is currently at beta 2, but development is heavy. And, AOL is using this for their highest traffic sites. The interactive development community site is at aolserver.lcs.mit.edu, and is run by the guys behind ArsDigita (the best known of whom is Philip Greenspun, Mr. Database-backed-website himself.). Their ArsDigita Community System (ACS) is written for the 2.3 server, but is chock full of example code that runs backed by Oracle, although an effort is underway to port over to PostgreSQL. The learning curve is surprising shallow, with any experienced programmer taking maybe a day or so to get up to speed on AOLserver's dialect of tk-less tcl. I have run this system for over two years, and it works very well. For more information on Greenspun's philosophy and on AOLserver itself, check out the book "Philip and Alex's Guide to Web Publishing", available at amazon.com or for free at photo.net/wtr/thebook -- this book really is a must-read. HTH. Lamar Owen WGCR Internet Radio
> Hi. There is interest at work in doing some fairly simple inventory > control using a database. We've already got Postgres up and running > (for obvious reasons) and I was wondering if anyone had suggestions > for a good approach to app development for brower-based user > interfaces. > > There are other applications which would be of interest, so something > with some growth potential would be helpful. > > We have a bit of expertise in Java servlets, etc, so that is one > option via the jdbc interface. > > Are there any options which are particularly "approachable" which > would allow newbies to get something working if they have some > existing code to look at? PHP is a must see. See FAQ. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
At 04:20 PM 7/29/99 +0000, Thomas Lockhart wrote:
>Hi. There is interest at work in doing some fairly simple inventory
>control using a database. We've already got Postgres up and running
>(for obvious reasons) and I was wondering if anyone had suggestions
>for a good approach to app development for brower-based user
>interfaces.
I'm fond of AOLserver and its TCL API, which has built-in pooled
db connectivity, maintaining persistent db connections with
no forking overhead. The webserver itself schedules TCL threads,
there's no CGI forking overhead as with older style Perl, etc
interfaces (of course, Apache + modPerl etc now implements a similarly
efficient interface). AOLserver's open source, GNU-licensed, and
also supports CGI and a C API. It works with many dbs, including
Postgres.
The integrated TCL API has been extended with literally dozens
of website-useful extensions to connect to the db, do selects,
do dml, get table info, send e-mail ("ns_sendmail to from message
extraheaders" - this gives a flavor of the ease in which one
gets things done in this environment), schedule TCL scripts
(I use this feature to do nightly pg_dumps), load pages from
other URLs, upload files from client browsers, etc etc etc.
If you're at all familiar with TCL you could have a few modest
pages up and running within hours of downloading the server
and the utilities package mentioned below.
An example of a website built using this combination plus
postgres 6.5.1 can be found at http://donb.photo.net/tweeterdom.
ArsDigita has a ton of code available to implement bboards,
e-commerce, bug (ticket) tracking, chat, and a bunch of other
stuff which sits on top of Oracle. I've found this stuff easy
to migrate to Postgres - the TCL scripts don't need changing
other than the actual SQL, which is mostly vanilla. The lack
of an outer join gets in the way of porting some of this code,
thus those who've discussed porting the complete ArsDigita system
are eagerly awaiting Postgres 6.6.
Other than that, the fact that Postgres implements sequences
in a way very much like Oracle with a just slightly different
syntax makes porting the SQL fairly easy. My particular
application doesn't include any of the specific modules
implemented by ArsDigita, other than that used to register
and log in visitors. But, I've poached a bunch of code from
the modules to avoid wheel-reinventing in a bunch of my own
stuff.
ArsDigita also has prototyping scripts available that quickly
builds form-based entry and edit pages from tables. This is
new, again is Oracle-based, but should be easy to move to
postgres.
They also supply a rich set of utilities which greatly
simplify using the db and forms, whether or not you use
their other tools.
All of this stuff's available from ArsDigita under the GNU
license as well, at arsdigita.com.
While not well-known, AOLserver, the ArsDigita stuff, and
Oracle lie underneath some very busy sites. Postgres 6.5.1
isn't quite robust enough to measure up to Oracle yet for
a truly busy site, but is so much better in the web environment
than 6.4 that I think it's really reasonable for modest sites,
up to a few ten thousands of hits a day at the very least.
I've tested the AOLserver+TCL+Postgres on a P200 classic
with Linux, 64 MB (running postgres -B 2000), and two IDE
disks (indices on one, datafiles on the other). On another
LAN-connected machine I fired up a bunch of browsers and
used them to run test scripts which simulated ten users
each doing four inserts a second, and two users doing
"selects" in tight TCL loops (did this in part to test
the changes which removed the unneeded logging after read-only
selects). The machine was perfectly happy performing these
tasks, not falling behind a bit. The four inserts were bundled
into a single transaction, so that's ten transactions a second
consisting of forty inserts. A lot of hits for a tiny machine,
really. Says a lot for Postgres, Linux, the web server and its
TCL API, not to mention the speed and capacity of modern
microcomputers!
If you're doing simple web applications, a straight interpreter,
be it TCL, Perl or whatever, has some advantages over a compiled
language. You make your changes, and poof! they're there, no
recompiling, relinking, etc.
Of course, I wouldn't use TCL for a large program requiring
hundreds of thousands of lines of code...but it does have a
reasonably clean syntax and the basic loop, select, if-then-else
structures and the ability to declare procedures.
The very nature of HTML imposes a structure on web programs
which is oriented around web pages, i.e. if you take input
via a form, that's a page. You process it and stuff into or
inquire from a database in the page that's the "action"
target of the form. You get to form pages via hyperlinks,
and normally they live on separate pages because that's the
natural way to present things to the user.
So the structure's typically not one imposed by the programmer's
decomposition of the problem in some abstract sense, but rather
your decomposition of the page flow through the client browser,
i.e. the design of the interface as you wish the user to see
it. That page flow design leads you around by the nose as you
develop the code underlying them (either html with embedded
TCL (.adp pages), or as I prefer scripts which write html (.tcl
pages), in AOLserver - ASP pages and ColdFusion-augmented
html are much like AOLserver .adp pages, CGI+Perl more like
the .tcl page approach).
>From the point of view of the user, this is almost cool - the
programmer's FORCED to design the user interface and the
page flow that takes the user through it. The UI - primitive
as it is - steps forward front-and-center, by necessity. One
can hope, at least, that the need to focus here leads to better
UIs, though of course HTML is so primitive that UIs are awkward
unless you get deep into client side java/javascript, which has
a lot of problems of its own.
Because of this, actual web code I've seen looks remarkably
the same regardless of the language being used. Much of
it is dominated by the writing of html, and shoving stuff
back-and-forth between pages (by URLencoding or hidden
form variables - html concepts, not Tcl or Perl or Java
concepts).
So I think it might be best to concentrate on looking for
combinations that can scale to high levels of activity, which
means avoiding CGI's forking interface (Apache and AOLserver
are both good at this), pooling DB connections (to avoid
forking off new db backends each time you connect), etc.
I'm using Linux+AOLserver+their Tcl API+Postgres+ArsDigita code
because the combination can service a lot of users on a cheap PC,
and it's all open-source/free software, not because I love Tcl
(I don't). The scripts underlying the sample site I gave above are
such relatively short and simple programs, though, that I don't mind
much what language I'm writing them in, language choice in this
case was a secondary consideration.
(given I'm a professional compiler writer, it still seems weird
to hear these words come from my mouth).
...
>Are there any options which are particularly "approachable" which
>would allow newbies to get something working if they have some
>existing code to look at?
If you're interested in the AOLserver approach, visit the ArsDigita
web site and poke around. You can download source code to all their
stuff to see what stuff look like.
- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, and other goodies at
http://donb.photo.net
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > Hi. There is interest at work in doing some fairly simple inventory > control using a database. We've already got Postgres up and running > (for obvious reasons) and I was wondering if anyone had suggestions > for a good approach to app development for brower-based user > interfaces. > > There are other applications which would be of interest, so something > with some growth potential would be helpful. > > We have a bit of expertise in Java servlets, etc, so that is one > option via the jdbc interface. > > Are there any options which are particularly "approachable" which > would allow newbies to get something working if they have some > existing code to look at? Since you explictly mention Java, you could look at the Java Apache project, which apparently implements the java servlet interface. (http://java.apache.org) If you like Perl, Apache + mod_perl + HTML::Mason have done right by me for a number of projects. I think it's incredibly approachable (and powerful), but I've got four years of solid perl experience and like the language a lot---YMMV. (http://perl.apache.org/, http://www.masonhq.com/) If you like TCL, AOLServer definitely deserves a look, as others have said. It's also a nice, low overhead server to administer. (http://www.aolserver.com/, http://www.arsdigita.com/) PHP has a lot of activity, and is supposed to be really fast if you compile it right into your apache server, although it's often YANAL for people to have to learn. (http://www.php.net) Roxen Challenger, with its Pike language and many other nifty features is also worth a glance, though it's also got the YANAL stigma. There's both a commercial version and a GPL'd version. (http://www.roxen.com/) With the exception of the Java stuff, I am personally aquainted with significant projects that have been implemented in each of these environments---all of them have the ability to support large projects, though I don't know how well they support programming in the large. I suspect approachability may initially hinge on language familiarity. If you have to learn a whole new language, you're probably going to have a steeper learning curve. Mike.
On 29-Jul-99 Thomas Lockhart wrote: > Hi. There is interest at work in doing some fairly simple inventory > control using a database. We've already got Postgres up and running > (for obvious reasons) and I was wondering if anyone had suggestions > for a good approach to app development for brower-based user > interfaces. You begin the star war ;-)) I use three different interface for different tasks Firstly, I use php3 to make web based interface http://www.piter-press.ru is an example (not the best, but the only public available) PHP3 code looks like $qu = pg_exec($conn, "select * from users where (uid = '$uid');" ); $nm = pg_numrows($qu); if ($nm > 0) { $data = pg_fetch_object ($qu, $i); $xpin = crypt($pin, $data->pin); if ($xpin == $data->pin) { BlueEcho("PIN of user '$uid' is valid"); } else { RedEcho("Sorry, you enter incorrect PIN for user '$uid'"); } } pg_close($conn); and seems to be very convenient for sambody familiar with perl or C Secondly, I use Perl every time as I need write anything for five minits just because I use Perl about five years. Perl code looks like (I skip any error check, usually doing inside runSQL) my $connect_args = 'dbname=voip host=nymph.wplus.net user=dms'; my $conn = Pg::connectdb($connect_args); my $query = "selectuid from users where(opstatus=1 and manstatus=1 and units < $insure) $result = $conn->exec("BEGIN");$result = $conn->exec("DECLARE killer001 CURSOR FOR $query;"); open(EMP,"|$empress"); while( ($result = Voip::runSQL($conn, "FETCH FORWARD 1 IN killer001;")) ) { while (@row = $result->fetchrow) { runSQL($conn, "begin"); runSQL($conn, "update users setopstatus=2 where(uid = '$row[0]');"); print EMP "update its_user set acctstatus=1 where(userid = '$row[0]');\n"; runSQL($conn, "commit"); print "User $row[0] disabled\n"; } } runSQL($conn,"CLOSE killer001;"); runSQL($conn, "END"); $conn->reset(); Third, I use C++ for really hard tasks (By historical reasons, I use my own library, not libpq++) C++ code looks like pgs = new PgSQL(listdb); pgs->trace(); sprintf( (char *)qbuf,"select id, email from %s where( msgid < %d );", (char *) list,msgid);pgs->openCursor( (char *)qbuf); while( pgs->fetchNext() ) { sprintf(update,"update %s set msgid=%d where( id = %s);", (char *)listn, msgid send_proc(qbuf, (char *) (*pgs)["email"], fm, (char*) update ); } // while pgs->closeCursor(); delete pgs; I also try to use Java but I find no appropriate task for it. Main disadvantage to Java - is lots of incompatible browser versions, for example Lucent made java interface works only on 2 MS Win based workstations and 0 of UNIX based from about 80 comps. All other have fonts, security manager or other problems ;-)) (but it's my opinion - any of Java gurus may be completely disagree with me ;-)) ) IMHO, PHP3 is the best choice for Web it self, but bakground programs should be written in C/C++ So, make your choice and good luck ;-)) > > There are other applications which would be of interest, so something > with some growth potential would be helpful. > > We have a bit of expertise in Java servlets, etc, so that is one > option via the jdbc interface. > > Are there any options which are particularly "approachable" which > would allow newbies to get something working if they have some > existing code to look at? > > TIA > > - Thomas > > -- > Thomas Lockhart lockhart@alumni.caltech.edu > South Pasadena, California --- Dmitry Samersoff, dms@wplus.net, ICQ:3161705 http://devnull.wplus.net * There will come soft rains ...
Thus spake Dmitry Samersoff > On 29-Jul-99 Thomas Lockhart wrote: > > (for obvious reasons) and I was wondering if anyone had suggestions > > for a good approach to app development for brower-based user > > interfaces. > > You begin the star war ;-)) > > I use three different interface for different tasks [PHP3, Perl and C++ discussion ellided] Or, use Python for everything. > Firstly, I use php3 to make web based interface I use Python over PHP because, like PHP, Ican embed it into the web server but I can reuse the code in non-web applications so I don't have to reinvent each wheel. > http://www.piter-press.ru is an example (not the best, but the only public > available) > PHP3 code looks like > > $qu = pg_exec($conn, "select * from users where (uid = '$uid');" ); > $nm = pg_numrows($qu); > if ($nm > 0) > { > $data = pg_fetch_object ($qu, $i); > $xpin = crypt($pin, $data->pin); > if ($xpin == $data->pin) > { BlueEcho("PIN of user '$uid' is valid"); > } > else > { RedEcho("Sorry, you enter incorrect PIN for user '$uid'"); > } > } > > pg_close($conn); for data in db.query("select * from users where uid = '%d'" % uid).dictresult():if crypt(pin, data.pin) == data.pin: print"PIN of user '%d' is valid" % uidelse: print "Sorry, you enter incorrect PIN for user '%d'" % uid I assume that BlueEcho and RedEcho are simply functions that wrap the strings in font color tags. Such functions can easily be added to Python. See http://www.druid.net/rides/ for a real example. > Secondly, I use Perl every time as I need write anything for five minits > just because I use Perl about five years. I use Python over Perl because I find it to be a cleaner and more logical language. This is a personal preference thing, of course. > Third, I use C++ for really hard tasks (By historical reasons, I use my own > library, not libpq++) I hardly do anything in C (never cared much for C++ except for a few specific features) any more as Python gives me the ability to do anything I could do in C and, if needed, I can always write low level code in C and link it in. Check out http://www.python.org/ for more information. For a PostgreSQL interface for Python see http://www.druid.net/pygresql/ or look in the PostgreSQL source tree. > IMHO, PHP3 is the best choice for Web it self, but bakground programs > should be written in C/C++ As I said, one language for all makes code reuse easier. I find that my projects generally require web interfaces, CLI interfaces as well as scheduled background tasks and I can write modules that get imported into all of them saving me much development time. > So, make your choice and good luck ;-)) Can't argue with that. -- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
At 11:49 PM 7/29/99 +0400, Dmitry Samersoff wrote:
...
> $qu = pg_exec($conn, "select * from users where (uid = '$uid');" );
> $nm = pg_numrows($qu);
> if ($nm > 0)
> {
> $data = pg_fetch_object ($qu, $i);
> $xpin = crypt($pin, $data->pin);
> if ($xpin == $data->pin)
> { BlueEcho("PIN of user '$uid' is valid");
> }
> else
> { RedEcho("Sorry, you enter incorrect PIN for user '$uid'");
> }
> }
>
> pg_close($conn);
Tcl code in AOLserver looks roughly like this (using the utilities
package from ArsDigita as well as AOLserver Tcl extensions):
# Note that this gets a persistent handle, i.e. the overhead is
# simply that of assigning a handle pointer from a pool
set db [ns_db gethandle]
set selection [ns_db select $db "select * from users where (uid='$uid')"
while {[ns_db getrow $db $selection]} { set_variables_after_query if {$pin == ...
}
ns_db releasehandle $db
>and seems to be very convenient for sambody familiar with perl or C
>
>Secondly, I use Perl every time as I need write anything for five minits
>just because I use Perl about five years.
>
>Perl code looks like (I skip any error check, usually doing inside runSQL)
> my $connect_args = 'dbname=voip host=nymph.wplus.net user=dms';
> my $conn = Pg::connectdb($connect_args);
This is bad for websites - building a new db connection is expensive.
This is why AOLserver provides pooled connections.
This is why Apache/modperl types use packages that pool persistent
connections if they plan to build a busy site.
> my $query = "select uid from users where(opstatus=1 and manstatus=1 and
units
>< $insure)
>
> $result = $conn->exec("BEGIN");
> $result = $conn->exec("DECLARE killer001 CURSOR FOR $query;");
As you can see, when it gets down to it, all of these solutions have
more in common than in differences.
The key to look at, IMO, is the efficiency of the webserver and its
database connectivity.
...
- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, and other goodies at
http://donb.photo.net