I need the ability to pass a 'class' param to a display method from the execute method of a rule.
You could also add class information by wrapping the container or rule with a DIV and assigning a class. Your style sheet could be set to detect specific nested classes and behave accordingly.. so how to do that?
Ahh no I wanted to change the display method on a per object basis in stInvocations for what I was doing - CSS selectors couldn't have done that for me. I've changed my design to be a bit simpler so I can avoid doing this, and just use CSS selectors by using the container's class as a parent class.
I need to wrap an entire rule's output in some html (before and after) but only if the rule outputs something (size(aInvocations) > 0). Maybe we could have display methods for rules?
No reason why you couldn't have multiple displays invoked by the execute method. Containers only understand UPDATE and EXECUTE but the rule itself could make reference to any number of display methods. In fact, you could even have different update handlers depending on the user.
I was just referring to maybe having a more structured way to add pre and post HTML to rules rather than placing them as strings into aInvocations. You may want to do reordering and what-not of aInvocations with the pre and post still staying constant.
Along the same idea, I need to wrap a entire container's output in some html (before and after) but only if the container outputs content.
Maybe this could be done just adding some params to the container tag or maybe something more robust is needed?
There are already pre and post HTML attributes for the container tag -- these shouldn't output anything if the aInvocations array is empty.
great -- Can't believe I missed it.
I need each rule's output in its own struct in aInvocations so as to distinguish each rule's objects in aInvocations.
How would you use this?
It seems silly to throw away the extra information (rule groupings) and just add everything to aInvocations. It would be just as easy to have container loop over all aRuleInvocations then all aRuleInvocations.aInvocations and would allow more control for filtering/reordering. It just seemed like a bizarre design choice -- but it's obviously been sufficient for your needs.
Also container filters could be quite powerful. They could be used to impelement something along the lines of removeDupes() before any rule's display method is called. Not sure if you need user-level assignment of filters or just have them defined in the template.
Ahah yes. De-duping or reordering are common requests theoretically but hard to get users to use containers at all let alone understand rules that act on container output only. But of course these are already possible in the current framework :)
Maybe to distinguish a content rule from a filter rule you could just add a property to the rule's CFC bIsFilter which is false in the base rule. You could then just add another button on the design screen for each container for filters. The publishing rule button's window just pulls up rules which bIsFilter=false, and the filter rule button's window just pulls up rules where bIsFilter=true.
This would give logical separation of content rules and filter rules for the users, and would be easy to implement.
At the mo I have to stick with outputting from execute()
How so? Why does your scenario not work in the current framework?
Well i don't anymore thanks to your above help. =)
-- tim
--- 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
