It might be good to try to ask specific questions about those issues that
you've seen. You will get good help here on the list, and from my
experience, you won't get a much better / simpler programming model than
what Wicket gives you. I've used Tapestry, where everything was stuffed
into the url
Yes we've experienced issues with multiple browser windows as well as
synchronization of shared session resources. Again, this has nothing to do
with optimization but everything to do with craving a solid, simple
programming model for frontend developers.
/Casper
Johan Compagner wrote:
>
> We
We tried that once, to have state transfered to the client, we didnt
like it (where it did go to) and we dropped it.
Cpu time and bandtwidth is way more expensive then memory. Wicket
takes now memory on the server but the overhead it would generate by
serializing and base64 every page into the resu
Right - that would only work for POST since I believe the HTTP RFC limits GET
requests to 2 or 4K. By experience, in JSF, pushing state this way to the
webpage (base64 encoded and pk encrypted) has the benefits of request scope
(no thread-safety issue, no multi-browser issue etc.) while maintainin
He's not suggesting going stateless. He's suggesting an alternate way
of maintaining state (by pushing it to the client in hidden fields).
Tapestry supports (or supported) this as an option, but it made for
some pretty gnarly URLs (all the state had to be appended to the end)
for links. On forms,
No worries - you're right - Wicket is designed to manage state for you, so
it's strength is not statelessness. But, you should really evaluate if you
have the need for stateless before constraining yourself to it. As long as
you use models correctly, you can support thousands of concurrent sessio
Ok. It sounds like the general philosophy behind Wicket is server side
statefulness. I was kind of hoping this was not the case. Just out of
curiosity, haven't anyone tried serializing and embedding state out on the
webpage that could then be POST'ed between requests - a kind of hybrid model
betwe
Tip: don't double post or some people will jump on you - it doesn't help you
get a good answer.
Anyway, for completely stateless page transitions, etc, and how to put data
into the URL rather than session, you need to use BookmarkablePageLink,
which will invoke the YourPage(PageParameters) constru
Pardon the (possible stupid) question, I'm new to Wicket but is quite
excited about the simplicity it seems to promote over JSF.
What's the usual way of pushing context on to a website and have it passed
along, such as to remain stateless? In JSF you would typically create a
request scoped backing
Pardon the (possible stupid) question, I'm new to Wicket but is quite
excited about the simplicity it seems to promote over JSF.
What's the usual way of pushing context on to a website and have it
passed along, such as to remain stateless? In JSF you would typically
create some hidden inputs w
10 matches
Mail list logo
