Re: Apache Wicket is a Flawed Framework

2011-11-22 Thread Eelco Hillenius
 @Alex Objelean  Igor Vanyberg-2
 Yea, my bad on just posting something up here without looking at any
 previous posts.  Look, it was my rant and how I felt about things at the
 time.  Nothing personal.  This was actually the clean version for public
 consumption.  It was probably still too rude though.  Sorry about that.  I
 suppose it would be lame to spend a lot of time on a framework and then have
 some kid post up a “Wicket Sucks” post.

If you want to blow off steam and tell people you think X sucks,
that's fine, but do it on a blog or something. It's just bad style to
do this on a list that is meant to help out with X. If at all, the
developer list would be better, but even then, you may want to
consider having a chat with some of the developers first to see what
their reasons for some of the things you dislike may be. Anyway,
constructive criticism is good on a list like that, but I didn't get
much of the constructiveness...

 @Jonathan Locke
 I agree that Java is fast.  I don't worry about scaling and performance
 because of that.  To the people worrying about memory, I don't think that is
 a big deal.  Sure any framework is going to waste more memory than bare
 bones JSP/Servlets, but memory is cheap.  Eclipse is like the biggest hog
 ever and look at how successful it is.

 Also, I am sticking with Java.  I have a really good job and such.  The only
 reason I would ever move is if I could land a leet job in the Valley doing
 Python at some sweet start-up.  Not likely though.

Do you live in the Bay Area? Seems to me there's plenty of work for
folks wanting to do coding in other languages than Java, particularly
for startups.

 Java is better than some
 of the alternatives out there:
 http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto.  Scala is still
 too unstable.  The other Java web-frameworks are all flawed too.  I don't
 hate my job either.

Any choice will have it's own disadvantages. Also depends on what you
use a language for. I'm not sold on Scala, but I wouldn't think it's
not stable enough for production. May have to be careful doing
upgrades maybe.

 @sthomps
 LOL!  You know Eleco Hilenius wrote the “Wicket in Action” book?  For some
 reason I can't stop laughing.  Now everyone is going to think you are a
 badass at work.  The book is decent, but it would be nice if the next
 edition would have a chapter at the end that rewrites the “Cheese Store”
 into  “Cheese Store 2.0,” using all the advanced stuff that was explained in
 the latter chapters.  It would help Wicket newcomers like me.  It would also
 show how to do a real app with best-practices.

Well, I can tell you that I hated every minute of writing it :-) One
of these things one can do to 'just have done once in a life' and I'm
happy to hear from people that were helped by it, and hope it helped
the framework reach a certain stage of 'maturity', but never again
will I write tech book in my life.

Anyway, I always thought and still think that a good set of examples
and test cases are often more valuable to a project. Imho the first
chapter of Wicket In Action is the most important one, as it goes into
the why and rough outline of how. After that, I think you should hit
the examples and dig through the code. That at least works best for
me... then again, I'm very much an autodidact kind of guy and respect
that this is not the best way for everyone.

Now, since I'm typing anyway, here are my 2c on your points:

* Violates Dry - It does a bit, but I believe for a reasonable
purpose. We've explored several alternatives at some point, but felt
this was the least of evils

* Not previewable - Hah, this one is funny... point by point;
- First, we don't have seperate designers at my company - so...
who's fault is that?
- Second, it is better if the samer person - ah, so you think that
1 is a good idea. Well, I - as I'm sure most people who've worked on
projects with some scale will agree with - disagree with you on that.
Unless you are a fantastic UX persons. But most likely (just
statistics, sorry) as you're posting to a programming list, you're not
does development and design.
- Third, if you use extends your page will not be priviewable... -
Yep. So if you use it, you lose that benefit. You could not use it, or
just suck it up and still be happy with the other benefits that a good
separation of concerns give you.

* Violates MVC - Who cares about MVC purity. It hasn't been 'pure'
since the original article. Funny you mention Spring MVC, as I think
that having special constructs for 'flow' is just very silly unless
maybe you are writing a business process engine.

* Excessively verbose and complicated - Verbosity is often there to
make it easier to understand what something is/ might do. I'm sure we
don't always succeed in that. Complicated is something that Wicket is
also. We've been trying to find the right balance between that and
power. Some things worked out better than others.

* Breaks POJOS - every frameworks comes with 

Re: Apache Wicket is a Flawed Framework

2011-11-22 Thread Gaetan Zoritchak
I didn't have a look one the wicket books for quite while. Good you told
us. I orderered yours yesterday on Amazon. :)

2011/11/18 Igor Vaynberg igor.vaynb...@gmail.com

 * there are three books written about wicket: two for beginners and
 one for intermediate-advanced users.
 * there is a searchable mailing list archive that spans years upon
 years of users asking questions and getting answers.
 * there is a wiki that lists examples and has some good articles.
 * there is stack overflow questions and answers.

 is there an answer to every single possible question out there? of
 course not. no framework has that. look at projects like spring and
 hibernate. do those have great documentation? i bet you would say
 yes. are their mailing lists any less busy than our own? no. so what
 does that say?

 if i had to make up a number i would say that armed with the resources
 i listed you would be able to answer about 80% of your own questions.
 and i think that is a pretty good number. there is a very active user
 list to help you answer questions you cant answer yourself, usually
 faster then a commercial support contract. for free.

 not too shabby.

 -igor

 On Thu, Nov 17, 2011 at 3:30 PM, Gaetan Zoritchak
 g.zoritc...@moncoachfinance.com wrote:
  I must admit that I agree with you. While I think Wicket is a
  great framework, the documentation is not up to par. This tool seems a
  little too elitist. If you're strong enough you will find
  a great framework. It's a shame because even if the mailing list is very
  effective it slows down the adoption of wicket.
 
  2011/11/17 geraldkw geral...@gmail.com
 
  This is not an april fool's day, it is just an opinion of an
 inexperienced
  developer. 
 
  This illustrates one of the traditional logical fallacies. If you can't
  effectively attack the argument, attack the speaker.
 
  My biggest problem with Wicket is that I haven't found any
 documentation on
  the web that really lets me get a solid grasp on the key concepts. I
 read a
  lot of poorly written documentation, weak examples and forum posts
  dealing
  with something that is only vaguely related to my goals, maybe learn a
  fragment of useful info, and then suffer while trying to apply it.
 
  I haven't looked a Wicket in Action or other Wicket Books, but I have
 not
  heard good things. Also, this is the Internet Age and this is web
  programming. I have no problem finding documentation on other web
  programming languages/frameworks like I do with Wicket.
 
  If I am wrong, point me to some solid learning materials, and you stand
 a
  chance of changing my mind.
 
  geraldkw
 
 
  --
  View this message in context:
 
 http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4081206.html
  Sent from the Users forum mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Apache Wicket is a Flawed Framework

2011-11-22 Thread Gaetan Zoritchak
Super cool list, thanks a lot.

2011/11/18 robert.mcguinness robert.mcguinness@gmail.com

 i'm baffled when people say the documentation is poor, the javadocs are
 excellent and like igor said there are some great books (blogs too!).
  books
 and blogs get outdated fast since technlogy is rapidly advancing, so *use
 the source luke!*.  Not only will you learn Wicket, but I guarantee your
 Java skills will improve.


 awesome examples:



 https://github.com/apache/wicket https://github.com/apache/wicket  (scan
 over the unit test, best way to learn any framework not just wicket)

 https://github.com/55minutes/fiftyfive-wicket
 https://github.com/55minutes/fiftyfive-wicket  (fantastic)

 https://github.com/42Lines https://github.com/42Lines

 https://github.com/wicketstuff/core https://github.com/wicketstuff/core (a
 gem, tons of examples on how to pretty much do anything)

 http://code.google.com/p/wiquery/source/checkout
 http://code.google.com/p/wiquery/source/checkout

 https://github.com/jolira/wicket-stateless
 https://github.com/jolira/wicket-stateless  (wicket stateless is
 excellent,
 even easier with wicket 1.5)

 https://github.com/reaktor/oegyscroll
 https://github.com/reaktor/oegyscroll
 (endless pagination)

 http://code.google.com/p/wiquery/source/browse/core
 http://code.google.com/p/wiquery/source/browse/core  (jquery)

 http://code.google.com/p/jqwicket/source/browse/
 http://code.google.com/p/jqwicket/source/browse/  (jquery, learn from the
 code and roll your own if it doesn't fit your needs, super easy

 https://github.com/rjnichols/visural-wicket
 https://github.com/rjnichols/visural-wicket  (great ui tools)

 https://xaloon.googlecode.com/svn/ https://xaloon.googlecode.com/svn/
 (excellent!)



 rob

 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082034.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Apache Wicket is a Flawed Framework

2011-11-20 Thread Eric Kizaki
@Alex Objelean  Igor Vanyberg-2
Yea, my bad on just posting something up here without looking at any
previous posts.  Look, it was my rant and how I felt about things at the
time.  Nothing personal.  This was actually the clean version for public
consumption.  It was probably still too rude though.  Sorry about that.  I
suppose it would be lame to spend a lot of time on a framework and then have
some kid post up a “Wicket Sucks” post.

@Jonathan Locke
I agree that Java is fast.  I don't worry about scaling and performance
because of that.  To the people worrying about memory, I don't think that is
a big deal.  Sure any framework is going to waste more memory than bare
bones JSP/Servlets, but memory is cheap.  Eclipse is like the biggest hog
ever and look at how successful it is.

Also, I am sticking with Java.  I have a really good job and such.  The only
reason I would ever move is if I could land a leet job in the Valley doing
Python at some sweet start-up.  Not likely though.  Java is better than some
of the alternatives out there: 
http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto.  Scala is still
too unstable.  The other Java web-frameworks are all flawed too.  I don't
hate my job either.

@sthomps
LOL!  You know Eleco Hilenius wrote the “Wicket in Action” book?  For some
reason I can't stop laughing.  Now everyone is going to think you are a
badass at work.  The book is decent, but it would be nice if the next
edition would have a chapter at the end that rewrites the “Cheese Store”
into  “Cheese Store 2.0,” using all the advanced stuff that was explained in
the latter chapters.  It would help Wicket newcomers like me.  It would also
show how to do a real app with best-practices.


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4089212.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-20 Thread Martijn Dashorst
On Sun, Nov 20, 2011 at 7:49 PM, Eric Kizaki erickiz...@gmail.com wrote:
 LOL!  You know Eleco Hilenius wrote the “Wicket in Action” book?  For some
 reason I can't stop laughing.  Now everyone is going to think you are a
 badass at work.  The book is decent, but it would be nice if the next
 edition would have a chapter at the end that rewrites the “Cheese Store”
 into  “Cheese Store 2.0,” using all the advanced stuff that was explained in
 the latter chapters.  It would help Wicket newcomers like me.  It would also
 show how to do a real app with best-practices.

Please note that this is not in any way a promise, suggestion or even
feeble flimsy tiny shred of evidence that there will be a second
edition–given our experiences writing edition one.

The problem is that such a thing will increase the weight of the book
considerably. What we strived to do was to keep the book under/at
about 350 pages. Hibernate in Action (the first edition) had about the
right size in our mind. Making a Spring in Action/Java Persistence
with Hibernate type of book would kill too many trees and break too
many backs. I don't know about you, but the high school years of
tugging along kilos of books are way behind me, and I don't look back
with fond memories to those days.

The whole idea of Wicket in Action (and in my opinion of the whole in
Action series) is that you are empowered to figure out stuff on your
own when you have completed the book. I can give you a fish or I can
teach you how to fish. We strived for the latter given 350 pages.

Yes, you will make mistakes. But don't think of those as mistakes but
learning experiences.

The cheese store holds your hand while taking the baby steps. From
there you should be able to go at it with the guidance of the latter
chapters. IMO the book would suffer from adding such a chapter at the
end. Kind of like those movies where they explain the whole plot to
the audience.

And as for your original post, while the wording was not very
friendly, I appreciate it that you took the effort to write it, and
even more so that you stick around to answer questions, remarks and
engage in discussion. Kudos!

Martijn

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-20 Thread jlazeraski
Hi Igor,

You have valid points. I've not built a Wicket app yet to compare, so I
can't honestly say. My intuition knowing about how session replication
occurs to provide at least fault tolerance does however make me believe that
in the end, wicket will scale much less than a stateless app with minimal
session objects.

Let me explain, however, that you are correct in that most developers that
don't know any better just stick everything in the session. It's convenient,
and works. Until you suddenly need to handle scaling and fault tolerance.
Thinking about that as an after thought is in my opinion a bad idea. I know
many developers, architects, even non-tech business folk that come up with
the ideas always think..just get it to market..make it work..we'll worry
about scalability later.. yadda yadda. Sure..that's possible, but if you've
already developed apps and know of the issues that can occur when the time
comes to scale.. why not use that at the start of your next project so you
don't get into a situation... even if you don't, building the application to
be ready to scale is a good thing to do from the start.

You bring up a good point as well.. just sticking objects in the session and
hoping that the containers can replicate them correctly, is what most
developers do. However, with a little bit of thought, you can provide a very
scalable statelss application while putting whatever you want in the
session. The trick is a hybrid database/memory approach, and I don't mean
cache. I mean, you put in the session only the info you need to help
reconstruct the rest of the user session. For example, a User object with a
List of emails.. do you need the List reference in memory? No. It's
convenient, but you can retrieve the list at any time with just the user id
of the User object. So rather than make the List serializable so that it too
replicates across the cluster using up memory on two (or more) servers.. you
only replicate the UserID. When the user.getEmails() is called on another
server (perhaps due to the 1st server failure, or round robin with no regard
to session-same server balancing), it will see it's null and then load it
up from the database at that point. Now, the list of emails is still not in
the session, but it's reachable from the user object that is in the session.
Even so, the User object isnt replicated either..just the id. That way
you're barely doing any replication and the memory used is only temporary
while a user is logged in and it's not part of the session, its held in
memory via a reference. It works very well, assures minimal replication time
and memory use, and allows for the app to be almost completely stateless.

I am not sure about what you mean when a web page sends tons of data? A Form
can submit plenty of data, as can an XHR ajax request at any time. File
uploads along with data can be sent via XHR or FORM or iFrame FORM post. So
I am unsure about your argument with regards to some pages having tons of
data. My guess is you were referring to completely stateless on the server
side such that ALL the user data is sent back as part of a page, and then
having to all be transmitted again..thus the server is stateless? Yah..I
will agree that is bad too if that is the case. Using the hybrid approach,
all of that is handled.

As for the object tree insertion in the same order as the page.. well you
may very well be right. I just cringe at the thought that you have to always
insert something in the same order as it appears in the object tree on the
page. I haven't read the entire post you linked though, and given that
Wicket 6 is coming, and I am not at liberty to use Wicket just yet anyway,
I'll wait and see what it provides to alleviate that issue.

