Tapestry vs. Wicket

[Christopher Dodunski <Ch...@christopher.net.nz>]

Hi,

For someone looking at moving away from MVC based web frameworks and
towards component based web frameworks, what in your opinion makes
Tapestry a better option than Wicket?  What is Tapestry's strengths?

Making an informed choice isn't a trivial exercise, considering the
sheer number of possibilities.

Thanks & regards,

Christopher.


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

Re: Tapestry vs. Wicket

[Geoff Hopson <ge...@gmail.com>]

Let me throw Click into the mix

http://click.sf.net/

It's Java, and also quite interesting :-)

On 20/12/05, Jamie Orchard-Hays <ja...@dang.com> wrote:
>
> For something interesting to look at, see Seaside. It's SmallTalk,
> and quite interesting:
>
> http://www.seaside.st/
>
>
> On Dec 20, 2005, at 9:25 AM, Jesse Kuhnert wrote:
>
> > This is something I posted a long time ago, it's sort of negative
> > sounding
> > now that I look back on it, but I'm too lazy to re-write it so here
> > ya go(in
> > regard to some items, I do have access to the source now, so all the
> > daydreamy stuff mentioned will be happening.. ;) ):
> >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .
> > I tried so hard to rationalize what wicket was doing so that I could
> > try playing with it but it just didn't make sense. All of those pretty
> > web pages/blogs couldn't hide what they had done....
> >
> > Which, from what I've read/seen is try to create a "clean and simple"
> > way to write web-apps, from an almost naive swing-based point of view.
> > What they failed to realise is that you only have to do new JPanel(),
> > panel.add(new ComponentBlahBlah) because that's the only medium
> > available...There is no html. And yet with all of this simplicity
> > someone made the gargantuine mistake of ignoring all of that html that
> > people still had to write. So yes, wicket is incredibly simple to use.
> > But not the good kind, the writing and debugging 30 lines of assembly
> > to paint a single line across your screen kind.
> >
> > Tapestry on the other hand looks more like swing than wicket does to
> > me, only the driving force behind it hasn't blindly ignored the fact
> > that the rendering environment is based around html and so has
> > provided lots of nice ways to define things naturally this way.
> >
> > Still though, there is so much more potential....If only there was a
> > way to get at the source, I think Tapestry could expose JSF/Wicket/etc
> > for the flawed architectures they are through a few simple little
> > enhancements to make things just sort of "work" the way you'd like
> > them to...Like Swing does....When you add a data item to a model in
> > swing it just sort of automatically (via firing awt events in the
> > background, but still...) paints the region of the grid that needs to
> > be painted to add this item in...Tapestry could so easily do this as
> > well. I think it would be so elegant and easy to do that the other
> > frameworks would have to more or less be quiet and/or do a lot of
> > backtracking and justification for why their users have to go through
> > what they do to do the same thing that you get in tapestry for free
> > without even thinking about it....If only....
> >
> > I think things could be done that not even the holy RoR or other
> > similar frameworks could touch currently. A totally new way of
> > attacking this whole "ajax" thing. ..Maybe some day....some day....
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> > jesse
> > On 12/20/05, Christopher Dodunski
> > <Ch...@christopher.net.nz> wrote:
> >>
> >> Hi,
> >>
> >> For someone looking at moving away from MVC based web frameworks and
> >> towards component based web frameworks, what in your opinion makes
> >> Tapestry a better option than Wicket?  What is Tapestry's strengths?
> >>
> >> Making an informed choice isn't a trivial exercise, considering the
> >> sheer number of possibilities.
> >>
> >> Thanks & regards,
> >>
> >> Christopher.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: tapestry-user-
> >> help@jakarta.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>

Re: Tapestry vs. Wicket

[Jamie Orchard-Hays <ja...@dang.com>]

For something interesting to look at, see Seaside. It's SmallTalk,  
and quite interesting:

http://www.seaside.st/


On Dec 20, 2005, at 9:25 AM, Jesse Kuhnert wrote:

