2 ms·

Yes. But does a CMS do this in a good way? Custom fields inside a admin interface is not a very modern approach.

knieveltech 16y ago
I'm sorry but I don't agree. Having the ability to define custom data entry forms (including unique field types like calendar dates, google maps location pickers, etc) and the data storage that goes with them via a web interface with no coding required seems pretty modern to me. Can you point out an example of another approach that seems better to you?
- lovskogen 16y ago
  Doing all those things in context. Imagine the client logging in, and on the About Us page pressing "Add Content". Then chosing "Insert a map" from a drop down of content types. A resizeble map container appears on the site. The client searches or drags the map into the right location and presses "save". Then he publishes the page.
  - lshepstone 16y ago
    I think we're mixing requirements here. Use case 1: I need to create a new page and for many corporate sites, each new page is different than the next for the majority of the body copy...different layout, one has a map etc. I need to choose where this page goes in the site as well. An in-context approach is very well suited. Use case 2: I just need to create a press release quickly, it always has the same template, always goes to the same part of the site and it's always the same process I go through. An in-context approach here isn't that good, you want a template approach where the user fills in some fields on a form, a title, body text, maybe image, checkbox for map yes/no etc. This isn't a page at all really, it is a piece of content that is created and using the Press Releas template, the page is created dynamically at the right point in the menu structure. They'll create the page in 30 secs and be done. There is very little point in choosing from a list of modules to insert when you're dealing with a fixed template. So you're talking about the templated approach vs the page builder approach. Neither is better or worse, just suited to different use cases.

I'm sorry but I don't agree. Having the ability to define custom data entry forms (including unique field types like calendar dates, google maps location pickers, etc) and the data storage that goes with them via a web interface with no coding required seems pretty modern to me. Can you point out an example of another approach that seems better to you?

lovskogen 16y ago
Doing all those things in context. Imagine the client logging in, and on the About Us page pressing "Add Content". Then chosing "Insert a map" from a drop down of content types. A resizeble map container appears on the site. The client searches or drags the map into the right location and presses "save". Then he publishes the page.
- lshepstone 16y ago
  I think we're mixing requirements here. Use case 1: I need to create a new page and for many corporate sites, each new page is different than the next for the majority of the body copy...different layout, one has a map etc. I need to choose where this page goes in the site as well. An in-context approach is very well suited. Use case 2: I just need to create a press release quickly, it always has the same template, always goes to the same part of the site and it's always the same process I go through. An in-context approach here isn't that good, you want a template approach where the user fills in some fields on a form, a title, body text, maybe image, checkbox for map yes/no etc. This isn't a page at all really, it is a piece of content that is created and using the Press Releas template, the page is created dynamically at the right point in the menu structure. They'll create the page in 30 secs and be done. There is very little point in choosing from a list of modules to insert when you're dealing with a fixed template. So you're talking about the templated approach vs the page builder approach. Neither is better or worse, just suited to different use cases.