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.
