Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
FuelPHProfiler
  • Haven't thought about it, but it needs to be something that either is (virtually) invisible on the page, something that can be popped up by some means, of in a separate window (like for example Smarty's debugger). I'm also thinking about a vertically tabbed interface, so the screen width doesn't limit you in the number of plugins you want to install. And I want to strip it from all built-in functionality, and go to to "everything is a plugin" and make if fully configurable. You only want session data? Only load that plugin... I plan to add a stub class to the core, with an __call() (or similar) method that just "absorbs" all method calls. So you can add profiler calls to your code that will become NOP's when the profiler, or the plugin needed, is not installed. When you then load the package, the bootstrap of the package can overload this stub class, and suddenly the methods of the plugins loaded become active... But I have to say I haven't spend a lot of time thinking about it yet...
  • The css is designed to look OK if you exceed width, the tab metaphor starts to break down but there is a correct select status.
    Make sure you have a look at Symfony2's profiler, got a lot of inspiration from that. I stopped short of implementing the "rendered in a separate request" as it seemed (like a lot of things in Symfony) overengineered and unnecessary in dev environment but the design is very nice. On the idea of invisibility: I have some code (in my application not the package) using $_REQUEST arguments and cookies to turn the profiler on and off eg
    local.mysite.com?profiler_on and local.mysite.com?profiler_off This state is then stored in a cookie so you only have to set it to turn it on or off.
    I might at some stage move this in to the package somehow I like the idea of an empty Core Profiler that can be replace, think it still needs a defined Interface to allow a common and documented API The package already has a "everything is a package" mentality, hence the profiling.tabs config array
    I'm not sure its quite the right implementation though

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion