After seeing the debate on Rails Engines and periodic calls for a more
unified approach to logins, I thought we could have a healthy thread on
to collaborate at levels beyond the Rails core.
I wonder whether our use of language is pushing the debate in less
productive directions. Instead of focusing on the pros and cons of
high-level “components”, shouldn’t we be figuring out how to create
conventions that foster decoupling across plug-ins while still allowing
unified access to relatively standard web data, like login ID,
name, and whether a session is a visitor, member, or some sort of admin?
A plug-in could say it needs access to a login (however that’s
and the Rails community has a convention (overridable at the DSL level)
logins have a loginID and some timestamps. Likewise, a component might
to address the user, “Hi Bill”, and therefore needs access to a profile
(however that’s implemented), and the Rails community has a convention
profiles provide first names, last names, web addresses, etc.
A while ago, I tried to bolt the phpBB message board system onto a
pre-existing website. Yes, I could have said “less is more” and built
what I needed from scratch, but there’s value in quickly adding
just like scaffolding. And there’s value in recognizing what’s a
function – one that’s used by many different websites and really isn’t
domain-specific – and what’s very central to the value of my web app.
Generic logins and forgotten password handling are commodity operations.
Just like Rails takes care of significant grunt work, I’d like to not
my own login handler if a public one fits. There’s also value in
standardizing on a commodity because it stress tests the component:
hacking the shared login handler will be detected and solved more
Message boards can be a commodity as well. Integrating phpBB is not easy
because phpBB has its own user management system. Many portal + phpBB
solutions either adopt the phpBB user system or provide glue between two
separate user systems. Wouldn’t it be nice to have conventions for
decoupling this dependence between bulletin board handling and user
handling, and in general, letting plug-ins know about common resources
without bundling in their own DB schema?
DHH says “if you have a great idea for an engine, or a high-level
in general, think about this: Is there a way I could abstract a smaller
slice of functionality as an independent plugin and then release that
alongside a pattern that described how to use it like the component
have done all in software?”
For message boards, you could implement a plug-in that handles posts and
threads. This plug-in would still need to know simple things like the
ID” and name of the poster, whether the poster has a home page URL, etc.
we can agree on how to make such queries without hardwired schemas, we
promote decoupling and have threads work with a variety of user systems.
Would the first step be creating a beautiful DSL for logins, user
information, and maybe even roles?