Servoy Forum

Hey Guys,

I wanted to get your input - do you develop multiple login solutions (e.g. one for every single solution)?

It seems to me that if you're doing multiple solutions - it would be nice to have a "wrapper" login solution that could use forms in another module (e.g. with a tabpanel on the main "login" form - linked to "standard" forms in another module).

I get that the idea is that the only way for the login forms to get to the data is through the authenticator module - so I would assume it would be "bad" to have a tabpanel on the main LOGIN solution with forms from another module?

(Sorry for being dense on this concept)

I would allways put everything into just one solution, whenever there would be the chance that some users need more than one solution.
It is not that much work to shield everything from users that they do not need, that is the purpose of every authorisation concept.

Further advantages: one update, one codebase, one installation procedure, one database

Whenever you start with two solutions and then see the need to join them in future, that will be quite a lot of work. So better to start united.

Thanks, Bernd!

After some thought - I see I was defeating the whole purpose of the secure login by attaching a "regular" module (that has access to all the backend tables). But I still wanted some encapsulation for all the other functionality (forgot password, forgot username, etc.).

What I wound up doing was I made a SECOND login solution that contains all the base forms, security.authenticate calls, etc. Then I have another login solution that is the "shell" (it can have different css, logos, appearances, etc).

Now by configuring a couple of properties in the "shell" I can have many different login (specific to each project), but all the underlying functionality can be shared (and updated) for all solutions.

THANKS for your input!

Bob

Yup, thats exactly right Bob! So I usually have a base module, 1 form for the UI. Just a tabpanel, It has some initialization functions in it, like what the login form is, forgot password form, reset password form, etc.

It also has other base forms, that has the core functions in it that the other forms (login, forgot password, and reset password extend).

Then as you need different types of login forms, its just making the UI, extend the base form, and calling the initialization functions for the base framework in the onSolutionOpen

PS. I use a tabpanel because you can't switch forms in a login solution, so you swap out forms in the tabpanel.

Most solutions only have 1 login solution, but in large corporate environments with where the internal login is through Active Directory/LDAP, then there can be various kinds of external entry points, its handy to share some logic. So, in that case, the entire forms can be completely different but share some code.

Thanks, Scott!

I was having problems with the tabpanel not redrawing when I wanted to switch the tabs.

I WAS able to change forms within the login solution - (e.g. in case of lost password, etc) - but I still just use a tabpanel to display unterlying forms with all the logic (that live in a different module all together).

I seems to be working - and now I just have to create a new login (per solution) - but it's just the shell with some properties that get set. The forms in the other module look at scope variables to do initialization, navigation, setting of the splash, etc.

It actually works pretty well.

Have you ever seen the case where you're in webclient (not NG) and you have some tabs on a tabpanel, and it just refuses to redraw?

Bob

Never seen that. Would double check those forms you want to show aren't connected to pure tables. Maybe its blocking it because they link to data, instead of the security api calls?

Hey Scott - thanks for your reply!

The forms only look at scope variables in the 2nd module - and no forms have any base tables....

Looks like you have arrived at this module architecture:



An alternative module organization is to flip the location of your client modules in relation to the entry point. Avoids the tight coupling introduced by extending forms and instead relies on composition of forms:



More info on what I think is an optimal module organization: http://data-sutra.com/documentation/ser ... dules.html

David - great minds think alike!

I was just going down the same path - and you are EXACTLY RIGHT.

I also found your documentation really interesting - so THANKS SO MUCH for sharing that as well!

I truly appreciate all your time and helpful input!

Bob