Creating a multi-tier client/server application
bruno.42.desthuilliers at wtf.websiteburo.oops.com
Wed Aug 29 15:45:49 CEST 2007
Jeff a écrit :
> Thanks for the quick responses.
> I was really hoping to avoid an entirely web-based app, for a few
> reasons, not the least of which is that I've been working almost
> entirely on web apps for the past few years, and I am getting mighty
> sick of it. A lot of that is due to the language (PHP, which I have
> since grown to hate) I had to use. I've worked on a site for my self
> in Python (using Pylons, actually--which is excellent) which was
> vastly easier and more fun. But I'd really like to try something
> Now, of course, that's not enough reason to force such a thing onto my
> clients (when I say clients, I mean the ones that are paying for this,
> but they're really within my same department, so they actually have
> working technical knowledge.) Some reasons for them would be (in no
> particular order): 1) More responsive and user-friendly interfaces,
You could explore something like a custom-made GUI client app
communicating thru the http protocol with a web-server app. http is just
a protocol, and it doesn't necessarily imply using html and a browser...
IIRC, some GUI toolkits uses XML description files for the UI.
> 3) Easier to "lock down" who's using the program by only
> installing it on certain machines.
Not a very reliable security scheme IMHO !-)
> Which leads me to the discussion of planning:
> This system will be used, often, to figure out how much people should
> be paid (and then interface directly with the University's payroll
> system), and store lovely things like SSNs, and will also have to have
> somewhat crazy business logic to track when hourly workers are
> eligible for raises, if they took enough training classes, etc. There
> are a lot of people with a stake in this system, and I will need to
> work with them very closely on how this should work, and they sure as
> hell don't want any surprises. My manager even wants use cases (if
> you've never had to deal with use cases, consider yourself a lucky,
> lucky person) which I am going to attempt to argue as that is even
> going *too* far.
> So, long story short (too late), no Extreme Programming for me.
Extreme Programming doesn't mean "no preparation", and makes heavy use
of use cases. Of course you need to have some - hopefully accurate -
functional specs. The point was mostly along the lines of "don't try to
have full-featured detailed design before you start coding, because
chances are it will be wrong".
> Hopefully, the amount of planning will be somewhere in between that
> and the bureaucratic nightmare of documenting up front what each
> module, class and function will do.
Which would be totally non-sensical. I don't believe anyone on earth
could come up with such a thing - done right - *before* the application
More information about the Python-list