>Thanks David, that's what I figured. I would use the
key
>'published_version', right?
"Returns the versions of the stories as they were last
published. The
checked_out parameter will be ignored if this parameter is
passed a true
value." -- yup, that sounds like it would work.
>But this doesn't help with previews and my preview site
when changes to
>the cover date occur prior to publishing.
Sure, but I wouldn't worry about that too much because the
appropriate
index corresponding to the current cover date IS being
previewed. You
could instruct your users to just re-preview the article's
former index
page if they want to verify that it would look correct when
republished
or, alternatively, you could just regenerate all index pages
(or all
that fall within a reasonable span of time anyway) when an
article is
previewed or published... but that might tax your system too
much.
>Looking at the other options,
>I think I could check the previous version using the
'version' key. If
>the cover dates of the current and previous versions
don't match,
update
>the Indexes for both.
Sure, but the previous version might not have been
published, so you'll
probably only want to look at the actual published versions.
Every time
a story is checked in / out, a new version of it is created,
so only a
subset of all versions are published versions.
>However, if the cover date change occurs during a single
version, I
>think I'm out of luck as far as the preview site goes,
which is
>acceptable and my users will have to manually
republish.
Republish or repreview? When you publish an article, you're
creating a
record of the last published version which will always be
available to
you next time around. It would only be a manual repreview I
think.
|