> Consider the following disadvantags of containers:
> * if an object gets removed in the webtop that was assigned to the
> container, it is not automatically removed from the container and
> can create
> errors in page execution.
This is not really a bug, imho. If you delete a record in any web app, and
that record is being used somewhere, you will get an error. If you delete an
object from the webtop, or anywhere for that matter, you should check to see
if it has been published. This is not that difficult. Plus, remember that
it's the rule barfing on the deleted object, not the container itself. So,
this is probably more an issue with the Basic Schedule rule then containers
themselves.
> * containers are slow to execute. Having more than a couple of them on the
> page can slow page processing down considerably.
Well, adding custom tags to your page will add execution time as well. Any
code will. I have not noticed bad slowdowns caused by containers. I also use
caching a lot as well - but I use that for Spectra and non Spectra sites.
> * when you allow users to create pages with unique containerids, large
> amounts of pages will bring/slow your server down, because the SLM is
> preloaded in server-memory. It will also render your snazzy SLM tree
> incredibly slow.
Ok, but how is this a Spectra problem? This is an issue w/ any web app that
allows users to make low level changes (I consider adding new pages to be
'low level'). If you allow your users to do this - things are going to get
messy - wether you use Spectra or not. The SLM, large or not, should not be
affecting your performance though. Can you give me an estimate on how large
(# of pages, containers) your site is?
> * container rules have edit handlers that allow multiple settings
> per rule.
> However, every setting that is different from the same rule in another
> container requires a unique containerid, costing performance.
That's not exactly true - or I may be misreading you. Every container that
is unique will have a unique ID. You can only reuse containers by passing in
the same ID. Therefore, every container will also have unique rules as well.
Therefore, when you embed the rule into the container, yo uare making unique
rule objects, not container objects. (Ok, I'm being anal. ;) Again, I don't
see this as that big of a deal.
> * containers mix database content (a container record, rule record) with
> programmatic functionality (show me all the press releases)
> * ...
Why is that bad? Isn't that the point of publishing? To me, every CMS
(content management system) has an idea of "In this area, apply this
publishing rule, where the rule fetches certain content objects." I mean -
that's the point of a CMS, right? To get and display content according to
certain rules. (I'm probably misreading your complaint here. Can you
rephrase?)
[deletia]
> It seems to me that the idea of containers is related to the concept of
> isolating back end users from the techies. If a system is well
> prepared, you
> can do a lot with containers, switching publishing rules,
> allowing metadata
> keyword selection, etc.
> However, I found in practice that users don't want to have this
> flexibility.
> They want to be able to add a press release and know that it
> appears on page
> so and so. Basically, an object centered and wizard based
> approach. Most of
Ok, but now it sounds like your complaining about the interface. Remember
that the container editor is _not_ something you have to use. At my last
Spectra job (and my current job), I'm not using the container editor. At the
earlier job, the client said it was too complex. So, no big deal, I just
wrote my own interface to the containers. At my current project, I'm the
admin, and I just wanted something short and sweet.
> done under the hood, why not use custom tags?
And I do! :) But your acting like it's a "one or the other" type thing, and
it's not. I use custom tags to interface with the containers. Well, the
default container editors do the same thing! It's just a matter of choice,
really. If you don't like the editors that come out of the box, you can
easily design your own.
=======================================================================
Raymond Camden, Principal Spectra Compliance Engineer for Macromedia
Email : [EMAIL PROTECTED]
ICQ UIN : 3679482
"My ally is the Force, and a powerful ally it is." - Yoda
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/spectra_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
