Designing a Doc-Centric Web App

[Chipp Walters]

Hi Dan,

You know, I've been building such apps for sometime now. In fact, Jerry
Daniels here in Austin, just finished one with our help. See below for some
comments...

> I have built a Web application in Zope and Python over the past year or
> so. The application has become so complex that maintaining it is
> becoming a bit nightmarish for me. I'm spending far too much time
> wrestling with the app framework (Zope) and syntax (Python accessing
> Zope Object Database) than I am solving problems for the client. I have
> also realized that using an OO database was overkill, and that decision
> is part of the reason for my current feeling of being trapped inside
> tiny, twisty passages.
>
> This application needs to allow its primary user, who is a professional
> facilitator conducting a process interview with a client, to:
>
> 1. Log in securely (to the app and/or the Web location)

No problem...one of the nice things about RR is you can create a 'stateless'
web application. In fact, I've been pushing this approach to some of our
clients because you *DON'T* have to download the interface, and interface
logic each time you launch it (unlike browser based web apps where all the
DHTML, button images, etc.. gets downloaded each time you visit a page).

You might want to check out Philip Chumbley's article:
"(Nearly) Unbreakable KeyFile Encryption" can be found at:
http://www.sonsothunder.com/devres/revolution/revolution.htm?_dply003

While this isn't SSL, it can be used to communicate between two clients...or
if you're good at scripting PHP, you could implement it on the PHP server.

> 2. Create a new document on the server (transparently to the user, who
> is decidedly NOT technical)

What type of document? Will the user be uploading a file? If so, get with me
offline as we've been working on a http file uploader which works with PHP
and Apache.

> 3. Update the document on the server as he or she asks questions and
> receives responses (i.e., the document needs to replace or update
> itself on the net as the user requests that it do so)

If it's a txt file, that's not a problem. If it's RTF or PDF, it might be a
bit more difficult, but not impossible.

> 4. Locate and retrieve documents from the server, limited only to those
> created by the particular user, and either view, print or revise those
> documents

Simple permissions stuff. You may have to write a group permissions editor.

>
> One other user, the supervisor, needs to be able to access all
> documents regardless of which interviewer created them, and review,
> print, or revise them.

Admin mode?

>
> The only tricky part is that there are two stages in this interview
> process where the precise number of times the question has to be asked
> and answered is not known in advance.
>
> I want to create a desktop app in Rev that will handle all the UI, data
> validation, and communication with the server. I have already designed
> the window and its screen contents as well as the interaction.
>
> The issues I have relate to the interaction between the desktop app and
> the server from a Revolution perspective.
>
> 1. Security is a significant concern. The interview data contains
> highly personal information about the interviewee. I suspect I'll want
> to use SSL for the Web connection but it's not clear to me what if
> anything I need Rev to be able to do to handle SSL and whether there
> are any gotchas lurking there.

SSL is not available yet, but is expected to be coming soon. I'm not a big
fan of SSL as I believe it slows things down too much. IMHO, Use it
sparingly.

>
> 2. I particularly do not want to send login ID and password for the
> facilitator in the clear. What encryption issues will I encounter in
> Revolution? Are there encryption algorithms that already work in Rev or
> will I need either to hook into an Open Source solution or roll my own?

See article above.

>
> 3. Does anyone see any major issues, problems, concerns, or flat-out
> roadblocks I should think about as I re-design this app?
>
> 4. One of my big issues is that if I design this as a document-centric
> app -- which it seems to want to be -- I won't be structuring the text
> much, except perhaps for display purposes. As opposed, e.g., to
> producing a mySQL app (which I could do but which seems like almost as
> much overkill as my current Zope solution), where the data would be
> stored presumably more efficiently. But since I *never* need to
> retrieve only part of the document, it seems most useful from a design
> perspective simply to treat it as a document.

Yep, I agree. Use the filesystemobject if you can. If you don't have to do
any database intensive stuff, it could work well for you. Though, I think
it's slower than updating a DB.

best.

Chipp