Pen  wrote / napĂ­sal(a):
I have a few question regarding the wicket usage. we are trying to Implement
wicket as our next MVC framework, Can please someone answer the questions
below

Hi

- about session support - wicket stores the render state of most renderer's
in session for different users of the systems. This means large/very large
sessions that need to be supported, means memory crunch, performance
degradation and implementing the failover at production level really hard.
Wicket doesn't store a render state of renderer's (have no clue what that might be). Wicket stores a component tree of last page in session.

Btw. this doesn't even sound like a question, it sounds like stating facts, not to mention that the facts are based on wrong assumtptions.

Very large sessions? I've seen a model 2 application with sessions over a megabyte. Usually a wicket page is (unless it's a big one - with lot of components) around 30kb (of course this is very relative, this just reflects my experience with most of my wicket based projects). I don't think a 30kb session results in performance degradation or makes implementing failover difficult.


- Also it looks like wicket  requires code changes when more pages are added
and each page needs to have separate handler and it can not be done in
configuration file. This may become an issue when number of pages increase
in future.


What handler? What configuration file? Page has a class that implements the logic (probably what you mean by "handler"). How is this related to a config file? Wicket doesn't need any config file. There's no external plumbing. I fail to see how this results in an issue with increased page numbers, as the pages are completely independent.

Also I'm kinda missing a question mark in this question again, which make it seem like a statement (wrong again as far as I can tell). I'm not sure if that was intended.

-Matej

Dummy




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to