> This is something I posted a long time ago, it's sort of negative  
> sounding
> now that I look back on it, but I'm too lazy to re-write it so here  
> ya go(in
> regard to some items, I do have access to the source now, so all the
> daydreamy stuff mentioned will be happening.. ;) ):
>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .
> I tried so hard to rationalize what wicket was doing so that I could
> try playing with it but it just didn't make sense. All of those pretty
> web pages/blogs couldn't hide what they had done....
>
> Which, from what I've read/seen is try to create a "clean and simple"
> way to write web-apps, from an almost naive swing-based point of view.
> What they failed to realise is that you only have to do new JPanel(),
> panel.add(new ComponentBlahBlah) because that's the only medium
> available...There is no html. And yet with all of this simplicity
> someone made the gargantuine mistake of ignoring all of that html that
> people still had to write. So yes, wicket is incredibly simple to use.
> But not the good kind, the writing and debugging 30 lines of assembly
> to paint a single line across your screen kind.
>
> Tapestry on the other hand looks more like swing than wicket does to
> me, only the driving force behind it hasn't blindly ignored the fact
> that the rendering environment is based around html and so has
> provided lots of nice ways to define things naturally this way.
>
> Still though, there is so much more potential....If only there was a
> way to get at the source, I think Tapestry could expose JSF/Wicket/etc
> for the flawed architectures they are through a few simple little
> enhancements to make things just sort of "work" the way you'd like
> them to...Like Swing does....When you add a data item to a model in
> swing it just sort of automatically (via firing awt events in the
> background, but still...) paints the region of the grid that needs to
> be painted to add this item in...Tapestry could so easily do this as
> well. I think it would be so elegant and easy to do that the other
> frameworks would have to more or less be quiet and/or do a lot of
> backtracking and justification for why their users have to go through
> what they do to do the same thing that you get in tapestry for free
> without even thinking about it....If only....
>
> I think things could be done that not even the holy RoR or other
> similar frameworks could touch currently. A totally new way of
> attacking this whole "ajax" thing. ..Maybe some day....some day....
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> jesse
> On 12/20/05, Christopher Dodunski  
> <Ch...@christopher.net.nz> wrote:
>>
>> Hi,
>>
>> For someone looking at moving away from MVC based web frameworks and
>> towards component based web frameworks, what in your opinion makes
>> Tapestry a better option than Wicket?  What is Tapestry's strengths?
>>
>> Making an informed choice isn't a trivial exercise, considering the
>> sheer number of possibilities.
>>
>> Thanks & regards,
>>
>> Christopher.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user- 
>> help@jakarta.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

Re: Tapestry vs. Wicket

[Jesse Kuhnert <jk...@gmail.com>]

Hmmm.. I had to actually go back and look at wicket again to be sure, but I
don't think you're right about the html markup. It's actually much worse
than I originally thought ;)

Look at http://wicket.sourceforge.net/ExampleGuestBook.html.

You will notice that you have to do tapestry-ish html markup in your
template, with the caveat that

" In the HTML below, notice the way that the TextArea component is being
nested inside the CommentForm. Wicket is able to keep everything straight
because the Java Component.add() calls have to result in the same nesting
structure as the HTML."

Which means that you have to do with swing-ish layout logic in your code AND
the tapestry-ish layout logic.

All of this just sounds like a very cool, yet immature framework to me. I
think it's more than likely that they might eventually get rid of some of
their swing code in favor of letting the html handle layout, but then you're
basically left with tapestry, only years behind ;)

Maybe I'm wrong?

jesse

