Hi Robin,
I agree with you on that. It is sufficient to have just one box for
staging and live content. But in terms of security it is much better allow
edit objects only on staging server, and publish content when it is
approved. We can publish not just objects, but containers with content,
rules, object types, handlers and even whole pages. It is not that hard to
implement, but give you more freedom in modelling content on staging
server. It also takes down the load from live Spectra box.
Mark Feldman.
Web Developer.
UniSuper Management
[EMAIL PROTECTED]
http://www.unisuper.com.au
>>> [EMAIL PROTECTED] 09/10/01 03:11pm >>>
Hi Mark,
Doesn't necessarily have to be a separate box - can have separate
stage/live
datasources used by single spectra app. I did this on a project - the
application datasource was set to the edit version of the content, there
was
a second datasource for live data. Only one piece of code on the site was
allowed to copy objects from the edit to the live datasource - this was
behind the "approve to go live" button. Gotcha 1 is that if you work with
a
particular object in both datasources over the course of one request,
delete
the copy of the object in request.cfa.objects before calling
cfa_contentObjectGet or you will turn your brain inside out trying to
debug
the problem. Gotcha 2 is the verity collections - they are distinct per
application but not per datasource. Would need to modify coapi so that
collection names include the name of the datasource to keep staging and
live
indexes distinct (Ray, will try to submit this change soon to
Spectrasource).
Cheers,
Robin Hilliard
Senior Product Support Engineer - Asia Pacific
Macromedia, Inc.
> -----Original Message-----
> From: Mark Feldman [mailto:[EMAIL PROTECTED]]
> Sent: Monday, 10 September 2001 2:07 PM
> To: Spectra-Talk
> Subject: Re: staging content
>
>
> Hi,
>
> I think it would be easier to have staging server separate from
> production
> one. You can edit objects on staging server and upon approval syndicate
> them to production. That way you keep object ID's the same and archive
> them easily.
>
> Mark Feldman.
> Web Developer.
> UniSuper Limited.
>
> >>> [EMAIL PROTECTED] 09/10/01 01:32pm >>>
> Greetings,
>
> I'm trying to build a content staging system for versioned
> content objects
> that would allow for edits to an existing object without effecting the
> objects version history unless the edits were approved by an
> administrator.
> To do this, within my edit handler I am generating a new co with
> matching
> properties (including the label which is unique per co) and setting it's
> active and archived flags to false. This is the object that is used to
> store edits to the corresponding live co (matching labels). Upon
approval
> of the edit, a new version of the true content object is created and the
> live version is updated with the edited content - lastly, the edit co is
> deleted.
>
> Is there a simpler way to go about this?
> Best Regards,
> Seth
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Get the mailserver that powers this list at http://www.coolfusion.com
------------------------------------------------------------------------------
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.
