mindplay.dk

I actually did attempt to build something, twice, last time a few years ago. My first attempt was based on lightweight WYSIWYG with very limited capabilities, e.g. h1-h6/bold/italic/links, not much else. It had drag-and-drop reordering of the sections, and a "template" drop-down for each section. It was not much use in practice. My second attempt was based on Markdown, which can be processed on both client and server-side. This had a single, floating (semi-transparent) form for the Markdown, and would render the HTML in the background, on the fly. It would detect placeholders on the Markdown content - so if you entered "{photo}", for example, a "photo" item would show up on a list of all the placeholders in the content. You would then click on a placeholder in that list to edit it, and you could then substitute it with, say, an image, a table, or some other piece of content - each type of content would have it's own editor. I loved that idea, but clients don't understand Markdown, or don't like it. Content-editable is now fairly ubiquitous, so I think something in between those two ideas would soon be feasible - a very simple, lightweight, in-place editor with basic formatting, draggable sections and containers and so forth, some of which would have custom UI for uploading images, populating tables, etc. I'm sure it's not a small can of worms to open up though.

I think he means with ProcessWire? So yes, "mydomain.com/about-us" returns 301, and "mydomain.com/about-us/" returns 200, by default - and having the extra redirect isn't good for your search-engine ranking. In other words, simply giving people the URL "/about-us" when the real URL is actually "/about-us/" is not a good idea. Having both URLs work (actually serving the same content from both addresses) also (generally) isn't good for your search engine ranking - search engines may be more forgiving in this case, not sure. It either case, it'll work - but it's not a good idea. This is part of the reason I perpetuated the discussion, and I'm still not satisfied with the answer...

Doesn't just happen in editors either - it's a general problem with iframes. I guess transparent updates are both good and bad? I just hope they fix this soon...

Again, I can only see this as being a work-around that doesn't address the root of the problem. I would strongly prefer working with core concepts that do not present those problems to begin with. To underline my point: look at the Features module for Drupal. 100K sites are using it, which means it should have been a standard feature, and the core architecture should have been designed with these requirements in mind - it should not have been an afterthought. Look at the number of open issues and bug-reports against this module. Look at the complexity - thousands of lines of code and special handling for lots of different modules: blocks, fields, images, menus, taxonomies, users, etc... Introducing so many new concepts and potential points of failure, just to work around this one problem - to me, this is an indication of core design failure. This is why good software must break backwards compatibility with major revisions - design issues have to be addressed when they're discovered, and with better design, not just with more code. Just my opinion

That actually sounds like a great approach for read-only sites. I suppose, if you used an external (Javascript) service for e.g. comments on a site, that approach would even still work - as long as no new data is being added to the public site. Continuous integration has become the default for me, I never even consider anything else - but I'll have to keep this approach in mind for projects that meet those requirements. Some clients would probably see it as an advantage - that they can tweak and adjust the site, in cooperation with us, and decide precisely when they think it's ready for the public.

The problem is source control - if it's data in a database, there is no file you can check in, compare version history or review changes made by other team members. Automated deployment becomes harder. You could dump SQL statements and check those in, but auto-increment keys make it extremely difficult to integrate, say, two different newly added fields or templates from different developers, since they will have the same primary keys. Just one example of many. Because metadata in nature is closer to code than it is to data, the metadata usually needs to be kept strictly in sync with the code - you usually have code that depends on the metadata, because the metadata "implements" (or at least strictly defines) the model. As opposed to data, which is usually less vulnerable to asynchronous deployment. I don't know if source-control and automated deployment are very important to most people - perhaps not a big concern for most smaller websites?

I brought this up a long time ago, in this thread - in a nutshell, the thing that I've been working on (on and off) is a generic model of a model ~ hence the term "meta-model", which I'm not even sure if that's the real or correct term, or whether that's even a common thing. Meta-models have lots of potential applications, but probably it's primary appeal is code-generation. There is of course no reason you can't consume a meta-model at run-time, which is what PW does. In PW, your meta-model is basically the Templates and Fields. The problem is, you make changes to the meta-model directly, which means you do not have a useful history of how the meta-model evolved. To use a practical example, in my generic meta-model, I have types like "class", "property" and "annotation" - just very generic constructs that are applicable to (or can be made useful in) just about any programming language. Let's say I have an object that represents a "property" in the model, for example - let's say that $property->name is currently "first_name". In my meta-model, the $name property is read-only - you can't change it directly. No values can be changed directly. Instead, if you want to change the name, you have to create and submit a command, so for example: $metamodel->add(new PropertyNameChange($property, 'last_name')); PropertyNameChange is a command object capable of actually changing the name of a property. To reiterate, there is no other way to change the name of a property in the meta-model. When that command-object is added to the meta-model, it is automatically executed, so the change actually gets applied - but the command-object itself also gets serialized and appended to the model's history. This enables me to repeat any change made to the meta-model, in sequence. This is very similar to how database schema migrations work - except you're not limited to migrating changes to the database schema, which really is an implementation artifact. You can now migrate changes to the entire model, and the entire history of the model becomes repeatable. Another important difference, is that the meta-model (and command history) gets written to flat files, rather than to the database. This enables me to make changes to a model, and check those changes into source-control, then repeat the commands on another system to continuously integrate the changes. Applying the same idea to ProcessWire, that would mean blocking Templates and Fields from direct modifications, writing serialized copies of Templates and Fields, and serialized command history of changes made to both, into flat files. This would be event-driven, so that you could hook into commands being added or executed... It has always been my philosophy that writing data and meta-data into the same back-end (e.g. database) isn't right... I think the problem with most CMS is that nobody bothers to make the distinction between data and meta-data - we tend to think, "oh, it's all just data", and then shove it all into the database. But meta-data is actually closer in nature to code, than it is to data - because it drives decision-making in the code. Things like "title" and "body" do not directly drive decisions, but things like "field type" and "template filename" directly drives decision-making, and therefore does not belong in databases, anymore than your source-code does. Some CMS take this misunderstanding to an extreme, and actually write PHP code into the database, iiiirk!...

That looks interesting - I will definitely check that out, although I don't think it's applicable to this.

Thanks, Ryan. Any thoughts on adopting a more robust (command-pattern) approach to the meta-model in general?