Marcus Crafter wrote:
> Hi Berin,
>
> Thanks for your answers, much appreciated.
>
> On Tue, Feb 12, 2002 at 10:13:58AM -0500, Berin Loritsch wrote:
>
>>Marcus Crafter wrote:
>>
>>> Should there be a start()/stop() method in the Profiler interface, or
>>> left up to the implementation ?
>>>
>>Good point, which would be more natural to you?
>>
>
> I would find it better in the interface - at least then it's a
> defined entry point into the profiler, and all implementations will
> use the same terminology.
We can make the Profiler extend the Startable interface to get it.
>>You are correct. A getName() method has been added ot Profilable.
>>
>
> Great. Thanks.
>
> Might getName() conflict with other classes that could contain such a
> generic method name ? How about getProfilableName() or something
> else indicating it's use in profiling and that won't conflict
> another interface, eg. Router.getName() or Customer.getName(), or
> OperatingSystem.getName(), etc ?
It is considered bad practice for a Component to have a getName(), but I do
see your point. Can I ask you this: Would it be reasonable to record the
Customer name/Router name as the name in the ProfileReport? I think so.
That saves the implementor from writing a new method.
>>The Group concept is a way to group the profile points together and
>>dynamically
>>create nicely scoped names. The group concept works to allow a GUI
>>ProfileReport
>>to present a nice tree view, or for Textual ProfileReports to create scoped
>>names to give the values some meaning.
>>
>>The latter statement you had is correct. The Profilable object can have
>>child
>>Profilable objects. I thought I had a nice graphic in there that shows how
>>it is supposed to work together.
>>
>
> The graphic is nice, but the letters G1, C1, C2, etc to me
> didn't mean anything in particular (ie. I didn't know whether
> they mean't profilable or profilable point ?). :)
Ok. The "node" or end is always the ProfilePoint. The graphic is to
show the order of group calls. All Groups/SubGroups are declared before
actual ProfilePoints are sampled.
>
> So your example:
>
> "Cocoon Container" Is the group name
> |
> +----------+-----------+
> | | |
> "Cache" "ECM" "Sitemap" Are the sub groups names
> | | |
> "misses" "requests" "500 Errors" Are the profilable point names
>
> and this would be built up like:
>
> report.addGroup("Cocoon Container", { "Cache", "ECM", "Sitemap" });
>
> (dynamically of course) ??
Yep.
> Ok, I understand so far (I think :) ), but how do the profilable point
> names get listed. addGroup() can't read them, and there
> doesn't seem to be any other method in ProfileReport to be able
> to specify them (or access from within the report
> via ProfilePoint.getName() ) ?
The Profiler sets the names in the addGroup() stage. Remember, the groups are
set up in advance, and the ProfileReport remembers those values when rendering
the report.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
