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 >>> > >>> >> >> >
