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
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)
I
Здравствуйте, 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 g
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 lis
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:
>
> so
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 ;-)
http://www.nabble.com/Can-you-comment-on-this--tf
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 a
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
---
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 that
: [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
>
>
> - 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
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
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,
Erik.
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 doi
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
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 i
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 result
> > > > > 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
-
yep, that should be doable also.
for power users you can even subclass SecondLevelCacheSessionStore or
implement ISessionStore directly to replace the entire mechanism completely.
-igor
On 12/15/06, Francis Amanfo <[EMAIL PROTECTED]> wrote:
On 12/15/06, Igor Vaynberg <[EMAIL PROTECTED]> wr
On 12/15/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
I
this is of course only the default behavior and the whole thing is still
easily configurable.
Ok, thats clear but want to know to what extent this would be configurable.
By that do you mean we can only configure two situations, one that
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 Terracotta-ser
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 re
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'
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 oft
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
(especially
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 ad
A few months ago I wrote to the Wicket user list explaining that I was
investigating view frameworks for a large enterprise project. This is a
follow up to that post explaining why I recommended Wicket. It may be useful
for other people who are going through the same decision process.
First a bit
27 matches
Mail list logo