t; 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
> 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 J
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
&g
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 altern
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
s (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-go
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
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.
Reg
n 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
> 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
> reso
> 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
>
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
here 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 tha
r . 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 bot
ur 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 P
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
ust 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.
>&g
gt; 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
>> s
ies 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.
> >
> >
> >
> >
> > --
> > Vie
mming 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.
--
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 additio
tion 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.
>
>
>
>
>
--
s 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
23 matches
Mail list logo
