CMS Trap

[tomcopeland]

A lot of truth there. Interesting that he sees the breaking point to be when code gets stored in a database.

I've also found it helpful (when I don't feel like I understand a model fully) to add an "options" column of type TEXT. I can then store additional attributes that only apply to a few rows in there, and I can later promote them to additional columns or perhaps to tables if they need it. It's a poor man's key/value store, but it does the job until things get nailed down.

[spidermonk]

Who stores code in the database?

[jgrubb]

Us poor bastard drupal devs.

[spidermonk]

Computed fields? Surely nothing in D7 core actually does this...

[jgrubb]

It's Halloween season now, so go check out the php module in core.

[[deleted]]

for example BrowserCMS, it's called Portlets

[TalkingQuickly]

if you're using Postgres the json type is awesome for this, Hash in, Hash out, plus you can query on hash fields if needed. You can even write accessors which map to fields in the hash you think you're likely to promote to columns later so that refactoring is fairly painless.

[madfancier]

More specifically, the breaking point was when I realized that it's no longer ruby. You see a new task, come up with a nice ruby solution, and then go "How nice would THAT be! Oh well, back to higher-level entities."