On 12/20/05, Francis Amanfo <fa...@gmail.com> wrote:
>
> I disagree with you on the point that there is no html in wicket. Aren't
> you
> confusing yourself with the Echo framework? Wicket has the same templating
> concept  as Tapestry but unlike Tapestry  there are no configuration
> files.
> Every page is mapped onto a Java class.
> Having done production applications both in Tapestry and and Wicket, I
> would
> say the big plus of Wicket is how quick one can get the job done.
> Tapestry's
> big plus is its error reporting and excellent integration with other
> frameworks such as Spring and Hibernate and of course, it's maturity. I
> missed Tapestry's error reporting so badly when developing with Wicket.
> Its
> a place wicket isn't doing a very good job.
> Which one do I prefer? It depends on the sophistication of the application
> and time pressure. IMHO, things can be done quicker in Wicket. Having said
> that, I would also mention that I haven't had a deep look at Tapestry 4
> yet,
> which seems to be a major improvement over 3.0. I'm currently evaluating
> 4.0.
> If things are really like it's been hyped, then I'll consider it for my
> next
> project.
>
> Regards,
>
> F
>
>
> On 12/20/05, Jesse Kuhnert <jk...@gmail.com> wrote:
> >
> > This is something I posted a long time ago, it's sort of negative
> sounding
> > now that I look back on it, but I'm too lazy to re-write it so here ya
> > go(in
> > regard to some items, I do have access to the source now, so all the
> > daydreamy stuff mentioned will be happening.. ;) ):
> >
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.
> > I tried so hard to rationalize what wicket was doing so that I could
> > try playing with it but it just didn't make sense. All of those pretty
> > web pages/blogs couldn't hide what they had done....
> >
> > Which, from what I've read/seen is try to create a "clean and simple"
> > way to write web-apps, from an almost naive swing-based point of view.
> > What they failed to realise is that you only have to do new JPanel(),
> > panel.add(new ComponentBlahBlah) because that's the only medium
> > available...There is no html. And yet with all of this simplicity
> > someone made the gargantuine mistake of ignoring all of that html that
> > people still had to write. So yes, wicket is incredibly simple to use.
> > But not the good kind, the writing and debugging 30 lines of assembly
> > to paint a single line across your screen kind.
> >
> > Tapestry on the other hand looks more like swing than wicket does to
> > me, only the driving force behind it hasn't blindly ignored the fact
> > that the rendering environment is based around html and so has
> > provided lots of nice ways to define things naturally this way.
> >
> > Still though, there is so much more potential....If only there was a
> > way to get at the source, I think Tapestry could expose JSF/Wicket/etc
> > for the flawed architectures they are through a few simple little
> > enhancements to make things just sort of "work" the way you'd like
> > them to...Like Swing does....When you add a data item to a model in
> > swing it just sort of automatically (via firing awt events in the
> > background, but still...) paints the region of the grid that needs to
> > be painted to add this item in...Tapestry could so easily do this as
> > well. I think it would be so elegant and easy to do that the other
> > frameworks would have to more or less be quiet and/or do a lot of
> > backtracking and justification for why their users have to go through
> > what they do to do the same thing that you get in tapestry for free
> > without even thinking about it....If only....
> >
> > I think things could be done that not even the holy RoR or other
> > similar frameworks could touch currently. A totally new way of
> > attacking this whole "ajax" thing. ..Maybe some day....some day....
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> > jesse
> > On 12/20/05, Christopher Dodunski <Ch...@christopher.net.nz>
> > wrote:
> > >
> > > Hi,
> > >
> > > For someone looking at moving away from MVC based web frameworks and
> > > towards component based web frameworks, what in your opinion makes
> > > Tapestry a better option than Wicket?  What is Tapestry's strengths?
> > >
> > > Making an informed choice isn't a trivial exercise, considering the
> > > sheer number of possibilities.
> > >
> > > Thanks & regards,
> > >
> > > Christopher.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> > >
> > >
> >
> >
>
>

Re: Tapestry vs. Wicket

[Francis Amanfo <fa...@gmail.com>]

I disagree with you on the point that there is no html in wicket. Aren't you
confusing yourself with the Echo framework? Wicket has the same templating
concept  as Tapestry but unlike Tapestry  there are no configuration files.
Every page is mapped onto a Java class.
Having done production applications both in Tapestry and and Wicket, I would
say the big plus of Wicket is how quick one can get the job done. Tapestry's
big plus is its error reporting and excellent integration with other
frameworks such as Spring and Hibernate and of course, it's maturity. I
missed Tapestry's error reporting so badly when developing with Wicket. Its
a place wicket isn't doing a very good job.
Which one do I prefer? It depends on the sophistication of the application
and time pressure. IMHO, things can be done quicker in Wicket. Having said
that, I would also mention that I haven't had a deep look at Tapestry 4 yet,
which seems to be a major improvement over 3.0. I'm currently evaluating 4.0.
If things are really like it's been hyped, then I'll consider it for my next
project.

Regards,

F


