Target containers seem like a great idea. In fact, they sound like an absolute necessity, until you actually encounter them in use and, in RedDot's case, forced misuse.
A target container is much the same as any content inclusion mechanism; the training manual describes them, intriguingly, as a combination of server-side includes and iframes. The one drawback RedDot has over (possibly all) other inclusion mechanisms is that it only allows one inclusion. Well, one inclusion per link to be fair and correct.
This only really dawns when:
- You start thinking about the nature of linking and whether links should only be able to lead to full pages, changes in one part of the page, or changes in several parts of the page. Each is vastly superior than its predecessor.
- You end up with an 'unbalanced' template: one whose open/close tag pairs do not match up.
The latter seems inevitable in any reasonably structured site that uses the one-hit target container, and causes untold problems involving trying to fit a 'good' template into a 'bad' hole.
I'm sure there's plenty more to be said about the dreaded target container; this is only the beginning.
2 comments:
You missed the point that you can only link to a page you created by a target container construction from the constucting link (without hacking) and lots of other "drawbacks".
Please understand that none of the features of the RedDot CMS is meant to be "academically" or "theoretically" correct. It is just a common use-case you cover with target containers and this use-case is really made easy isn't it? Beyond this point ... your are right.
Yes, it is a simple conclusion mechanism, cause it is a container. But set up as a target from specified structure elements.
If you don't want to have some bad templates in this container, don't pre-assign them to the container and don't pre-assign them to the structure elements, which have it's target pointing to this target container.
Post a Comment