event generation bug

[Raymond Camden]

Looking for confirmation on this one.

I've got event generation turned on. I go to

event=weapons.fire

And MG correctly adds everything it needs to.

I then go to

event=shields.raise

and again, MG does the right thing.

But if I do

event=shields.lower

I get an unknown event error. It looks like the use case documented:

index.cfm?event=news.view
index.cfm?event=news.search

Doesn't actually work. Can someone else confirm that?

--
===========================================================================
Raymond Camden, ColdFusion Jedi Master

Email : r...@camdenfamily.com
Blog : www.coldfusionjedi.com
AOL IM : cfjedimaster

Keep up to date with the community: http://www.coldfusionbloggers.org

[Ezra Parker]

Hmm, seems to work fine for me...

--
Ezra Parker

> --
> 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 model...@googlegroups.com
> To unsubscribe from this group, send email to
> model-glue+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/model-glue?hl=en
>

[Raymond Camden]

Woah - get this. First hit to x.y works. Next hit to x.z fails. Reload
x.z and it works. wtf. Go to x.a and it fails and reload and it works.

[Ezra Parker]

Ah, OK. I'm now able to replicate this. I had been testing with CF 8,
and I just tried it with CF 9 and am observing the same behavior you
noted, where the first hit to a new event for an existing section will
return the event not found error, but it will work after a refresh.

Investigating...

--
Ezra Parker

[Ezra Parker]

OK, I think I know what the story is here.

Unless you're seeing something different, what I'm observing is
actually not an event not found error, but a *method* not found error:

The method test2 was not found in component MG3Test.controller.TestController.

The generation is actually working correctly, as if you go look at
your app you will find the new view file, controller method and XML
nodes have indeed been added, but the attempt to invoke the new method
on the controller is failing.

This appears to be caused by the new "Cache Template in Request"
setting in the CF admin, as disabling this setting (which I believe is
enabled by default) appears to resolve the problem.

I believe that the issue here is the fact that the controller CFC is
instantiated in order to determine whether the function to be
generated already exists, so I'm going to see if using
getComponentMetadata() instead of getMetadata() resolves the
problem...

--
Ezra Parker

[Mike Brunt]

This interests me Ezra as I can see that default setting in CF9
causing other issues, thank for the info.

Kind Regards - Mike Brunt
Senior Server Engineer
Cell: 562.243.6255
http://www.cfwhisperer.com
Twitter @cfwhisperer

[Ezra Parker]

I have created a branch with modifications that should resolve this
issue, which can be found here:

http://svn.model-glue.com/branch/eventgeneration/

Ray, if you have a chance, please try this out and let me know if you
encounter any further difficulties.

For anyone who's keeping score (e.g., Mike), using the
getComponentMetadata() function resulted in the same issue, so it was
necessary to read the component with cffile and search for the
function name in order to prevent the CFC from being cached for the
request.

Please let me know if anyone has any questions, or encounters any
problems when testing against this branch.

--
Ezra Parker

[Elliott]

Would a better way to solve this possibly be issuing a redirect back
to the same page? Then it would be a different request and the cache
wouldn't be an issue.

On Nov 20, 2:44 am, Ezra Parker <e...@cfgrok.com> wrote:
> I have created a branch with modifications that should resolve this
> issue, which can be found here:
>
> http://svn.model-glue.com/branch/eventgeneration/
>
> Ray, if you have a chance, please try this out and let me know if you
> encounter any further difficulties.
>
> For anyone who's keeping score (e.g., Mike), using the
> getComponentMetadata() function resulted in the same issue, so it was
> necessary to read the component with cffile and search for the
> function name in order to prevent the CFC from being cached for the
> request.
>
> Please let me know if anyone has any questions, or encounters any
> problems when testing against this branch.
>
> --
> Ezra Parker
>

> On Wed, Nov 18, 2009 at 3:21 PM, Mike Brunt <go2ri...@gmail.com> wrote:
> > This interests me Ezra as I can see that default setting in CF9
> > causing other issues, thank for the info.
>

> > On Wed, Nov 18, 2009 at 3:18 PM, Ezra Parker <e...@cfgrok.com> wrote:
> >> OK, I think I know what the story is here.
>
> >> Unless you're seeing something different, what I'm observing is
> >> actually not an event not found error, but a *method* not found error:
>
> >> The method test2 was not found in component MG3Test.controller.TestController.
>
> >> The generation is actually working correctly, as if you go look at
> >> your app you will find the new view file, controller method and XML
> >> nodes have indeed been added, but the attempt to invoke the new method
> >> on the controller is failing.
>
> >> This appears to be caused by the new "Cache Template in Request"
> >> setting in the CF admin, as disabling this setting (which I believe is
> >> enabled by default) appears to resolve the problem.
>
> >> I believe that the issue here is the fact that the controller CFC is
> >> instantiated in order to determine whether the function to be
> >> generated already exists, so I'm going to see if using
> >> getComponentMetadata() instead of getMetadata() resolves the
> >> problem...
>
> >> --
> >> Ezra Parker
>

> >> On Wed, Nov 18, 2009 at 2:59 PM, Ezra Parker <e...@cfgrok.com> wrote:
> >>> Ah, OK. I'm now able to replicate this. I had been testing with CF 8,
> >>> and I just tried it with CF 9 and am observing the same behavior you
> >>> noted, where the first hit to a new event for an existing section will
> >>> return the event not found error, but it will work after a refresh.
>
> >>> Investigating...
>
> >>> --
> >>> Ezra Parker
>

> >>> On Wed, Nov 18, 2009 at 2:08 PM, Raymond Camden <rcam...@gmail.com> wrote:
> >>>> Woah - get this. First hit to x.y works. Next hit to x.z fails. Reload
> >>>> x.z and it works. wtf. Go to x.a and it fails and reload and it works.
>

> >>>> On Wed, Nov 18, 2009 at 3:23 PM, Ezra Parker <e...@cfgrok.com> wrote:
> >>>>> Hmm, seems to work fine for me...
>
> >>>>> --
> >>>>> Ezra Parker
>

[Ezra Parker]

Well, I have to say that is definitely a more elegant solution that
what I ended up doing, as in addition to modifying the method used to
check for the existence of a controller function for the event, I also
had to move the generation process before the XML module loading in
order to circumvent the caching issue.

The only potential drawbacks I can think of regarding the redirect
approach would be the absence of the "Event Generation" trace message
in the MG debugging display, and a slight increase in overhead for a
generation request. Neither of these strikes me as being very
significant, and I rather like the simplicity of Elliott's suggestion.

Does anyone else have an opinion on the best way to go here?

--
Ezra Parker

[Raymond Camden]

Ezra - sorry I missed your reply. Going to try your mod later today.

[Raymond Camden]

Just an FYI, I confirmed this. Setting off in the admin everything
works perfectly. Setting on I got the error described.

On Wed, Nov 18, 2009 at 5:18 PM, Ezra Parker <ez...@cfgrok.com> wrote:
> OK, I think I know what the story is here.
>
> Unless you're seeing something different, what I'm observing is
> actually not an event not found error, but a *method* not found error:
>
> The method test2 was not found in component MG3Test.controller.TestController.

[Raymond Camden]

Ezra - I'd say to go ahead and do the redirect. Seems simplest/most direct.

On Fri, Nov 20, 2009 at 11:17 PM, Ezra Parker <ez...@cfgrok.com> wrote:
[deleted]