On another note.. I did want to mention about the use of components and
ajax. I've read many comments that ajax support.. or perhaps components with
ajax built in is a bit weak within Wicket. I absolutely HATE dealing with
javascript, css, layout issues across browsers, platforms etc. If there is
any one thing that would make me switch, it's this. Right now I am trying to
figure out how to add a jQuery file upload feature.. and while there are
some good examples.. I imagine with Wicket it's as simple as inserting a
single component that handles file uploads? It's frustrating because while I
know javascript somewhat, I've not used it much the past many years and a
lot has changed.. or perhaps a lot of new creative libraries have just been
built. Regardless.. I've spent the better part of 5 days trying to get this
stupid dialog to upload a file and the server code to handle it and still
don't have it working. Part of the reason is I have to work within two other
developers existing code and not break anything, but this along with css
layout issues is the most aggravating part of my job.. I know some of it,
just not an expert in all areas from the UI to the back end. It's part of
why I am a bit afraid to try to start my own contract 

Re: Apache Wicket is a Flawed Framework

2011-11-20 Thread Igor Vaynberg
On Sun, Nov 20, 2011 at 6:40 PM, jlazeraski
supreme_java_gur...@yahoo.com wrote:
 Hi Igor,

 You have valid points. I've not built a Wicket app yet to compare, so I
 can't honestly say. My intuition knowing about how session replication
 occurs to provide at least fault tolerance does however make me believe that
 in the end, wicket will scale much less than a stateless app with minimal
 session objects.

intuition by definition lacks reasoning :)

 Let me explain, however, that you are correct in that most developers that
 don't know any better just stick everything in the session. It's convenient,
 and works. Until you suddenly need to handle scaling and fault tolerance.
 Thinking about that as an after thought is in my opinion a bad idea. I know
 many developers, architects, even non-tech business folk that come up with
 the ideas always think..just get it to market..make it work..we'll worry
 about scalability later.. yadda yadda. Sure..that's possible, but if you've
 already developed apps and know of the issues that can occur when the time
 comes to scale.. why not use that at the start of your next project so you
 don't get into a situation... even if you don't, building the application to
 be ready to scale is a good thing to do from the start.

Wicket is not some framework that came out yesterday. people have
built tons of apps with it, and a good portion of them runs in a
cluster. so it *can* scale. vegas.com and mobile.walmart.com are good
examples of public sites that are built on top of Wicket. i doubt they
run on a single machine :)

 You bring up a good point as well.. just sticking objects in the session and
 hoping that the containers can replicate them correctly, is what most
 developers do. However, with a little bit of thought, you can provide a very
 scalable statelss application while putting whatever you want in the
 session. The trick is a hybrid database/memory approach, and I don't mean
 cache. I mean, you put in the session only the info you need to help
 reconstruct the rest of the user session. For example, a User object with a
 List of emails.. do you need the List reference in memory? No. It's
 convenient, but you can retrieve the list at any time with just the user id
 of the User object. So rather than make the List serializable so that it too
 replicates across the cluster using up memory on two (or more) servers.. you
 only replicate the UserID. When the user.getEmails() is called on another
 server (perhaps due to the 1st server failure, or round robin with no regard
 to session-same server balancing), it will see it's null and then load it
 up from the database at that point. Now, the list of emails is still not in
 the session, but it's reachable from the user object that is in the session.
 Even so, the User object isnt replicated either..just the id. That way
 you're barely doing any replication and the memory used is only temporary
 while a user is logged in and it's not part of the session, its held in
 memory via a reference. It works very well, assures minimal replication time
 and memory use, and allows for the app to be almost completely stateless.

youve just described the LoadableDetachableModel :)

 I am not sure about what you mean when a web page sends tons of data? A Form
 can submit plenty of data, as can an XHR ajax request at any time. File
 uploads along with data can be sent via XHR or FORM or iFrame FORM post. So
 I am unsure about your argument with regards to some pages having tons of
 data. My guess is you were referring to completely stateless on the server
 side such that ALL the user data is sent back as part of a page, and then
 having to all be transmitted again..thus the server is stateless? Yah..I
 will agree that is bad too if that is the case. Using the hybrid approach,
 all of that is handled.

i mean that sometimes the UI is complex enough to where you cannot fit
all the state in a URL. once this happens you have no choice but to
use session or make everything a POST.

 As for the object tree insertion in the same order as the page.. well you
 may very well be right. I just cringe at the thought that you have to always
 insert something in the same order as it appears in the object tree on the
 page.

lets get something straight, Wicket does not require the INSERTION
order to be the same as the html markup. only the NESTING of
components needs to be the same. as in if you say A.add(B); B.add(C);
then the C div has to be inside the B div and the B div has to be
inside the A div.

 I haven't read the entire post you linked though, and given that
 Wicket 6 is coming, and I am not at liberty to use Wicket just yet anyway,
 I'll wait and see what it provides to alleviate that issue.

 On another note.. I did want to mention about the use of components and
 ajax. I've read many comments that ajax support.. or perhaps components with
 ajax built in is a bit weak within Wicket. I absolutely HATE dealing with
 javascript, css, layout issues 

Re: Apache Wicket is a Flawed Framework

2011-11-20 Thread Jonathan Locke
Why this business about component nesting keeps coming up is really beyond
me. If you're running into non-trivial problems with keeping component
nesting in sync, you really need to stop what you're doing and back up a
step or two because you're definitely looking through the wrong end of the
Wicket telescope. If you've got some giant page or panel or form with piles
of nested anonymous classes defining a multi-level hierarchy, you're pretty
much headed off into the woods. 

To tap Wicket's OO power you MUST start getting into the habit of breaking
things up into appropriate conceptual pieces. Either break them up into
reusable panels and/or break them up using these crazy things we have in
Java called packages, classes and methods. 

If I had to paraphrase my book on software design in a sentence, I'd say
this: if you break the problem down right, it will solve itself. Java and
Wicket provide more than enough to break your problem down into simple
pieces so the solution just falls out, without huge complexity all in one
place.

The real work of software design is all about beating complexity and it has
little to do with the pros and cons of any specific technology. It's ALL
ABOUT how you conceptualize and then divide and conquer your problem. The
rest is a bunch of boring mechanics.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4090715.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-19 Thread Girts Ziemelis
On Fri, 2011-11-18 at 06:27 -0800, Eric Kizaki wrote:

 I was not expecting so much hate.  I guess now I am infamous in the Java
 world now.  Look, it is just my opinion.  Not many people actually stopped
 to address many of my points.  They just immediately bashed me. 

I did not bother to respond to the first e-mail, as there were way too
many points, which from my experience were incorrect and even strange
(ORM, JSP, etc). 
Beeing so happy with wicket during last couple years (last week finally
removed last traces of Struts/Spring MVC/JSP from applications), seemed
pointless to try to convince someone with so different view on things ;)


 I am sticking with Wicket because it is required for work.  I am able to do
 stuff in it but it seems unnecessarily complicated.

Depends on what you are doing.  In Wicket I am doing things I never
considered in SpringMVC, as they were too cumbersome and
ugly to get working and then maintain them ,,, 


   I own the “Wicket in
 Action” book and “Enjoying Web Development with Wicket Book” by Kent Ka Iok
 Tong.  The second book is much more practical.  Without these books I would
 not be able to do anything in Wicket.  That is why I did not mention
 documentation.

I started without any wicket books. Now I own two, but to be honest -
have not red them from cover to cover. There is sufficient 
information in mailing lists + Javadoc + wicket examples, + WIKI, but I
would agree, it could be improved. Learning curve for wicket is not
small, but it is objective. It is not reasonable to pick up UI
lframework  as quickly as JSP or velocity.


   I would prefer to just be able to check out something like
 this http://static.springsource.org/docs/petclinic.html.  This is a real
 working application that shows how to do things with databases etc.  With
 Wicket, I had to string a bunch of snippets together and read two books.  I
 am still not sure I am doing things the best way.

Yeah. For the beginners it would probably be helpful. Then again -
wicket examples cover most components.

 
 To people who say I am inexperienced, I have tried JSF and GWT.  Wicket is
 better than both of those.  JSF has an invasive and complicated lifecycle. 
 When I saw the lifecycle diagram I just stopped even looking into it.

Same here, After Struts, I considered JSF, but after a week and still
not getting the magic of JSF lifecycle I just gave up ...

  In my humble opinion Spring MVC done right (no scriplets) with JSTL  EL and
 jQuery is better than Wicket.  You can also use Velocity templating.

