Certainly full fledged visualizer is much more flexible and does not
have all the limitations the debugger views have, it is however much
more complex to develop and requires far more work.
There's already one prototype built for Autofac, and I met at last
Brisbane ALT.NET meeting a guy (can't recall the name :( ) that creates
similar thing targetting Autofac for now, but with plans to expand to
Windsor at some point.
However more than in proc visualizer I like the idea of something
similar to Ayende's profilers although that's something that would be
yet more work consuming.
Krzysztof
On 19/09/2010 6:03 PM, Jonathon Rossi wrote:
Nice, I like it.
If we wanted to go further than just a string for potential lifestyle
mismatches I think the only way is custom UI like
http://xmlvisualizer.codeplex.com/. I am not sure if this is something
that is worthwhile providing for all the registered components,
facilities, etc, like you have already done with the debugger object
graph. I would expect most people would be happy to use the debugger
object graph when the contents of the container is small, however
you'd probably want to be able to filter if you have hundreds of
components.
2010/9/19 Krzysztof Koźmic <[email protected]
<mailto:[email protected]>>
I don't think you can bold/italic it ;)
So you don't think that the fact that name of the component is in
quotations and lifestyle not is enough of a difference?
On 19/09/2010 3:39 PM, Ken Egozi wrote:
I like it very much. We've had a few times when with various
auto-wiring scenarios some components were missing or behaving
strangely and we found ourselves looking through the Handlers
collection and figuring out things manually.
So the debugger visualizer is great. Logging will be even
great-er but this would be a large change that needs to be
designed thoroughly so lets be happy with what we get.
As for the solution - I think it would be beneficial to mark the
lifestyle in a visual way to make it distinct. Is there any way
to tell the debugger to present things in italics/bold ? if not,
adding square brackets (or % or ^ sign, whatever) can help in
making it clearer.
2010/9/19 Krzysztof Koźmic <[email protected]
<mailto:[email protected]>>
hehe,
We'll do that also via logging in v3, but that requires
adding loggin throughout the entire framework and big changes
is something I wanted to avoid for .5 release.
This provides best (cost*risk)/benefit ratio. And it has
proven very valuable to me on several ocasions already :)
And not just me: http://mookid.dk/oncode/archives/1553
cheers,
Any other feedback?
On 19/09/2010 11:28 AM, John Simons wrote:
I think the idea of reporting such mismatches is great +1
but reporting them through visual debugger -1.
Sorry mate.
Cheers, John
On 19/09/2010, at 11:09, Krzysztof Koźmic
<[email protected]
<mailto:[email protected]>> wrote:
Windsor has no internal logging as of yet.
I consider adding it for v3 but adding logging, or adding
debugger visualizer is much more work.
This works only if you start your app with attached
debugger and break into the code where the container is in
scope.
Krzysztof
On 19/09/2010 11:06 AM, John Simons wrote:
So is this warning only available/visible in debug
attached mode?
Or can I also see it in my logs?
I guess what I'm trying to say is that imho this would be
more beneficial in the log then in the debugger visualiser.
Cheers, John
On 19/09/2010, at 9:47, Krzysztof Koźmic
<[email protected]
<mailto:[email protected]>> wrote:
Hi,
I've been working on a new addition for Windsor 2.5.1 in
its debugger views support.
The goal is to detect and report Singletons depending on
Transients or PerWebRequest components (directly or
indirectly) and report it.
Here's how it looks like in action:
<VS_live.png>
I call it "Potential Lifestyle Mismatches", because there
are some cases when what it reports is valid case.
At the top level menu I show the number of such
dependencies (sounds like the most reasonable thing to me).
One level in I show each such (direct or indirect)
dependency as "Depender" DependersLifestyle -> "Dependee"
DependeesLifestyle
Idea was to show enough information here, so that you
don't need to go deeper to fix the issue.
If you do want to go one level deeper though you get a
descriptive message of the issue and list of all
components in the dependency chain in question.
So you can see that C (singleton) depends on B
(singleton) which depends on A (Transient)
The description message looks like this:
<message.png>
*So now I want your feedback here - am I showing the
right information, is everything clear and intuitive?*
The code is not yet pushed, I need to do some cleanup and
testing first, which will take me an hour or two.
cheers,
Krzysztof
--
You received this message because you are subscribed to
the Google Groups "Castle Project Development List" group.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[email protected]>.
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
--
You received this message because you are subscribed to
the Google Groups "Castle Project Development List" group.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[email protected]>.
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
--
You received this message because you are subscribed to the
Google Groups "Castle Project Development List" group.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[email protected]>.
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
--
You received this message because you are subscribed to the
Google Groups "Castle Project Development List" group.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[email protected]>.
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
--
You received this message because you are subscribed to the
Google Groups "Castle Project Development List" group.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:castle-project-devel%[email protected]>.
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
--
Ken Egozi.
http://www.kenegozi.com/blog
http://www.delver.com
http://www.musicglue.com
http://www.castleproject.org
http://www.idcc.co.il - הכנס הקהילתי הראשון למפתחי דוטנט - בואו
בהמוניכם
--
You received this message because you are subscribed to the
Google Groups "Castle Project Development List" group.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:[email protected]>.
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
--
You received this message because you are subscribed to the Google
Groups "Castle Project Development List" group.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:castle-project-devel%[email protected]>.
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
--
Jono
--
You received this message because you are subscribed to the Google
Groups "Castle Project Development List" 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/castle-project-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups "Castle
Project Development List" 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/castle-project-devel?hl=en.
