1. Regarding the switch to postgresql, I think that's a good choice. Just pay
attention to postgresql's data types, and try to get your fields types and
lengths correct the first time if possible. It doesn't completely support the
ALTER TABLE command, so changing column types can be a pain, although it's still
possible. The other thing is that SQL syntax might be slightly different in a
few cases, though it's been too long since I used MySQL to remember any
examples. Postgresql's web site has some tips for switching, I think at
http://techdocs.postgresql.org.
2. Have them read some articles on the whole MVC approach, since it sounds like
you'll be using that. And of course read Damian's book several times for OO
perl.
4. You might put the formulas in a perl superclass, with one method per formula.
Then create a subclass for each different company that has that company's
algorithm. All the calling code has to worry about is which company it's dealing
with when it instantiates the object; after that all the right formulas will get
used automatically. This should make it easy to add more companies, too. I guess
the general principle is that when you're faced with tons of complexity, try
breaking it down into smaller pieces and add an abstraction layer or two, so you
and the program can deal with it.
Hope this helps. I'll be watching for the success story!
-- Wes Sheldahl
Viljo Marrandi <[EMAIL PROTECTED]> on 12/19/2001 03:50:49 AM
To: modperl list <[EMAIL PROTECTED]>, templates list
<[EMAIL PROTECTED]>
cc: (bcc: Wesley Sheldahl/Lex/Lexmark)
Subject: Tips & tricks needed :)
Hello,
We're going to make a web-site for insurance company (err, more like
portal for several companies) and the problem is that ( I think ) it's
going to be our biggest and most complex site we've ever done AND we're
going to use some new stuff we've never used. So I'd be very happy if
you can give me some points what to look at, what are real no-no's and
what are go-go's.
1. We're going to switch from mysql to postgresql, because we need
transactions, triggers and all other stuff that mysql doesn't support.
What could be possible problems going from mysql to postgres, if any?
2. We will use Template-Toolkit and Apache/mod_perl. Problem is that 2
out of 3 people have never used TT or programmed mod_perl and OO Perl.
Only I've made sites this way, they've used Embperl til now. How can I
make this switch for them a little easier? I know I must spend a lot of
time teaching them, but may-be there are some kinda switchover tutorials
or something?
3. Authorization. Is cookie based auth most reasonable or are there some
other ways too? .htaccess will not do, I think, because all data is in
the same directory and authorized access/login is needed only on some
parts of site. Which data should I send with cookie? Only some random
key which is also stored in dbase and this key is used to find real data
from dbase? (I guess I must read again this thread about cookies).
4. How is most reasonable to store(and use too) complex formulas and
coefficients? Problem is that there are 4 companies and each of them has
different way to calculate same thing eg. insurance for travelling, car
insurance etc. Unfortunately they are all quite different, because every
company uses even different things to calculate final result. So if we
use different formula for every company and insurance type we end up
with ~50 formulas and none understands afterwards which is which. Are
there any guidelines to generalize formulas? Ok, let's say we even
somehow make these formulas general enough to use, but where shall the
calculation take place? Postgres stored procs or in perl code/module (i
think this) or even in TT? Constans will be in db.
5. Any other things to look out when creating large site and/or running
it over SSL and/or using above described configuration?
P.S. I hope that in about few months I can write about this project to
success stories ;-)
Thanks for your attention,
Viljo
