Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Implementing a logging system  (Read 9653 times)
justSteve
Courseware Beta
Sr. Member
***
Posts: 55


View Profile Email
« on: July 23, 2007, 06:57:51 »


I've had the chance to play around with Arch101 and danieleUg's ApplicationSkeleton enough to grasp the generalities. To my mind, the route to the next level is adding a layer of 'something' to see how stuff changes.

I think it would be useful to add a logging layer to provide a better visual sense of the circuitry involved. What's the route taken - how is the map drawn.

In the AS<3 days I'd just toss trace statements in at various points and watch the order of execution. That approach seems a) not feasible in as3; b) non-pure. Logging has changed at a fundamental level.

So my question at the point is, in a real world - production app, - given one of our existing demo apps - how would a team implement a logging system that helps bring junior members up to speed? How can logging be implemented in a centralized, generalized fashion?

thx
--steve...
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: July 23, 2007, 07:52:58 »

Steve,

I have been low-level processing this idea for a while now.

My idea includes an an 'intercepting facade' that overrides the notifyObservers method and tee's off a stream of info about notifications sent to a logging facility. It might also include regexp crunching of the source code as well.

Ultimately, it ought to analyze everything and spit out something like this:
http://puremvc.org/pages/demos/codepeek/AppGraph.swf

...that shows the layout of your app (note, double click to drill into the model and further into the proxies...).

Further, each node would also when clicked on show you all the notifications it listens for (if a Mediator or Command), those it sends, and link or display to the source code.

Of course this is all add-on tools and packages to come, and not new features for the framework itself.

-=Cliff>
Logged
justSteve
Courseware Beta
Sr. Member
***
Posts: 55


View Profile Email
« Reply #2 on: July 26, 2007, 07:17:08 »

The springy thingy looks cool and I don't doubt that is indispensable in larger project tho I might be the first one to admit that something about those things are just too....ummm....organic. I feel like i'm hurting 'em if I pull too far. And I _can't not _try to pull too far.

But as useful as I'm sure they are in some situations I'm wondering if the goal of getting a big picture map of relations and interactions doesn't require more persistence than the springie thingie. Have you seen the movie 'Stranger than fiction' where graphic overlays animate without demanding foreground focus. Shows a way that multiple points of focus can share the stage. Layers of focus.

But first things first....

I toyed around a little bit with implementing XRay and eventually got the object browser working but it was much too much hit or miss. The first place i tried to instantiate an xray connector tossed an error like '1067: Implicit coercion of a value of type '. Other attempts convince me that there are appropriate places to apply logging and not-so.

What I'm after at this stage is some general direction (or production system examples) as to the best way to add support for the Logging API.

Thx
--steve...
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: July 27, 2007, 08:31:06 »

Steve,

Don't hurt the springy thingy, its frail and only made of bits.  :P

In practical terms, first steps to getting a logging system would in my mind, be to get a handle on the Notification traffic.

That would best be done by overriding the notifyObservers method in your ApplicationFacade. It would {do something} then call super with the  Notification, so that everything continues as normal.

What that {do something} part is can be whatever.

It could be that you add a timestamped log entry to a logging proxy, which could in turn log client side activity to a server side resource. 

It could be you send another Notification that is picked up by a Mediator which dumps the data into a View Component that displays Notification traffic. This wouldn't start an infinite loop, because the ApplicationFacade would not use its own notifiyObservers method to send the logging notification, it would use the View's.

By routing everything through the Facade, not only do we essentially collapse the Model View and Controller into a single actor from the developers point of view, but we have a handy place to intercept traffic.

-=Cliff>
Logged
Pages: [1]
Print