Re: Help with choice of suitable Architecture



"Rob Cowie" <cowie.rob@xxxxxxxxx> writes:

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



Relevant Pages

  • Re: Saving dynamically created data on client side?
    ... Serve the "editor page" with the JS from a cgi. ... the server-side CGI inside the pop-up can serve the data file ...
    (comp.lang.javascript)
  • Re: Possibly strange question regarding VB.NET and CGI
    ... > Im currently developing a web site using PHP. ... this doesn't really bother me as I prefer XML anyway. ... > At the moment I am fighting a design battle in relation to file writing ... Now apparently any application can use CGI as ...
    (microsoft.public.dotnet.languages.vb)
  • Re: processing XML posts through a web server
    ... can be persuaded to run Perl CGI scripts. ... SOAP can be used for a form of RPC where the parameters and return values are converted to XML for transmission - but the application programmer usually doesn't have to deal with XML. ...
    (comp.lang.perl.misc)
  • Possibly strange question regarding VB.NET and CGI
    ... this doesn't really bother me as I prefer XML anyway. ... using ASP.NET for design reasons at the moment. ... Now apparently any application can use CGI as ...
    (microsoft.public.dotnet.languages.vb)
  • Re: form tutorials
    ... DOM but the methods for collecting information such as posting or CGI ... client-side script - something like JavaScript, processing things like forms, images, et ... This can be used to validate the contents of forms before submission to a CGI. ...
    (comp.lang.javascript)