While I can understand the need to cache different views, I do not like the
idea of invoking an event from the view. That is a break from the normal
pattern and while it may work, isn't really in the Model-Glue philosophy.
If this is a use case many people want to see, maybe we should look at a
more correct Model-Glue structure apart from using <cfset event =
event.getModelGlue().executeEvent('myEvent') /> inside an view. While it is
possible to get the reference to Model-Glue at that point, and it is
possible to execute a specific event, the intent is for that to be used by
the framework, not really consumers of the Model-Glue framework... and
certainly not in a view.
An event handler may be thought of as a top level entry point into an
application, like User.Form, or it also may be thought of as a container for
each of the three MVC portions of a specific process. In your case, if the
view requires something to be present in the event, I'd probably try to
break up the viewlets in to separate event handlers (private if necessary
and logical) then bundle the needed event-handlers in your top level events.
Then place any appropriate caching at the event handler level, since the
event-handler is cachable and is designed to deal with broadcasts, includes
and views.
<event-handler name="Main.Page1">
<results>
<result do="Viewlet1" />
<result do="Viewlet2" />
</results>
</event-handler>
<event-handler name="Viewlet1" cache="true"
cacheKeyValues="someID,anotherID">
<broadcasts>
<message-listener name="weNeedSomething" />
</broadcasts>
<views>
<include name="fluffy" template="theViewlet1.cfm" />
</views>
</event-handler>
<event-handler name="Viewlet2" cache="true"
cacheKeyValues="somethingelseID,evenmoreID">
<broadcasts>
<message-listener name="weNeedSomethingElse" />
</broadcasts>
<views>
<include name="cloudy" template="theViewlet2.cfm" />
</views>
</event-handler>
Using the above structure you get the same encapsulated benefits you get in
normal Model-Glue programming, and you also get modularity and
encapsulation. We can see the view dependencies in the Model-Glue.xml file,
and don't have to endlessly scan through all manner of files to see how the
application works and where the dependencies are between the views and the
model.
DW
On Thu, Jan 7, 2010 at 2:59 AM, andreacfm <[email protected]> wrote:
> I think that having single events in the queue caching separately ( I
> mean not only the initial event ) can be a good call.
> I also like the viewlets approach maybe cause I am used to leverage
> also an external event manager that carry
> portable functionalities between applications and also in model glue I
> normally tend to have events that make 1 thing.
> On event broadcast and as result call another event that include the
> view.
>
> Like this thinks becomes very very flexible.
>
> Andrea
>
> On Jan 7, 2:16 am, Ezra Parker <[email protected]> wrote:
> > Andrea,
> >
> > No offense intended, but to me the approach of invoking events from
> > the view in this manner has a "code smell" to it, and this seems
> > inelegant in that you will now need a separate event to contain the
> > necessary message broadcasts for each of these "viewlets". I would
> > much prefer to handle this use case by adding the capability to cache
> > an event queued by a result, as this would encapsulate all the
> > necessary elements within a single event-handler in the XML config,
> > and not "break" the typical MVC pattern.
> >
> > --
> > Ezra Parker
> >
> >
> >
> > On Wed, Jan 6, 2010 at 11:23 AM, andreacfm <[email protected]>
> wrote:
> > > Ezra,
> >
> > > when caching views is working you can dispatch the event that creates
> > > the data for the view from the view itself.
> >
> > > myview.cfm ( cached )
> >
> > > event = event.getModelGlue().executeEvent('myEvent')
> >
> > > #generate output#
> >
> > > Now you can have both : flexibilty in view cachign and portability of
> > > your "viewlet"
> >
> > > Andrea
> >
> > > On 4 Gen, 10:07, Ezra Parker <[email protected]> wrote:
> > >> I can confirm that despite the fact that the docs indicate views can
> > >> be cached, this capability does not presently exist. The caching
> > >> support included in the EventContext will currently only work to cache
> > >> an entire "top-level" event, by which I mean an event that is directly
> > >> invoked, *not* an event that is queued by using a result.
> >
> > >> I agree with Andrea that this is limiting, and that we should ideally
> > >> include support for caching at a more granular level, but I don't
> > >> think that allowing the caching of views directly is the best
> > >> approach. I say this because unless one is dealing with a view that
> > >> only references event data that is defined in the MG XML config (or
> > >> does not pull anything from the event), then messages that are used to
> > >> retrieve data for a view will still be broadcast even if the view
> > >> itself is cached, thus partially defeating the purpose of caching.
> >
> > >> As caching of event types presents other difficulties (the fact that
> > >> messages, results and views from a type are merged into a typed
> > >> event-handler when modules are loaded, and the caching of content
> > >> occurs during invocation), it seems to me that the best strategy would
> > >> be to allow for events queued via results to be cached as well.
> >
> > >> --
> > >> Ezra Parker
> >
> > >> On Sun, Jan 3, 2010 at 7:45 AM, andreacfm <[email protected]>
> wrote:
> > >> > I also tried to add a key but in all my tests I can confirm I can
> cahe
> > >> > just the main event handler.
> >
> > >> > Andrea
> >
> > >> > On 3 Gen, 15:57, [email protected] wrote:
> > >> >> This is an important topic and one that needs to be discussed.
> >
> > >> >> I'm traveling right now and only have my Blackberry, which means I
> won't be of much help.
> >
> > >> >> I recall from the documentation on caching about a need to define a
> key of some sort for the content to be cached, and it does not appear like
> you've defined any such thing.
> >
> > >> >> Is there in fact a key attribute required for caching to work?
> >
> > >> >> Sent from my Verizon Wireless BlackBerry
> >
> > >> >> -----Original Message-----
> > >> >> From: andreacfm <[email protected]>
> > >> >> Date: Sat, 2 Jan 2010 09:22:13
> > >> >> To: model-glue<[email protected]>
> > >> >> Subject: [Model-Glue] Re: caching on include declaration
> >
> > >> >> Dan,
> >
> > >> >> I am testing on cf 8.1.
> > >> >> MG is latest ones just downloaded.
> >
> > >> >> An easy snippet can be :
> >
> > >> >> <!-- home -->
> > >> >> <event-handler name="page.index"
> type="layout.site.main">
> > >> >> <views>
> > >> >> <include name="body"
> template="pages/index.cfm" cache="true"/>
> > >> >> </views>
> > >> >> </event-handler>
> >
> > >> >> If you place a dump now() into index.cfm you will note this is not
> > >> >> cached.
> >
> > >> >> In this case for example I would like to be able to just cache the
> > >> >> index view while the rest of the thread ( event-type in this case )
> > >> >> will be processed at runtime.
> >
> > >> >> What I see is that at the moment I can cache just the main event.
> This
> > >> >> is quite limitating in my opinion cause I cannot choose what slice
> of
> > >> >> my template
> > >> >> take from cache and what process.
> >
> > >> >> This also make inpossible a "viewlet" approach ( a view that invoke
> an
> > >> >> event and craete an output to be cached ).
> >
> > >> >> What do you think about?
> >
> > >> >> Andrea
> >
> > >> >> On 2 Gen, 17:12, Dan Wilson <[email protected]> wrote:
> > >> >> > Hey Andrea,
> >
> > >> >> > Thanks for starting the discussion. Would you be able to provide
> some
> > >> >> > additional information?
> >
> > >> >> > 1- What version of Model Glue?
> > >> >> > 2- What version of ColdFusion?
> > >> >> > 3- A sample of the code that does not work along with a
> description of what
> > >> >> > you feel should be happening?
> >
> > >> >> > Dw
> >
> > >> >> > On Sat, Jan 2, 2010 at 11:04 AM, andreacfm <
> [email protected]> wrote:
> > >> >> > > HI,
> >
> > >> >> > > looks like the caching on the include declaration is not
> working.
> > >> >> > > Does someone can confirm that?
> >
> > >> >> > > Thanks
> >
> > >> >> > > Andrea
> >
> > >> >> > > --
> > >> >> > > Model-Glue Sites:
> > >> >> > > Home Page:http://www.model-glue.com
> > >> >> > > Documentation:http://docs.model-glue.com
> > >> >> > > Bug Tracker:http://bugs.model-glue.com
> > >> >> > > Blog:http://www.model-glue.com/blog
> >
> > >> >> > > You received this message because you are subscribed to the
> Google
> > >> >> > > Groups "model-glue" group.
> > >> >> > > To post to this group, send email to
> [email protected]
> > >> >> > > To unsubscribe from this group, send email to
> > >> >> > > [email protected]<model-glue%[email protected]>
> <model-glue%2bunsubscr...@googlegrou ps.com>
> > >> >> > > For more options, visit this group at
> > >> >> > >http://groups.google.com/group/model-glue?hl=en
> >
> > >> >> > --
> > >> >> > “Come to the edge, he said. They said: We are afraid. Come to the
> edge, he
> > >> >> > said. They came. He pushed them and they flew.”
> >
> > >> >> > Guillaume Apollinaire quotes
> >
> > >> >> --
> > >> >> Model-Glue Sites:
> > >> >> Home Page:http://www.model-glue.com
> > >> >> Documentation:http://docs.model-glue.com
> > >> >> Bug Tracker:http://bugs.model-glue.com
> > >> >> Blog:http://www.model-glue.com/blog
> >
> > >> >> You received this message because you are subscribed to the Google
> > >> >> Groups "model-glue" group.
> > >> >> To post to this group, send email to [email protected]
> > >> >> To unsubscribe from this group, send email to
> > >> >> [email protected]<model-glue%[email protected]>
> > >> >> For more options, visit this group athttp://
> groups.google.com/group/model-glue?hl=en
> >
> > >> > --
> > >> > Model-Glue Sites:
> > >> > Home Page:http://www.model-glue.com
> > >> > Documentation:http://docs.model-glue.com
> > >> > Bug Tracker:http://bugs.model-glue.com
> > >> > Blog:http://www.model-glue.com/blog
> >
> > >> > You received this message because you are subscribed to the Google
> > >> > Groups "model-glue" group.
> > >> > To post to this group, send email to [email protected]
> > >> > To unsubscribe from this group, send email to
> > >> > [email protected]<model-glue%[email protected]>
> > >> > For more options, visit this group at
> > >> >http://groups.google.com/group/model-glue?hl=en
> >
> > > --
> > > Model-Glue Sites:
> > > Home Page:http://www.model-glue.com
> > > Documentation:http://docs.model-glue.com
> > > Bug Tracker:http://bugs.model-glue.com
> > > Blog:http://www.model-glue.com/blog
> >
> > > You received this message because you are subscribed to the Google
> > > Groups "model-glue" group.
> > > To post to this group, send email to [email protected]
> > > To unsubscribe from this group, send email to
> > > [email protected]<model-glue%[email protected]>
> > > For more options, visit this group at
> > >http://groups.google.com/group/model-glue?hl=en
>
> --
> Model-Glue Sites:
> Home Page: http://www.model-glue.com
> Documentation: http://docs.model-glue.com
> Bug Tracker: http://bugs.model-glue.com
> Blog: http://www.model-glue.com/blog
>
> You received this message because you are subscribed to the Google
> Groups "model-glue" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]<model-glue%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/model-glue?hl=en
>
--
“Come to the edge, he said. They said: We are afraid. Come to the edge, he
said. They came. He pushed them and they flew.”
Guillaume Apollinaire quotes
--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
