That's one of the next things I want to work on later this week. Here's what I'm thinking:
- Make it so that any debug contributor can also contribute an overlay panel. - Make it so that any contributor can signal an error, which will make the debug bar blink red or something (not really blink, but something obvious). I would love to tie this in so that if there was a serialization error, for instance, that it would make the debug bar red. Then if you clicked a little error icon that would appear on the bar, it would open an overlay with your error messages in it. - Add a request timer / logger contributor for the bar -- Jeremy Thomerson http://www.wickettraining.com On Tue, Mar 31, 2009 at 1:10 PM, Igor Vaynberg <[email protected]>wrote: > good first step, nice job. would be nice to have the inspect stuff > open in an overlay rather than a separate page. > > -igor > > On Tue, Mar 31, 2009 at 1:23 AM, Jeremy Thomerson > <[email protected]> wrote: > > Thanks to both of you - I'm committing it now. > > > > Now, rather than adding an inspectorbug to your page, you should add a > > WicketDebugBar. Check it out in the examples. > > > > -- > > Jeremy Thomerson > > http://www.wickettraining.com > > > > > > > > On Tue, Mar 31, 2009 at 1:19 AM, Martijn Dashorst < > > [email protected]> wrote: > > > >> put it in 1.4 > >> > >> On Tue, Mar 31, 2009 at 7:01 AM, Igor Vaynberg <[email protected] > > > >> wrote: > >> > my vote is to pack it all into 1.4. once 1.4 is out we cannot have any > >> > api-breaking changes, so some things might be hard to move into 1.4.1 > >> > > >> > -igor > >> > > >> > On Mon, Mar 30, 2009 at 9:14 PM, Jeremy Thomerson > >> > <[email protected]> wrote: > >> >> So, I have created the submodule and moved the inspector bug as well > as > >> the > >> >> new stateless checker over to the submodule. The code is in my > >> experimental > >> >> branch, and tagged [1]. > >> >> > >> >> Question: do we want to include this in 1.4? In theory, it shouldn't > be > >> >> able to break anything because nobody's been using it unless they > were > >> >> compiling wicket-examples as a jar themselves. In which case, this > will > >> be > >> >> a welcome change. > >> >> > >> >> Next question: I'm going to continue with the rest of the things we > >> >> discussed in my branch. Will we want to include any of that in 1.4? > Or > >> >> should it wait until 1.4.1? > >> >> > >> >> -- > >> >> Jeremy Thomerson > >> >> http://www.wickettraining.com > >> >> > >> >> > >> >> > >> >> On Sat, Mar 28, 2009 at 7:31 AM, Jeremy Thomerson < > >> [email protected] > >> >>> wrote: > >> >> > >> >>> 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 > >> >>>>> > > >> >>>>> > >> >>>> > >> >>>> > >> >>> > >> >> > >> > > >> > >> > >> > >> -- > >> Become a Wicket expert, learn from the best: http://wicketinaction.com > >> Apache Wicket 1.3.5 is released > >> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. > >> > > >
