Stewart:
A few questions and suggestions here.
Why not just add a property to your articles that stores all the
navigational contexts that the article is in. This assumes that there is a
place on the site where you associate articles with your different
navigational contexts unless you are doing it manually or by publishing
rules. You could place code that updates this property of the article
whenever an association is made from the article to a context. Making this
property searchable and/or indexed would make it easier for you to get to it
via verity or a query on the properties table.
Another option I guess would be to create a table that links contexts to
articles. If you had several records for any given article it would mean it
was associated with several contexts and you could create some kind of
thread through them in the display handler for the article. This might be a
better option if you don't have an admin screen for associating articles to
contexts but are using publishing rules to pull up an article for a context.
I may be totally off-base and not have understood your questions but I
hope I helped somehow nonetheless.
Andrew Hewitt
Web Application Developer
webworld studios inc.
----- Original Message -----
From: "Stewart Johnston" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 14, 2000 11:30 PM
Subject: RE: Objects, Containers &Pages
> Thanks all for this info.
>
> Actually we have a verity search over body elements of the site (they are
> just boring long winded articles). I've read the archives and the only
> solution presented so far is to imbed the URL of the article in the
> article - making it kind of complicated for the content owner - however,
if
> it must be so it must be so. One of our requirements is to display the
> article (selected from the search results) in situation (on the actual
> normal page) rather than just to use a generic invoke type method to show
> the item. Also some articles may appear more than once in different
> navigational contexts and the ability to then duplicate the single search
> result into the actual number of page instances probably with some sort of
a
> navigational bread crumb like heading would be quite nice.
>
> Anybody with any ideas - I'm listening and greatful.
>
> Thanks
>
> Stewart Johnston
> -----Original Message-----
> From: Richard Ragan [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 15 August 2000 12:59 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Objects, Containers &Pages
>
>
> Yep, pretty much what David said.
>
> However, why don't you tell us what you are trying to accomplish and maybe
> we
> can come up with a better solution. There have been others with questions
> almost the same as yours where different solutions finally surfaced.
>
> Cheers, Rich Ragan
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, August 14, 2000 7:51 PM
> Subject: RE: Objects, Containers &Pages
>
>
> > actually, there's no global way to do this because the publishing rules
> are
> > completely flexible, i.e. the publishing rules you write can use any
data
> you
> > specify to determine which objects appear where. So figuring out which
> objects
> > are associated where requires an intimate knowledge of the publishing
> rules
> > being used. Even if you are only interested in the default scheduling
> rule, it
> > would still be a hard question to answer since it is time dependent.
> >
> > The question would really have to be something like "which objects are
> > associated with which containers/pages at which moment in time?"
> >
> > To answer that I assume you'd have to crack open the stored data about
> each
> > container and evaluate it -- probably not just an afternoon's worth of
> coding!
> > :-)
> >
> > And even if it was, I can't imagine that the performance would be good
> enough
> > for realtime reporting.
> >
> > Sorry to be the bearer of bad news.
> >
> > I guess the flip side is that if you are using your own rule and getting
> this
> > data is an important requirement, you could:
> >
> > 1) Build something that would know how to get the data back out easily
or
> >
> > 2) Build a reporting mechanism so that your rule would update some data
> store
> > (perhaps a set of queriable objects) to record where which objects will
be
> used.
> >
> > or, if you're lucky, perhaps someone has already built such a reporting
> tool for
> > the default scheduling rule.
> >
> > david aden
> > webworld studios, inc
> > www.wwstudios.com
> >
> > -----Original Message-----
> > From: Stewart Johnston [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, August 14, 2000 10:31 PM
> > To: [EMAIL PROTECTED]
> > Subject: Objects, Containers &Pages
> >
> >
> > Hi
> >
> > I am trying to determine how I can determine what containers/pages any
> given
> > object is utilised on. Its part of a search thing. It seems to me I
should
> > be able to - performance of this is then a subsequent question - any
> > feedback on this would be appreciated as well.
> >
> > Stewart Johnston
> >
>
> --------------------------------------------------------------------------
> ----
> > 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.
> >
>
> --------------------------------------------------------------------------
> ----
> > 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.
>
> --------------------------------------------------------------------------
--
> --
> 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.
>
> --------------------------------------------------------------------------
----
> 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.
>
------------------------------------------------------------------------------
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.