Spring MVC is nice in its simplicity. So, for simple things, I like it.
Problem starts, when you need something more complicated.  And page
logic in templates is a nightmare, especially for maintenance. Velocity
does not help very much, as IDE tool support is very basic. 



 Here is a quote from the Restlet page
 (http://www.restlet.org/about/introduction):
 “While powerful for complex centralized models, the object-oriented paradigm
 isn't always the best suited for Web development.

I would agree with this in pre-wicket days. With wicket this is not true
any more. And this is what wicket
 is all about - OO in web development. 



Re: Apache Wicket is a Flawed Framework

2011-11-19 Thread Eelco Hillenius
Really, is this what you do, go around posting to user lists of
frameworks you don't like? I imagine one can have a full time job
doing that.

Eelco


On Thu, Nov 17, 2011 at 7:44 AM, Eric Kizaki erickiz...@gmail.com wrote:
 Violates Dry:  You must repeat the component hierarchy of your widgets that
 are in HTML in Java Code for no good reason.  If you move your widget around
 in the html it will break the Java and you get a stack trace if you change
 the nesting.  You have to keep these two files synched.  A JSP file is more
 maintainable.  At least the view code is in one place.

 Not previewable:  One of the supposed benefits of Wicket is a clean template
 that could make pages previewable for designers.  First, we don't have
 seperate designers at my company.  Second, it is better if the samer person
 does development and design.  Third, if you use extends your page will not
 be priviewable outside an application server running Wicket.  This supposed
 benefit does not exist.

 Violates MVC:  It smashes view and controller code into the same Java file.
 You have code that regulates page flow and code that changes css attributes
 in the same file.  Even Spring MVC had better separation of concerns.
 JSP/Servlets with Spring MVC is better.

 Excessively verbose and complicated:  What is a LoadableDetachableModel?
 The learning curve for Wicket is immense.

 Breaks POJOS:  A real POJO does not need to implement an interface or extend
 a class.  Wicket forces your beans to be Serializable.  This is like using
 EJBs in how it forced you to implement interfaces.

 Terrible AJAX:  Compared to a few lines of jQuery AJAX is excessively
 complicated and verbose in Wicket.  A lot of things like “AJAX” links should
 not be done via “AJAX” at all.  Hiding a div on the client would simply be
 done with JavaScript on the client.  Wicket better not require a server
 request for that.  You also have no JSON support and good luck debugging any
 JavaScript or AJAX in Firefox.  Instead you have to use the subpar Wicket
 debugging.

 HTML5:  No support for HTML 5 form elements unless you upgrade to Wicket
 1.5.  You will get a stack trace.  The upgrade to Wicket 1.5 is painful and
 will break your code.  Good luck getting this to work with jQuery mobile.

 Bad Defaults:  Most pages are stateless.  The default for Wicket is
 stateful.  So if I want a decent URL and a bookmarkable page I have to mount
 the page and use a bookmarkable page link with page parameters.  Using page
 parameters is worse than how Spring MVC does binding.  I have to keep doing
 this over and over for each page.  There is too much work involved to get a
 decent stateless page with a nice URL. This should be the default.

 Interferes with other libraries:  It screws up your jQuery code.  It forces
 you into a restrictive way of doing web-development:  the Wicket Way.

 Causes a redeploy whenever you add anything:  Maybe Java developers are used
 to this, but in any other web development environment I do not need to
 redeploy after adding a text box to the page.  It is completely absurd.
 Only with JRebel is this alleviated.  No, embedded Jetty in debug mode still
 slow.  Even a simple JSP file has hot reloading on Tomcat and if I make a
 change to my view code the changes are immediately viewable in the browser
 when I refresh.  This is WITHOUT JRebel.

 HTTPSession Objects are not hard:  Most pages do not need state.  If you do
 use HTTPSession it is simple.  Can you use a map?  Then you can use
 HTTPSession.  This is less comlicated than most Wicket code.

 Stateful Component based framework are a terrible idea:  Even at the
 theoretical level this is a bad idea. It is a leaky abstraction over a
 simple request/response cycle.  It made something simple and made it overly
 complicated.  This remind me of Hibernate and ORMS.  I disagree that we
 should abstract things to this level and do everything in verbose Java.
 People are dropping Hibernate and going back to native SQL and Spring JDBC
 template.  SQL and the relational model are easy.  Working with HTTP
 requests is easy too.  What was wrong with JSPs/Servlets?  Keep it simple
 stupid.  We know JSF was too complicated and it was terrible.  Spring MVC is
 better and has rest support.  It just works with Spring and has great
 support for the JSON Jackson mapper.

 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4080411.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-19 Thread Jeremy Thomerson
On Fri, Nov 18, 2011 at 9:27 AM, Eric Kizaki erickiz...@gmail.com wrote:

 I was not expecting so much hate.  I guess now I am infamous in the Java
 world now.  Look, it is just my opinion.  Not many people actually stopped
 to address many of my points.  They just immediately bashed me.


Like someone else said, you actually weren't really bashed.  The great
majority of replies (at least within this thread and this community) have
been very cordial, especially considering the tone of your initial email -
which I would go so far as to call rude.


 I am sticking with Wicket because it is required for work.  I am able to do
 stuff in it but it seems unnecessarily complicated.  I own the “Wicket in
 Action” book and “Enjoying Web Development with Wicket Book” by Kent Ka Iok
 Tong.  The second book is much more practical.  Without these books I would
 not be able to do anything in Wicket.  That is why I did not mention
 documentation.  I would prefer to just be able to check out something like
 this http://static.springsource.org/docs/petclinic.html.  This is a real
 working application that shows how to do things with databases etc.  With
 Wicket, I had to string a bunch of snippets together and read two books.  I
 am still not sure I am doing things the best way.


I'm actually working on putting together several example applications with
Wicket.  The first one will use Wicket, Spring, Hibernate Search (which
uses Lucene).  I hope to have it ready sometime next month.  From there I
may expand it to other variations (for instance, one with JCR/Brix).  It
(or they) will also be available as Maven archetypes for you to create your
own applications with.

PS here: if anyone is interested in helping with that, feel free to shoot
me an off-list email.


 To people who say I am inexperienced, I have tried JSF and GWT.  Wicket is
 better than both of those.  JSF has an invasive and complicated lifecycle.
 When I saw the lifecycle diagram I just stopped even looking into it.  GWT
 uses terrible Swing style layouts and all these crappy interfaces for RPC.
 There was also no real help on the server.


I don't mean the following to be rude, but from your LinkedIn profile
(which was linked to earlier in the thread), I think saying you are
inexperienced is a fair assessment from those who have said it.  From your
profile it looks like out of school you've done six months of ColdFusion
development, and just started Java this month.  You mention that Apache
Wicket is one of your specialties, but it really doesn't sound like you've
been using it, or any of the other major Java frameworks, for a long enough
time to say you're experienced.  I wrote a C app once (
https://github.com/jthomerson/pastebinc) but I wouldn't say that makes me
experienced.  I'm inexperienced in C although I've been making a living
programming for nearly 14 years.  Trying a framework for a week or two or
even a month or two doesn't make you experienced in it.


 At least with Wicket I can still
 use HTML and CSS for my layouts.  However, these component based frameworks
 are still way too complicated for a simple task:  building a web page.


I think that's one of the keys.  If all you are doing is building a web
page - use something else.  I tell my clients that.  Wicket is great at
building web *applications*.  Complex applications.  The kind that many
enterprises need.  The kind that have complex interfaces with lots of
dynamic rules, etc.  I would not use Wicket to build Craigslist.  The
interface and front-end logic is too simple.  Wicket *excels* beyond any
other framework I've worked with when used for complex applications.


 In my humble opinion Spring MVC done right (no scriplets) with JSTL  EL
 and
 jQuery is better than Wicket.  You can also use Velocity templating.  I
 have
 also used Swing to build desktop apps.  I would not say Swing is a shining
 example of how to build GUIs.  I thought it was pretty bad, verbose, and
 impractical.  The Play Framework has the right idea:  stateless and
 restful.
 No clunky components and over-engineered objected-oriented baggage.

 Here is a quote from the Restlet page
 (http://www.restlet.org/about/introduction):
 “While powerful for complex centralized models, the object-oriented
 paradigm
 isn't always the best suited for Web development. Java developers need
 realize this and start thinking more RESTfully when developing new Web
 servers or new AJAX-based Web clients. The Restlet project is providing a
 simple yet solid foundation that can get you started right away on the Web
 2.0.”
 - Jérôme Louvel, Restlet founder
 Maybe you can look up his Linkdin and start bashing him too.  Oh no he said
 object-oriented is not the Holy Grail!


Rather than being sarcastic and snarky, please re-read your own quote.  HE
said isn't always the best suited for Web development.  I put the food on
my family's table by teaching other people how to use Wicket and writing
Wicket applications and I just told you the 

Re: Apache Wicket is a Flawed Framework

2011-11-19 Thread jlazeraski
Hey all,

Wanted to weigh in on the subject as I have some similar feelings regarding
Wicket and since so many experienced have posted perhaps they can be
addressed.

I will however include some positives. I absolutely love the idea of the
templated html page where by a web designer can build up the page and I can
focus on the back end code that adds the dynamic content. I did buy WIA and
another, Wicket Cookbook I think it is, and while I read and understand the
principals behind the framework, it was indeed a much steeper learning curve
for me. So much so that even after reading the book and starting on my own
project, I had a difficult time getting basic stuff working. However, I'd
still like to learn it more and use it for the separation it provides
between the back end and the web page itself.

I also love the idea of panels. My go to framework is (don't hate me for it)
Struts 2 and/or Jersey (via ajax calls to a rest api). I have found that I
love the idea of annotated classes to handle actions, response strings that
forward to specific jsp pages and all the code I can do.. calling to ejb
session beans, etc. The biggest down side to using Struts is, as many said,
the JSP hell. JSP itself is not too bad.. but when you add in % % code,
scriplets, looping constructs.. it's a darn pain in the butt to manage. This
is why Wicket appealed to me so much. Also, getting back to panels, the
notion of reusable components that you just place an element in the html
page and put the component in the tree in code and it works is fantastic!!
Those two things are why I will attempt to use Wicket in the near future
soon as the project I am working on is out in beta and I can look to switch
from Struts 2 to Wicket.

Now for the areas I am not so sure about and hope maybe some of you may have
some answers for.

The big one for me is the server side statefulness. Maybe I misunderstood
this, but I am really worried about the ability for Wicket to scale given
that it keeps per user object trees in memory for the page the user is on.
On the one hand, that is pretty nifty especially for the swing like event
driven approach with ajax, but where I am not sure of is with the memory
consumption used continuously on a server, it seems to me you would reduce
the number of users per server you could handle. More so, replication of
state information would require 2 (or more) servers in a cluster to have the
same sort of object tree + state in memory to have any sort of fault
tolerance. Am I correct in understanding how Wicket maintains an object tree
per user on the server side? If this is the correct understanding then to me
the stateless model of using a REST api or Struts actions where each request
comes in with a session id, and minimal data is in the session.. typically
just a userId tied to the sesion id so data can then be looked up using the
userId. Again, if I am correct, then the struts/mvc approach typically is
keep as little in memory across requests, but each request may need to spend
some processing time loading up data to reconstruct a page to send back as a
response (or set as attributes for a JSP page to use to render the response
with). So there is a bit more processing and temporary memory use, but the
memory expands/contracts continuously as users make requests and responses
go back. At least as far as  I understand the whole scalability side of
things, this is better for more user capacity. As for session replication,
at least in the old days, you had to replicate session data to at least one
other server in the cluster. In Wicket, how is this done?

Another area I am not keen with at all with wicket which is mentioned is
having to build the object tree code the same way the html page is. With
element Ids, I am a little confused as to why we cant simply insert the
component using the element id and let wicket figure out where to stick it
on the page. To me, as it scans the html page for wicket ids, it should be
able to pluck wicket component/objects from a Map using the same ID and put
it where it needs to be. This is one of the areas I have had some trouble
getting right. If Wicket did not have this requirement, you could rearrange
panels, components, etc on a page and not have to worry about any server
side code change, redeploy, etc. It would, in my opinion fix Wicket as the
ultimate framework (barring my question about scalability/session memory
above also being resolved). Someone mentioned Wicket 6 will resolve
something of this.. if you could elaborate (or point a link) that would be
great. I would love to see them resolve this issue in the framework. It
would be great to allow a web page designer build up the page, then I add
dynamic elements, then they decide to change things around and simply edit
the page and redeploy and see the changes, then do it again until they like
it.

Lastly, the bookmarkable and ugly link stuff.. I also agree that it's a bit
of a pain. It may make sense to some, but having to 

Re: Apache Wicket is a Flawed Framework

2011-11-19 Thread Cristi Manole
I think all of us were frustrated a lot more than once during our career
and decided to rant about it. I do think Eric's comments were actually made
to be contradicted by the experienced people here so that he could learn
more about Wicket and so take something out of it. It showed passion for
the profession. It's a shame to analyze somebody's competence based on
their LinkedIn profile, no matter how you look at it. How relevant is that,
really? I've seen people with tens of years of experience who couldn't
properly debug code.

I for one love Wicket and might use it for any kind of webapp, but it's by
no means a silver bullet. Anyway, reality proved that most times it was my
dumb programming that made the application not scale or use too much
memory, etc, not the Wicket framework. More I learned about it, which was
most times by browsing the CODE itself, not the books, not the
documentation, the more I knew how great of a framework it is.

I do love writing the SQLs myself or the html or pluging some nice JQuery,
but also letting my designer do his own thing (and appreciate a good DBA),
no matter how much I believe in my own skills and basically Wicket was the
first framework that I found to allow me to do just that.

Then again, I'm the only one I know who really appreciated Swing
development, which comes close to the Wicket way, so I'm sure there are
plenty who think Wicket sucks. It's their choice to do so, even it they say
it to my face, in my home and even not so politely :)

On Sat, Nov 19, 2011 at 8:24 PM, Jeremy Thomerson jer...@wickettraining.com
 wrote:

 Sorry, I don't have time to read your whole message right now (man these
 are some long messages, huh?), but I scanned it and saw a couple things I
 could help you with right away.

 On Sat, Nov 19, 2011 at 7:52 PM, jlazeraski
 supreme_java_gur...@yahoo.comwrote:

  Hey all,
 
  Wanted to weigh in on the subject as I have some similar feelings
 regarding
  Wicket and since so many experienced have posted perhaps they can be
  addressed.
 
  I will however include some positives. I absolutely love the idea of the
  templated html page where by a web designer can build up the page and I
 can
  focus on the back end code that adds the dynamic content. I did buy WIA
 and
  another, Wicket Cookbook I think it is, and while I read and understand
 the
  principals behind the framework, it was indeed a much steeper learning
  curve
  for me. So much so that even after reading the book and starting on my
 own
  project, I had a difficult time getting basic stuff working. However, I'd
  still like to learn it more and use it for the separation it provides
  between the back end and the web page itself.
 
  I also love the idea of panels. My go to framework is (don't hate me for
  it)
  Struts 2 and/or Jersey (via ajax calls to a rest api). I have found that
 I
  love the idea of annotated classes to handle actions, response strings
 that
  forward to specific jsp pages and all the code I can do.. calling to ejb
  session beans, etc. The biggest down side to using Struts is, as many
 said,
  the JSP hell. JSP itself is not too bad.. but when you add in % % code,
  scriplets, looping constructs.. it's a darn pain in the butt to manage.
  This
  is why Wicket appealed to me so much. Also, getting back to panels, the
  notion of reusable components that you just place an element in the html
  page and put the component in the tree in code and it works is
  fantastic!!
  Those two things are why I will attempt to use Wicket in the near future
  soon as the project I am working on is out in beta and I can look to
 switch
  from Struts 2 to Wicket.
 
  Now for the areas I am not so sure about and hope maybe some of you may
  have
  some answers for.
 
  The big one for me is the server side statefulness. Maybe I misunderstood
  this, but I am really worried about the ability for Wicket to scale given
  that it keeps per user object trees in memory for the page the user is
 on.
  On the one hand, that is pretty nifty especially for the swing like event
  driven approach with ajax, but where I am not sure of is with the memory
  consumption used continuously on a server, it seems to me you would
 reduce
  the number of users per server you could handle.


 A lot of people have this same concern when coming to Wicket.  However,
 this amounts to the equivalent of premature optimization - assuming that
 something will be your hotspot when it will not be.  I recently wrote an
 article for an in-print Java magazine about Wicket (I'll post more details
 to the list soon).  Here is an excerpt from it.  Please read the two
 included links:

 QUOTE: If you’re really concerned about being able to validate my
 assertion that Wicket will not use more memory than other frameworks, you
 may want to check out http://tinyurl.com/wicket-perf-1 and for a more
 elaborate comparison of Wicket versus several alternative frameworks, see
 http://tinyurl.com/wicket-perf-2 (both 

RE: Apache Wicket is a Flawed Framework

2011-11-19 Thread Chris Colman
Another area I am not keen with at all with wicket which is mentioned
is
having to build the object tree code the same way the html page is.
With
element Ids, I am a little confused as to why we cant simply insert the
component using the element id and let wicket figure out where to stick
it
on the page. To me, as it scans the html page for wicket ids, it should
be
able to pluck wicket component/objects from a Map using the same ID and
put
it where it needs to be.

We do exactly what you say with Wicket now (since 1.4.x and with 1.5.x).
We have a Wicket based CMS and we really needed to be able to
dynamically build pages from components - even at run time (and
therefore obviously without restructuring Java object hierarchies and
without requiring a rebuild) - just by adjusting HTML. We run Wicket in
debug mode in production (breakin' all the rules - but no performance
problem is detectable) so that changed HTML files are detected by Wicket
and reloaded in the Markup repository.

The trick that allows this to occur is a custom implementation of the
IComponentResolver interface. Doing this you can daisy chain
responsibility for instantiating components from the page, down to the
components and then child components - it all works scary well ;)

In 1.5 the component resolver is refined to make implementations even
easier than 1.4. 

Regards,
Chris

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-19 Thread jlazeraski
Hey Jeremy, thanks for the info.

I am having a hard time seeing how Wicket uses less memory if for each
user/page it keeps a DOM tree of objects in memory + any model data for that
page.. where at least in my struts2 apps, there is nothing in memory on the
server side.. only when a request comes in do I load some data, then send it
back as part of the response. The memory is then GC'd at some point by JVM..
but there is no object tree or anything else related to the user, page they
are on, etc in memory at all. So I am not sure how Wicket can use comparable
if not less memory when the struts/mvc way with a stateless request flow
uses pretty much no memory. 

One day, if a startup I work at takes off and I make enough mula to not have
to work, I would love to write an app in spring, struts, wicket, couple
others.. and compare the details and differences.



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4087996.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-19 Thread jlazeraski
Cristi,

Oh how I miss Swing! That is one of the main reasons I took a look at
Wicket.. I loved Swing. I still don't get why so many people feel Swing
wasn't a good UI to develop in. Threading was a bit tricky, but workable if
you knew how to deal with it. The event system was fantastic, and while it
may not have run GUI as fast as native, it ran on damn near every platform
out there and looked the same on all. I thought it was by far the best
overall cross-platfrom desktop GUI kit to develop in.. the only time it was
a bit trivial was with complex large screens that had tons of widgets and
data on it.. but after JDK 1.4 it was pretty smooth even then on Solaris,
Windows, Mac and Linux.

So you're not alone.. I built several desktop apps, my plugin engine was
originally modeled after Eclipse (platonos on sourceforge) and I was working
on a complete pluggable Swing framework when everything started going Web
2.0.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4088005.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-19 Thread Igor Vaynberg
On Sat, Nov 19, 2011 at 9:20 PM, jlazeraski
supreme_java_gur...@yahoo.com wrote:
 Hey Jeremy, thanks for the info.

 I am having a hard time seeing how Wicket uses less memory if for each
 user/page it keeps a DOM tree of objects in memory + any model data for that
 page.. where at least in my struts2 apps, there is nothing in memory on the
 server side.. only when a request comes in do I load some data, then send it
 back as part of the response. The memory is then GC'd at some point by JVM..
 but there is no object tree or anything else related to the user, page they
 are on, etc in memory at all. So I am not sure how Wicket can use comparable
 if not less memory when the struts/mvc way with a stateless request flow
 uses pretty much no memory.

while struts 2 does not put anything into session, you as a developer
eventually will because there will eventually be a page that is too
complex to manage by passing data via urls. why spend two days
rewiring a bunch of code to add more url parameters for a new page
feature when you can just stick it into session and call it a day,
right? what if the data is too long to fit in a url and you cant use a
POST? this has eventually happened in every web-project ive worked on
that used jsps or mvc-type frameworks, and ive worked on a lot of them
before i found Wicket. and no, it wasnt just me sticking things into
session :)

you may think that this is still less data then a Wicket page, and per
particular usecase you are probably right. but, once you add up all
the state that developers start sticking into session eventually it is
going to get very large.

why Wicket eventually wins out is because it manages state like this.
Wicket is like a garbage collector for your session. so even though it
has a higher session size out of the door, in the long run it actually
ends up saving you that size.

of course this is just my experience...

-igor



 One day, if a startup I work at takes off and I make enough mula to not have
 to work, I would love to write an app in spring, struts, wicket, couple
 others.. and compare the details and differences.



 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4087996.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-19 Thread sthomps
Again address the content and not the speaker.  I prompted him to post this to 
get some good feedback on why Wicket is a better alternative than the UI 
frameworks than we have come across.

Frameworks in the ui space are numerous and all serve a different need or 
perspective.

If all you have to say is essentially you suck, you haven't done anything to 
promote the virtues of wicket and it's ideals.

I like wicket and I've seen
It put to good use  based on the ideals it try's to follow by.

If all you have to say is you suck you're stupid etc don't fucking post.

He's obviously done some research and has as an informed opinion - give him the 
respect by offering a intelligent counter argument to his points or dont post 
at all. 

You really just come off as a  jerkoff zealot.
Sent from my iPhone

