Help with choice of suitable Architecture

[Rob Cowie]

Hi,

This is my first post so go easy!

I have been asked (as part of an MSc project) to create a server based
planner for a research group at my uni. It will have a web interface to
interact with data stored in an XML document. Basic functionality is
required such as viewing, searching, editing, creating and deleting
entries for things such as paper submission deadlines, events, funding
application deadlines. I would also like to use AJAX principles in the
web interface.
Additionaly, it must email a BibTex file once a month to a
predetermined address.

I'm totally new to web programming. I have been looking into the best
way to proceed. CGI is of course an option but it seems slow, clunky
and outdated. Twisted provides a rich architecture but might be
overkill. Nevow seems to be very popular.
I suspect I could achieve what I want using PHP but I would really like
to get to grip with Python.

I'm not asking for a comparison of each architecture per se.... that
seems to be well covered in this group. I would like to know how you
all would set about creating this realtively simple application.

Cheers,
Rob Cowie
Coventry University, Britain

 

[Paul Rubin]

I have been asked (as part of an MSc project) to create a server based
planner for a research group at my uni. It will have a web interface to
interact with data stored in an XML document.

Why not just a regular database?

Basic functionality is required such as viewing, searching, editing,
creating and deleting entries for things such as paper submission
deadlines, events, funding application deadlines. I would also like
to use AJAX principles in the web interface.

Yecch, just use standard HTML, don't depend on client scripting
without a concrete good reason. It makes stuff more confusing for
both human and automated users, and makes people weaken their browser
security by enabling scripting. That stuff went out of style with
pop-up ads.

Additionaly, it must email a BibTex file once a month to a
predetermined address.

That's no big deal.

I'm totally new to web programming. I have been looking into the best
way to proceed. CGI is of course an option but it seems slow, clunky
and outdated. Twisted provides a rich architecture but might be
overkill. Nevow seems to be very popular.

CGI is conceptually the simplest, but leaves you needing to do a bunch
of stuff yourself. A database back end helps a lot in dealing with
concurrent updates. There's a bunch of other Python web frameworks
too (Spyce, CherryPy, Zope, ...).

For a generic overview, you might look at the now-somewhat-outdated
book "Philip and Alex's Guide to Web Publishing",

http://philip.greenspun.com/panda/

I suspect I could achieve what I want using PHP but I would really like
to get to grip with Python.

If the goal is simply to get to the finish line, PHP might get you
there faster for something like this. If it's an academic project
where "the journey is the reward" there's lots of things you can try.

 

[Dennis Lee Bieber]

also some mechanics under the hood - manipulating data etc. BTW, does it
have to be stored in xml file? The SQL database could be easier. You can
add import and export to/from xml file if this is really needed.

If it MUST be in a single XML file, some means of serializing
access may be required -- be pretty messy if two clients both submit
updates (spawning two CGI processes, each of which does a
read/modify/write of the file).

--

 

[Rob Cowie]

I agree with the sentiments that a single XML file is not the way to go
for storing data that may be accessed concurrently. However, my hands
are tied.

It seems that CGI is likely to be the most straightforward option. Is
the learning curve likely to be steeper for pure CGI or a web
application architecture such as Nevow?

Paul..... I agree that client-side scripting increases the level of
compexity, but did it really go out of fashion with pop-ups? It seems
to be just getting started. Google use it to great effect.... maps,
suggest etc. I wasn't thinking of using it to deal with any 'business
logic', just to add some dynamism to the interface - use
XMLhttprequests, a bit of DOM scripting etc.

 

[Mike Meyer]

Paul..... I agree that client-side scripting increases the level of
compexity, but did it really go out of fashion with pop-ups? It seems
to be just getting started. Google use it to great effect.... maps,
suggest etc. I wasn't thinking of using it to deal with any 'business
logic', just to add some dynamism to the interface - use
XMLhttprequests, a bit of DOM scripting etc.

It's clearly not gone. Just remember, that people do turn it off for
security reasons. Doing so also does a good job of killing popups and
the like. I normally run with JavaScript off, and the local city
government has installed IE with it disabled on all their desktops.

