For quite a while now Ive been working on a new version of this website based on Model-Glue Unity. As a part of this update Im essentially rewriting the process by which users can add comments to blog entries.
Well, for the last hour or so Ive been battling a problem. After a new comment is posted I ask reactor for a query of all users subscribed to the entry so that I can send them an email notifying them of the new comment. I then want to include a view which will simply loop over the query and send out an email using the cfmail tag.
Heres the event handler for your reference:
<event-handler access="private" name="blog.subscribe"> <broadcasts> <message name="modelglue.genericDelete"> <argument name="object" value="EntrySubscription"/> <argument name="criteria" value="entryId,emailAddress"/> </message> <message name="modelglue.genericCommit"> <argument name="object" value="EntrySubscription"/> <argument name="criteria" value="entryId,emailAddress"/> </message> <message name="NeedSubscribers"/> </broadcasts> <views> <include name="email" template="dspNotifySubscribers.cfm"/> </views> <results> <result anchor="commentForm" append="entryId" do="blog.viewEntry" preservestate="false" redirect="true"/> </results> </event-handler>
Im honestly not sure why, but the system is sending me to the blog.viewEntry event before the dspNotifySubscribers.cfm is being included. I suspected that Unity ignores all views when the unnamed result is a redirect. To confirm this I set the redirect attribute to false and reran the event. Wonderfully the view was included, but unfortunately Im not being redirected as I wanted.
So, I decided to try to create another event handler which I would do my redirect. In other words, I changed the do attribute to run blog.goToViewEntry and redirect to false. I then wrote the blog.goToViewEntry event to do nothing but redirect to blog.viewEntry.
Theoretically this should have worked!
Did it? No!
Why? I dont know yet!
Does it matter? In the grand scheme of things, no.
But, as frustrated as I was, it was nice to see one thing
As least the Captcha Component felt my pain.
Comments on: "The Captcha Component Shares My Frustration" (2)
Nice story. 🙂
Sorry Doug, but this isn’t a bug.
(Ouch, what a lousy rhyme.)
With any redirecting named (explicit) result the redirect happens the moment the result is announced, before the view queue is rendered. With unnamed (implicit) results, it happens after the event-handler is complete, before views are rendered (as you’ve discovered).
It’d be inconsistent for one type to happen pre-view, and the other to happen post-view.
In your specific case, I’ve dealt with exactly the problem you’re in, and it was most cleanly solved by moving e-mail functionality out of views and into a service called by my controller layer.
Views are meant to render HTML, not to integrate with other protocols, and their mechanism represents this.