On Nov 19, 2011, at 5:29 PM, Eelco Hillenius [via Apache 
Wicket]ml-node+s1842946n408747...@n4.nabble.com wrote:

 Really, is this what you do, go around posting to user lists of 
 frameworks you don't like? I imagine one can have a full time job 
 doing that. 
 
 Eelco 
 
 
 On Thu, Nov 17, 2011 at 7:44 AM, Eric Kizaki [hidden email] wrote:
 
  Violates Dry:  You must repeat the component hierarchy of your widgets that 
  are in HTML in Java Code for no good reason.  If you move your widget 
  around 
  in the html it will break the Java and you get a stack trace if you change 
  the nesting.  You have to keep these two files synched.  A JSP file is more 
  maintainable.  At least the view code is in one place. 
  
  Not previewable:  One of the supposed benefits of Wicket is a clean 
  template 
  that could make pages previewable for designers.  First, we don't have 
  seperate designers at my company.  Second, it is better if the samer person 
  does development and design.  Third, if you use extends your page will not 
  be priviewable outside an application server running Wicket.  This supposed 
  benefit does not exist. 
  
  Violates MVC:  It smashes view and controller code into the same Java file. 
  You have code that regulates page flow and code that changes css attributes 
  in the same file.  Even Spring MVC had better separation of concerns. 
  JSP/Servlets with Spring MVC is better. 
  
  Excessively verbose and complicated:  What is a LoadableDetachableModel? 
  The learning curve for Wicket is immense. 
  
  Breaks POJOS:  A real POJO does not need to implement an interface or 
  extend 
  a class.  Wicket forces your beans to be Serializable.  This is like using 
  EJBs in how it forced you to implement interfaces. 
  
  Terrible AJAX:  Compared to a few lines of jQuery AJAX is excessively 
  complicated and verbose in Wicket.  A lot of things like “AJAX” links 
  should 
  not be done via “AJAX” at all.  Hiding a div on the client would simply be 
  done with JavaScript on the client.  Wicket better not require a server 
  request for that.  You also have no JSON support and good luck debugging 
  any 
  JavaScript or AJAX in Firefox.  Instead you have to use the subpar Wicket 
  debugging. 
  
  HTML5:  No support for HTML 5 form elements unless you upgrade to Wicket 
  1.5.  You will get a stack trace.  The upgrade to Wicket 1.5 is painful and 
  will break your code.  Good luck getting this to work with jQuery mobile. 
  
  Bad Defaults:  Most pages are stateless.  The default for Wicket is 
  stateful.  So if I want a decent URL and a bookmarkable page I have to 
  mount 
  the page and use a bookmarkable page link with page parameters.  Using page 
  parameters is worse than how Spring MVC does binding.  I have to keep doing 
  this over and over for each page.  There is too much work involved to get a 
  decent stateless page with a nice URL. This should be the default. 
  
  Interferes with other libraries:  It screws up your jQuery code.  It forces 
  you into a restrictive way of doing web-development:  the Wicket Way. 
  
  Causes a redeploy whenever you add anything:  Maybe Java developers are 
  used 
  to this, but in any other web development environment I do not need to 
  redeploy after adding a text box to the page.  It is completely absurd. 
  Only with JRebel is this alleviated.  No, embedded Jetty in debug mode 
  still 
  slow.  Even a simple JSP file has hot reloading on Tomcat and if I make a 
  change to my view code the changes are immediately viewable in the browser 
  when I refresh.  This is WITHOUT JRebel. 
  
  HTTPSession Objects are not hard:  Most pages do not need state.  If you do 
  use HTTPSession it is simple.  Can you use a map?  Then you can use 
  HTTPSession.  This is less comlicated than most Wicket code. 
  
  Stateful Component based framework are a terrible idea:  Even at the 
  theoretical level this is a bad idea. It is a leaky abstraction over a 
  simple request/response cycle.  It made something simple and made it overly 
  complicated.  This remind me of Hibernate and ORMS.  I disagree that we 
  should abstract things to this level and do 

Re: Apache Wicket is a Flawed Framework

2011-11-19 Thread Igor Vaynberg
On Sat, Nov 19, 2011 at 4:52 PM, jlazeraski
supreme_java_gur...@yahoo.com wrote:
 The big one for me is the server side statefulness. Maybe I misunderstood
 this, but I am really worried about the ability for Wicket to scale given
 that it keeps per user object trees in memory for the page the user is on.

the question is: do you *really* need to scale? :) so far you know
that Wicket keeps *some* state in session. have you measured how much
it actually is on average per user? have you calculated how many user
session fit into your server's ram given average user session size.
the big question then is what will bottle neck first, your ram, your
cpu, or your network backplane for the cluster?

just because something is stateful doesnt mean it automatically does
not scale. in my current place we use two beefy servers to run the
wicket portion of the app that manages an relatively large university.
thats right, two servers - each running two instances of tomcat. will
your app have more load then that?

it is of course much easier to counter this: if i write my app
completely stateless then i wont even have this porblem. of course,
you are right. the qustions then become: will you be able to keep your
app completely stateless? if your ui is complex, probably not. another
question is: how much money will you save by using something like
Wicket which allows you a much faster coding page and a much more
maintenable code base? Will this savings be enough to buy more
servers? more ram for the servers? a fiber backplane for the cluster?
see what im getting at?

-igor



 On the one hand, that is pretty nifty especially for the swing like event
 driven approach with ajax, but where I am not sure of is with the memory
 consumption used continuously on a server, it seems to me you would reduce
 the number of users per server you could handle. More so, replication of
 state information would require 2 (or more) servers in a cluster to have the
 same sort of object tree + state in memory to have any sort of fault
 tolerance. Am I correct in understanding how Wicket maintains an object tree
 per user on the server side? If this is the correct understanding then to me
 the stateless model of using a REST api or Struts actions where each request
 comes in with a session id, and minimal data is in the session.. typically
 just a userId tied to the sesion id so data can then be looked up using the
 userId. Again, if I am correct, then the struts/mvc approach typically is
 keep as little in memory across requests, but each request may need to spend
 some processing time loading up data to reconstruct a page to send back as a
 response (or set as attributes for a JSP page to use to render the response
 with). So there is a bit more processing and temporary memory use, but the
 memory expands/contracts continuously as users make requests and responses
 go back. At least as far as  I understand the whole scalability side of
 things, this is better for more user capacity. As for session replication,
 at least in the old days, you had to replicate session data to at least one
 other server in the cluster. In Wicket, how is this done?

 Another area I am not keen with at all with wicket which is mentioned is
 having to build the object tree code the same way the html page is. With
 element Ids, I am a little confused as to why we cant simply insert the
 component using the element id and let wicket figure out where to stick it
 on the page. To me, as it scans the html page for wicket ids, it should be
 able to pluck wicket component/objects from a Map using the same ID and put
 it where it needs to be. This is one of the areas I have had some trouble
 getting right. If Wicket did not have this requirement, you could rearrange
 panels, components, etc on a page and not have to worry about any server
 side code change, redeploy, etc. It would, in my opinion fix Wicket as the
 ultimate framework (barring my question about scalability/session memory
 above also being resolved). Someone mentioned Wicket 6 will resolve
 something of this.. if you could elaborate (or point a link) that would be
 great. I would love to see them resolve this issue in the framework. It
 would be great to allow a web page designer build up the page, then I add
 dynamic elements, then they decide to change things around and simply edit
 the page and redeploy and see the changes, then do it again until they like
 it.

 Lastly, the bookmarkable and ugly link stuff.. I also agree that it's a bit
 of a pain. It may make sense to some, but having to worry about bookmarkable
 links and when to use them or not, etc adds to the complexity and learning
 curve. I think this is one other area I enjoy about Struts, but perhaps I've
 not worked enough with Wicket to fully realize why its needed and/or can't
 just be avoided.

 Otherwise, I love the idea of Wicket. I've often thought of making my own
 template framework like how I describe above.. stateless on the server 

Re: Apache Wicket is a Flawed Framework

2011-11-19 Thread Igor Vaynberg
On Sat, Nov 19, 2011 at 4:52 PM, jlazeraski
supreme_java_gur...@yahoo.com wrote:
 Another area I am not keen with at all with wicket which is mentioned is
 having to build the object tree code the same way the html page is. With
 element Ids, I am a little confused as to why we cant simply insert the
 component using the element id and let wicket figure out where to stick it
 on the page. To me, as it scans the html page for wicket ids, it should be
 able to pluck wicket component/objects from a Map using the same ID and put
 it where it needs to be.

ironically, i already posted a link to the discussion thread on how
this will be fixed in this thread :) here it is:

http://markmail.org/message/imgf6a2heszaptbp

that thread is a good read that explains why a simple map of
id-component wont do.

 This is one of the areas I have had some trouble
 getting right.

this is a growing pain, after using Wicket for two weeks it will
become second nature...

 Otherwise, I love the idea of Wicket. I've often thought of making my own
 template framework like how I describe above.. stateless on the server side
 (no object model in memory), modular components that can be reused on any
 page, without all the JSP scriplet nightmares.

if you try to build it, eventually you will end up with Wicket :)

-igor




 Look forward to any replies. Thanks all.


 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4087666.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-19 Thread Igor Vaynberg
On Sat, Nov 19, 2011 at 9:31 PM, sthomps stho...@gmail.com wrote:
 Again address the content and not the speaker.  I prompted him to post this 
 to get some good feedback on why Wicket is a better alternative than the UI 
 frameworks than we have come across.

* the email was written as a statement, not a question.
* it had a derogatory and arrogant tone
* it did not directly ask for feedback
* most of these questions have been asked before and answers are
available in the mail archives

-igor



 Frameworks in the ui space are numerous and all serve a different need or 
 perspective.

 If all you have to say is essentially you suck, you haven't done anything to 
 promote the virtues of wicket and it's ideals.

 I like wicket and I've seen
 It put to good use  based on the ideals it try's to follow by.

 If all you have to say is you suck you're stupid etc don't fucking post.

 He's obviously done some research and has as an informed opinion - give him 
 the respect by offering a intelligent counter argument to his points or dont 
 post at all.

 You really just come off as a  jerkoff zealot.
 Sent from my iPhone

 On Nov 19, 2011, at 5:29 PM, Eelco Hillenius [via Apache 
 Wicket]ml-node+s1842946n408747...@n4.nabble.com wrote:

 Really, is this what you do, go around posting to user lists of
 frameworks you don't like? I imagine one can have a full time job
 doing that.

 Eelco


 On Thu, Nov 17, 2011 at 7:44 AM, Eric Kizaki [hidden email] wrote:

  Violates Dry:  You must repeat the component hierarchy of your widgets that
  are in HTML in Java Code for no good reason.  If you move your widget 
  around
  in the html it will break the Java and you get a stack trace if you change
  the nesting.  You have to keep these two files synched.  A JSP file is more
  maintainable.  At least the view code is in one place.
 
  Not previewable:  One of the supposed benefits of Wicket is a clean 
  template
  that could make pages previewable for designers.  First, we don't have
  seperate designers at my company.  Second, it is better if the samer person
  does development and design.  Third, if you use extends your page will not
  be priviewable outside an application server running Wicket.  This supposed
  benefit does not exist.
 
  Violates MVC:  It smashes view and controller code into the same Java file.
  You have code that regulates page flow and code that changes css attributes
  in the same file.  Even Spring MVC had better separation of concerns.
  JSP/Servlets with Spring MVC is better.
 
  Excessively verbose and complicated:  What is a LoadableDetachableModel?
  The learning curve for Wicket is immense.
 
  Breaks POJOS:  A real POJO does not need to implement an interface or 
  extend
  a class.  Wicket forces your beans to be Serializable.  This is like using
  EJBs in how it forced you to implement interfaces.
 
  Terrible AJAX:  Compared to a few lines of jQuery AJAX is excessively
  complicated and verbose in Wicket.  A lot of things like “AJAX” links 
  should
  not be done via “AJAX” at all.  Hiding a div on the client would simply be
  done with JavaScript on the client.  Wicket better not require a server
  request for that.  You also have no JSON support and good luck debugging 
  any
  JavaScript or AJAX in Firefox.  Instead you have to use the subpar Wicket
  debugging.
 
  HTML5:  No support for HTML 5 form elements unless you upgrade to Wicket
  1.5.  You will get a stack trace.  The upgrade to Wicket 1.5 is painful and
  will break your code.  Good luck getting this to work with jQuery mobile.
 
  Bad Defaults:  Most pages are stateless.  The default for Wicket is
  stateful.  So if I want a decent URL and a bookmarkable page I have to 
  mount
  the page and use a bookmarkable page link with page parameters.  Using page
  parameters is worse than how Spring MVC does binding.  I have to keep doing
  this over and over for each page.  There is too much work involved to get a
  decent stateless page with a nice URL. This should be the default.
 
  Interferes with other libraries:  It screws up your jQuery code.  It forces
  you into a restrictive way of doing web-development:  the Wicket Way.
 
  Causes a redeploy whenever you add anything:  Maybe Java developers are 
  used
  to this, but in any other web development environment I do not need to
  redeploy after adding a text box to the page.  It is completely absurd.
  Only with JRebel is this alleviated.  No, embedded Jetty in debug mode 
  still
  slow.  Even a simple JSP file has hot reloading on Tomcat and if I make a
  change to my view code the changes are immediately viewable in the browser
  when I refresh.  This is WITHOUT JRebel.
 
  HTTPSession Objects are not hard:  Most pages do not need state.  If you do
  use HTTPSession it is simple.  Can you use a map?  Then you can use
  HTTPSession.  This is less comlicated than most Wicket code.
 
  Stateful Component based framework are a terrible idea:  Even at the
  theoretical 

Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread Andrea Del Bene

On 17/11/11 16:44, Eric Kizaki wrote:

Violates MVC:  It smashes view and controller code into the same Java file.
You have code that regulates page flow and code that changes css attributes
in the same file.  Even Spring MVC had better separation of concerns.
JSP/Servlets with Spring MVC is better.

Wicket is NOT based on MVC, so there's nothing to violate :). From 
Wicket in Action: Wicket components represent the View and Controller 
in this pattern (MVC)

Excessively verbose and complicated:  What is a LoadableDetachableModel?
The learning curve for Wicket is immense.

Breaks POJOS:  A real POJO does not need to implement an interface or extend
a class.  Wicket forces your beans to be Serializable.  This is like using
EJBs in how it forced you to implement interfaces.
if you had understood LoadableDetachableModel (or at least used it) you 
would not say breaks POJO.

Terrible AJAX:  Compared to a few lines of jQuery AJAX is excessively
complicated and verbose in Wicket.  A lot of things like “AJAX” links should
not be done via “AJAX” at all.  Hiding a div on the client would simply be
done with JavaScript on the client.  Wicket better not require a server
??! do you know that Wicket is a Java framework and not a JavaScript 
(client side) library?


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



RE: Apache Wicket is a Flawed Framework

2011-11-18 Thread Chris Colman
Breaks POJOS:  A real POJO does not need to implement an interface or
extend a class.

A object oriented framework is a foundation on which you extend your
application. Back in the C++ world there was MFC, OWL, .Net, etc., In
the Java world there was AWT and then Swing etc.,. All event driven,
object oriented component based frameworks. All were pretty easy to
build desktop applications in. 

Most of an application's UI elements extended from core classes in the
framework. That's just how you use OO frameworks. If you want to write
UI elements that do not extend or implement classes of interfaces of a
'framework' then you're not really using any framework and reinventing
the wheel.