On 12/20/05, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> This is something I posted a long time ago, it's sort of negative sounding
> now that I look back on it, but I'm too lazy to re-write it so here ya
> go(in
> regard to some items, I do have access to the source now, so all the
> daydreamy stuff mentioned will be happening.. ;) ):
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.
> I tried so hard to rationalize what wicket was doing so that I could
> try playing with it but it just didn't make sense. All of those pretty
> web pages/blogs couldn't hide what they had done....
>
> Which, from what I've read/seen is try to create a "clean and simple"
> way to write web-apps, from an almost naive swing-based point of view.
> What they failed to realise is that you only have to do new JPanel(),
> panel.add(new ComponentBlahBlah) because that's the only medium
> available...There is no html. And yet with all of this simplicity
> someone made the gargantuine mistake of ignoring all of that html that
> people still had to write. So yes, wicket is incredibly simple to use.
> But not the good kind, the writing and debugging 30 lines of assembly
> to paint a single line across your screen kind.
>
> Tapestry on the other hand looks more like swing than wicket does to
> me, only the driving force behind it hasn't blindly ignored the fact
> that the rendering environment is based around html and so has
> provided lots of nice ways to define things naturally this way.
>
> Still though, there is so much more potential....If only there was a
> way to get at the source, I think Tapestry could expose JSF/Wicket/etc
> for the flawed architectures they are through a few simple little
> enhancements to make things just sort of "work" the way you'd like
> them to...Like Swing does....When you add a data item to a model in
> swing it just sort of automatically (via firing awt events in the
> background, but still...) paints the region of the grid that needs to
> be painted to add this item in...Tapestry could so easily do this as
> well. I think it would be so elegant and easy to do that the other
> frameworks would have to more or less be quiet and/or do a lot of
> backtracking and justification for why their users have to go through
> what they do to do the same thing that you get in tapestry for free
> without even thinking about it....If only....
>
> I think things could be done that not even the holy RoR or other
> similar frameworks could touch currently. A totally new way of
> attacking this whole "ajax" thing. ..Maybe some day....some day....
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> jesse
> On 12/20/05, Christopher Dodunski <Ch...@christopher.net.nz>
> wrote:
> >
> > Hi,
> >
> > For someone looking at moving away from MVC based web frameworks and
> > towards component based web frameworks, what in your opinion makes
> > Tapestry a better option than Wicket?  What is Tapestry's strengths?
> >
> > Making an informed choice isn't a trivial exercise, considering the
> > sheer number of possibilities.
> >
> > Thanks & regards,
> >
> > Christopher.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
>

Re: Tapestry vs. Wicket

[Jesse Kuhnert <jk...@gmail.com>]

This is something I posted a long time ago, it's sort of negative sounding
now that I look back on it, but I'm too lazy to re-write it so here ya go(in
regard to some items, I do have access to the source now, so all the
daydreamy stuff mentioned will be happening.. ;) ):

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.
I tried so hard to rationalize what wicket was doing so that I could
try playing with it but it just didn't make sense. All of those pretty
web pages/blogs couldn't hide what they had done....

Which, from what I've read/seen is try to create a "clean and simple"
way to write web-apps, from an almost naive swing-based point of view.
What they failed to realise is that you only have to do new JPanel(),
panel.add(new ComponentBlahBlah) because that's the only medium
available...There is no html. And yet with all of this simplicity
someone made the gargantuine mistake of ignoring all of that html that
people still had to write. So yes, wicket is incredibly simple to use.
But not the good kind, the writing and debugging 30 lines of assembly
to paint a single line across your screen kind.

Tapestry on the other hand looks more like swing than wicket does to
me, only the driving force behind it hasn't blindly ignored the fact
that the rendering environment is based around html and so has
provided lots of nice ways to define things naturally this way.

Still though, there is so much more potential....If only there was a
way to get at the source, I think Tapestry could expose JSF/Wicket/etc
for the flawed architectures they are through a few simple little
enhancements to make things just sort of "work" the way you'd like
them to...Like Swing does....When you add a data item to a model in
swing it just sort of automatically (via firing awt events in the
background, but still...) paints the region of the grid that needs to
be painted to add this item in...Tapestry could so easily do this as
well. I think it would be so elegant and easy to do that the other
frameworks would have to more or less be quiet and/or do a lot of
backtracking and justification for why their users have to go through
what they do to do the same thing that you get in tapestry for free
without even thinking about it....If only....

I think things could be done that not even the holy RoR or other
similar frameworks could touch currently. A totally new way of
attacking this whole "ajax" thing. ..Maybe some day....some day....
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
jesse
On 12/20/05, Christopher Dodunski <Ch...@christopher.net.nz> wrote:
>
> Hi,
>
> For someone looking at moving away from MVC based web frameworks and
> towards component based web frameworks, what in your opinion makes
> Tapestry a better option than Wicket?  What is Tapestry's strengths?
>
> Making an informed choice isn't a trivial exercise, considering the
> sheer number of possibilities.
>
> Thanks & regards,
>
> Christopher.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>