Hi Jack,
> [...]
I'd suggest another database table called "states" (or something)
with the following attributes/fields:
state_id - short int
state_name - short string (char 10 or so)
state_desc - long string
state_readonly - bool
and then loading them up. I think that will be
much more robust in the long term since it means
we don't have to keep the code aligned with the DB
schema and it also kinda nails down the definition
of the states.
Of course, we'll need a little "state edit" screen
like what is available for projects.
Anyway... just a thought.
Sounds good to me. The reason why it is the way it is is because of
"hysterical" reasons - the days before Codestriker even used a database
for persistence. Having said that, there is no reason why we couldn't
migrate to the above schema.
I'm pretty busy these days, so I don't know when I'd work on this. I've
added it to the task list though so it is not forgotten.
Cheers,
David
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Codestriker-user mailing list
Codestriker-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/codestriker-user
