Maybe the idea of https://issues.apache.org/jira/browse/WICKET-2084 could be incorporated too.
El mar, 31-03-2009 a las 13:13 -0500, Jeremy Thomerson escribió: > 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 <igor.vaynb...@gmail.com>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 > > <jer...@wickettraining.com> 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 < > > > martijn.dasho...@gmail.com> wrote: > > > > > >> put it in 1.4 > > >> > > >> On Tue, Mar 31, 2009 at 7:01 AM, Igor Vaynberg <igor.vaynb...@gmail.com > > > > > >> 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 > > >> > <jer...@wickettraining.com> 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 < > > >> jer...@wickettraining.com > > >> >>> 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 < > > >> >>> jer...@wickettraining.com> 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 < > > >> 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 > > >> >>>>> > > > >> >>>>> > > >> >>>> > > >> >>>> > > >> >>> > > >> >> > > >> > > > >> > > >> > > >> > > >> -- > > >> 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. > > >> > > > > >
