Re: Comparing JSF and Wicket
On Thu, Aug 7, 2008 at 12:24 PM, nlif [EMAIL PROTECTED] wrote: Peter, Actually, when I said I googled a bit and found some material, I was in fact referring to your blog post and the slides :) This is very useful information, and your comparison was done, IMHO, very fairly and skillfully. However, as I said, this is from 2006, and I figured things may have changed. Obviously, Wicket has matured and improved, but for all I know - so did JSF probably. Are you still up-to-date with JSF nowadays? Would you still hold to the same opinion based on current offering of both frameworks? Thanks, Naaman Naaman, Sorry for replying a little late. Actually the comparison you are referring to was done in mid 2007 not 2006 - so I don't think it is *that* out of date. I still do try to keep track of JSF but not hands-on. With respect to the JSF 1.1 code in the blog-post (which is a very simple example), I am not aware of anything new in JSF 1.2 that would improve any particular aspect. There were a few pro-JSF comments saying that Facelets would address the lack of previewability, and it is true that I stuck to core JSF for the comparison. Facelets and today Spring WebFlow appear to offer some respite from what many see as significant limitations in the spec - but if you choose to go down that path, one of the main arguments for using JSF does not hold good anymore. Which is of course, the tired old argument that JSF is a standard. So if you look beyond the core spec - you now have a big choice to make, for instance do you want to go the Sun / Facelets way, the JBoss Seam way, the Spring way or the high-way. This is what JSF advocates cunningly refer to as an ecosystem. As an example of where the current version of the spec has limitations - JSF 1.X was obviously drafted in an age where Ajax was unheard of. The pro-JSF arguments with respect to Ajax are that JSF is designed for extension and you just have to hook into the life-cycle phases etc. To me this honestly sounds more like a workaround, and there are comments on the above mentioned blog post that speak of javascript library collisions when you mix components from multiple JSF vendors. Let me just say that in over one and half years of developing (at least three different applications) with Wicket, I am yet to see a situation where the stuff I want to do in Ajax is restricted in any way by the framework design or anything like that. Seriously. Coming to JSF 2.0 it is anybody's guess as to when that community process (read: design-by-committee) will get over and when usable implementations will start appearing. Life is too short and I prefer being intensely productive rather than waiting for a promised spec and enduring the pain and sleepless nights while the ecosystem stabilizes. Generally specifications like JSF gravitate towards a least common denominator approach. I'm not saying that there is no place for standards, but especially when building user interfaces, you will agree that every client is different and demands a different approach. One thing that even JSF advocates will admit is that it is hard to create custom components. So if you hit a wall and find that an existing JSF component needs to be tweaked for your project, you are at the mercy of the component vendor or you have to customize the component yourself. JSF makes an IMHO flawed assumption that the committee has done the Big Design Up Front to cover all use cases and context variations. Case in point: just take this example of a simple autocomplete component [1]. Look at all the possible attributes that this component supports. To me, this smells strongly of YAGNI [2]. Thanks, Peter. [1] https://blueprints.dev.java.net/complib/v2/auto-complete.html [2] http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It ptrthomas wrote: Hi, Here is a list of bullet points I compiled on JSF when compared with Wicket: – Not really OO components, more of XML tags than Java – Added complexity of JSF-EL and mixing JSP-EL if applicable – faces-config.xml : synchronize multiple files for navigation, page-centric, string expressions not type-safe – Poor separation of concerns / preview-ability (in core JSF spec) – General consensus that for practical use you have to supplement with non-standard extensions -e.g. Facelets, Spring WebFlow etc. – Hard to unit test – Hard to debug / step-through – More dependence on tooling / IDE support – Mixing components from multiple vendors problematic especially with AJAX – Generated HTML is typically verbose – Creating custom components is much harder – Slow evolution as it is a specification, now JSF 2.0 is being discussed… I had this as a back-up slide in a presentation recently (which I ended up having to use because of all the questions :) You can find the presentation here if you are interested, it is more to do with comparing Wicket with action / JSP based frameworks, but may help:
Re: Comparing JSF and Wicket
Oh my God. You started off so nicely, I was caught completely unprepared for the blow :) Let's get a few things straight, then: I have used Wicket in a couple of small projects in the past, and really really liked it. I read the excellent and highly recommended Wicket in Action (I bought it via the MEAP program). I read it cover to cover. I am familiar with Wicket extensions, Wicket-stuff, and Wicket to Spring integration. In fact, had you done what you advocate I should do - which is to take a few minutes and read my posts in this thread - you would have noticed that my point was that I am not familiar with JSF, and was looking for people who have used both and can give me their feedback. Furthermore, you would have learned that I was in fact trying (very hard, I might add) to convince my current management to use Wicket and not JSF as the framework for the next generation of our product (which is, I will risk an estimate, somewhat more than 8 hours of work. More likely a year or two for a team of 3-4 people). I was only trying to gather arguments to support using Wicket in favor of JSF, while making a minimal effort to be objective. I think that as a technologist, and unlike some religious evangelist, I need to at least try to support my opinions with empirical data, instead of just dismissing JSF because it is the work of Satan :) Now, will you please try to calm down, and have a nice day :) Naaman Al Maw wrote: 2008/8/7 nlif [EMAIL PROTECTED]: While it is very good to know that it's relatively easy to develop Wicket components, bear in mind that management (at least mine) is more easily convinced when presented with a wide selection of 3rd party component libraries, since that provides an alternative to allocating time and resources of our own developers. Thus, for them, the issue is decided more an economical merits, then on its design/architectural ones. Your company should concentrate on what it does as its core competency as that will bring you the most value for time invested. Based on past experience with many companies, I can most glibly and universally sum this up as: Don't write a ticketing system unless you sell ticketing systems. You are presumably building web apps because you think you're quite good at it (or perhaps will be), and you're worried about working at the right level of abstraction to achieve good productivity. You're concerned that Wicket might be at too low a level of abstraction compared to JSF, because JSF has a plentiful array of off-the-shelf components that you think will let you work at a higher level of abstraction, and therefore you'll be more productive with it. It's a nice idea. It certainly looks tempting. Unfortunately, it just isn't the case. Why is that? Go and read Joel Spolsky's article on leaky abstractions[1]. Right now: http://www.joelonsoftware.com/articles/LeakyAbstractions.html Good to have you back. Here are just a few reasons why pre-built components in JSF are not the answer. At some point, normally just after you've completely wedded yourself to a component, someone important will want you to change something that on the surface should be trivial. At this point, you will need to unpick the entire component and figure out how it works, and change it. This will be hard. You will probably introduce bugs. Unless it's a component with a lot of distinct regions of complexity, it will probably be so hard that you may as well have developed the code yourself from scratch (in either JSF or Wicket). Reading code is harder than writing it. Anything remotely complex will need to you restyle it all to make it fit in with the rest of your web pages. This will likely be painful unless the component developer has a clue. Nine times out of ten, it will take you so long to find the component you need, test it works in your environment, make sure it does what you need, make sure it probably does what you might need, discover it doesn't, find another component that does, sort out the licensing, file a purchase order for it, etc. etc. that you could have developed something in Wicket that did exactly what you wanted in half the time. It seems to be the case that if the component is sufficiently complex that you think you will save time/money by buying it in rather than building it, it doesn't do what you want. There are only about five or six truly universal components that are applicable to almost everyone. These are: tree, tree but in a table, sortable paginated data-driven list, date picker, modal pop-up window, AJAX auto-complete drop-down. I can't think of any others, but there might be a couple. Wicket has all of these. Which you'd know if you'd bothered to look at the examples, which are live and prominently linked from the site. Sorry to sound harsh, but how much web development are you going to do? Hmmm? Eight hours' worth? Go use PHP or JSP or DHTML or
Re: Comparing JSF and Wicket
I was only trying to gather arguments to support using Wicket in favor of JSF, while making a minimal effort to be objective. I think that as a technologist, and unlike some religious evangelist, I need to at least try to support my opinions with empirical data, instead of just dismissing JSF because it is the work of Satan :) Haha... yep, that's a good idea. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
Thanks Scott. Nice experiment. In my experience, not many organizations would be willing to commit resources for such a research. But the result is hard to dismiss: after all, when everything is said and done, the most important factor in most companies is - how fast can you deliver this? Still, I'd like to ask - can you point to any advantage JSF has over Wicket? Anything at all? Scott Swank wrote: My company compared several frameworks and settled on either JSF or Wicket. We then had a 2 week development effort implementing the same proof-of-concept app with 2 teams of 4 devs each. Everyone was at least somewhat familiar with JSF, while only one person in our department had ever worked with Wicket. After 1 week the Wicket team was done, while the JSF team was struggling over whether to use facelets or jsp for rendering, which rendering implementation to use, which ajax library to use (and how that required re-deciding some of the previous items). Now many of those problems that plagued the JSF team are one-time decisions that are not indicative of day-to-day development. That said, every developer who worked with Wicket ended up advocating for it as our web framework, even though most of them had initially preferred JSF. In fact, after seeing the Wicket JSF code side-by-side most of the devs on the JSF team voted for Wicket, as did the rest of the department. In the previously recommended article http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/ go down to [The List Forums Screen] and compare the JSF tags with the Wicket html. We can hire presentation-layer developers who only need to know html css. Also, go into a working Wicket page and screw up something (misspell a wicket:id, whatever). Now examine the exception you get. It will likely describe in rather clear terms what is wrong. Now try this with JSF. Now take your problem and post it to the Wicket forum (perhaps with a different e-mail address) and ask for help. Now try that with JSF. Scott On Wed, Aug 6, 2008 at 11:30 AM, Peter Thomas [EMAIL PROTECTED] wrote: Hi, Here is a list of bullet points I compiled on JSF when compared with Wicket: – Not really OO components, more of XML tags than Java – Added complexity of JSF-EL and mixing JSP-EL if applicable – faces-config.xml : synchronize multiple files for navigation, page-centric, string expressions not type-safe – Poor separation of concerns / preview-ability (in core JSF spec) – General consensus that for practical use you have to supplement with non-standard extensions -e.g. Facelets, Spring WebFlow etc. – Hard to unit test – Hard to debug / step-through – More dependence on tooling / IDE support – Mixing components from multiple vendors problematic especially with AJAX – Generated HTML is typically verbose – Creating custom components is much harder – Slow evolution as it is a specification, now JSF 2.0 is being discussed… I had this as a back-up slide in a presentation recently (which I ended up having to use because of all the questions :) You can find the presentation here if you are interested, it is more to do with comparing Wicket with action / JSP based frameworks, but may help: http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/ Thanks, Peter. On Wed, Aug 6, 2008 at 11:44 PM, Igor Vaynberg [EMAIL PROTECTED]wrote: On Wed, Aug 6, 2008 at 2:13 AM, nlif [EMAIL PROTECTED] wrote: Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. actually, imho, this is one of wicket's biggest advantages over jsf. jsf is a standard so it moves very slowly. wicket is a much more agile project and moves much faster. Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). actually i find myself creating components all the time, because it is so damn easy. trivial and non trivial, because wicket uses composition it is not that much harder to create components with complex interactions. sure, jsf has plenty of components out there that offer high level things like data grids, etc, but so does wicket. the difference with wicket is this: the other day i created a productlink component for our application. it is a simple component that builds an anchor that takes the user to the product page. it also adds proper css class based on whether the product is for sale or not and whether it is in or out of stock. so now anytime someone needs to link to a product they simply do add(new ProductLink(link, product)); and attach it to wicket:id=linkwhatever . the productlink can be embedded
Re: Comparing JSF and Wicket
Peter, Actually, when I said I googled a bit and found some material, I was in fact referring to your blog post and the slides :) This is very useful information, and your comparison was done, IMHO, very fairly and skillfully. However, as I said, this is from 2006, and I figured things may have changed. Obviously, Wicket has matured and improved, but for all I know - so did JSF probably. Are you still up-to-date with JSF nowadays? Would you still hold to the same opinion based on current offering of both frameworks? Thanks, Naaman ptrthomas wrote: Hi, Here is a list of bullet points I compiled on JSF when compared with Wicket: – Not really OO components, more of XML tags than Java – Added complexity of JSF-EL and mixing JSP-EL if applicable – faces-config.xml : synchronize multiple files for navigation, page-centric, string expressions not type-safe – Poor separation of concerns / preview-ability (in core JSF spec) – General consensus that for practical use you have to supplement with non-standard extensions -e.g. Facelets, Spring WebFlow etc. – Hard to unit test – Hard to debug / step-through – More dependence on tooling / IDE support – Mixing components from multiple vendors problematic especially with AJAX – Generated HTML is typically verbose – Creating custom components is much harder – Slow evolution as it is a specification, now JSF 2.0 is being discussed… I had this as a back-up slide in a presentation recently (which I ended up having to use because of all the questions :) You can find the presentation here if you are interested, it is more to do with comparing Wicket with action / JSP based frameworks, but may help: http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/ Thanks, Peter. On Wed, Aug 6, 2008 at 11:44 PM, Igor Vaynberg [EMAIL PROTECTED]wrote: On Wed, Aug 6, 2008 at 2:13 AM, nlif [EMAIL PROTECTED] wrote: Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. actually, imho, this is one of wicket's biggest advantages over jsf. jsf is a standard so it moves very slowly. wicket is a much more agile project and moves much faster. Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). actually i find myself creating components all the time, because it is so damn easy. trivial and non trivial, because wicket uses composition it is not that much harder to create components with complex interactions. sure, jsf has plenty of components out there that offer high level things like data grids, etc, but so does wicket. the difference with wicket is this: the other day i created a productlink component for our application. it is a simple component that builds an anchor that takes the user to the product page. it also adds proper css class based on whether the product is for sale or not and whether it is in or out of stock. so now anytime someone needs to link to a product they simply do add(new ProductLink(link, product)); and attach it to wicket:id=linkwhatever . the productlink can be embedded inside any other component just as easily and have any other component embedded in it as well. i dont think jsf folks would bother creating anything so fine-grained, because although it is very useful there would be too much overhead and pain involved. the problem is that jsf approaches web application development with a few roles in mind: the application developer and the component developer. the component developer is a smarter person that understands the intricacies of jsf. in wicket we do not assume the separation of roles, so our programming model is consistent and is optimized towards component creation. my two cents -igor Many thanks in advance. -- View this message in context: http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18847208.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18865081.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
Thanks Igor, While it is very good to know that it's relatively easy to develop Wicket components, bear in mind that management (at least mine) is more easily convinced when presented with a wide selection of 3rd party component libraries, since that provides an alternative to allocating time and resources of our own developers. Thus, for them, the issue is decided more an economical merits, then on its design/architectural ones. This is a classic advantage a standard solution usually offers - a thriving ecosystem. (than again, I've got to admit, I don't really know that much about JSF's ecosystem...). How many Wicket components are there, and how mature are there? Are there tables with sorting, filtering, scrolling, paging etc.? Are there tree-controls with all the typical tree-functions? Is there Ajax support, as well automatic fallback for non-javascript browsers (and what about comet)? Thanks again, Naaman igor.vaynberg wrote: On Wed, Aug 6, 2008 at 2:13 AM, nlif [EMAIL PROTECTED] wrote: Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. actually, imho, this is one of wicket's biggest advantages over jsf. jsf is a standard so it moves very slowly. wicket is a much more agile project and moves much faster. Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). actually i find myself creating components all the time, because it is so damn easy. trivial and non trivial, because wicket uses composition it is not that much harder to create components with complex interactions. sure, jsf has plenty of components out there that offer high level things like data grids, etc, but so does wicket. the difference with wicket is this: the other day i created a productlink component for our application. it is a simple component that builds an anchor that takes the user to the product page. it also adds proper css class based on whether the product is for sale or not and whether it is in or out of stock. so now anytime someone needs to link to a product they simply do add(new ProductLink(link, product)); and attach it to whatever . the productlink can be embedded inside any other component just as easily and have any other component embedded in it as well. i dont think jsf folks would bother creating anything so fine-grained, because although it is very useful there would be too much overhead and pain involved. the problem is that jsf approaches web application development with a few roles in mind: the application developer and the component developer. the component developer is a smarter person that understands the intricacies of jsf. in wicket we do not assume the separation of roles, so our programming model is consistent and is optimized towards component creation. my two cents -igor Many thanks in advance. -- View this message in context: http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18847208.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18865282.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
Actually, when I said I googled a bit and found some material, I was in fact referring to your blog post and the slides :) This is very useful information, and your comparison was done, IMHO, very fairly and skillfully. However, as I said, this is from 2006, and I figured things may have changed. Obviously, Wicket has matured and improved, but for all I know - so did JSF probably. Are you still up-to-date with JSF nowadays? Would you still hold to the same opinion based on current offering of both frameworks? If you really want to find out, nothing beats looking at it yourself. Those articles could provide you with a framework, and you just have to check whether the arguments hold today and whether you agree in the first place. Or take a few evenings/ weekend and set up a little hobby project yourself to see how the two frameworks 'feel' when you work with them. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
While it is very good to know that it's relatively easy to develop Wicket components, bear in mind that management (at least mine) is more easily convinced when presented with a wide selection of 3rd party component libraries, since that provides an alternative to allocating time and resources of our own developers. Thus, for them, the issue is decided more an economical merits, then on its design/architectural ones. Always look at the facts, never just go on a hunch. What may sound like common sense, especially from a managerial point of view, not always is that sensible. In this case, while having a whole bunch of standard components might sound good and sell well, you have to wonder how much time it actually saves you. Very often you'll have to customize components to exactly fit your needs. How hard is that, and is it possible at all is something you need to look at. The fact that component lib X has a datagrid component doesn't mean it fits your needs. It might be inflexible or - when it is flexible - hard to use because the API is big and clumsy. The great thing about custom components is that extending a base component often is just as easy or even easier than having to figure out an of the shelf component that does it all but needs to be configured for a specific use case. Also, because you'll make it fit to your needs without having to do lots of configuration, you'll likely avoid a lot of code duplication, and it might be easier to optimize for specific cases because you can access internals more easily. This is a classic advantage a standard solution usually offers - a thriving ecosystem. (than again, I've got to admit, I don't really know that much about JSF's ecosystem...). And again, look at the facts. If you look past the marketing slogans en count the available high quality components for the two frameworks, I honestly don't think the difference is that huge. I actually expect Wicket's community to do a bit better. And we don't need as many components because extending a baseclass is very often a more efficient way of customizing than designing complex components upfront and guiding them through configuration. How many Wicket components are there, and how mature are there? Are there tables with sorting, filtering, scrolling, paging etc.? Are there tree-controls with all the typical tree-functions? Is there Ajax support, as well automatic fallback for non-javascript browsers (and what about comet)? You'll have to do your homework here. It's simple, just check out the Wicket core projects, and a bunch of wicket-stuff projects in your IDE of choice, and look for an inheritance view (F4 in Eclipse) of the Component class and see what components there are. We can't really give meaningful numbers imho, because many components gradually go from covering just base functionality to supporting very specific functions (like TreeTable or tables with sorters and filter fields). You should also consider doing the same thing for the IBehavior interface, because often you can add behavior to a component through behaviors. Final remark... it seems that many people are always looking for 'winners' and 'losers'. Why don't you just take the projects you're thinking off, see what you really need and match that with the frameworks you're evaluating, and try to get a hunch of what it would be like to actually do these projects with the frameworks so that you can decide whether it would fit your needs? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
On Thu, Aug 7, 2008 at 12:12 AM, nlif [EMAIL PROTECTED] wrote: Thanks Igor, While it is very good to know that it's relatively easy to develop Wicket components, bear in mind that management (at least mine) is more easily convinced when presented with a wide selection of 3rd party component libraries, since that provides an alternative to allocating time and resources of our own developers. Thus, for them, the issue is decided more an economical merits, then on its design/architectural ones. well, if we are talking in purely managerial/economical terms then i would definately go with jsf. a) it is always easy to find very high-paid consultants to rescue a project that is running late or is totally broken, lots of companies out there offer jsf consulting services b) it is much easier to find someone to replace you when you screw up, there are many more job postings for jsf then for wicket c) it is much easier to find someone to replace you when you ask for a raise, see above This is a classic advantage a standard solution usually offers - a thriving ecosystem. (than again, I've got to admit, I don't really know that much about JSF's ecosystem...). i havent seen an ecosystem yet, but maybe im not looking very hard. How many Wicket components are there, and how mature are there? Are there tables with sorting, filtering, scrolling, paging etc.? Are there tree-controls with all the typical tree-functions? Is there Ajax support, as well automatic fallback for non-javascript browsers (and what about comet)? if you cannot find this on your own then i dont think you will enjoy wicket at all. wicket is not about serving up everything on a silver platter. the answers to these questions are only a short trip away from looking at wicket-examples. -igor Thanks again, Naaman igor.vaynberg wrote: On Wed, Aug 6, 2008 at 2:13 AM, nlif [EMAIL PROTECTED] wrote: Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. actually, imho, this is one of wicket's biggest advantages over jsf. jsf is a standard so it moves very slowly. wicket is a much more agile project and moves much faster. Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). actually i find myself creating components all the time, because it is so damn easy. trivial and non trivial, because wicket uses composition it is not that much harder to create components with complex interactions. sure, jsf has plenty of components out there that offer high level things like data grids, etc, but so does wicket. the difference with wicket is this: the other day i created a productlink component for our application. it is a simple component that builds an anchor that takes the user to the product page. it also adds proper css class based on whether the product is for sale or not and whether it is in or out of stock. so now anytime someone needs to link to a product they simply do add(new ProductLink(link, product)); and attach it to whatever . the productlink can be embedded inside any other component just as easily and have any other component embedded in it as well. i dont think jsf folks would bother creating anything so fine-grained, because although it is very useful there would be too much overhead and pain involved. the problem is that jsf approaches web application development with a few roles in mind: the application developer and the component developer. the component developer is a smarter person that understands the intricacies of jsf. in wicket we do not assume the separation of roles, so our programming model is consistent and is optimized towards component creation. my two cents -igor Many thanks in advance. -- View this message in context: http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18847208.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18865282.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail:
Re: Comparing JSF and Wicket
Sorry, not really. *) JSF doesn't consume less Memory over Wicket. But this is not really an Argument since Hardware isn't that expensive today. *) Maybe the availability of Millions of extension Libraries for JSF. *) EL Tags are quite useful, but IMHO just another way to do the same thing. Regards, Timm Am Donnerstag, 7. August 2008 08:44:22 schrieb nlif: Thanks Timm. This is valuable feedback. Nevertheless - can you point to any advantage JSF has over Wicket? Anything at all? Thanks Timm Helbig wrote: Hi, I did one Project with JSF and two with Wicket. By far Wicket is much easier to handle, (nearly) everything works as supposed, which is not true for JSF, especially when it comes to external Libraries like Trinidad or other UI Extension Libraries. One other thing which is important for me is the Productivity. And this is much higher with Wicket than with JSF. The Community support is suberb with Wicket, and somewhat difficult when you check the JSF Forums, but this depends on the Manufactor of the Library you use. I don't want to slash JSF here, but I find it is miles away from a usable Product. For me it looks more like a prototype of what could be possible. Just check what happened from 1.1 to 1.2, and you see, that even Sun seemed to face this. Regards, Timm Am Mittwoch, 6. August 2008 11:13:53 schrieb nlif: Hi all, We are in the process of selecting a web-framework, and although I am in favor of Wicket, I was asked to provide an objective comparison of Wicket with JSF. I have developed a few small apps in Wicket, but I admit I am not very familiar with JSF. Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. Although this is the Wicket forum, I expect there are people here who also used (or at least evaluated) JSF at some point, so I'd be happy if folks here could share their experience. If anyone can point me to useful links that would be great too. I really am not trying to provoke a flame war, just to gather information. In your opinion, what are Wicket strengths? What are JSF's ? (even if you're a Wicket fan, surely there's something ;) I would be interested to hear people thoughts regarding the fact the JSF is a standard, while Wicket is not. How important is that to you? In what ways do you think this matters (if at all)? Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). Many thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
I don't need nearly as much extensions for wicket because it's such a no-brainer to write my own custom components... I think JSF is a big joke with nobody laughing :) my 2 % Cheers Peter Am 07.08.2008 um 17:59 schrieb Timm Helbig: Sorry, not really. *) JSF doesn't consume less Memory over Wicket. But this is not really an Argument since Hardware isn't that expensive today. *) Maybe the availability of Millions of extension Libraries for JSF. *) EL Tags are quite useful, but IMHO just another way to do the same thing. Regards, Timm Am Donnerstag, 7. August 2008 08:44:22 schrieb nlif: Thanks Timm. This is valuable feedback. Nevertheless - can you point to any advantage JSF has over Wicket? Anything at all? Thanks Timm Helbig wrote: Hi, I did one Project with JSF and two with Wicket. By far Wicket is much easier to handle, (nearly) everything works as supposed, which is not true for JSF, especially when it comes to external Libraries like Trinidad or other UI Extension Libraries. One other thing which is important for me is the Productivity. And this is much higher with Wicket than with JSF. The Community support is suberb with Wicket, and somewhat difficult when you check the JSF Forums, but this depends on the Manufactor of the Library you use. I don't want to slash JSF here, but I find it is miles away from a usable Product. For me it looks more like a prototype of what could be possible. Just check what happened from 1.1 to 1.2, and you see, that even Sun seemed to face this. Regards, Timm Am Mittwoch, 6. August 2008 11:13:53 schrieb nlif: Hi all, We are in the process of selecting a web-framework, and although I am in favor of Wicket, I was asked to provide an objective comparison of Wicket with JSF. I have developed a few small apps in Wicket, but I admit I am not very familiar with JSF. Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. Although this is the Wicket forum, I expect there are people here who also used (or at least evaluated) JSF at some point, so I'd be happy if folks here could share their experience. If anyone can point me to useful links that would be great too. I really am not trying to provoke a flame war, just to gather information. In your opinion, what are Wicket strengths? What are JSF's ? (even if you're a Wicket fan, surely there's something ;) I would be interested to hear people thoughts regarding the fact the JSF is a standard, while Wicket is not. How important is that to you? In what ways do you think this matters (if at all)? Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). Many thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
If you can find JSF components that do exactly what you want then JSF
is more compact. If, however, you find JSF components that do nearly
what you want, but you have to add a bit of functionality, well then
you're into the lovely world of phase listeners and the
request/response life cycle. Dante located JSF phase listeners within
the 4th circle of hell if I remember correctly.
One of the first ah ha moments I had with Wicket was when I needed
to copy customer names from one field to another. If a customer
purchases several items (tickets to shows, books a tour, reserves a
hotel room) then the guest name associated with one item is typically,
but not always, the guest name for all of the items. With a nominal
amount of reasonably clear code I was able to create a behavior that I
simply attach to all of the first names and last names. It copies the
value of one field to all of the matching fields that are empty and
updates all of these fields via ajax. It's 22 lines if you don't
count whitespace braces and it is completely reusable. It can be
attached to any two or more form components and it just works.
public class ModelPropagationBehavior extends AjaxFormComponentUpdatingBehavior
{
private static final long serialVersionUID = -451063727688504933L;
public enum PREBUILT
{
FIRST_NAME, LAST_NAME;
public ModelPropagationBehavior getBehavior()
{
return new ModelPropagationBehavior(name());
}
}
private final String name;
public ModelPropagationBehavior(String n)
{
super(onblur);
this.name = n;
}
private String getName()
{
return name;
}
private boolean hasMatchingBehavior(Component component)
{
for (Object behavior : component.getBehaviors())
{
if (behavior instanceof ModelPropagationBehavior
((ModelPropagationBehavior)
behavior).getName().equals(this.name))
return true;
}
return false;
}
@Override
protected void onUpdate(final AjaxRequestTarget target)
{
final FormComponent thisComponent = getFormComponent();
thisComponent.getForm().visitChildren(new IVisitor()
{
public Object component(Component otherComponent)
{
if (otherComponent.equals(thisComponent))
return
CONTINUE_TRAVERSAL_BUT_DONT_GO_DEEPER;
if (hasMatchingBehavior(otherComponent)
otherComponent.getModelObjectAsString().isEmpty())
{
otherComponent.setModelObject(thisComponent.getModelObject());
target.addComponent(otherComponent);
return
CONTINUE_TRAVERSAL_BUT_DONT_GO_DEEPER;
}
return CONTINUE_TRAVERSAL;
}
});
}
}
On Wed, Aug 6, 2008 at 11:44 PM, nlif [EMAIL PROTECTED] wrote:
Thanks Timm. This is valuable feedback. Nevertheless - can you point to any
advantage JSF has over Wicket? Anything at all?
Thanks
Timm Helbig wrote:
Hi,
I did one Project with JSF and two with Wicket.
By far Wicket is much easier to handle, (nearly) everything works as
supposed,
which is not true for JSF, especially when it comes to external Libraries
like Trinidad or other UI Extension Libraries.
One other thing which is important for me is the Productivity. And this
is
much higher with Wicket than with JSF.
The Community support is suberb with Wicket, and somewhat difficult when
you
check the JSF Forums, but this depends on the Manufactor of the Library
you
use.
I don't want to slash JSF here, but I find it is miles away from a usable
Product. For me it looks more like a prototype of what could be possible.
Just check what happened from 1.1 to 1.2, and you see, that even Sun
seemed
to face this.
Regards,
Timm
Am Mittwoch, 6. August 2008 11:13:53 schrieb nlif:
Hi all,
We are in the process of selecting a web-framework, and although I am in
favor of Wicket, I was asked to provide an objective comparison of Wicket
with JSF. I have developed a few small apps in Wicket, but I admit I am
not
very familiar with JSF. Prior to posting here, I googled a bit, and found
a
few forum-threads and blog posts on this topic, but most are from 1-2
years
ago and in framework years, this may be considered obsolete.
Although this is the Wicket forum, I expect there are people here who
Re: Comparing JSF and Wicket
LOL! Great saying! I was asked for something positive.. Regards, Timm Am Donnerstag, 7. August 2008 18:09:03 schrieb Peter Ertl: I don't need nearly as much extensions for wicket because it's such a no-brainer to write my own custom components... I think JSF is a big joke with nobody laughing :) my 2 % Cheers Peter Am 07.08.2008 um 17:59 schrieb Timm Helbig: Sorry, not really. *) JSF doesn't consume less Memory over Wicket. But this is not really an Argument since Hardware isn't that expensive today. *) Maybe the availability of Millions of extension Libraries for JSF. *) EL Tags are quite useful, but IMHO just another way to do the same thing. Regards, Timm Am Donnerstag, 7. August 2008 08:44:22 schrieb nlif: Thanks Timm. This is valuable feedback. Nevertheless - can you point to any advantage JSF has over Wicket? Anything at all? Thanks Timm Helbig wrote: Hi, I did one Project with JSF and two with Wicket. By far Wicket is much easier to handle, (nearly) everything works as supposed, which is not true for JSF, especially when it comes to external Libraries like Trinidad or other UI Extension Libraries. One other thing which is important for me is the Productivity. And this is much higher with Wicket than with JSF. The Community support is suberb with Wicket, and somewhat difficult when you check the JSF Forums, but this depends on the Manufactor of the Library you use. I don't want to slash JSF here, but I find it is miles away from a usable Product. For me it looks more like a prototype of what could be possible. Just check what happened from 1.1 to 1.2, and you see, that even Sun seemed to face this. Regards, Timm Am Mittwoch, 6. August 2008 11:13:53 schrieb nlif: Hi all, We are in the process of selecting a web-framework, and although I am in favor of Wicket, I was asked to provide an objective comparison of Wicket with JSF. I have developed a few small apps in Wicket, but I admit I am not very familiar with JSF. Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. Although this is the Wicket forum, I expect there are people here who also used (or at least evaluated) JSF at some point, so I'd be happy if folks here could share their experience. If anyone can point me to useful links that would be great too. I really am not trying to provoke a flame war, just to gather information. In your opinion, what are Wicket strengths? What are JSF's ? (even if you're a Wicket fan, surely there's something ;) I would be interested to hear people thoughts regarding the fact the JSF is a standard, while Wicket is not. How important is that to you? In what ways do you think this matters (if at all)? Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). Many thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
2008/8/7 nlif [EMAIL PROTECTED]: While it is very good to know that it's relatively easy to develop Wicket components, bear in mind that management (at least mine) is more easily convinced when presented with a wide selection of 3rd party component libraries, since that provides an alternative to allocating time and resources of our own developers. Thus, for them, the issue is decided more an economical merits, then on its design/architectural ones. Your company should concentrate on what it does as its core competency as that will bring you the most value for time invested. Based on past experience with many companies, I can most glibly and universally sum this up as: Don't write a ticketing system unless you sell ticketing systems. You are presumably building web apps because you think you're quite good at it (or perhaps will be), and you're worried about working at the right level of abstraction to achieve good productivity. You're concerned that Wicket might be at too low a level of abstraction compared to JSF, because JSF has a plentiful array of off-the-shelf components that you think will let you work at a higher level of abstraction, and therefore you'll be more productive with it. It's a nice idea. It certainly looks tempting. Unfortunately, it just isn't the case. Why is that? Go and read Joel Spolsky's article on leaky abstractions[1]. Right now: http://www.joelonsoftware.com/articles/LeakyAbstractions.html Good to have you back. Here are just a few reasons why pre-built components in JSF are not the answer. At some point, normally just after you've completely wedded yourself to a component, someone important will want you to change something that on the surface should be trivial. At this point, you will need to unpick the entire component and figure out how it works, and change it. This will be hard. You will probably introduce bugs. Unless it's a component with a lot of distinct regions of complexity, it will probably be so hard that you may as well have developed the code yourself from scratch (in either JSF or Wicket). Reading code is harder than writing it. Anything remotely complex will need to you restyle it all to make it fit in with the rest of your web pages. This will likely be painful unless the component developer has a clue. Nine times out of ten, it will take you so long to find the component you need, test it works in your environment, make sure it does what you need, make sure it probably does what you might need, discover it doesn't, find another component that does, sort out the licensing, file a purchase order for it, etc. etc. that you could have developed something in Wicket that did exactly what you wanted in half the time. It seems to be the case that if the component is sufficiently complex that you think you will save time/money by buying it in rather than building it, it doesn't do what you want. There are only about five or six truly universal components that are applicable to almost everyone. These are: tree, tree but in a table, sortable paginated data-driven list, date picker, modal pop-up window, AJAX auto-complete drop-down. I can't think of any others, but there might be a couple. Wicket has all of these. Which you'd know if you'd bothered to look at the examples, which are live and prominently linked from the site. Sorry to sound harsh, but how much web development are you going to do? Hmmm? Eight hours' worth? Go use PHP or JSP or DHTML or whatever. Your use case isn't complex enough to be having this discussion. Eight months' worth? What? You're going to make a decision without investing a day in each option at least? Are you crazy? How many Wicket components are there, and how mature are there? Are there tables with sorting, filtering, scrolling, paging etc.? Are there tree-controls with all the typical tree-functions? Is there Ajax support, as well automatic fallback for non-javascript browsers (and what about comet)? Come back here when you have real questions that you can't answer for yourself in ten minutes. http://www.justfuckinggoogleit.com/search.pl?query=wicket+tree http://www.justfuckinggoogleit.com/search.pl?query=wicket+ajax http://londonwicket.org/content/LondonWicket-ListEditor.pdf etc. etc. etc. Alastair - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
Hello, maybe you read this already: http://www.nabble.com/Questions-about-GWT%2C-JSF-and-Wicket-to12875910.html#a12875910 http://www.nabble.com/JSF%3A-standards-versus-OSS-to13400509.html#a13400509 greetings nlif wrote: Hi all, We are in the process of selecting a web-framework, and although I am in favor of Wicket, I was asked to provide an objective comparison of Wicket with JSF. I have developed a few small apps in Wicket, but I admit I am not very familiar with JSF. Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. Although this is the Wicket forum, I expect there are people here who also used (or at least evaluated) JSF at some point, so I'd be happy if folks here could share their experience. If anyone can point me to useful links that would be great too. I really am not trying to provoke a flame war, just to gather information. In your opinion, what are Wicket strengths? What are JSF's ? (even if you're a Wicket fan, surely there's something ;) I would be interested to hear people thoughts regarding the fact the JSF is a standard, while Wicket is not. How important is that to you? In what ways do you think this matters (if at all)? Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). Many thanks in advance. -- View this message in context: http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18847535.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
here is a comparison http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/ - Brill On 6-Aug-08, at 5:36 AM, greeklinux wrote: Hello, maybe you read this already: http://www.nabble.com/Questions-about-GWT%2C-JSF-and-Wicket-to12875910.html#a12875910 http://www.nabble.com/JSF%3A-standards-versus-OSS-to13400509.html#a13400509 greetings nlif wrote: Hi all, We are in the process of selecting a web-framework, and although I am in favor of Wicket, I was asked to provide an objective comparison of Wicket with JSF. I have developed a few small apps in Wicket, but I admit I am not very familiar with JSF. Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. Although this is the Wicket forum, I expect there are people here who also used (or at least evaluated) JSF at some point, so I'd be happy if folks here could share their experience. If anyone can point me to useful links that would be great too. I really am not trying to provoke a flame war, just to gather information. In your opinion, what are Wicket strengths? What are JSF's ? (even if you're a Wicket fan, surely there's something ;) I would be interested to hear people thoughts regarding the fact the JSF is a standard, while Wicket is not. How important is that to you? In what ways do you think this matters (if at all)? Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). Many thanks in advance. -- View this message in context: http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18847535.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
On Wed, Aug 6, 2008 at 2:13 AM, nlif [EMAIL PROTECTED] wrote: Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. actually, imho, this is one of wicket's biggest advantages over jsf. jsf is a standard so it moves very slowly. wicket is a much more agile project and moves much faster. Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). actually i find myself creating components all the time, because it is so damn easy. trivial and non trivial, because wicket uses composition it is not that much harder to create components with complex interactions. sure, jsf has plenty of components out there that offer high level things like data grids, etc, but so does wicket. the difference with wicket is this: the other day i created a productlink component for our application. it is a simple component that builds an anchor that takes the user to the product page. it also adds proper css class based on whether the product is for sale or not and whether it is in or out of stock. so now anytime someone needs to link to a product they simply do add(new ProductLink(link, product)); and attach it to a wicket:id=linkwhatever/a. the productlink can be embedded inside any other component just as easily and have any other component embedded in it as well. i dont think jsf folks would bother creating anything so fine-grained, because although it is very useful there would be too much overhead and pain involved. the problem is that jsf approaches web application development with a few roles in mind: the application developer and the component developer. the component developer is a smarter person that understands the intricacies of jsf. in wicket we do not assume the separation of roles, so our programming model is consistent and is optimized towards component creation. my two cents -igor Many thanks in advance. -- View this message in context: http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18847208.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
Hi, Here is a list of bullet points I compiled on JSF when compared with Wicket: – Not really OO components, more of XML tags than Java – Added complexity of JSF-EL and mixing JSP-EL if applicable – faces-config.xml : synchronize multiple files for navigation, page-centric, string expressions not type-safe – Poor separation of concerns / preview-ability (in core JSF spec) – General consensus that for practical use you have to supplement with non-standard extensions -e.g. Facelets, Spring WebFlow etc. – Hard to unit test – Hard to debug / step-through – More dependence on tooling / IDE support – Mixing components from multiple vendors problematic especially with AJAX – Generated HTML is typically verbose – Creating custom components is much harder – Slow evolution as it is a specification, now JSF 2.0 is being discussed… I had this as a back-up slide in a presentation recently (which I ended up having to use because of all the questions :) You can find the presentation here if you are interested, it is more to do with comparing Wicket with action / JSP based frameworks, but may help: http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/ Thanks, Peter. On Wed, Aug 6, 2008 at 11:44 PM, Igor Vaynberg [EMAIL PROTECTED]wrote: On Wed, Aug 6, 2008 at 2:13 AM, nlif [EMAIL PROTECTED] wrote: Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. actually, imho, this is one of wicket's biggest advantages over jsf. jsf is a standard so it moves very slowly. wicket is a much more agile project and moves much faster. Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). actually i find myself creating components all the time, because it is so damn easy. trivial and non trivial, because wicket uses composition it is not that much harder to create components with complex interactions. sure, jsf has plenty of components out there that offer high level things like data grids, etc, but so does wicket. the difference with wicket is this: the other day i created a productlink component for our application. it is a simple component that builds an anchor that takes the user to the product page. it also adds proper css class based on whether the product is for sale or not and whether it is in or out of stock. so now anytime someone needs to link to a product they simply do add(new ProductLink(link, product)); and attach it to a wicket:id=linkwhatever/a. the productlink can be embedded inside any other component just as easily and have any other component embedded in it as well. i dont think jsf folks would bother creating anything so fine-grained, because although it is very useful there would be too much overhead and pain involved. the problem is that jsf approaches web application development with a few roles in mind: the application developer and the component developer. the component developer is a smarter person that understands the intricacies of jsf. in wicket we do not assume the separation of roles, so our programming model is consistent and is optimized towards component creation. my two cents -igor Many thanks in advance. -- View this message in context: http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18847208.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
My company compared several frameworks and settled on either JSF or Wicket. We then had a 2 week development effort implementing the same proof-of-concept app with 2 teams of 4 devs each. Everyone was at least somewhat familiar with JSF, while only one person in our department had ever worked with Wicket. After 1 week the Wicket team was done, while the JSF team was struggling over whether to use facelets or jsp for rendering, which rendering implementation to use, which ajax library to use (and how that required re-deciding some of the previous items). Now many of those problems that plagued the JSF team are one-time decisions that are not indicative of day-to-day development. That said, every developer who worked with Wicket ended up advocating for it as our web framework, even though most of them had initially preferred JSF. In fact, after seeing the Wicket JSF code side-by-side most of the devs on the JSF team voted for Wicket, as did the rest of the department. In the previously recommended article http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/ go down to [The List Forums Screen] and compare the JSF tags with the Wicket html. We can hire presentation-layer developers who only need to know html css. Also, go into a working Wicket page and screw up something (misspell a wicket:id, whatever). Now examine the exception you get. It will likely describe in rather clear terms what is wrong. Now try this with JSF. Now take your problem and post it to the Wicket forum (perhaps with a different e-mail address) and ask for help. Now try that with JSF. Scott On Wed, Aug 6, 2008 at 11:30 AM, Peter Thomas [EMAIL PROTECTED] wrote: Hi, Here is a list of bullet points I compiled on JSF when compared with Wicket: – Not really OO components, more of XML tags than Java – Added complexity of JSF-EL and mixing JSP-EL if applicable – faces-config.xml : synchronize multiple files for navigation, page-centric, string expressions not type-safe – Poor separation of concerns / preview-ability (in core JSF spec) – General consensus that for practical use you have to supplement with non-standard extensions -e.g. Facelets, Spring WebFlow etc. – Hard to unit test – Hard to debug / step-through – More dependence on tooling / IDE support – Mixing components from multiple vendors problematic especially with AJAX – Generated HTML is typically verbose – Creating custom components is much harder – Slow evolution as it is a specification, now JSF 2.0 is being discussed… I had this as a back-up slide in a presentation recently (which I ended up having to use because of all the questions :) You can find the presentation here if you are interested, it is more to do with comparing Wicket with action / JSP based frameworks, but may help: http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/ Thanks, Peter. On Wed, Aug 6, 2008 at 11:44 PM, Igor Vaynberg [EMAIL PROTECTED]wrote: On Wed, Aug 6, 2008 at 2:13 AM, nlif [EMAIL PROTECTED] wrote: Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. actually, imho, this is one of wicket's biggest advantages over jsf. jsf is a standard so it moves very slowly. wicket is a much more agile project and moves much faster. Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). actually i find myself creating components all the time, because it is so damn easy. trivial and non trivial, because wicket uses composition it is not that much harder to create components with complex interactions. sure, jsf has plenty of components out there that offer high level things like data grids, etc, but so does wicket. the difference with wicket is this: the other day i created a productlink component for our application. it is a simple component that builds an anchor that takes the user to the product page. it also adds proper css class based on whether the product is for sale or not and whether it is in or out of stock. so now anytime someone needs to link to a product they simply do add(new ProductLink(link, product)); and attach it to a wicket:id=linkwhatever/a. the productlink can be embedded inside any other component just as easily and have any other component embedded in it as well. i dont think jsf folks would bother creating anything so fine-grained, because although it is very useful there would be too much overhead and pain involved. the problem is that jsf approaches web application development with a few roles in mind: the application developer and the component developer. the component developer is a smarter person that
Re: Comparing JSF and Wicket
Can we perhaps take this conversation to a wiki page (feel free to continue here, but for those who contribute it'd be nice if they added their $0.02 to a wiki)? I would love to be able to send our management to a page where all of these stories are listed. It would be great to have a Testimonials section on the Wicket Wiki! On Wed, Aug 6, 2008 at 3:07 PM, Scott Swank [EMAIL PROTECTED] wrote: My company compared several frameworks and settled on either JSF or Wicket. We then had a 2 week development effort implementing the same proof-of-concept app with 2 teams of 4 devs each. Everyone was at least somewhat familiar with JSF, while only one person in our department had ever worked with Wicket. After 1 week the Wicket team was done, while the JSF team was struggling over whether to use facelets or jsp for rendering, which rendering implementation to use, which ajax library to use (and how that required re-deciding some of the previous items). Now many of those problems that plagued the JSF team are one-time decisions that are not indicative of day-to-day development. That said, every developer who worked with Wicket ended up advocating for it as our web framework, even though most of them had initially preferred JSF. In fact, after seeing the Wicket JSF code side-by-side most of the devs on the JSF team voted for Wicket, as did the rest of the department. In the previously recommended article http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/ go down to [The List Forums Screen] and compare the JSF tags with the Wicket html. We can hire presentation-layer developers who only need to know html css. Also, go into a working Wicket page and screw up something (misspell a wicket:id, whatever). Now examine the exception you get. It will likely describe in rather clear terms what is wrong. Now try this with JSF. Now take your problem and post it to the Wicket forum (perhaps with a different e-mail address) and ask for help. Now try that with JSF. Scott On Wed, Aug 6, 2008 at 11:30 AM, Peter Thomas [EMAIL PROTECTED] wrote: Hi, Here is a list of bullet points I compiled on JSF when compared with Wicket: – Not really OO components, more of XML tags than Java – Added complexity of JSF-EL and mixing JSP-EL if applicable – faces-config.xml : synchronize multiple files for navigation, page-centric, string expressions not type-safe – Poor separation of concerns / preview-ability (in core JSF spec) – General consensus that for practical use you have to supplement with non-standard extensions -e.g. Facelets, Spring WebFlow etc. – Hard to unit test – Hard to debug / step-through – More dependence on tooling / IDE support – Mixing components from multiple vendors problematic especially with AJAX – Generated HTML is typically verbose – Creating custom components is much harder – Slow evolution as it is a specification, now JSF 2.0 is being discussed… I had this as a back-up slide in a presentation recently (which I ended up having to use because of all the questions :) You can find the presentation here if you are interested, it is more to do with comparing Wicket with action / JSP based frameworks, but may help: http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/ Thanks, Peter. On Wed, Aug 6, 2008 at 11:44 PM, Igor Vaynberg [EMAIL PROTECTED]wrote: On Wed, Aug 6, 2008 at 2:13 AM, nlif [EMAIL PROTECTED] wrote: Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. actually, imho, this is one of wicket's biggest advantages over jsf. jsf is a standard so it moves very slowly. wicket is a much more agile project and moves much faster. Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). actually i find myself creating components all the time, because it is so damn easy. trivial and non trivial, because wicket uses composition it is not that much harder to create components with complex interactions. sure, jsf has plenty of components out there that offer high level things like data grids, etc, but so does wicket. the difference with wicket is this: the other day i created a productlink component for our application. it is a simple component that builds an anchor that takes the user to the product page. it also adds proper css class based on whether the product is for sale or not and whether it is in or out of stock. so now anytime someone needs to link to a product they simply do add(new ProductLink(link, product)); and attach it to a wicket:id=linkwhatever/a. the productlink can be embedded inside any other component
Re: Comparing JSF and Wicket
Hi, I did one Project with JSF and two with Wicket. By far Wicket is much easier to handle, (nearly) everything works as supposed, which is not true for JSF, especially when it comes to external Libraries like Trinidad or other UI Extension Libraries. One other thing which is important for me is the Productivity. And this is much higher with Wicket than with JSF. The Community support is suberb with Wicket, and somewhat difficult when you check the JSF Forums, but this depends on the Manufactor of the Library you use. I don't want to slash JSF here, but I find it is miles away from a usable Product. For me it looks more like a prototype of what could be possible. Just check what happened from 1.1 to 1.2, and you see, that even Sun seemed to face this. Regards, Timm Am Mittwoch, 6. August 2008 11:13:53 schrieb nlif: Hi all, We are in the process of selecting a web-framework, and although I am in favor of Wicket, I was asked to provide an objective comparison of Wicket with JSF. I have developed a few small apps in Wicket, but I admit I am not very familiar with JSF. Prior to posting here, I googled a bit, and found a few forum-threads and blog posts on this topic, but most are from 1-2 years ago and in framework years, this may be considered obsolete. Although this is the Wicket forum, I expect there are people here who also used (or at least evaluated) JSF at some point, so I'd be happy if folks here could share their experience. If anyone can point me to useful links that would be great too. I really am not trying to provoke a flame war, just to gather information. In your opinion, what are Wicket strengths? What are JSF's ? (even if you're a Wicket fan, surely there's something ;) I would be interested to hear people thoughts regarding the fact the JSF is a standard, while Wicket is not. How important is that to you? In what ways do you think this matters (if at all)? Also, supposedly JSF has a larger selection of 3rd party components compared to Wicket. Is this true? how often do you find yourself rolling your own components and how hard is it to do so in Wicket (and I mean non-trivial-good-looking-Ajax-enabled stuff). Many thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
