You can render a small piece of JavaScript at the end. There's serverandclienttimefilter iirc that does this.
Martijn On Tue, Mar 31, 2009 at 8:26 AM, Jeremy Thomerson <[email protected]> wrote: > 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 < > [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. >> > -- 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.
