I guess I dont have the time to do the convincing - too many other
things to deal with at present.

I am simply moving more and more away from allowing access to any
global scopes.  If I have to, I will pass the WHOLE scope over (like
SESSION for example) to ensure that I am not tied to it in the future.

This approach has saved me lots of times recently.

The biggest "failure" of CFMX to support this approach is the FORM
scope when uploading files.


Gary


On Fri, 28 Jan 2005 19:47:27 +1100, Geoff Bowers <[EMAIL PROTECTED]> wrote:
> Andrew Mercer wrote:
> > 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/
>

---
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/

Reply via email to