Thread

I spent some time with MODx, and what I’m doing here is EE makes the most sense to me.
Everything is black and white to this designer, maybe it’s just how much you dig in to any particular CMS, but EE for me has been straight foreward, and the easiest to understand.
I didn’t quite get MODx’s chunks, snippets, variables, maybe now the concepts might make a bit more sense for me.
It could be the professionalism of the crowd around here too that’s a big draw. Not to many people talking down at you.

Makes sense.  I’ve been wanting to dig into MODx for years, but never went too far because it never reached 1.0.  What’s up with how slow it’s taken to reach that critical point?  I just assumed the traction wasn’t there for developers to get behind it.

Back on topic, Ellis Lab used to refuse to call ExpressionEngine a CMS.  I remember calling them on the phone when I first began and asked them to explain the difference between their term “Web Publishing System” and the more mainstream term “Content Management System.”  I think I spoke with Leslie.  I’m sure he gave me a reasonable answer, but I hung up the phone scratching my head.  Now that I understand EE, I can see why they originally called it a “web publishing system.”  I think that name still applies although I think they’re moving toward a CMS with 2.0.  It’s an evolutionary thing I suppose.

whereas in other CMS’s, you go to your content and choose how it will be viewed

I find that ass backwards 😊
It implies that a page/template is one piece of content and you style for that (and maybe so on simple sites) whereas every site I’ve worked on (some really, really big ones) are comprised of a multitude of content types being assembled in a coherent page (template). And some content may be used in different sections of a site and styled differently.

I don’t know about other systems, but remember you can build the back end entry form for the data type (weblog) just using the control panel. The data then goes right along with a template that then presents it on the front-end, using custom fields and even field types.
Authors don’t need to even have hand’s on with the templates that way, just the weblog’s post entry form.

PXLated—Well, maybe it is backwards, but it’s gotta mean something if all the developers in my company chose to do it that way. I think it’s more consistent with all the MVC frameworks/architectures I’ve ever looked at.  Of course a rendered page consists of multiple pieces of “content”, but I still find it more logical to have each piece of content have a view associated with it; e.g. a blog post might have a div tag wrapper as its view or “template”, where as a “page” bit of content (e.g. a legal terms-of-use document) might have a full html page as its view or “template”.  Every system has ways to circumvent the default, but content having a view has been the most common implementation I’ve seen as a developer.  And as I mentioned, we’re using MODx on some enormous sites as well.

stephenslater—yeah, I don’t think MODx terms are the most clear, but in EE terms, a MODx chunk is like a static EE template, whereas a MODx snippet is like an EE template with PHP parsing enabled.  I just find that to be a clearer way to abstract dynamic portions of a page (i.e. scripts).  The {exp:} blocks {/exp} are powerful, to be sure, but sometimes you have to construct a FOREACH loop in your head to follow them.  I have no idea why the MODx team is so slow in dev… but hey, you get what you pay for

Crssp-ee—yeah, having a professional crowd and a phone number for support is a huge draw for EE.  If you need that, there aren’t too many other options.

but it’s gotta mean something if all the developers in my company chose to do it that way

Maybe it just means you’re all backwards - sorry, couldn’t resist 😊

but I still find it more logical to have each piece of content have a view associated with it; e.g. a blog post might have a div tag wrapper as its view or “template”, where as a “page” bit of content (e.g. a legal terms-of-use document) might have a full html page as its view or “template”

In most systems I’ve used it only makes sense if content can be assigned multiple views depending on where used. If content can only be assigned a single view it’s a limited, crippled system - period.

Every system has ways to circumvent the default, but content having a view has been the most common implementation I’ve seen as a developer.

To each their own experience. Your default view has not been mine. I can guarantee that your view would not have worked on any of the big sites I’ve worked on. None, zero, zip!

“None, zero, zip!”? You must be working on some pretty niche sites.  We own thousands of domains, the architecture I outlined works on all of them, as would yours I’m sure.  I don’t want to argue potato/po-tah-to with you.  All I wanted to do in this thread was point out that there are other ways of thinking about templates and content, and for those coming from similar backgrounds as mine, the EE way of doing things is not immediately obvious.  You can snuff it out and guarantee that it’s crippled I guess… it doesn’t change the way I think.

You must be working on some pretty niche sites

Not exactly - But to each their own view of the world 😉

WOW, I’m really glad I found this thread. Spinhirn finally clarified what what was confusing me. I’m trying to find a CMS for my ski club web site. I need a forum, a newsletter, photo gallery. etc.

I have localhost sites with Joomla, CMS Made Simple, Websitebaker, and ExpressionEngine Core running. I feel like Goldielocks; some are too simple and others are too difficult. With Joomla I can’t imagine how to get the data managed. After a few hours with ExpressionEngine I can’t imagine how to get the data to display. I found this topic searching for “themes.” After downloaded a new theme, I can’t figure out how to “use” it.

We are outgrowing a site made with Sandvox. Can I reuse html/css from that site with ExpressionEngine?

Can I reuse html/css from that site with ExpressionEngine?

Definitely. Just paste it in your template, then add EE tags where appropriate.

I might be crazy articulating this thought, but here goes:

One of the things I like about EE is that I feel somewhat future-proofed as things evolve in terms of web presentation. The mere fact that I can invoke content through a tag (versus content-associated-with-a-view), the better I feel. The viewport can change—heck, it could change by user—and the content remains.
(I could demonstrating how little I know here, but I’m ok with that…)

At some point, users will have browsers (or whatever) that allow them to retrieve and view content their way. And the more our content is married to presentation, the more difficult things will be. To some degree RSS affords users the ability to strip content from presentation, but that’s the tip of the iceberg…

...in my very humble opinion.

Developers/users of a weblog (e.g., a dynamic index page containing ‘n’ number of database records) can switch easily between template groups as desired. How does that workflow differ logically from a WordPress user entering content and switching between themes (which include tags)?

If I understand you correctly, there really isn’t a fundamental difference: content is kept isolated from the code that formats/displays it.  In all CMS’s that I’ve looked at, you can put content into Templates, but it’s considered bad practice because it violates the rule of semantic web development: keep content isolated.

Wordpress themes are divided by architectural design into files from which a single webpage is built programmatically at run-time. Those files contain tags which retrieve data from the database.  A single EE template assembles the entire page by default (exception: embeds), using tags which retrieve data from the database.

How does this become a case of EE putting content into templates by (apparent) stark contrast with other CMS/blogging tools?

Now that I understand EE, I can see why they originally called it a “web publishing system.”  I think that name still applies although I think they’re moving toward a CMS with 2.0.  It’s an evolutionary thing I suppose.

Well said.

Once you get started on a major app with a constant stream of revisions, changes almost always become evolutionary out of practicality.