Hi Luis,
coldbox looks great, i'm just starting to play with it.
one thing i think would make a huge improvement is event tracing.
i imagine this to consist of two things
1. event tracing, which would consist of diffing RequestContext
between events when runEvent is used, or even just between the start
and end of request... that way you can follow the changes which an
event makes to the RequestContext, espcially when you chain events.
2. event monitor, a little like the unix syslog or the old lotus notes
(arrgghh yuck) console. Basically a popup monitor like the cache
monitor which tracks events being called on the framework.. kinda like
livehttpheaders... but integrating the event tracing
having these would allievate some of the need for the old cfdump,
cfabort which i find my self doing a lot
Hi Zac,
Can you explain further what you would like to see. As I recall, the
debugging panel, let's you know all the events that get fired and
their execution times in specific order. Will this work?
Luis
Hi Zac,
Can you explain further what you would like to see. As I recall, the
debugging panel, let's you know all the events that get fired and
their execution times in specific order. Will this work?
ok, idea is to extend this with a diff of the requestContext between
each event, to show how each step modifies the requestContext with
added queries or flags etc
example with from the ColdBox WebServices Example (fake RC diffs added
to illustrate)
Timestamp Execution Time Framework Method
04:11:18.265 PM 10531 ms invoking runEvent [ehGeneral.doGetNews]
RC Diff: q_feeds, error_occurred added
04:11:18.281 PM 16 ms Rendering View [vwHome.cfm]
RC Diff body added
04:11:18.281 PM 16 ms Rendering Layout [Layout.Main.cfm]
and then to store this in a application variable which could then be
displayed in a popup "coldbox request monitor" window like the cache
monitor....
rather like the Livehttpheaders extension for firefox, but displaying
the events etc within each request from coldbox
Ok, now I am understanding. Keeping track of the events fired with diffs of the request context in a monitor like fashion. You could then clear the tracer or something. Ok, yes, this is interesting, I will start brainstorming some more. If you have more ideas on this, please post them here so I can base a ticket off of this. This is very interesting Zac. Maybe this log will only be available in debug mode and specifically turned on/off in the config? what do you think?
What about showing the entire requestContext, not the diff’s. Maybe you want to see the other values, flattened out?
ANy ideas? OSCAR?
Ok, now I am understanding. Keeping track of the events fired with diffs of
the request context in a monitor like fashion. You could then clear the
tracer or something. Ok, yes, this is interesting, I will start
brainstorming some more. If you have more ideas on this, please post them
here so I can base a ticket off of this. This is very interesting Zac.
Maybe this log will only be available in debug mode and specifically turned
on/off in the config? what do you think?
yep that makes sense...kinda like a db trace, it's heavy and you only
turn it on when you want it
What about showing the entire requestContext, not the diff's. Maybe you want
to see the other values, flattened out?
showing the entire request context prior to the first event makes
sense, being able to expand the requestcontext debug between each
event would be useful as a clickable option, ( with the changes
highlighted ) however, there is a lot of repeated information,
thats why i suggsted the diff approach
this has scope down the track to be extended into a test case tool type thing
I like the diff approach, do you have any more ideas in mind for this
feature?
Luis
let see....
being able to re-fire a request from the request monitor based on the
rc from the event would be good would be good, plus tracking execution
times per event, per request over time and graphing them would be
useful to pin point performance problems and repeat things
Zac