Bad Defaults:  Most pages are stateless.

Every page in our app is stateful. We show the username of the current
user at the top of the page after logging on and we also have a panel on
the right that shows alerts specific to the current user. Sure the main
content of each page is not delivered differently per user but many of
the auxiliary components are.
 
Causes a redeploy whenever you add anything:  Maybe Java developers are
used to this, but in any other web development environment I do not
need to
redeploy after adding a text box to the page.

We use a component resolver. That can make it possible for the HTML
markup to drive the component hierarchy without explicitly adding
components in Java code each time you want to add a new component.

Stateful Component based framework are a terrible idea:  Even at the
theoretical level this is a bad idea. It is a leaky abstraction over a
simple request/response cycle.

My examples of desktop app frameworks above were all event driven,
object oriented, component based frameworks. This model evolved to be
*universal* in the desktop world for a good reason - it's a damn fine
architecture IMHO and obviously in the opinion of the rest of the world
of desktop application developers.

Einstein said, Make something as simple as possible but not too
simple. Request/response is just too simple to be useful for anyone who
has come through from the desktop application world and 'gets' event
driven, object oriented component based architectures.

When I moved from desktop to web development I went CGI, servlets, JSPs,
Struts, Echo and now Wicket. Until I started using Echo  Wicket my web
app days were never as fun or 'clean' as ye olde desktop app days. For
me Wicket is the ONLY web UI framework that gives me the same kind of
development productivity and clean, reusable application source code
that I enjoyed in the desktop app development world.


It made something simple and made it overly complicated.  This remind
me of Hibernate and ORMS.

Yeah, ok, if you're not using an ORM in your apps by now and still
spending your days writing SQL glue code then we need to have a talk ;)

Chris

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread kamiseq
well, I have nothing against writing my own SQL with spring;]

but it is true that before I read wicket in action I was like a child in fog :/

after JSP I started palying with tapestry and tapestry has a bit
better introduction pages. it is not that there is not enough
information around but wicket lacks free introduction that shows the
wicket way (but maybe I could not find it). looking at wicket stuff is
hard at the beginning.

I tried vaadin and tapestry and I still find wicket as very nice
framework anyway I would never ever go back to JSP ;]

pozdrawiam
Paweł Kamiński

kami...@gmail.com
pkaminski@gmail.com
__



On 18 November 2011 10:35, Chris Colman chr...@stepaheadsoftware.com wrote:
Breaks POJOS:  A real POJO does not need to implement an interface or
extend a class.

 A object oriented framework is a foundation on which you extend your
 application. Back in the C++ world there was MFC, OWL, .Net, etc., In
 the Java world there was AWT and then Swing etc.,. All event driven,
 object oriented component based frameworks. All were pretty easy to
 build desktop applications in.

 Most of an application's UI elements extended from core classes in the
 framework. That's just how you use OO frameworks. If you want to write
 UI elements that do not extend or implement classes of interfaces of a
 'framework' then you're not really using any framework and reinventing
 the wheel.

Bad Defaults:  Most pages are stateless.

 Every page in our app is stateful. We show the username of the current
 user at the top of the page after logging on and we also have a panel on
 the right that shows alerts specific to the current user. Sure the main
 content of each page is not delivered differently per user but many of
 the auxiliary components are.

Causes a redeploy whenever you add anything:  Maybe Java developers are
used to this, but in any other web development environment I do not
 need to
redeploy after adding a text box to the page.

 We use a component resolver. That can make it possible for the HTML
 markup to drive the component hierarchy without explicitly adding
 components in Java code each time you want to add a new component.

Stateful Component based framework are a terrible idea:  Even at the
theoretical level this is a bad idea. It is a leaky abstraction over a
simple request/response cycle.

 My examples of desktop app frameworks above were all event driven,
 object oriented, component based frameworks. This model evolved to be
 *universal* in the desktop world for a good reason - it's a damn fine
 architecture IMHO and obviously in the opinion of the rest of the world
 of desktop application developers.

 Einstein said, Make something as simple as possible but not too
 simple. Request/response is just too simple to be useful for anyone who
 has come through from the desktop application world and 'gets' event
 driven, object oriented component based architectures.

 When I moved from desktop to web development I went CGI, servlets, JSPs,
 Struts, Echo and now Wicket. Until I started using Echo  Wicket my web
 app days were never as fun or 'clean' as ye olde desktop app days. For
 me Wicket is the ONLY web UI framework that gives me the same kind of
 development productivity and clean, reusable application source code
 that I enjoyed in the desktop app development world.


It made something simple and made it overly complicated.  This remind
 me of Hibernate and ORMS.

 Yeah, ok, if you're not using an ORM in your apps by now and still
 spending your days writing SQL glue code then we need to have a talk ;)

 Chris

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread Jens Jahnke
Hi,

On Fri, 18 Nov 2011 11:04:39 +0100
kamiseq kami...@gmail.com wrote:

K but it is true that before I read wicket in action I was like a
K child in fog :/

I totally agree with that.

I'm just starting with wicket and without the book I think I would have
dumped it because there is not much free documentation. Although I find
most other web frameworks suffer in that region too. ;-)

Regards

-- 
18. Nebelung 2011, 11:36
Homepage : http://www.jan0sch.de

Right now I'm having amnesia and deja vu at the same time.
-- Steven Wright


pgpmQcvPd0RKP.pgp
Description: PGP signature


RE: Apache Wicket is a Flawed Framework

2011-11-18 Thread Hielke Hoeve
If you come here and try to start a flame about how bad Wicket is while you 
obviously have no clue how it works then atleast have the decency to write a 
propert post instead of a lame list of cons (and no pros) and a oneliner saying 
Spring MVC is the only other option...

Hielke

-Original Message-
From: Eric Kizaki [mailto:erickiz...@gmail.com] 
Sent: donderdag 17 november 2011 16:45
To: users@wicket.apache.org
Subject: Apache Wicket is a Flawed Framework

Violates Dry:  You must repeat the component hierarchy of your widgets that are 
in HTML in Java Code for no good reason.  If you move your widget around in the 
html it will break the Java and you get a stack trace if you change the 
nesting.  You have to keep these two files synched.  A JSP file is more 
maintainable.  At least the view code is in one place.
 
Not previewable:  One of the supposed benefits of Wicket is a clean template 
that could make pages previewable for designers.  First, we don't have seperate 
designers at my company.  Second, it is better if the samer person does 
development and design.  Third, if you use extends your page will not be 
priviewable outside an application server running Wicket.  This supposed 
benefit does not exist. 

Violates MVC:  It smashes view and controller code into the same Java file. 
You have code that regulates page flow and code that changes css attributes in 
the same file.  Even Spring MVC had better separation of concerns. 
JSP/Servlets with Spring MVC is better. 

Excessively verbose and complicated:  What is a LoadableDetachableModel? 
The learning curve for Wicket is immense.  

Breaks POJOS:  A real POJO does not need to implement an interface or extend a 
class.  Wicket forces your beans to be Serializable.  This is like using EJBs 
in how it forced you to implement interfaces. 

Terrible AJAX:  Compared to a few lines of jQuery AJAX is excessively 
complicated and verbose in Wicket.  A lot of things like “AJAX” links should 
not be done via “AJAX” at all.  Hiding a div on the client would simply be done 
with JavaScript on the client.  Wicket better not require a server request for 
that.  You also have no JSON support and good luck debugging any JavaScript or 
AJAX in Firefox.  Instead you have to use the subpar Wicket debugging. 

HTML5:  No support for HTML 5 form elements unless you upgrade to Wicket 1.5.  
You will get a stack trace.  The upgrade to Wicket 1.5 is painful and will 
break your code.  Good luck getting this to work with jQuery mobile. 

Bad Defaults:  Most pages are stateless.  The default for Wicket is stateful.  
So if I want a decent URL and a bookmarkable page I have to mount the page and 
use a bookmarkable page link with page parameters.  Using page parameters is 
worse than how Spring MVC does binding.  I have to keep doing this over and 
over for each page.  There is too much work involved to get a decent stateless 
page with a nice URL. This should be the default. 

Interferes with other libraries:  It screws up your jQuery code.  It forces you 
into a restrictive way of doing web-development:  the Wicket Way.  

Causes a redeploy whenever you add anything:  Maybe Java developers are used to 
this, but in any other web development environment I do not need to redeploy 
after adding a text box to the page.  It is completely absurd. 
Only with JRebel is this alleviated.  No, embedded Jetty in debug mode still 
slow.  Even a simple JSP file has hot reloading on Tomcat and if I make a 
change to my view code the changes are immediately viewable in the browser when 
I refresh.  This is WITHOUT JRebel.  

HTTPSession Objects are not hard:  Most pages do not need state.  If you do use 
HTTPSession it is simple.  Can you use a map?  Then you can use HTTPSession.  
This is less comlicated than most Wicket code. 

Stateful Component based framework are a terrible idea:  Even at the 
theoretical level this is a bad idea. It is a leaky abstraction over a simple 
request/response cycle.  It made something simple and made it overly 
complicated.  This remind me of Hibernate and ORMS.  I disagree that we should 
abstract things to this level and do everything in verbose Java. 
People are dropping Hibernate and going back to native SQL and Spring JDBC 
template.  SQL and the relational model are easy.  Working with HTTP requests 
is easy too.  What was wrong with JSPs/Servlets?  Keep it simple stupid.  We 
know JSF was too complicated and it was terrible.  Spring MVC is better and has 
rest support.  It just works with Spring and has great support for the JSON 
Jackson mapper.  

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4080411.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread Gaetan Zoritchak
I started with the book wicket in action so it was ok. Before choosing a
technology I look at the number of existing books and I buy the best one.
But I'm not sure that every body does like me.

My main problem is the wiki. The pages are often very old explaining things
that do not apply with the last version of wicket and the wiki si so
slow that I can't imagine working on it to update the pages :(

2011/11/18 robert.mcguinness robert.mcguinness@gmail.com

 i'm baffled when people say the documentation is poor, the javadocs are
 excellent and like igor said there are some great books (blogs too!).
  books
 and blogs get outdated fast since technlogy is rapidly advancing, so *use
 the source luke!*.  Not only will you learn Wicket, but I guarantee your
 Java skills will improve.


 awesome examples:



 https://github.com/apache/wicket https://github.com/apache/wicket  (scan
 over the unit test, best way to learn any framework not just wicket)

 https://github.com/55minutes/fiftyfive-wicket
 https://github.com/55minutes/fiftyfive-wicket  (fantastic)

 https://github.com/42Lines https://github.com/42Lines

 https://github.com/wicketstuff/core https://github.com/wicketstuff/core (a
 gem, tons of examples on how to pretty much do anything)

 http://code.google.com/p/wiquery/source/checkout
 http://code.google.com/p/wiquery/source/checkout

 https://github.com/jolira/wicket-stateless
 https://github.com/jolira/wicket-stateless  (wicket stateless is
 excellent,
 even easier with wicket 1.5)

 https://github.com/reaktor/oegyscroll
 https://github.com/reaktor/oegyscroll
 (endless pagination)

 http://code.google.com/p/wiquery/source/browse/core
 http://code.google.com/p/wiquery/source/browse/core  (jquery)

 http://code.google.com/p/jqwicket/source/browse/
 http://code.google.com/p/jqwicket/source/browse/  (jquery, learn from the
 code and roll your own if it doesn't fit your needs, super easy

 https://github.com/rjnichols/visural-wicket
 https://github.com/rjnichols/visural-wicket  (great ui tools)

 https://xaloon.googlecode.com/svn/ https://xaloon.googlecode.com/svn/
 (excellent!)



 rob

 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082034.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread Josh Kamau
Gaetan;

I also like starting from a book. Then read the (scattered) docs and wiki
when am looking for a solution to specific issues. Some projects have an
official user guide that is downloadable as pdf or read online as html. I
know documentation is one of the the most boring tasks for developers but
its is necessary. May be we should hire someone to do the user guide. The
users can donate to pay him.

My 2c.

Josh.

On Fri, Nov 18, 2011 at 2:45 PM, Gaetan Zoritchak 
g.zoritc...@moncoachfinance.com wrote:

 I started with the book wicket in action so it was ok. Before choosing a
 technology I look at the number of existing books and I buy the best one.
 But I'm not sure that every body does like me.

 My main problem is the wiki. The pages are often very old explaining things
 that do not apply with the last version of wicket and the wiki si so
 slow that I can't imagine working on it to update the pages :(

 2011/11/18 robert.mcguinness robert.mcguinness@gmail.com

  i'm baffled when people say the documentation is poor, the javadocs are
  excellent and like igor said there are some great books (blogs too!).
   books
  and blogs get outdated fast since technlogy is rapidly advancing, so *use
  the source luke!*.  Not only will you learn Wicket, but I guarantee your
  Java skills will improve.
 
 
  awesome examples:
 
 
 
  https://github.com/apache/wicket https://github.com/apache/wicket  (scan
  over the unit test, best way to learn any framework not just wicket)
 
  https://github.com/55minutes/fiftyfive-wicket
  https://github.com/55minutes/fiftyfive-wicket  (fantastic)
 
  https://github.com/42Lines https://github.com/42Lines
 
  https://github.com/wicketstuff/core https://github.com/wicketstuff/core(a
  gem, tons of examples on how to pretty much do anything)
 
  http://code.google.com/p/wiquery/source/checkout
  http://code.google.com/p/wiquery/source/checkout
 
  https://github.com/jolira/wicket-stateless
  https://github.com/jolira/wicket-stateless  (wicket stateless is
  excellent,
  even easier with wicket 1.5)
 
  https://github.com/reaktor/oegyscroll
  https://github.com/reaktor/oegyscroll
  (endless pagination)
 
  http://code.google.com/p/wiquery/source/browse/core
  http://code.google.com/p/wiquery/source/browse/core  (jquery)
 
  http://code.google.com/p/jqwicket/source/browse/
  http://code.google.com/p/jqwicket/source/browse/  (jquery, learn from
 the
  code and roll your own if it doesn't fit your needs, super easy
 
  https://github.com/rjnichols/visural-wicket
  https://github.com/rjnichols/visural-wicket  (great ui tools)
 
  https://xaloon.googlecode.com/svn/ https://xaloon.googlecode.com/svn/
  (excellent!)
 
 
 
  rob
 
  --
  View this message in context:
 
 http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082034.html
  Sent from the Users forum mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 



Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread Martijn Dashorst
On Thu, Nov 17, 2011 at 4:44 PM, Eric Kizaki erickiz...@gmail.com wrote:

Thanks for taking the time to vent your frustrations. I don't see any
reason to start to ridicule you, or to think you are an incapable
developer just because you don't like Wicket and have taken the time
to get it off your chest.

Wicket is not suitable for everyone, not suitable for every
application, not suitable for every situation. We don't claim such,
and neither do we force anyone to use Wicket. If you don't like what
you see, too bad, move on to something you do like.

Martijn

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread heikki
I have tried out the Wicket framework and many things I really like about it.
Some observations:


- Wicket changes drastically between versions, and even between minor
versions / release candidates, things suddenly disappear from the API,
sometimes without having been flagged as deprecated ;

