Suggestion : Log in same array or group with several call

[GoogleCodeExporter]

I wish to be able to log in same array or group with multiple call.

Example
with a new fbg('placeHolder','label',object) log function where :
'placeHolder' is the group or array name
'label' is the label of object
object is the var to dump

use case: To log some SQL trace 
After a parse of request
fbg('sqlTrace1',  'request',$request);
After the exec
fbg('sqlTrace1', 'exec time', $elapseTime);
After reading data
fdg('sqlTrace1', 'fetch', $data);

At end of script, firePhp will parse each different placeHolder and dump
each one in a firebug group or an array

With this way, if i have multiple sql session, i will be able to log each
sql transactions of each sessions distinctly without to melted session log

Original issue reported on code.google.com by tit...@gmail.com on 10 Oct 2008 at 5:21

[GoogleCodeExporter]

Original comment by christ...@christophdorn.com on 14 Oct 2008 at 1:37

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

@See http://n2.nabble.com/firephp-groups-tp1371671p1371671.html

I think the grouping mechanism of firephp would make more sense, if you would 
really
groups them together, i.e. if you have two groups with the same name, which are
generated at different locations in your code that these groups are not 
presented in
firephp as different groups and so show up disjunctive, but rather form one(!) 
group

e.g.
[code]
$firephp->group('Group1');
$firephp->log('log1');
$firephp->log('log2');
$firephp->endgroup();

// ...

$firephp->group('Group1');
$firephp->log('log3');
$firephp->log('log4');
$firephp->endgroup();
[/code]

should show as

+ Group1
  log1
  log2
  log3
  log4

and not as

+ Group1
  log1
  log2
...
+ Group1
  log3
  log4 

Original comment by christ...@christophdorn.com on 2 Nov 2008 at 3:41

[GoogleCodeExporter]

As i need this functionality, i start to implement it.
Please find my current implementation of it.

Every firebug functions but dump have an equivalent ending with To
Eg for log
$firebug->logTo()
fbTo()
FB::logTo()

I didn't implement dump because i'm not sure there is interest or meanings to 
do it.

All new functions works in same way but take a new first parameter that is the 
named
group.
eg.
$firebug->logTo('logGroup', $object, $label);
DB::logTo('logGroup', $object, $label);
fbTo('logGroup', $object, $label);

The tableTo function is slightly different because it's allow to merge a table 
with
multiple call.

eg. Each call to tableTo with same destination will merge array
$firephp->tableTo('myTable', $tableLabel, $table);
$firephp->tableTo('myTable', null, $addToTable);

A new option showNamedGroup (true by default), will create firebug group for 
each
namedGroup (except for table since namedGroup means merging)

The first call to firephp will automatically start output buffering.
There is an example file.

Hope this can be useful.

Regards,

Original comment by tit...@gmail.com on 5 Nov 2008 at 4:32

Attachments:

• firePhp#46Enh.ZIP

[GoogleCodeExporter]

I like your approach a lot. I'll take a look at the underlying implementation 
when I
get a chance.

Just one observation. I would change the table method to:

$firephp->tableTo('GroupName', $tableLabel, $table, $merge);

Where $merge is a boolean value to indicate if the table should be merged. This 
would
ensure consistentcy with the other *To() methods and allow tables in groups.

I would also implement nested groups. A nested group could be specified with:

'/Group1/Group2'

with the "/" at the beginning indicating that it should start at the top-most 
level
(an absolute group path). If the "/" is missing at the beginning of the group 
path
you would get a relative group math, meaning it would append your group to the 
last
absolute group.

You can also use "../SubGroup" to go up one level in the last absolute path.

This would allow for different objects to keep their logging data together in
addition to allowig intelligent nesting of objects.

What do you think?

Original comment by christ...@christophdorn.com on 5 Nov 2008 at 7:04

[GoogleCodeExporter]

Another thought. We could also use this API:

$firephp->to('Group/Path')->log();

It would allow you to keep a reference to the target group:

$group = $firephp->to('Group/Path');

And would not require us to introduce a whole bunch of new and only slightly 
modified
methods. It may be longer to type, but would make a much cleaner API. I don't 
think
this is too much of an issue as logging groups are typically only used when the
logging statements are carefully placed and will remain in the code.

Original comment by christ...@christophdorn.com on 5 Nov 2008 at 7:07

[GoogleCodeExporter]

Omg! I didn't even know that firebug group could be recursive... 

I like a lot the idea of specified group with a path.
I'll dig my mind on how implements different options (abtsolute, relative, and 
..)
you have suggested.

tableTo with merge option will change signature from the original table 
function. It
may be confusing but i'm ok with the idea.

I really like the idea of ->to() API. The lenght is not a problem since you 
have add
phpdoc, there is completion, and even without it, it's not so long and may give 
a
real cleaner API.

Just somthing i didn't say in my previous post. As the log to named group need 
to be
asynchronous, actually, every regular log will appears first in firebug console.
I flush the log queue at end of script but flushQueue could be public, so user 
can
flush the queue when needs to. 

If you want to preserve order of all logs, we should put all logs in queue. 
Could be
interesting way because log calling may be faster. 

Original comment by tit...@gmail.com on 6 Nov 2008 at 1:35

