> 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]
