Since ya'll seem to be around - another quick question. How would I put the total time it took to process the request into a Label? Since the label needs to render during the request, and the time it took to render the request obviously isn't over yet. At least a close approximation? Any ideas? The only thing I've thought of so far is a second request via ajax that retrieves a cached value from the previous request on that session - which would be buggy.
Not a big deal - just an idea. -- 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. >
