Hi Nick, The question I need to ask here is:
Do you want: (A) a single random entry to appear in the container where you have placed the advertising rule or (B) a specific advertisement to appear in each of the places that you use it? If (A) (a random one) then you will probably be best off creating your own rule to do this (not really hard - just use the "random fact" rule as a template to copy from and cut it down to your Advertising news). If (B) (a specific one) then you could look at using the Handpicked Rule instead of the News rule. This rule lets you wander through all the content and tick off specific items you want displayed (as well as the display method to use). You would only need to write a display method (which you probably already have). I am guessing your answer will be (A) so I thought I would provide additional generic comment regarding rules.... Rules basically have two methods that you have to implement (three if you count the getDefaultProperties method). The two methods are: update and execute. The update method is what is used by the interface to gather data about the parameters for the rule (e.g. display method, what category filter to use, how many you want, etc.). This information can be as complex as you wish it to be and is determined by the coder of the rule. You do need to ensure though that you specify the <CFPROPERTY> information so that the Admin interface can pick this up to create the schema for the rule when you DEPLOY it. Don't forget to deploy your rule - otherwise there will be nowhere to store the parameters of your rule. The execute method is what is called by the container to obtain one of three things: 1. a populated array of invocation items that allows deferred rendering (best method) 2. a HTML snippet that is the rendering of the item (so you can have a rule that has no displayMethod associated with it - XML Feed rule does this and it can be good if you have some one-off external/transient sources) 3. a direct rendering inside the rule (Random Fact does this - but I would prefer it used one of the first two methods - actually method 1 - to separate the View from the Model) The first option is the one that gives you the most flexibility and fits best in the FarCry framework (and current recommended coding practices). The concept is that you create up a structure for each item that your rules parameters return and pop them into the invocations array. If you check out some of the existing rules you will see what I mean. Basically you end up with an array of things that describe a key (the objected), the type of object that the data is, and the display method you want to use to render the information for this instance of the rule. This is very powerful because it means you can use that same rule in many places but have different parameters (including display methods) depending on the rules context. It also means that a rule can be very clever and pull data from multiple sources (like the Handpicked Rule) but present a unified model for FarCry to be able to then render the content appropriately. The second option is also great. It means you can very quickly create a rule that obtains data from ANYWHERE and create the rendering on the spot - rather than deferring the processing of the rendering to the container. This has its downside though as this means the rendering of the rule is static and will always appear the same no matter where you use that rule (which may be desirable in some cases). I have already given my opinion on rendering directly inside the rule. More specifically.... If you took the Random Fact rule you could cut out the portions that requested "category" as your Advertising is always in the "Advertising" category (if you wanted to have sub-categories of Advertising then leave the categorisation in and modify the "base" of where your category list would start from and grab all the categories underneath Advertising). Removing categorisation from your rule greatly simplifies the code you have to maintain - but may make the rule less flexible. If you expect a small number of items the randomisation method in Random Fact will be OK. If you intend to have a lot of items the method used will increase exponentially with size. You would want to look at a shuffle algorithm instead which will remain linear. I.E. put all possible keys into a list or array (pick the fastest - probably array) pick a random number to maxlength, get the key, add it into a new array/list, remove the one just copied from the original set (reduces maxlength by 1), start again. This method will take N passes to randomise (where N is the original number of items). What you could do in your case is to create up a different custom class that can obtain a random Advertisement. This class could then both randomise and cache Advertising news objectID's. This class could perform the above randomisation mechanism up to a nominated number to return guaranteed unique items for each call. Once you have your keys (in the order you want them) you loop through and create the invocations array (or use one of the other methods) so your content can be rendered. I would strongly recommend at least allowing the "number" of items to be configured in the update method - but default it to ONE. That way you can very easily get more than one if an occasion calls for it. And also allow the selection of a "display method" (even if you only have one of those at the moment). An "intro" field is something that I also always find useful to have. Make sure you check out a few of the other rules - specifically News - to see how the invocations stuff works. Once you understand how rules work in FarCry you will probably want to race off and create all sorts of rules to do "stuff". Containers, Rules and Display Methods are very kewl and form the core of the FarCry framework and provide a very stable mechanism of separating your data from your display and your retrieval logic. As I said in my reply to Tom.... If you think that you may have a use for your "Advertising" system in non-FarCry implementations and decide to create it as a stand-alone with an API, then the only change you would make to the above method is to use something like the External Type have mentioned recently to interface with the Advertising system. NOTE: most of the above probably forms part of the (longer) article that I am writing regarding the External Type extension that meshes nicely into the FarCry rule/displayMethod framework. Hope this has been helpful. Regards, Gary Menzel [PS - I note that Brendan has just posted the same suggestion - custom Rule based on Random Fact rule] --- You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
