Steve,
This is when I think containers work out well: when non-technical users need
to populate, order and publish content. For example, we've built a site that
has as part of its features a simple newsletter. On the homepage we have a
featured article from the current newsletter which links to the article; the
article displays the article content of course and it links to sections of
the site called "current newsletter", "newsletters by issue (archive)",
"articles by subject". The current newsletter page displays a list of all
the articles in the current newsletter and an intro to the newsletter
itself. The "by issue" page provides a list of all newsletter issues with
links to each one. When you click a link for the newsletter, it displays
that newsletters intro and links to its articles, in the same fashion as the
current newsletter. The "by subject" listing does just that, lists article
links by subject area.
The archive and the subject listing are generated dynamically. If an article
or newsletter is published, it appears in those two places without user
intervention. The exception is for the newsletter and articles that are
designated as part of the current newsletter.
What we use containers for is to provide the people who manage the content
of the site on a daily basis with a simple interface to select one or more
articles and order them for the home page. We use another to provide them
with a simple interface for them to select and publish the current
newsletter. Behind the scenes, we use containers to associate articles and
issues in the WebTop.
That's one example. And it's a simple one. We are now starting to use the
publishing rules in containers to present granular content to user based on
their interests profile and categorization of content.
In some ways the containers are clunky and have little too much capability.
We need to train people on what not to touch in the container editors. Maybe
there's a way to disable options in the editor selectively.
My suggestion: start considering ways to use them. You're probably
reinventing some wheels that containers already provide if you're building
complex sites and you're not using them.
My caveat: expect some problems, some limitations and continued need to
invent wheels.
I'd be interested in feedback on what you or other people think of the way
we're using containers. Maybe there are better ways to do what we're doing.
Ed
-----Original Message-----
From: Stephen Collins [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 06, 2001 1:33 AM
To: Spectra-Talk
Subject: Containers... Why?
Okay, I've been "doing" Spectra for about a year now. I'm on my third major
project using the technology.
The team I'm a part of has, through one reason or another, never chosen to
put info on a page using a container, we've just coded to address our needs
as we came across them. This technique has always worked for us.
What I'd like some feedback on is why I should or shouldn't use containers
for object presentation. Just going over what's available again, I can't
see any compelling reason to use containers, but several not to (need to use
WebTop to implement, multiple steps, etc.)
Your feedback anxiously anticipated.
Steve
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