So make sure the functionality of the site doesn't require javascript
to be enabled. This may require duplicating functionality, but you can
save your design by hiding the non-javascript version of the
functionality in a <noscript> element.

<mike

 

[Paul Rubin]

Paul..... I agree that client-side scripting increases the level of
compexity, but did it really go out of fashion with pop-ups? It seems
to be just getting started.

Pop-ups and scripting-related security holes are why the cool kids all
surf with Javascript turned off. Who cares about what Joe Sixpack is
doing? ;-)

Anyway, don't increase complexity without a good reason.

Google use it to great effect.... maps, suggest etc. I wasn't
thinking of using it to deal with any 'business logic',

There is some case to be made that the Google maps interface presents
concrete good reasons to use scripting, falling into the "concrete
good reason" exception. I dunno about "suggest". I do see that
Google Groups uses scripting in an unnecessary and obnoxious way, just
like most other uses of scripting. You're doing a text-only service
so you shouldn't even depend on graphics being available in the
browser (your system is IMO defective it doesn't work properly with
Lynx).

just to add some dynamism to the interface - use XMLhttprequests, a
bit of DOM scripting etc.

That's sort of vague. A concrete good reason means a specific set of
benefits you can provide to the user with scripting that you can't
provide without scripting.

See also: http://www.anybrowser.org

 

[Kent Johnson]

I agree with the sentiments that a single XML file is not the way to go
for storing data that may be accessed concurrently. However, my hands
are tied.

You might like to see the thread "write to the same file from multiple processes at the same time?"
for a preview of the issues this raises.
http://groups-beta.google.com/group...71e63/c2fc42fefe114d38?hl=en#c2fc42fefe114d38

Kent

 

[Cameron Laird]

.
.
.

good reason" exception. I dunno about "suggest". I do see that

.
.
.
<URL: http://labs.google.com//suggestfaq.html >, to ensure we're
all talking about the same thing.

 

[Rob Cowie]

Thanks for the comments.

I kind of get the impression that CGI is the way to go for this
application, and that I should forget about adding client-side
scripting based functionality for the sake of accessibility - which I
understand and kind of agree with.

I'll look into the problem of concurrent access to an XML file. I may
get back to the group about this!

Cheers

 

[John J. Lee]

Thanks for the comments.

I kind of get the impression that CGI is the way to go for this
application, and that I should forget about adding client-side
scripting based functionality for the sake of accessibility - which I
understand and kind of agree with.

I don't see any intrinsic reason for client-side scripting, or
JavaScript in particular, messing up accessibility. One can fall back
to vanilla HTML+CSS for people who don't have JS turned on. I don't
say it's easy, though. I don't know what you intend the content of
your Masters to be, but this seems like an interesting and useful
thing to work on, and a fashionable topic to boot: write your app as
one piece of code that can run happily with JavaScript (and taking
advantage of AJAX) or without (without resort to if statements in your
application code, obviously ;-).

Personally, I'm anticipating the day I can change an import statement
in my Qt GUI applications and run them on the web (== JavaScript +
HTML + CSS + HTTP) <0.5 wink>.

In the mean time, I recommend Quixote (yes, you can run it on CGI).
Lots of people seem to like Twisted, too (nevow has some AJAX
support), though perhaps Twisted and CGI don't sensibly go together
(and I certainly understand the desire to avoid long-running server
processes).

If you're interested in new stuff, certainly take a look at Kamaelia
(after you've oriented yourself a bit by writing a tiny web app or
two!).

I'll look into the problem of concurrent access to an XML file. I may
get back to the group about this!

From my own unpleasant experience, CGI + locking = pain. At least if
you don't have full control of the server (even then, do yourself a
favour, use a DBMS, and let somebody else worry about some of the hard
parts of locking, transactions &c.). Why not keep the XML in a
database blob, if somebody insists on an XML-based implementation?
Or, more sane, store your data in the DB, then just write out XML,
which presumably solves the *real* problem for which XML is the
solution (interoperability)?

have-the-appropriate-amount-of-fun-ly y'rs,


John