On 2/5/07, Jon Steelman <[EMAIL PROTECTED]> wrote:
Speaking of Tapestry 5, they claim a total codebase rewrite and it looks
like Wicket had a significant influence on that rewrite.
tapestry 5 is a simplification of tapestry 4 using new language features
such as annotations. there arent many "new" features in it as far as users
are concerned. but some of what we consider horrible limitations still
remain unchanged - like a static page component hierarchy.
Do I remember
correctly that the original target was that Wicket 2.0 would be released
before 2007? But now to be realistic considering previous projections, the
date looks more like late 2007?
that is because we are working on a lot more features then were originally
planned for 2.0. also the move to apache has slowed down our development
velocity, there was a pretty big adjustment period.
Makes me a little nervous that Tapestry can
completely turn around their code base, pick up lots of Wicket's formerly
distinguishing checklist features, and do it all before Wicket does even a
lite rewrite ala 2.0 much less a serious rewrite like maybe 3.0 would be.
Hopefully I'm just being paranoid.
tapestry 5 is nowhere near ready. not even for a demo. i dont think it can
even submit a complex form yet. ask howard when he thinks t5 will be feature
complete and production ready.
Tapestry 5 is a totally new code base for the groundbreaking Tapestry
framework.
Tapestry 5 features many improvements over Tapestry 4, including:
* Component classes no longer extend from base classes
this doesnt apply. we do not think there is anything wrong with extending
base classes. if you look at the screenst where he shows a simple loop you
will see that the index that the loop uses is actually a property of the
page not the loop. it is not encapsulated at all inside the loop component.
this is a horrible example that shows off scope leakage due to the way
tapestry keeps state.
* Component classes are no longer abstract
wicket still has and always will have abstract components. but this is a
different issue.
in t4 components had to be abstract because of the way t4 kept state. any
state you wanted to keep you had to create abstract setters/getters for and
tapestry would fill them in at runtime by generated a non-abstract class for
you page for you. this made debugging hell. in t5 you just annotate your
getters/setters with annots instead of making them abstract.
in wicket classes are abstract because they require you to fill in some code
to complete them and abstract methods are great coding guides because the
compiler makes you implement them. so reasons for having abstract classes
are completely and utterly different between wicket and t4. in t5 if you
wanted the user to finish some part of the component you would also make
that method abstract i would imagine.
* Component configuration is based on Java annotations, not external XML
files
we do it all in code where we believe it belongs.
* Changes to page and component classes are picked up immediately
this is a red herring. if you add state that needs to be initialized it will
still break. we also have a reloading filter that has the same problem.
* URLs are shorter, "prettier", and case-insensitive
tapestry always had this, its just a small improvelement
* Blazing Speed: Code paths have been simplified and runtime reflection
is all but eliminated
we never used much reflection to start with.
* Simplfied coding model, based on convention over configuration
principles
ours is even simpler as you dont even need to annotate anything.
* Built-in BeanEditForm component for building simple create/update UIs
we have something in wicket-stuff for this, but there has never been much
interest.
* Many, many, many other improvements too numerous to mention.
same here.
so please next time before posting something like this at least read up
-igor
