Re: Apache Wicket is a Flawed Framework
@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
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
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
@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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
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