[GoogleCodeExporter]

Keeping a buffer and flushing it at the end is fine for now.

I have plans to add a "Group" key to the meta info for each log message so the 
client
extension can group the messages rather than the server library. That way 
messages
can be added to the headers as they come in.

Original comment by christ...@christophdorn.com on 6 Nov 2008 at 8:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Please, find a proof of concept with what you suggested.
All functions are done but dump (in FirePHP).

Array merge is done if you log an array with same label in same group

Tell me what do you think about it.

Original comment by tit...@gmail.com on 7 Nov 2008 at 4:03

Attachments:

• firePhp#46Enh2.ZIP

[GoogleCodeExporter]

Not sure I like the merging with the same label. There are many cases where I 
would
not want that to happen.

What if we use something like $firephp->log('Message', 'Label', FirePHP::MERGE) 
where
the third argument is a bitmask of options.

The implementation you made while flexible needs a lot of code. I was hoping to 
wrap
all the functionality into the FirePHP class.

Until I have implemented the "Group" meta functionality in the extension we 
could
simply que all messages and refactor them by looking at the Group meta info and
generating the groups before flushing the messages.

This would dramatically simplify the logging code and implement the ->to()
functionality as it would be in the final version.

->to() should return a simple FirePHPGroup class that keeps the value of the 
"Group"
meta info that gets used for each message when logged through the group 
instance.

I know that this way of doing things is not very object oriented, but I am 
trying to
keep the core implementation very compact. We can build a completely object 
oriented
and very flexible implementation for the Zend Framework which already has the 
OO base
for the rest of the core library. 

What do you think?

Original comment by christ...@christophdorn.com on 7 Nov 2008 at 6:39

[GoogleCodeExporter]

About merge, the problem is to identified on which table the merge should be 
done.
FirePHP::MERGE will said that a merge should be done, but where...

I implement this way the queue to make minimal impact on core (actually, it s 
just
add to() function). But this just a proof of concept about functionality. The 
way of
coding is free even if i prefer specialized class to avoid to big class of 
function.

Original comment by tit...@gmail.com on 8 Nov 2008 at 9:04

[GoogleCodeExporter]

The merge would be based on the Label, but if the merge flag is not set a second
table with the same label would be added.

Original comment by christ...@christophdorn.com on 8 Nov 2008 at 5:32

[GoogleCodeExporter]

So it's means to manage stack of table and merge on last added in same group 
with
same label... Are you sure the complexity added to manage that will worth the
flexibility it give ?
Does change group or label is really an issue ? Isn't similarly to dump process 
?
Anyway, everything is possible.

Original comment by tit...@gmail.com on 9 Nov 2008 at 8:48

[GoogleCodeExporter]

I think it is worth the effort.

If we log the messages with the "Group" meta info and then re-arrange them into
groups when the buffer is flushed it should not take a lot of code at all.

Original comment by christ...@christophdorn.com on 9 Nov 2008 at 6:03

[GoogleCodeExporter]

Ok, i'll work on that after my long week end :)

Original comment by tit...@gmail.com on 10 Nov 2008 at 7:55

[GoogleCodeExporter]

FYI: I will not be online much in the next month as I will only have dial-up.

Original comment by christ...@christophdorn.com on 10 Nov 2008 at 8:17

[GoogleCodeExporter]

Hi, 

Here a new version with :
- Most of code is in FirePHP class
- FirePHPGroup class hold instance of group
- FirePHPLog hold data entry to log
- Log queue is just an array of FirePHPLog 
- All functions are using the queue (a default group is created as '/')
- Code that reorder queue or merge table is set apart, so it will be easier to 
remove
it when extension will natively manage groups.
- Merge table is done in same group with same label and FirePHP::MERGE flag is 
given
- fb has been split to make it more easier to maintain

Let's me know what do you think about it.

Original comment by tit...@gmail.com on 20 Nov 2008 at 11:17

Attachments:

• firePhp#46Enh3.ZIP

[GoogleCodeExporter]

Another thing:
Group creation order is preserved.

Original comment by tit...@gmail.com on 21 Nov 2008 at 11:20

[GoogleCodeExporter]

Wow. Great work! I'll take a closer look at it as soon as I get a chance. Feel 
free
to add group support to the default processor within FirePHP. Once that is 
added you
can remove the logic from the server code.

See: http://www.firephp.org/Wiki/Reference/CustomizeDisplay

Original comment by christ...@christophdorn.com on 21 Nov 2008 at 9:55

[GoogleCodeExporter]

I'm sorry but I didn't get it : will you integrate those changes in the next 
version
of FirePHP ? I think the code is great because it add a great functionality but 
also
don't modify the code itself a lot and then you stay with the simplicity of 
FirePHP
as now...

Original comment by laurent....@gmail.com on 11 Feb 2009 at 8:06

[GoogleCodeExporter]

Yes, I will. Just need to get around to starting on the tickets. I am still 
working
on a new foundation for FirePHP that will take it to the next level. I'll be 
posting
some progress info on my blog soon.

Original comment by christ...@christophdorn.com on 11 Feb 2009 at 4:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Issue 105 has been merged into this issue.

Original comment by christ...@christophdorn.com on 3 May 2009 at 5:02