Question 1:
Was wicket ever tested within a high request volume environment, meaning a
site with lots of users and requests per second? If it was, are there
any stats or ideas on how much memory is required per user on average?
What is high request volume? How many users are we talking about then?
But we are constantly looking at performance and memory consumption.
in the time of the release 1.1 i have being able to fix quite somethings for memory and cpu consumption
Some are in the 1.1 release others where to heavy and are in the 1.2 stream.
I will check the current state in the comming week.
I personally think that wicket will not be the bottleneck for a high request volume environment
But the database will.
Question 2:
Our project is going to be using a different markup other than xhtml,
namely, XDIME, which is a device independent markup language usually
used to render the pages on mobile phones. They are quite similar,
except for things like forms, which contain different tags, as well as
different hierarchy within the markup (ie. the multiselect in a form
is defined as <xfmuselect> with the options following one by one.) How
much of a problem will this present? Will I have to write
wicket.markup.xdime.*? If yes, what would be a good pattern to use to
avoid code duplication? If no, how is the wicket team thinking about
supporting other markups?
That is the the way, you need to create youre own Page (just like WebPage)
and then make for specific components a n implementation.
We (the wicket core team) just didn't need it (except XmlPage) but it would be great
to have such a thing!
Question 3:
In our design, we want the customer to be able to lay the
components in a simple, stacked, sequential layout for the future, so
we actually have one Page/PageLayer, which gets the order of the
components and calls them accordingly. So I will probably be using
something like ListView with sequential Panels inside, which will be
the actual components. Has anyone tried something similar, meaning a
one page app instead of the regular multiple pages approach? Will
there be any problems bugging me in the future if I choose this approach?
This is possible. But wouldn't be my solution.
Don;t make big monolitic things. Divide it and make easy to use small things.
you can ofcourse use panels and use setVisible or replace panels in the main page.
johan
