Yes - I agree. I think that would be the next step. I've been doing some work on a PHP site lately - which at first I thought I was going to hate. But everyone at that company only knew PHP - so I chose to go with Symfony [1] - and I've enjoyed it. Anyway, the point is - they have a great floating toolbar at the top right of the screen in development mode that gives you each query that was run, logging output for that request, timing for different cycles of the request, etc. It's great.
I'd love to build something like it that would allow you to register various contributors to add different details to the debug bar. But I think that the proposal below is sort of the first step towards that. -- Jeremy Thomerson http://www.wickettraining.com On Sat, Mar 28, 2009 at 2:42 AM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote: > martijn and matej and i talked about having a floating console that > can be enabled at runtime and that would host all these kinds of > tools. so basically extending or encorporating our existing ajax > console into something much more powerful. seems like if we move away > from having these tools as pages and making them panels we can create > a console. > > -igor > > On Fri, Mar 27, 2009 at 9:17 PM, Jeremy Thomerson > <jer...@wickettraining.com> wrote: > > Please review WICKET-670 [1] and give your input. The idea is basically > > that we want to be able to use the inspector bug and associated > > development-time utilities in our applications. Currently, the inspector > > bug is built into wicket-examples, which builds as a war, which makes it > > difficult to include in your app. We just added the @StatelessComponent > > annotation and associated checker to wicket-core which is meant for > > development time error catching. > > > > I'm proposing that we: > > > > - Create subpackage wicket-devutils (by subpackage, I mean a maven > > submodule, etc, similar to wicket-extensions - lives as a folder in the > > wicket core tree) > > - In it, put the inspector page(s), inspector bug and related utilties > as > > well as the new @StatelessComponent > > - Add to it a common place that all such dev utilities get their on/off > > switch (which will read from application's debug settings, perhaps) > > - Enable it in dev by default, off in prod by default, but have a way > > that it can be enabled in production (by setting the value in debug > > settings) > > - As Jon suggested - the pages will throw an exception if they are > > accessed and are disabled at the time. > > > > > > Thoughts? I'd like to get this done in the 1.4 release so that it's > > available to all those who pick up Wicket in the next year while we're > > working on 1.5. > > > > [1] https://issues.apache.org/jira/browse/WICKET-670 > > > > -- > > Jeremy Thomerson > > http://www.wickettraining.com > > >
