Oops - forgot link: [1] - http://www.symfony-project.org/
-- Jeremy Thomerson http://www.wickettraining.com On Sat, Mar 28, 2009 at 7:31 AM, Jeremy Thomerson <[email protected] > wrote: > 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 <[email protected]>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 >> <[email protected]> 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 >> > >> > >
