the entire component hierarchy is stored in sessionit goes something like thisyou create a page and all its components, that page is stored in sessionwhen you click a link on that page wicket pulls out the appropriate page from the session , finds the appropriate link component, and invokes the lis
Actually may be using the term life cycle is not really accurate, the
thing I interested to know is like how many component is cached, what
is the level of caching? Say I have a component used in difference
page, are thoses component render difference times or it render once
then put to the cache a
> The biggest hurdle I can think of now, apart from API stabilization is
> the legal stuff. This will take us a while to get it according to
> Apache standards. And until the book is done, I hardly see us working
> on the legal things.
Why not? We have more than 10 active people in our team! :)
E
On 11/3/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> When the API is fixed, we can churn out betas and it'll
> be a few months until all the nitty gritty details are settled (though
> so far, there have not been that many urgent problems with 2.0).
The biggest hurdle I can think of now, apart
> 1) You mentioned tweaking the number of history items kept in the
> session as something to make sure to pay attention to. I understand
> wicket keeps a history of the component tree in the session on a
> render by render basis? Do you know of a good source where I can learn
> more about this mec
> It threw me for a loop when I saw that
> nested components need to be added to their parent and not the page.
> That is quite a different paradigm from what I am used to. =)
It's a commonly overlooked aspect in discussions about component
oriented frameworks. Page is just another component, thou
On 11/3/06, Ryan <[EMAIL PROTECTED]> wrote:
Thanks for the tips. Of course they have spawned a few more questions.I appreciate you taking the time to answer them!1) You mentioned tweaking the number of history items kept in thesession as something to make sure to pay attention to. I understand
wick
Thanks for the tips. Of course they have spawned a few more questions.
I appreciate you taking the time to answer them!
1) You mentioned tweaking the number of history items kept in the
session as something to make sure to pay attention to. I understand
wicket keeps a history of the component tree
why would that be help full in performance?What you should know when the session is created and when pages are created and what does happen to that after that. johanOn 11/3/06,
Carfield Yim <[EMAIL PROTECTED]> wrote:
I personally think this is nice to show the life-cycle from thecontainer start to
I personally think this is nice to show the life-cycle from the
container start to generate a page at some where in wiki. Sound like
this is a complex process that many user of wicket like to learn more
and understand more about the performance impact to their application?
On 11/3/06, Eelco Hillen
> I have a few questions:
>
> 1) Does anyone know of Wicket being used on a high traffic website?
I know of people building them, but the ones I know are not yet in
full production. But maybe someone else on this list knows.
> 2) What are some of the challenges related to scaling a Wicket
> appli
Hi Everybody,
I am currently evaluating several view frameworks for a large
enterprise application that is yet to be built. One of the primary
concerns of this application is response time. I have heard success
stories about Tapestry being deployed successfully in a similar
environment but have no
12 matches
Mail list logo
