It would need to cater for pages with multiple containers and they may or may not share parameters.
I'm not sure how this would be an issue. Parameters could be stored in REQUEST.container.ruletypename.parameters giving a unique scope for each type of rule.
I guess if multiple containers had the same rule type with different parameters you'd need to alter the scope before each container execution... but you'd have to prepare the passed in attributes for the container tag in the same way.
When I pass a parameter in, I may need to pass it in with a different argument name.
Can you elaborate?
When I was looking into this I was also reading up on decouple objects. I guess in the scope of a farCry application, this may not be an issue??
What advantages normally associated with decoupling in OO would be advantageous in this situation?
Containers and rules only work in the context of each other. Containers are always executed in the context of a presentation layer template. The REQUEST scope always exists in the context of an HTTP request.
I can only see the issue of REQUEST being a public scope that can be overwritten -- its unprotected. But then in many use cases this is desirable. And its hard to imagine a documented REQUEST.container.ruletypename.parameters scope being accidentally overwritten.
-- geoff http://www.daemon.com.au/
--- You are currently subscribed to farcry-dev as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
