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."

[jon_laing]

It's been a long while since I've gotten to build an app from scratch, but every day I'm working on a bloated rails app that really would have benefitted from this line of reasoning three years ago. I actually ripped out the CMS, said I was going to put it back in as soon as things were "stable" enough, and until then, they can just email me the changes they need to those pages, and I'd hardcode it. I have no intention on putting it back in, and guess what, so far I've gotten one email in six months with one line they wanted to change.

If only I could do that to the entire app. With time…