Ian Bicking: the old part of his blog

Re: Little Apps Instead of Little Frameworks

I really like this approach, especially as it relates to easily extending login types. I'm not really a fan of writing my own login/logout scheme for every new web application, plus more advanced login schemes could be done in an external small login webapp, like ISSO and all that single-sign-on stuff.

Of course, that leaves me wondering how such little apps would keep a consistence appearence that actually looks like part of the site they're used with. Probably the easiest way to let the app user decide, would be to intercept the login/logout call, do the function, then "inject" the form to login, etc into the web application. That way the person using the little app would be able to fit it in with their existing website however they wanted. That's just the first scheme that comes to mind though...

Comment on Little Apps Instead of Little Frameworks
by Ben Bangert

Comments:

I really like this approach, especially as it relates to easily extending login types. I'm not really a fan of writing my own login/logout scheme for every new web application, plus more advanced login schemes could be done in an external small login webapp, like ISSO and all that single-sign-on stuff.

I have noticed that the single-sign-on stuff tends to have a login process that is a lot more complicated than just asking for a username and password, and a login can take place over several HTTP requests. That's a really hard library to write. But a pretty simple app.

Of course, that leaves me wondering how such little apps would keep a consistence appearence that actually looks like part of the site they're used with. Probably the easiest way to let the app user decide, would be to intercept the login/logout call, do the function, then "inject" the form to login, etc into the web application. That way the person using the little app would be able to fit it in with their existing website however they wanted. That's just the first scheme that comes to mind though...

That is possible, if you make it possible to include other resources. I.e. <<include "/login/formfragment">> which does a subrequest and inserts the result (adapted to whatever your templating language). However, this gets complicated if there's any interaction -- it only really works for displaying the initial form, not the form action or any intermediate screens. And maybe that's okay. The actual form action should be directed automatically to the application, though if you were doing it as middleware you could also just capture some particular pattern.

For other applications, a simple method would be if there were good conventions for how to override templates. Like a template path, with local templates first on the path. You might have to replicate your appearance several times in several templating systems, but if there are good conventions that's not so hard. And it's a useful feature to have even if something better comes along, so I think it's a good start.

# Ian Bicking