> Of course, we always are more productive with the tools we already are used
> to them. But this doesn't mean you couldn't be more productive if you learn
> a better tool.
Oh - its not that I did not learn Tapestry ;-)
> You don't need to create components to use JavaScript at all. If you don't
> think you need to write components, don't write them. Just use jQuery UI or
> any other JavaScript package directly in your pages.
Yeah - you could do this, but a lot of problems will arise. You don't
want to do this, I've tried it.
In the end you give up the advantages of components and gain nothing.
And its still more complex to use than in an action based framework,
especially if it comes to AJAX.
> Anyway, you don't need to worry about lifecycles in Tapestry unless you're
> writing something more complex, and that doesn't happen everyday, and
> lifecycles in Tapestry (page and components) are not complex, specially when
> compared to JSF, for example.
Oh.. of course. Tapestry is a dream of productivity compared to JSF.
But we are talking about action based approaches here, more concrete
about Play!
And sure I have to worry about life cycles.. I had to in every single
tapestry app I've built. You need to worry about component IDs, about
life cycles and how your data flows through them. It's all coming
together in an elegant way - but you need to worry a lot more within
the "component" world.
>> To build a tapestry project you need more work/thinking in the
>> beginning,
>
> This is a very good thing! :)
Agreed - but sometimes you need to prototype quickly. I prefer to be
able to "upgrade" the prototype to the final app, without completely
rewriting it. I found it difficult to deliver quick changing
prototypes in tapestry. Customizing the UI costs too much time,
especially if your available web developers dont have a clue about
tapestry. And most of them dont ;)
> All projects eventually get bigger and more complex as time passes.
> I respect your reasons, but I disagree with them.
Agreed. On the other hand experience has shown that its not worth to
think about all possibilities the future may bring. Solve the problem,
solve it fast.
If the application needs to get more complex in 2 years, think about
how to solve this complexity then. Else you are in danger to
over-architect your application from the beginning. The result is much
more work than needed.
Just to say it again.. I love tapestry. I like the clean code and the
endless possibilities. But _my_ reality right now is that it is not
the best choice for some of _my_ projects. Thats sad, but I am not too
religious about the tools I use.
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