- as a result, many times the example code you find on the web or in books
like 'Wicket in Action' does no longer work as is

- the Javadoc of the source is quite OK for some classes, but for the great
majority any textual explanations there are either sparse or absent

- luckily the mailing list is nothing short of fantastic !

- I agree that it is rather too easy for Wicket to make things stateful,
when you don't want it

- and in my opinion the stuff you need to do to achieve normal URLs (no ?,
no version number, no nothing) is just a pain. *Every* URL, for stateless or
stateless pages or whatever, should be normal, otherwise it is just not
acceptable -- users never want to see those complicated-looking URLs under
any circumstance

- did not yet try out Ajax with Wicket, so I have no opinion on that

Just my 2¢. In all, a great framework that is much easier to use than e.g.
things based on JSP. Keep up the good work, guys !

Kind regards
Heikki Doeleman


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082988.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread Josh Kamau
- did not yet try out Ajax with Wicket, so I have no opinion on that 

In my opinion, ajax is the killer feature. Give it a try.

Josh.

On Fri, Nov 18, 2011 at 3:07 PM, heikki tropic...@gmail.com wrote:

 I have tried out the Wicket framework and many things I really like about
 it.
 Some observations:


 - Wicket changes drastically between versions, and even between minor
 versions / release candidates, things suddenly disappear from the API,
 sometimes without having been flagged as deprecated ;

 - as a result, many times the example code you find on the web or in books
 like 'Wicket in Action' does no longer work as is

 - the Javadoc of the source is quite OK for some classes, but for the great
 majority any textual explanations there are either sparse or absent

 - luckily the mailing list is nothing short of fantastic !

 - I agree that it is rather too easy for Wicket to make things stateful,
 when you don't want it

 - and in my opinion the stuff you need to do to achieve normal URLs (no
 ?,
 no version number, no nothing) is just a pain. *Every* URL, for stateless
 or
 stateless pages or whatever, should be normal, otherwise it is just not
 acceptable -- users never want to see those complicated-looking URLs under
 any circumstance

 - did not yet try out Ajax with Wicket, so I have no opinion on that

 Just my 2¢. In all, a great framework that is much easier to use than e.g.
 things based on JSP. Keep up the good work, guys !

 Kind regards
 Heikki Doeleman


 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082988.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread Chantal Ackermann
Hi all!

Thanks for this list, Rob!

Not that there would be any more to say except:

* I've never seen so informative and extremely helpfull Exception/Error
messages in any framework or tool so far.
Thank you!
* Concerning the ugly URLs: well, I don't think that the real users
out there bother so much. (But you should still aim to the most perfect
solution, for the honour...)
Working with APEX I've realized that there are blogs based on APEX - and
hey, compared to APEX' URLs, wicket's are a treat...

Cheers,
Chantal

On Fri, 2011-11-18 at 04:35 +0100, robert.mcguinness wrote:
 i'm baffled when people say the documentation is poor, the javadocs are
 excellent and like igor said there are some great books (blogs too!).  books
 and blogs get outdated fast since technlogy is rapidly advancing, so *use
 the source luke!*.  Not only will you learn Wicket, but I guarantee your
 Java skills will improve.  
 
 
 awesome examples:
 
 
 
 https://github.com/apache/wicket https://github.com/apache/wicket  (scan
 over the unit test, best way to learn any framework not just wicket)
 
 https://github.com/55minutes/fiftyfive-wicket
 https://github.com/55minutes/fiftyfive-wicket  (fantastic)
 
 https://github.com/42Lines https://github.com/42Lines 
 
 https://github.com/wicketstuff/core https://github.com/wicketstuff/core  (a
 gem, tons of examples on how to pretty much do anything)
 
 http://code.google.com/p/wiquery/source/checkout
 http://code.google.com/p/wiquery/source/checkout 
 
 https://github.com/jolira/wicket-stateless
 https://github.com/jolira/wicket-stateless  (wicket stateless is excellent,
 even easier with wicket 1.5)
 
 https://github.com/reaktor/oegyscroll https://github.com/reaktor/oegyscroll 
 (endless pagination)
 
 http://code.google.com/p/wiquery/source/browse/core
 http://code.google.com/p/wiquery/source/browse/core  (jquery)
 
 http://code.google.com/p/jqwicket/source/browse/
 http://code.google.com/p/jqwicket/source/browse/  (jquery, learn from the
 code and roll your own if it doesn't fit your needs, super easy
 
 https://github.com/rjnichols/visural-wicket
 https://github.com/rjnichols/visural-wicket  (great ui tools)
 
 https://xaloon.googlecode.com/svn/ https://xaloon.googlecode.com/svn/ 
 (excellent!)
 
 
 
 rob
 
 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082034.html
 Sent from the Users forum mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread Daniel Neugebauer
I was searching for a Java framework two years ago because I wanted 
server-side persistence and a statically typed language with the option 
for easy AJAX and debugging while the output markup is largely 
maintained the way I wrote the templates.


I think I found Wicket via DZone due to the 1.4 release. I already read 
a book from Manning before and liked that it was written in a way that 
enables the reader to jump right into programming after having read the 
introductory chapters. I was happy when I saw that Wicket in Action 
seemed to use a similar structure. I think I tried Wicket without the 
book first but got stuck really quick (at latest when I got to the point 
when I needed models which was quite immediate) and so buying WiA was a 
quick (and good) decision.


As with any framework, it takes at least one project to get your head 
around it, so you better start with some personal project in your free 
time. On the following 2-3 projects you are iterating on the maybe I 
could have done it better that way process. But that's just the way it 
is for any framework in any language (and also without any framework at 
all). I assume the OP is using Wicket the first time without any 
guidance and just hasn't found into it yet.


I wasn't able to put Wicket in use at work until January this year but 
now we are on our 2nd (my 4th) Wicket project. What I could observe is that


1) you usually don't find into Wicket until you read a book
   (with WiA it's sufficient to read the introductory chapters, jump
   into coding and come back to the chapters whenever you need to know
   something)

2) there is an aversion until you get your head around the correct use
   of models and anonymous inner classes, at least if you never did
   something like that before
   (WiA introduces it quite good but you have to start coding before
   you really get it)

3) you should follow the (excellent) mailing list to read about issues
   you may encounter and use it as a knowledge base once you hit some
   problem/question
   (better on an own email account than on the archives)

4) if documentation does not help, read the source code
   (I found it pretty readable which is much different from other
   frameworks I have used/tried before - being easily accessible with
   Maven and a decent IDE, there is no excuse not to look into it)

So, the conclusion is: There should be better free documentation but if 
you pick up a book it's quite easy to get started and the best 30€ ever 
spent.



- I agree that it is rather too easy for Wicket to make things stateful,
when you don't want it


To turn that into a point of critique: It may be hard to get stateless 
pages.


I've made a similar experience where I had a search form that would not 
go stateless. I couldn't figure out where anything was persisted but if 
I had dug deeper, I may have found the cause, but that issue wasn't 
important enough to invest more time in it.



- and in my opinion the stuff you need to do to achieve normal URLs (no ?,
no version number, no nothing) is just a pain. *Every* URL, for stateless or
stateless pages or whatever, should be normal, otherwise it is just not
acceptable -- users never want to see those complicated-looking URLs under
any circumstance


I prefer the way Wicket handles persistence with at-most-once semantics 
by simply adding version numbers on the URL (after a redirect from an 
internal URL) as other methods are less successful in achieving that out 
of the box, pollute URLs even further or add hidden markup. IMO, two 
numbers on the URL are quite unobtrusive, especially as they are simply 
ignored and transparently reassigned if the session does not match (i.e. 
on a URL that has been pasted into an email etc.).



- did not yet try out Ajax with Wicket, so I have no opinion on that


It's incredibly easy to use; you should really try it. :)


Just my 2¢. In all, a great framework that is much easier to use than e.g.
things based on JSP. Keep up the good work, guys !


Full ack! :)

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread Eric Kizaki
I was not expecting so much hate.  I guess now I am infamous in the Java
world now.  Look, it is just my opinion.  Not many people actually stopped
to address many of my points.  They just immediately bashed me. 

I am sticking with Wicket because it is required for work.  I am able to do
stuff in it but it seems unnecessarily complicated.  I own the “Wicket in
Action” book and “Enjoying Web Development with Wicket Book” by Kent Ka Iok
Tong.  The second book is much more practical.  Without these books I would
not be able to do anything in Wicket.  That is why I did not mention
documentation.  I would prefer to just be able to check out something like
this http://static.springsource.org/docs/petclinic.html.  This is a real
working application that shows how to do things with databases etc.  With
Wicket, I had to string a bunch of snippets together and read two books.  I
am still not sure I am doing things the best way.

To people who say I am inexperienced, I have tried JSF and GWT.  Wicket is
better than both of those.  JSF has an invasive and complicated lifecycle. 
When I saw the lifecycle diagram I just stopped even looking into it.  GWT
uses terrible Swing style layouts and all these crappy interfaces for RPC. 
There was also no real help on the server.  At least with Wicket I can still
use HTML and CSS for my layouts.  However, these component based frameworks
are still way too complicated for a simple task:  building a web page.  In
my humble opinion Spring MVC done right (no scriplets) with JSTL  EL and
jQuery is better than Wicket.  You can also use Velocity templating.  I have
also used Swing to build desktop apps.  I would not say Swing is a shining
example of how to build GUIs.  I thought it was pretty bad, verbose, and
impractical.  The Play Framework has the right idea:  stateless and restful. 
No clunky components and over-engineered objected-oriented baggage.  

