Regarding scalability. If you stick to using loadable detachable models
and use terracotta, I've heard thats a good option?
And no defiantly the automatic handling of state are have never been a
problem for me, you just need to remember that things can be serialized
at times, but the serializable checker will remind you if somethings not
serializable, and then you have a heads up.
GK1971 wrote:
Hi.
Thank you all for your input. Very valuable. I started reading Wicket In
Action last night and I like how the book is written - very much. It has the
right explanations in the right places. So, I'm becoming convinced to try
it. But I have concerns around the handling of state. I understand this is
probably where people do have concerns and I know I am not the first to ask.
I want to imagine myself in a position where I have a fairly rich web
application that is publically available on the web, where people can join
by invitation and have a great user experience. All this may take some
state. Everyone talks about the RESTful model these days but I'm not
convinced thats either new or wise all of the time. What it does allow you
is easy scalability.
What are the best ways to scale a Wicket built application across multiple
servers? I'm assuming Layer 7 load balancers. With bigger state stored (is
that true?) than an average web app that may mean less users concurrently
per server, but of course you can add more servers.
Does anyone have any experience with this? Has this automatic handling of
state ever been an issue for anyone?
Thanks, Graeme.
Martin Voigt wrote:
while I haven't migrated any big app from tapestry to wicket (but i
know tapestry nonetheless), the number one reason to do so would be
(at least for me) this: wicket is driven by usability (from the
developers pov) and tapestry is driven by technology. while one does
not exclude the other, wicket's approach is the better one. i've seen
java web frameworks come and go, and i watched wicket's progress for
ages now, and wicket still get's easier to use with each version while
advancing in terms of technology where it makes sense.
and for the concern about scalability, wicket goes the easy road: more
load? add some servers and go with the standard apache plus mod-jk
session sticky thingy or whatever is you load balancer of choice.
but the main reason still would be the developer-friendliness of
wicket, cos most things are too easy to believe, i18n for example, or
the serving of error pages. I'm not writing this because I get
something from promoting wicket, but I did several projects migrating
to wicket or using it from scratch, and it really delivers what it
promises. it made me like java again ;)
Regardsm
Martin
2008/10/30 GK1971 <[EMAIL PROTECTED]>:
Hi.
You are possibly correct. My main concern is that I have to upgrade from
Tapestry 4 to... something. Given that Tapestry 5 is not compatible in
the
least I have allowed myself to look at the options.
I guess I am really asking for reasons to move from Tapestry to Wicket -
particularlu if anyone has any experience of doing this which they could
share. What were those reasons, and pros/cons after sampling both
solutions.
Thanks for pointing out that I was not clear.
Daniel Frisk wrote:
I actually read your mail but I didn't quite get it, what is your main
concern?
It seems to me like Wicket would be a perfect fit to your four criteria.
// Daniel
jalbum.net
On 2008-10-30, at 21:05, GK1971 wrote:
Hi. I hope this email is appropriate for the forum - its my first time
posting.
My partner and I are in the process of working on a site that
currently uses
Tapestry 4 and must be reasonably scalable vertically (we have
horizontally
covered in a road map). I am looking around at technologies that we
can
pursue in the future that will provide us with a way of creating a
wonderful
experience for a user based on dynamic content with Java as a base
language.
I have used Tapestry 3 and 4 in prior lives in prior companies and as
Tapestry 5 was still early a year ago when we started the project I
decided
to work with Tapestry 4 an understand that once the site was up and
running
we may look at rewriting the web layer in an updated framework,
using the
lessons we had learned along the way about our specific application.
I have grown unhappy with Tapestry generally - for example, its clumsy
handling of AJAX. Even a seasoned developer can write a Tapestry
application
which is incredibly complex and inefficient, also. I'm not certain its
declarative approach in Tapestry 5 is a wise thing from a
productivity point
of view (maintenance). Debugging a Tapestry application can be
difficult.
I found myself looking at JSF, but we'd like to actually deliver a
functioning site quickly and not have our hands tied by bureaucracy.
I also
looked into other frameworks, and short of writing something myself
I have
found the best for our needs to be Tapestry 5 (scares me - what will
Tapestry 6 bring in terms of backward compatibility etc?) and Wicket.
I'm liking the look of Wicket but I wondered if it would fill a few
ideas I
have.
I have had significant issues with DOJO/Tapestry bugs that I cannot
fix
myself and that has limited productivity. I would like to write an
AJAX
library for myself and hook it into Wicket somehow. Would this be
possible.
I feel it may be a pain in Tapestry because there 'appears' to be
such a
high coupling with DOJO now. Would it be conceptually easy for me to
write
Javascript/AJAX and hook them into Wicket in a simple way? I
understand
Wicket has a good framework for AJAX but if I require to implement
code of
my own, is it easy to slip under the hood (with Tapestry this is
very hard).
Many forums have mentioned scalability is an issue, but I believe
that this
is down to an applications individual handling of state rather than
the
framework. Am I correct? I am not so worried about this vertical
scaling as
long as I can horizontally scale my application on many servers
(which I can
if I control state).
What's the road map for Wicket? I understand it is now one of the main
Apache projects (which is one reason I am looking at it), so I
assume it
won't disappear sometime next year after I have invested time and
effort
into developing with it.
Please tell me you are not going to pull a 'Tapestry' on me and
other users
by making future versions so ridiculously incompatible I have to
rewrite my
project again?
Honestly, I'm looking for a framework that will allow me to:
1) Utilize HTML templates (which you do, I understand).
2) Utilize CSS (which you do) files externally for my artist.
3) Utilize Javascript (which I assume you do).
4) Utilize a Java, component based web framework for creating a fast
lightweight but rich user experience for my users (which I guess you
do).
I have just purchased Wicket in Action so as I can do some research,
but I
do appreciate your time if possible.
Many thanks for your help, and your help.
Regards, Graeme.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Moving-from-Tapestry-to-Wicket--tp20254394p20254748.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
