Re: Comparing JSF and Wicket
://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
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] -- View this message in context: http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18912393.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
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
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] - 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-tp18847208p18865035.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
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
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] -- View this message in context: http://www.nabble.com/Comparing-JSF-and-Wicket-tp18847208p18864975.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
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]
Comparing JSF and Wicket
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-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]
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
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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Comparing JSF and Wicket
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] - 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, 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]