Here is a quote from the Restlet page
(http://www.restlet.org/about/introduction):
“While powerful for complex centralized models, the object-oriented paradigm
isn't always the best suited for Web development. Java developers need
realize this and start thinking more RESTfully when developing new Web
servers or new AJAX-based Web clients. The Restlet project is providing a
simple yet solid foundation that can get you started right away on the Web
2.0.”
- Jérôme Louvel, Restlet founder
Maybe you can look up his Linkdin and start bashing him too.  Oh no he said
object-oriented is not the Holy Grail!

I am definitely in the “I like to hand-code HTML, CSS, and Javascript” camp. 
I even like hand-coding SQL.  I get complete control.  These are all pretty
easy languages; most of them are declarative.  They are easier than Java.  I
know most Java developers do not feel this way and want to just do
everything in Java.  I think you should use the best tool for the job.  Java
is a mediocre tool to use in every domain.



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4083476.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread Adam Gray
That's actually interesting you feel that way because I was just making the
comment that I was surprised at how little hate was being displayed.  Sure
there are a couple here and there, but par for the internet is far, far
lower (higher? maybe a golf analogy was a bad idea) than what we're seeing
here.  And, in fact, many people did attempt to address specific issues.
 However, you can't really expect sunshine and rainbows when the initial
post says nothing positive whatsoever and offers no suggestions for
improvement.  This more recent post, however, I like so much better because
you actually get into specific instances where there is room for
improvement and link to a potential guide for a solution.

I would definitely agree with you that something like the spring petclinic
would be really handy.  I, personally, can't count the number of times I
found myself doing it wrong because I hadn't known to look at the javadoc
in that other class over there (I'm looking at you, ListView vs DataTable).
 One of the largest strengths of wicket is its flexibility, but it tends to
come at the cost of there being too many ways to do something.  That makes
it difficult to know which is the right way to accomplish the task.
 Until you really get to know wicket, it definitely feels a bit like you
need to learn the secret handshakes and hidden incantations to make it do
something as simple as showing feedback properly in a repeating view.
 There are a lot of us here that have gone through (and still going) that
learning curve and could probably contribute to a large sample application
that shows how to do stuff.

Additionally, I believe work on Wicket 6 has officially started, so if
there are concrete suggestions for improvement, I bet Jira would love to
record them for you.  Is Wicket perfect?  No, no framework is.  But it's
getting better and the more help it has, the better it will get.

On Fri, Nov 18, 2011 at 9:27 AM, Eric Kizaki erickiz...@gmail.com wrote:

 I was not expecting so much hate.  I guess now I am infamous in the Java
 world now.  Look, it is just my opinion.  Not many people actually stopped
 to address many of my points.  They just immediately bashed me.

 I am sticking with Wicket because it is required for work.  I am able to do
 stuff in it but it seems unnecessarily complicated.  I own the “Wicket in
 Action” book and “Enjoying Web Development with Wicket Book” by Kent Ka Iok
 Tong.  The second book is much more practical.  Without these books I would
 not be able to do anything in Wicket.  That is why I did not mention
 documentation.  I would prefer to just be able to check out something like
 this http://static.springsource.org/docs/petclinic.html.  This is a real
 working application that shows how to do things with databases etc.  With
 Wicket, I had to string a bunch of snippets together and read two books.  I
 am still not sure I am doing things the best way.

 To people who say I am inexperienced, I have tried JSF and GWT.  Wicket is
 better than both of those.  JSF has an invasive and complicated lifecycle.
 When I saw the lifecycle diagram I just stopped even looking into it.  GWT
 uses terrible Swing style layouts and all these crappy interfaces for RPC.
 There was also no real help on the server.  At least with Wicket I can
 still
 use HTML and CSS for my layouts.  However, these component based frameworks
 are still way too complicated for a simple task:  building a web page.  In
 my humble opinion Spring MVC done right (no scriplets) with JSTL  EL and
 jQuery is better than Wicket.  You can also use Velocity templating.  I
 have
 also used Swing to build desktop apps.  I would not say Swing is a shining
 example of how to build GUIs.  I thought it was pretty bad, verbose, and
 impractical.  The Play Framework has the right idea:  stateless and
 restful.
 No clunky components and over-engineered objected-oriented baggage.

 Here is a quote from the Restlet page
 (http://www.restlet.org/about/introduction):
 “While powerful for complex centralized models, the object-oriented
 paradigm
 isn't always the best suited for Web development. Java developers need
 realize this and start thinking more RESTfully when developing new Web
 servers or new AJAX-based Web clients. The Restlet project is providing a
 simple yet solid foundation that can get you started right away on the Web
 2.0.”
 - Jérôme Louvel, Restlet founder
 Maybe you can look up his Linkdin and start bashing him too.  Oh no he said
 object-oriented is not the Holy Grail!

 I am definitely in the “I like to hand-code HTML, CSS, and Javascript”
 camp.
 I even like hand-coding SQL.  I get complete control.  These are all pretty
 easy languages; most of them are declarative.  They are easier than Java.
  I
 know most Java developers do not feel this way and want to just do
 everything in Java.  I think you should use the best tool for the job.
  Java
 is a mediocre tool to use in every domain.



 --
 View this message in context:
 

Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread hfriederichs

heikki wrote:
 
 - and in my opinion the stuff you need to do to achieve normal URLs (no
 ?, no version number, no nothing) is just a pain. *Every* URL, for
 stateless or stateless pages or whatever, should be normal, otherwise it
 is just not acceptable -- users never want to see those
 complicated-looking URLs under any circumstance
 
 

Here I totally agree. I think there are very few developers who understand
this. An URL is a technical entity, and, if they had a choice, the vast
majority of internet-users could very well do without it.
URL's are /not/ user friendly.

It's better now, but in the early days it was very cumbersome to help my 80
father (y'all understand 80, I presume) on the phone: 'No, dad, just type
h-t-t-p-:-/-/.'.

I really think this is a flaw in wicket, caused by a collective blank spot
of it's otherwise very clever developers.

But I really love Wicket, I managed to develop a quite complex application
that's robust and easy to use, and it's only my second web application ever,
the first being a Servlet with html-spawning only...


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4083524.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread Gaetan Zoritchak
 The Play Framework has the right idea:  stateless and restful.
 No clunky components and over-engineered objected-oriented baggage.


Play has some advantages but also shortcomings and presents significant
risks. The transition from version 1 to version 2 will require re-writing
the code. No migration possible! The new version seems to focus
on scala (the views are now coded in scala instead of groovy). The business
code can be in java and scala. What will happen to the java version in 2
years? Play's vision is a fully integrated technology stack with
fairly fixed choices (JPA data access for java, Anorm - single
layer over jdbc - for scala).

This is not the approach of wicket which is much more modular and
simply treat the presentation layer.

In short, there is no silver bullet ... just find the framework that best
meets your needs.


Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread Igor Vaynberg
i will address some points that i dont think have been addressed yet...

On Thu, Nov 17, 2011 at 7:44 AM, Eric Kizaki erickiz...@gmail.com wrote:
 Violates Dry:  You must repeat the component hierarchy of your widgets that
 are in HTML in Java Code for no good reason.  If you move your widget around
 in the html it will break the Java and you get a stack trace if you change
 the nesting.  You have to keep these two files synched.  A JSP file is more
 maintainable.  At least the view code is in one place.

this will be much improved in the upcoming 6.0. this is not as trivial
as saying: oh, just let me move my components in markup anywhere
because a lot of the usecases actually depend on component hiearchy on
the java side so it doesnt make sense having them out of sync.

anyways, this was thoroughly discussed on the mailing list, have you
bothered to search the archive before ranting? here is the link to a
discussion:

http://markmail.org/thread/5iczgvd42k6oeera

 Not previewable:  One of the supposed benefits of Wicket is a clean template
 that could make pages previewable for designers.

the pages are previewable to a much larger degree then they are with
most other frameworks. we dont claim complete previewability i dont
think, and if we do we shouldnt. wicket allows you to chunk up the ui
and swap bits and pieces out at runtime, so of course it is very hard
to construct a preview for a page that is composed of lots of smaller
pieces, however, the pieces themselves are previewable.

  First, we don't have
 seperate designers at my company.

im sorry

 Second, it is better if the samer person
 does development and design.

heh. personally, i dont like to spend my time thinking about which css
hack i need to apply to make a div line up perfectly across all
browsers. i think most developers would agree with me. im just glad i
work at a company where we do have designers who do that, do it well,
and most of all love doing it :)

  Third, if you use extends your page will not
 be priviewable outside an application server running Wicket.  This supposed
 benefit does not exist.

yep. or if you use panels. however, you are free to add chunks outside
the wicket:extend tags that add the missing body/html/head tags to
make the page or panel at least somewhat previewable, which our
designers do sometimes.

i think previewability in our context should mean that the designer
can open a markup file used by wicket in the tool of their liking and
not feel completely lost or afraid to tweak stuff. in my company the
designers do the first pass on new markup, then the developers
wicketize it and write the code. once that is done the designers often
go back and tweak things, and they can do so easily without breaking
anything - i think thats the important bit to take away.

 Violates MVC:  It smashes view and controller code into the same Java file.
 You have code that regulates page flow and code that changes css attributes
 in the same file.  Even Spring MVC had better separation of concerns.
 JSP/Servlets with Spring MVC is better.

ive never understood why people want to externalize the flow of the
application. it seems rather silly considering a lot of the flows are
dynamic. especially once you consider panel-swapping or
single-page-applications as they are often called. how do you
externalize that flow? you cant.

also, i do not see a semantic difference between the code that
navigates and the code that tweaks css attributes. they are both about
the user interface. as long as no one puts business logic into my
components im ok.

 Excessively verbose and complicated:  What is a LoadableDetachableModel?

an LDM is basically a closure. its only verbose because java is
verbose when it comes to creating closures, but this will be fixed in
java 8.

 The learning curve for Wicket is immense.

yes. for those coming from the mvc/servlets/action frameworks world it
involves a complete, and i hate to use the term, paradigm shift in
how you approach problems. you actually have to learn the OOP part of
java :)

people who have been coding swing, swt, gwt, or any other oop
framework can pick up wicket very quickly.

i think all your other points have been addressed in other emails.

good luck

-igor

 Breaks POJOS:  A real POJO does not need to implement an interface or extend
 a class.  Wicket forces your beans to be Serializable.  This is like using
 EJBs in how it forced you to implement interfaces.

 Terrible AJAX:  Compared to a few lines of jQuery AJAX is excessively
 complicated and verbose in Wicket.  A lot of things like “AJAX” links should
 not be done via “AJAX” at all.  Hiding a div on the client would simply be
 done with JavaScript on the client.  Wicket better not require a server
 request for that.  You also have no JSON support and good luck debugging any
 JavaScript or AJAX in Firefox.  Instead you have to use the subpar Wicket
 debugging.

 HTML5:  No support for HTML 5 form elements unless you upgrade to Wicket

RE: Apache Wicket is a Flawed Framework

2011-11-18 Thread Brown, Berlin [GCG-PFS]
Wicket is a different approach from the JSP(Spring MVC/Struts) model but is 
certainly an improvement over the basic Servlets and JSPs oriented MVC.

One of the benefits is that you compile your wicket components to mostly pure 
Java and you have a good idea how your page will behave.

Yes, Wicket does a lot of the work for you.  That is good or bad depending on 
what your requirements are.


-Original Message-
From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] 
Sent: Friday, November 18, 2011 1:50 PM
To: users@wicket.apache.org
Subject: Re: Apache Wicket is a Flawed Framework

i will address some points that i dont think have been addressed yet...

On Thu, Nov 17, 2011 at 7:44 AM, Eric Kizaki erickiz...@gmail.com wrote:
 Violates Dry:  You must repeat the component hierarchy of your widgets 
 that are in HTML in Java Code for no good reason.  If you move your 
 widget around in the html it will break the Java and you get a stack 
 trace if you change the nesting.  You have to keep these two files 
 synched.  A JSP file is more maintainable.  At least the view code is in one 
 place.

this will be much improved in the upcoming 6.0. this is not as trivial as 
saying: oh, just let me move my components in markup anywhere
because a lot of the usecases actually depend on component hiearchy on the java 
side so it doesnt make sense having them out of sync.

anyways, this was thoroughly discussed on the mailing list, have you bothered 
to search the archive before ranting? here is the link to a
discussion:

http://markmail.org/thread/5iczgvd42k6oeera

 Not previewable:  One of the supposed benefits of Wicket is a clean 
 template that could make pages previewable for designers.

the pages are previewable to a much larger degree then they are with most other 
frameworks. we dont claim complete previewability i dont think, and if we do we 
shouldnt. wicket allows you to chunk up the ui and swap bits and pieces out at 
runtime, so of course it is very hard to construct a preview for a page that is 
composed of lots of smaller pieces, however, the pieces themselves are 
previewable.

  First, we don't have
 seperate designers at my company.

im sorry

 Second, it is better if the samer person does development and design.

heh. personally, i dont like to spend my time thinking about which css hack i 
need to apply to make a div line up perfectly across all browsers. i think most 
developers would agree with me. im just glad i work at a company where we do 
have designers who do that, do it well, and most of all love doing it :)

  Third, if you use extends your page will not be priviewable outside 
 an application server running Wicket.  This supposed benefit does not 
 exist.

yep. or if you use panels. however, you are free to add chunks outside the 
wicket:extend tags that add the missing body/html/head tags to make the page or 
panel at least somewhat previewable, which our designers do sometimes.

i think previewability in our context should mean that the designer can open 
a markup file used by wicket in the tool of their liking and not feel 
completely lost or afraid to tweak stuff. in my company the designers do the 
first pass on new markup, then the developers wicketize it and write the code. 
once that is done the designers often go back and tweak things, and they can do 
so easily without breaking anything - i think thats the important bit to take 
away.

 Violates MVC:  It smashes view and controller code into the same Java file.
 You have code that regulates page flow and code that changes css 
 attributes in the same file.  Even Spring MVC had better separation of 
 concerns.
 JSP/Servlets with Spring MVC is better.

ive never understood why people want to externalize the flow of the 
application. it seems rather silly considering a lot of the flows are dynamic. 
especially once you consider panel-swapping or single-page-applications as they 
are often called. how do you externalize that flow? you cant.

also, i do not see a semantic difference between the code that navigates and 
the code that tweaks css attributes. they are both about the user interface. as 
long as no one puts business logic into my components im ok.

 Excessively verbose and complicated:  What is a LoadableDetachableModel?

an LDM is basically a closure. its only verbose because java is verbose when it 
comes to creating closures, but this will be fixed in java 8.

 The learning curve for Wicket is immense.

yes. for those coming from the mvc/servlets/action frameworks world it involves 
a complete, and i hate to use the term, paradigm shift in how you approach 
problems. you actually have to learn the OOP part of java :)

people who have been coding swing, swt, gwt, or any other oop framework can 
pick up wicket very quickly.

i think all your other points have been addressed in other emails.

good luck

-igor

 Breaks POJOS:  A real POJO does not need to implement an interface or 
 extend a class.  Wicket forces your

Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread Alex Objelean
First of all, sorry for my previous comment. It was wrong judging you instead
discussing the points addressed in your post. Nevertheless, nobody hates you
for your opinion :). This kind of posts appears from time to time and there
is nothing wrong with them as long as these address valid issues (which is
not the case this time). You cannot please everybody. 

The only problem is the way you titled your post - that is the real bashing.
When writing this kind of post, don't forget that you are bashing not only
the framework, but also the time and effort of the people who contributed to
this open source project. A constructive critique is always appreciated. 





 



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4084976.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-18 Thread Jonathan Locke
Needless to say, I don't particularly agree with most of the criticisms
listed. 

And for the right job, Java isn't half as bad as you seem to think. I'd say
the trouble is Java vs. the JDK (and other libraries). While Java itself is
still reasonably cool, there is a lot of real crap out there. And there's
plenty in the JDK! But if you're determined to program well, you can wrap
and hide the majority of this crap quite excellently in Java. What you're
left with is a screaming fast server-side programming language with more
support in terms of platforms and functionality than anything in history.
While I'd love to see a Scala where I can read 90% of the source code out
there at a glance like I can with Java, I'll stick with Java (at least on
the server side) for now.

Given that you hate Wicket and Java (and have a LOT of energy for that given
the length of your post), why don't you switch jobs? You sound unhappy with
your gig. And although the economy is down, software is actually quite hot
and there are a lot of jobs for people that just want to hack on loosely
typed UI scripts. Heck, I'm getting emails from headhunters almost daily.
I'd say life is too short to lump it. If Wicket doesn't suit you, switch
frameworks. If it's required at work and that makes you hate your job,
switch jobs.


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4085067.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread Sven Meier

Thanks for the laugh. Where are the irony tags?

Sven

Am 17.11.2011 16:44, schrieb Eric Kizaki:

Violates Dry:  You must repeat the component hierarchy of your widgets that
are in HTML in Java Code for no good reason.  If you move your widget around
in the html it will break the Java and you get a stack trace if you change
the nesting.  You have to keep these two files synched.  A JSP file is more
maintainable.  At least the view code is in one place.

Not previewable:  One of the supposed benefits of Wicket is a clean template
that could make pages previewable for designers.  First, we don't have
seperate designers at my company.  Second, it is better if the samer person
does development and design.  Third, if you use extends your page will not
be priviewable outside an application server running Wicket.  This supposed
benefit does not exist.

Violates MVC:  It smashes view and controller code into the same Java file.
You have code that regulates page flow and code that changes css attributes
in the same file.  Even Spring MVC had better separation of concerns.
JSP/Servlets with Spring MVC is better.

Excessively verbose and complicated:  What is a LoadableDetachableModel?
The learning curve for Wicket is immense.

Breaks POJOS:  A real POJO does not need to implement an interface or extend
a class.  Wicket forces your beans to be Serializable.  This is like using
EJBs in how it forced you to implement interfaces.

Terrible AJAX:  Compared to a few lines of jQuery AJAX is excessively
complicated and verbose in Wicket.  A lot of things like “AJAX” links should
not be done via “AJAX” at all.  Hiding a div on the client would simply be
done with JavaScript on the client.  Wicket better not require a server
request for that.  You also have no JSON support and good luck debugging any
JavaScript or AJAX in Firefox.  Instead you have to use the subpar Wicket
debugging.

HTML5:  No support for HTML 5 form elements unless you upgrade to Wicket
1.5.  You will get a stack trace.  The upgrade to Wicket 1.5 is painful and
will break your code.  Good luck getting this to work with jQuery mobile.

Bad Defaults:  Most pages are stateless.  The default for Wicket is
stateful.  So if I want a decent URL and a bookmarkable page I have to mount
the page and use a bookmarkable page link with page parameters.  Using page
parameters is worse than how Spring MVC does binding.  I have to keep doing
this over and over for each page.  There is too much work involved to get a
decent stateless page with a nice URL. This should be the default.

Interferes with other libraries:  It screws up your jQuery code.  It forces
you into a restrictive way of doing web-development:  the Wicket Way.

Causes a redeploy whenever you add anything:  Maybe Java developers are used
to this, but in any other web development environment I do not need to
redeploy after adding a text box to the page.  It is completely absurd.
Only with JRebel is this alleviated.  No, embedded Jetty in debug mode still
slow.  Even a simple JSP file has hot reloading on Tomcat and if I make a
change to my view code the changes are immediately viewable in the browser
when I refresh.  This is WITHOUT JRebel.

HTTPSession Objects are not hard:  Most pages do not need state.  If you do
use HTTPSession it is simple.  Can you use a map?  Then you can use
HTTPSession.  This is less comlicated than most Wicket code.

Stateful Component based framework are a terrible idea:  Even at the
theoretical level this is a bad idea. It is a leaky abstraction over a
simple request/response cycle.  It made something simple and made it overly
complicated.  This remind me of Hibernate and ORMS.  I disagree that we
should abstract things to this level and do everything in verbose Java.
People are dropping Hibernate and going back to native SQL and Spring JDBC
template.  SQL and the relational model are easy.  Working with HTTP
requests is easy too.  What was wrong with JSPs/Servlets?  Keep it simple
stupid.  We know JSF was too complicated and it was terrible.  Spring MVC is
better and has rest support.  It just works with Spring and has great
support for the JSON Jackson mapper.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4080411.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



RE: Apache Wicket is a Flawed Framework

2011-11-17 Thread Wilhelmsen Tor Iver
Ah, it's been a while since a JSF/JSP zealot bothered to annoy Wicket users. 

Now go away and cook up a tag library or five.

- Tor Iver


Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread Adam Gray
I'm curious why you wasted your time if you have already determined
that Stateful,
component-based frameworks are a terrible idea.  Html5 + jQuery + Restlet
is over -- http://www.restlet.org/

No framework is for everyone or even the best solution for every problem.
 If you have real suggestions for improvements:
