Best GUI for small-scale accounting app?

[Gabriel Cosentino de Barros]

> From: Paul Rubin [mailto:"http://phr.cx"@NOSPAM.invalid]
> 
> Dave Cook <davecook at nowhere.net> writes:
> > > You might not care.
> > 
> > And in that case Tk is much simpler than just about anything else,
unless
> > looks are really important.
> 
> I've used tk and I don't think it's simpler than html.

I've been doing webapps for 5 years now. *THE* thing that make it's
worthless: after you've sent the data, your program loose all ability to
deal with user interface.

After you send the form to the user, you loose ALL habilities of python,
php, mysql, etc... and are solely on the javascript fields. And that
javascript will have only the provided data of that session to get things
done, so you can't send all the DB to the client :)

Nowadays that you can use and trust user requests, as widely advertised by
"google sugest", you can overcome one of the pitfalls of html: the
responsiveness to user input.

Now, the second one: responsiveness to server envents, still has to rely on
non-standard xml streams or third party hacks using macromedia crap.

take for example gMail. A program like that had at least 60% of it's
development made on the javascript side. And it still doens't solve the
second issue.

So, as i said in my 1st post in this thread: both have their problems, but
it's all about what you need to get done. so, get used to both.

If you can use one-shot pages, go for html, since all the toolkit is easily
available in the browser, the network hassle is also done by the browser,
the input history... also done by the browser! yada yada yada

Now, if you need interactivity, say a game for example, then run away from
html like hell.

Gabriel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20041227/f7eaebc3/attachment.html>