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]