https://issues.apache.org/jira/browse/WICKET.  If you're just trolling, I
had a good laugh.

This is not the framework you're looking for.
You can go about your business.
#jedimindtrick


On Thu, Nov 17, 2011 at 11:43 AM, Wilhelmsen Tor Iver toriv...@arrive.nowrote:

 Ah, it's been a while since a JSF/JSP zealot bothered to annoy Wicket
 users.

 Now go away and cook up a tag library or five.

 - Tor Iver



Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread Nelson Segura
I am just a user of Wicket, but this make me laugh, since we are
desperately trying to get out of the JSP nightmare and have found
Wicket a quite nice framework. Nice.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread Gabriel Landon
Is this April fool's day? Seriously?

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4081149.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread Alex Objelean
This is not an april fool's day, it is just an opinion of an 
http://www.linkedin.com/pub/eric-kizaki/30/2b1/1a4 inexperienced developer . 
Eric, if you have troubles in understanding wicket, you are definitely doing
it wrong. Wicket is not a silver bullet, but it is a great tool when
comparing to existing technologies.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4081174.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread thomas willomitzer
Ooohh... I better double check what I'm writing on this list, Since the FBI
is around ... ;)

On Thu, Nov 17, 2011 at 7:56 PM, Alex Objelean alex.objel...@gmail.comwrote:

 This is not an april fool's day, it is just an opinion of an
 http://www.linkedin.com/pub/eric-kizaki/30/2b1/1a4 inexperienced
 developer .
 Eric, if you have troubles in understanding wicket, you are definitely
 doing
 it wrong. Wicket is not a silver bullet, but it is a great tool when
 comparing to existing technologies.

 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4081174.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread geraldkw
This is not an april fool's day, it is just an opinion of an inexperienced
developer. 

This illustrates one of the traditional logical fallacies. If you can't
effectively attack the argument, attack the speaker.

My biggest problem with Wicket is that I haven't found any documentation on
the web that really lets me get a solid grasp on the key concepts. I read a
lot of poorly written documentation, weak examples and forum posts dealing
with something that is only vaguely related to my goals, maybe learn a
fragment of useful info, and then suffer while trying to apply it.

I haven't looked a Wicket in Action or other Wicket Books, but I have not
heard good things. Also, this is the Internet Age and this is web
programming. I have no problem finding documentation on other web
programming languages/frameworks like I do with Wicket. 

If I am wrong, point me to some solid learning materials, and you stand a
chance of changing my mind.

geraldkw


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4081206.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread Richard W. Adams
IMHO, your post looks at the wrong question (i.e., is Wicket perfect?). Of 
course it's not. No framework is.

A better question is: How does it compare to OTHER frameworks? This is 
subjective of course, but in my personal opinion it is far better than any 
other framework I've tried (Struts, JSP, ColdFusion, etc.).  Yes, it has a 
learning curve, but so does any framework.

Where I DO agree with you is that the documentation can be improved. But 
from what I've seen, it's improving as it matures.

RAM /abr./: Rarely Adequate Memory. 



From:   geraldkw geral...@gmail.com
To: users@wicket.apache.org
Date:   11/17/2011 02:54 PM
Subject:Re: Apache Wicket is a Flawed Framework



This is not an april fool's day, it is just an opinion of an 
inexperienced
developer. 

This illustrates one of the traditional logical fallacies. If you can't
effectively attack the argument, attack the speaker.

My biggest problem with Wicket is that I haven't found any documentation 
on
the web that really lets me get a solid grasp on the key concepts. I read 
a
lot of poorly written documentation, weak examples and forum posts 
dealing
with something that is only vaguely related to my goals, maybe learn a
fragment of useful info, and then suffer while trying to apply it.

I haven't looked a Wicket in Action or other Wicket Books, but I have not
heard good things. Also, this is the Internet Age and this is web
programming. I have no problem finding documentation on other web
programming languages/frameworks like I do with Wicket. 

If I am wrong, point me to some solid learning materials, and you stand a
chance of changing my mind.

geraldkw


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4081206.html

Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




**

This email and any attachments may contain information that is confidential 
and/or privileged for the sole use of the intended recipient.  Any use, review, 
disclosure, copying, distribution or reliance by others, and any forwarding of 
this email or its contents, without the express permission of the sender is 
strictly prohibited by law.  If you are not the intended recipient, please 
contact the sender immediately, delete the e-mail and destroy all copies.
**


Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread anant . asty
First ofc all I do not see any need to convince you you can take it or leave 
it. 1 there is an awesome set of examples if you search for wicket examples, 
also there are a lot of other extensions or plug ins in wicket extensions , 
wicket stuff, wi query j query that support all ajax functionality. This forum 
as you noticed is great to get place to get answers. As far as not having as 
extensive of documentation wicket is relatively newer so obviously it will take 
a bit.
--Original Message--
From: geraldkw
To: users@wicket.apache.org
ReplyTo: users@wicket.apache.org
Subject: Re: Apache Wicket is a Flawed Framework
Sent: Nov 17, 2011 12:05 PM

This is not an april fool's day, it is just an opinion of an inexperienced
developer. 

This illustrates one of the traditional logical fallacies. If you can't
effectively attack the argument, attack the speaker.

My biggest problem with Wicket is that I haven't found any documentation on
the web that really lets me get a solid grasp on the key concepts. I read a
lot of poorly written documentation, weak examples and forum posts dealing
with something that is only vaguely related to my goals, maybe learn a
fragment of useful info, and then suffer while trying to apply it.

I haven't looked a Wicket in Action or other Wicket Books, but I have not
heard good things. Also, this is the Internet Age and this is web
programming. I have no problem finding documentation on other web
programming languages/frameworks like I do with Wicket. 

If I am wrong, point me to some solid learning materials, and you stand a
chance of changing my mind.

geraldkw


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4081206.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread Peter Ertl
Nice post, Eric!

Wicket people are a humorous folk and always appreciate good entertainment :-)

Am 17.11.2011 um 22:02 schrieb anant.a...@gmail.com:

 First ofc all I do not see any need to convince you you can take it or leave 
 it. 1 there is an awesome set of examples if you search for wicket examples, 
 also there are a lot of other extensions or plug ins in wicket extensions , 
 wicket stuff, wi query j query that support all ajax functionality. This 
 forum as you noticed is great to get place to get answers. As far as not 
 having as extensive of documentation wicket is relatively newer so obviously 
 it will take a bit.
 --Original Message--
 From: geraldkw
 To: users@wicket.apache.org
 ReplyTo: users@wicket.apache.org
 Subject: Re: Apache Wicket is a Flawed Framework
 Sent: Nov 17, 2011 12:05 PM
 
 This is not an april fool's day, it is just an opinion of an inexperienced
 developer. 
 
 This illustrates one of the traditional logical fallacies. If you can't
 effectively attack the argument, attack the speaker.
 
 My biggest problem with Wicket is that I haven't found any documentation on
 the web that really lets me get a solid grasp on the key concepts. I read a
 lot of poorly written documentation, weak examples and forum posts dealing
 with something that is only vaguely related to my goals, maybe learn a
 fragment of useful info, and then suffer while trying to apply it.
 
 I haven't looked a Wicket in Action or other Wicket Books, but I have not
 heard good things. Also, this is the Internet Age and this is web
 programming. I have no problem finding documentation on other web
 programming languages/frameworks like I do with Wicket. 
 
 If I am wrong, point me to some solid learning materials, and you stand a
 chance of changing my mind.
 
 geraldkw
 
 
 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4081206.html
 Sent from the Users forum mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread Gaetan Zoritchak
I must admit that I agree with you. While I think Wicket is a
great framework, the documentation is not up to par. This tool seems a
little too elitist. If you're strong enough you will find
a great framework. It's a shame because even if the mailing list is very
effective it slows down the adoption of wicket.

2011/11/17 geraldkw geral...@gmail.com

 This is not an april fool's day, it is just an opinion of an inexperienced
 developer. 

 This illustrates one of the traditional logical fallacies. If you can't
 effectively attack the argument, attack the speaker.

 My biggest problem with Wicket is that I haven't found any documentation on
 the web that really lets me get a solid grasp on the key concepts. I read a
 lot of poorly written documentation, weak examples and forum posts
 dealing
 with something that is only vaguely related to my goals, maybe learn a
 fragment of useful info, and then suffer while trying to apply it.

 I haven't looked a Wicket in Action or other Wicket Books, but I have not
 heard good things. Also, this is the Internet Age and this is web
 programming. I have no problem finding documentation on other web
 programming languages/frameworks like I do with Wicket.

 If I am wrong, point me to some solid learning materials, and you stand a
 chance of changing my mind.

 geraldkw


 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4081206.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread Nelson Segura
You might/might not be right about documentation. This is usually true
of most frameworks when you move from the Hello World program to a
real life app.

The original message said little to nothing about documentations. It
is basically comparing Wicket to JSPs, and saying JSP are better. It
might be true for some people. For me, that have been working in JSPs
for a long while, it is very humorous :D

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread Igor Vaynberg
* there are three books written about wicket: two for beginners and
one for intermediate-advanced users.
* there is a searchable mailing list archive that spans years upon
years of users asking questions and getting answers.
* there is a wiki that lists examples and has some good articles.
* there is stack overflow questions and answers.

is there an answer to every single possible question out there? of
course not. no framework has that. look at projects like spring and
hibernate. do those have great documentation? i bet you would say
yes. are their mailing lists any less busy than our own? no. so what
does that say?

if i had to make up a number i would say that armed with the resources
i listed you would be able to answer about 80% of your own questions.
and i think that is a pretty good number. there is a very active user
list to help you answer questions you cant answer yourself, usually
faster then a commercial support contract. for free.

not too shabby.

-igor

On Thu, Nov 17, 2011 at 3:30 PM, Gaetan Zoritchak
g.zoritc...@moncoachfinance.com wrote:
 I must admit that I agree with you. While I think Wicket is a
 great framework, the documentation is not up to par. This tool seems a
 little too elitist. If you're strong enough you will find
 a great framework. It's a shame because even if the mailing list is very
 effective it slows down the adoption of wicket.

 2011/11/17 geraldkw geral...@gmail.com

 This is not an april fool's day, it is just an opinion of an inexperienced
 developer. 

 This illustrates one of the traditional logical fallacies. If you can't
 effectively attack the argument, attack the speaker.

 My biggest problem with Wicket is that I haven't found any documentation on
 the web that really lets me get a solid grasp on the key concepts. I read a
 lot of poorly written documentation, weak examples and forum posts
 dealing
 with something that is only vaguely related to my goals, maybe learn a
 fragment of useful info, and then suffer while trying to apply it.

 I haven't looked a Wicket in Action or other Wicket Books, but I have not
 heard good things. Also, this is the Internet Age and this is web
 programming. I have no problem finding documentation on other web
 programming languages/frameworks like I do with Wicket.

 If I am wrong, point me to some solid learning materials, and you stand a
 chance of changing my mind.

 geraldkw


 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4081206.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread robert.mcguinness
i'm baffled when people say the documentation is poor, the javadocs are
excellent and like igor said there are some great books (blogs too!).  books
and blogs get outdated fast since technlogy is rapidly advancing, so *use
the source luke!*.  Not only will you learn Wicket, but I guarantee your
Java skills will improve.  


awesome examples:



https://github.com/apache/wicket https://github.com/apache/wicket  (scan
over the unit test, best way to learn any framework not just wicket)

https://github.com/55minutes/fiftyfive-wicket
https://github.com/55minutes/fiftyfive-wicket  (fantastic)

https://github.com/42Lines https://github.com/42Lines 

https://github.com/wicketstuff/core https://github.com/wicketstuff/core  (a
gem, tons of examples on how to pretty much do anything)

http://code.google.com/p/wiquery/source/checkout
http://code.google.com/p/wiquery/source/checkout 

https://github.com/jolira/wicket-stateless
https://github.com/jolira/wicket-stateless  (wicket stateless is excellent,
even easier with wicket 1.5)

https://github.com/reaktor/oegyscroll https://github.com/reaktor/oegyscroll 
(endless pagination)

http://code.google.com/p/wiquery/source/browse/core
http://code.google.com/p/wiquery/source/browse/core  (jquery)

http://code.google.com/p/jqwicket/source/browse/
http://code.google.com/p/jqwicket/source/browse/  (jquery, learn from the
code and roll your own if it doesn't fit your needs, super easy

https://github.com/rjnichols/visural-wicket
https://github.com/rjnichols/visural-wicket  (great ui tools)

https://xaloon.googlecode.com/svn/ https://xaloon.googlecode.com/svn/ 
(excellent!)



rob

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082034.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread sthomps
As gerald mentioned address the content - not the speaker, much more
effective.  

i'll address a few of your points and bring up a few of my own.  I'm sure
the others can be addressed with thoughtful/intelligent responses.

*Violates DRY*:  There is a reason that HTML is separated from your
corresponding Java component (not every html snippet has to have a component
btw).  Behavior is not allowed in your HTML and that makes me happy.  I can
have a Human Factors/Web designer do what they do best.  Design a beautiful,
high fidelity prototype that has taken actual user need in mind with plain
ol HTML/JS/CSS.  

I've seen data driven UI's done by backend programmers - not so nice. I know
because I've done them myself.

Not having behavior embedded in your view like a JSP/Facelet means that when
something goes wrong with a page, I have one place to look - in the
corresponding Java component.  No hidden loops tucked away in that page, no
calls to a Java API embedded within a mess of HTML code - clean separation.

*Breaks POJOS*:  The data being stored in your model doesn't have to
implement an interface.  See this response
http://apache-wicket.1842946.n4.nabble.com/confusion-about-Wicket-models-and-serialization-td1933714.html

A couple of things I think Wicket could improve upon is when you *don't*
want back button support and having to worry about PageMaps being stored in
the users session  disk.  As this is a corner case for the most part in the
web app world, I can live with what I have.

In that same vein, having to deal with PageExpiration exceptions when back
button support is not needed and I don't want my users to encounter this
when an Ajax action takes place.  Again this is not the norm and there's a
workaround but it's hacky.

As mentioned no UI framework is perfect.  All have their strengths and
weaknesses and usually those depend on your point of view, coding style,
time of day...

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-is-a-Flawed-Framework-tp4080411p4082041.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread Attila Király
Currently a link to this mail is the most popular on dzone:
http://www.dzone.com/links/apache_wicket_is_a_flawed_framework.html

Attila


Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread Jeroen Steenbeeke
I really liked the comment by javakata on that post. Counters every
argument with a counter-example and doesn't attack the speaker once.

2011/11/18 Attila Király kiralyattila...@gmail.com:
 Currently a link to this mail is the most popular on dzone:
 http://www.dzone.com/links/apache_wicket_is_a_flawed_framework.html

 Attila




-- 
Jeroen Steenbeeke
www.fortuityframework.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Apache Wicket is a Flawed Framework

2011-11-17 Thread nino martinez wael
Sensational news are always a hit, even when not true.

Any tool can be misused. With great power comes great responsibility.

-Nino

2011/11/18 Attila Király kiralyattila...@gmail.com

 Currently a link to this mail is the most popular on dzone:
 http://www.dzone.com/links/apache_wicket_is_a_flawed_framework.html

 Attila