Replying to my own question. LoginManager redefines getItem to look into its userSourcesList rather than into the rackList, as in the specialist class. So it seems to me that loginManager is not following the Liskov substitution principle (LSP) by not equivalently redefining newItem. So for now, I have fixed my problem by also redefining newItem in loginManager, substituting userSourcesList[0] for rackList[0]. Seems to me that would be a desirable behavior of loginManager. Another solution, which would also satisfy LSP without redefining newItem, would be to have rackList return the contents of userSourcesList rather than an empty list (I haven't looked into why rackList is empty in the first place in loginManager). Again, I think that would be a consistent interpretation based on the behavior of getItem as implemented in loginManager. Cheers, Jean

Hi folks,

I am slowly, very slowly, getting comfortable with loginManager, but I've hit yet another snag, and I am too tired today so I'll just ask and hope for a kind soul to hep me out. ^ | -------- See, I am tired!

And I also forgot that the paragraph would auto wrap, so even my attempt at making fun of my typo failed ;-)

I am in the process of adapting the example provided by dlpierson (thanks by the way), so I am using a skinscript and an external database (MySQL). In coming up with form based addition of new users, I figured might as well use newItem and the skinscript rather than calling SQL methods directly. But newItem complains, and I found out that the problem is that rackList is empty, but isn't UserSource a rack? Why isn't it in rackList? (In case someone asks, yes I do have a UserSource in the LoginManager, and it seems to work OK otherwise).

Cheers,

Jean