I love the ability to cache views, but have a question on best
practice and proper API. I have a view that appears on every page
that is a complex table derived from a complex query. The data only
changes only once per week, so it's ideal for caching.
It seems to me that if my view is cached, there's obviously no need to
also cache the query. So I was thinking that the best practice would
be to first check to see if the view is cached and if not, and only
then run the query.
Is that considered best practice?
Second, assuming it is best practice, I found no simple API to do a
lookup() for cached views? After trolling through the Coldbox cfc's
it looks like I can do this:
if ( NOT
getColdboxOCM("template").lookup( getColdboxOCM("template").VIEW_CACHEKEY_PREFIX
& 'standingsPod') )
But that seems cumbersome? Is there a cleaner API? Also, the
"template" part does not seem to be documented as the way to do this
anywhere?
OK - I have created a viewlet and it works nicely!
I am not really sure that I see any practical difference between using
an eh for my viewlets or an interceptor? Can someone explain what the
resultant differences between the 2 approaches would be?
I can see how to implement both of them, I am just not sure how
"running an event" really differs from "announcing an interception
point" and when one is better to use than the other?
I am not really sure that I see any practical difference between using
an eh for my viewlets or an interceptor? Can someone explain what the
resultant differences between the 2 approaches would be?
I can see how to implement both of them, I am just not sure how
"running an event" really differs from "announcing an interception
point" and when one is better to use than the other?
now there is a good question! IMHO it comes down to AOP vs II styles
you are utilizing within your architecture.
in terms of Coldbox, i see Implicit invocation (II) as Handler
methodology, basically having events handled by a controller layer in
MVC, while Aspect-oriented Programming (AOP) is Interceptor
methodology, having events as triggered responses in line in a
request.
Wikipedia has a really good explanation if you are unfamiliar with AOP
- especially see their description of "cross cutting concern".
Interceptors are basically a great way to handle cross-cutting
concerns, things like logging, auditing, security, etc. Your example
seems to be a cross-cutting concern, when you say "I have a view that
appears on every page".
if you are calling a viewlet from one place only, stick with rendering
it in the Handler. If you are injecting this viewlet on certain page
requests only, go with Interceptor so you aren't having to call
renderView across multiple Handler methods. If it is truly every
single page, easiest may be to just render the viewlet directly in the
Layout.
OK - so I *am* actually rendering the Viewlet directly on the Layout
as it truly is on every single page (the same as I suppose site nav
would be?) Perhaps that's why I could not grasp the distinction
between "running" an event and "announcing" an interception... as they
both appear to be direct ways of "telling" the framework to render
this viewlet.
The concept of an interceptor being a "listener" for a specified event
to occur and then react make sense as a distinction, but when I am
having to tell the framework each time that this is an interception
point (i.e. making an announcement) it seems the distinction (in this
specific case anyways) is lost.
