nice :)
why this thread is our biggest Achilles heal is beyond me..
http://www.nabble.com/Directly-map-a-bean-to-HTML-form-tf2845102.html#a7944709
johan
On 12/21/06, karthik Guru [EMAIL PROTECTED] wrote:
someone else picked it up too ;-)
What do you mean ?
Paolo
On 12/21/06, Johan Compagner [EMAIL PROTECTED] wrote:
why this thread is our biggest Achilles heal is beyond me..
http://www.nabble.com/Directly-map-a-bean-to-HTML-form-tf2845102.html#a7944709
johan
On 12/21/06, karthik Guru [EMAIL PROTECTED] wrote:
someone
I really like the guy who say : which one is the better, emacs or VI. This
is the exact same point here and I like the irony of making this statement
in that post!
Even if I never touch to tapestry, I think it should be good enough. Why in
open source (In general, it's not my first mailling
Здравствуйте, Marc-Andre.
Вы писали 21 декабря 2006 г., 19:05:39:
I really like the guy who say : which one is the better, emacs or
VI. This is the exact same point here and I like the irony of
making this statement in that post!
Even if I never touch to tapestry, I think it should be good
I think I seriously owe an apology here. I seriously didnt mean to start a
flame war. Its just that I c'dnt help posting this - as this was the first
time I ran into a wicket related post in the Tapestry user list.
and the 'achilles heel' came along later. ( may be i should have seen it
coming)
you didn't start a flame ware here
I just commented on a bit that they think that thread has something to do
that is bad with wicket (our Achilles heel) why that is is strange.
What was wrong with that thread except that we didn't support and removed
something that we didn't want to improve
and
And InfoQ picked up this thread:
http://www.infoq.com/news/2006/12/wicket-vs-springmvc-and-jsf
Martijn
--
Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket
Wicket 1.2.3 is as easy as 1-2-3. Download Wicket now!
http://wicketframework.org
someone else picked it up too ;-)
http://www.nabble.com/Can-you-comment-on-this--tf2858705.html
regards
Karthik
On 12/20/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
And InfoQ picked up this thread:
http://www.infoq.com/news/2006/12/wicket-vs-springmvc-and-jsf
Martijn
--
Vote for Wicket at
: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ryan
Sonnek
Sent: Thursday, December 14, 2006 5:02 PM
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] Why I recommended Wicket...
Other points of consideration is long term maintenance. A
component oriented framework
Wicket is the framework that I've been looking for for a long time. The
certain feature of wicket that made itself the fovorite of mine is it
doesn't allow me (and anyone from my co-programmers) to put programming
logic in the markup. A little wicket-specific tags, one wicket:id attribute
and
Despite the trade off you depict very well, I can still the benefits of
this approach:
- no more session time outs,
- infinite number of pages in pagemaps,
- and a bit more theoretic: smooth scalability. I say theoretic since it
is not likely you'll need this kind of scaling.
Regards,
On 12/17/06, Erik van Oosten [EMAIL PROTECTED] wrote:
Despite the trade off you depict very well, I can still the benefits of
this approach:
- no more session time outs,
That depends, then we also have to serialize the WebSession with every page.
The problem with that approach e is that you
- and a bit more theoretic: smooth scalability. I say theoretic
since it
is not likely you'll need this kind of scaling.
And that is just what igor was trying to explain. You will not get
smooth scalability
Because much more cpu power is needed and more importantly
client side storage doesnt really make sense. what you make up in ram you
give up in cpu+bandwidth. which is cheaper?
lets say you have a page that is 30k big when the object graph is
serialized. you need to store it on the client. you need to encode it first,
usually base64 encoding which
umm... a whole bunch? like about 65K pages.
igor.vaynberg wrote:
client side storage doesnt really make sense. what you make up in ram you
give up in cpu+bandwidth. which is cheaper?
lets say you have a page that is 30k big when the object graph is
serialized. you need to store it on
You can do what every you want.
in Wicket1.3/2.0 you don't have only the choice of what we have now
(SecondLevelCache or the 1.2.x way of doing things)
No you can be in control what to do with the pages that are falling out of
the pagemap.
The pagemap only hold 1 page anymore, so session are very
Thanks Johan, this explanation is crystal clear! Very interesting stuff
indeed.
Regards,
Francis
On 12/16/06, Johan Compagner [EMAIL PROTECTED] wrote:
You can do what every you want.
in Wicket1.3/2.0 you don't have only the choice of what we have now
(SecondLevelCache or the 1.2.x way of
Igor Vaynberg wrote:
disadvantages being that fail over is harder unless the disk is shared
between the cluster nodes. the disk can always be replaced by a database
as well. the whole idea is relatively new and we have yet to explore its
full potential.
Yes... that is kind of gutsy. I don't
You want the session to be as lightweight as possible in order for it to be
easily replicated in a fault tolerant system.
With service/dao layer code I like to let the ORM (EJB/Hibernate) cache
whatever I need for performance. By keeping a cache of these objects in the
application layer and a
Have you tried using LoadableDetachable models for that? Another way
could be to use Terracotta for the clustering where the objects are
just replicated to servers which need them. I haven't tried it yet but
this approach seems pretty scalable and fault-tolerant to me (given
that the
1. Session support. Many other web frameworks do not use sessions
out of
How about this approach of store session data? Or part of session
data? http://weblogs.java.net/blog/gmurray71/archive/2005/05/storing_secure.html
Ryan wrote:
[...]
1. Session support. Many other web frameworks do not use sessions out of
the box. Wicket uses the session extensively to store the render state
of most renders. This leads to a large session and if you are not
careful a VERY large session. I understand Wicket 1.3 will
Other points of consideration is long term maintenance. A component
oriented framework like Wicket encapsulates component functionality into a
black box that can be used in many different contexts and still work as
designed. The same effect is very difficult to achieve with custom tags
It is actually quiet a bit different.
all visited pages except the most recent are saved to disk instead of being
held in session. the session now only holds the most recently accessed page.
the pages saved on disk are only needed when the user uses the back button,
which is probably not that
24 matches
Mail list logo
