[albatross-users] Albatross Form Question

[alan.junk at sunwave.com]

Mike & Andrew,

Thank you both for your excellent replies.  They have given me a lot to
think about.

Andrew, a (hopefully) quick question about your reply:

> One advantage to splitting things up this way is that you can change the
> business logic without effecting the presentation, or vica versa. And
> because the business logic is separate, you could write unit-tests for
> it without the added complexity of interacting with the user interface.
> You can also use the same Model (business logic) with alternate interfaces
> (web, gui, command line, etc).

OK, this sounds good and on target for what I want to do.

> What I'm trying to say is that you might find Albatross easier to get
> along with if you introduce another layer of abstraction between your
> business logic and the presentation.

I'm willing to go here. Not a problem.  Probably better this way for
sanity checking routines.

> You might have something like:
>
>     class CustomerController:
> ...

OK, here is where I got lost.  Here is the simple CustomerController I
came up with:

   class CustomerController:

        def __init__(self,c):

	        self.firstname = c.firstName()
	        self.lastname  = c.lastName()

        def update_cust(self,c)

                c.firstName(self.firstname)
                c.lastName(self.lastname)

Now, I know this is beginning to be more of a python question than an
albatross one, but the class above is starting to have that bulky feel
again.

There are probably 100 customer methods in the customer object dealing
with setting, getting, and sanity checking.  If I entered them all in the
CustomerController just like the methods above, it would start to get
pretty ugly.

There is also some mention of creating __setitem__ and __getitem__ methods
for my customer object, to allow a more "loop" like approach to setting
and getting.  Although I can see how these would work nicely if my
customer data was stored in a dictionary, I don't see how to use them when
my customer data is accessed via methods.

I'm afraid what I may have done is built a customer object that isn't as
python friendly as it could be.  I really liked the idea of having a
'firstName' method that could retrieve, store, and run sanity checks but
perhaps I need to work with the customer class in some other way?

Or perhaps I just need to come to terms with having a bulky
CustomerController?

I could use the pSQL module to turn my SQL tables into python objects that
could play well with albatross just like the CustomerController.  My
python code would shrink considerably but then I lose any business logic I
might have been able to put into a customer method.

Alan