On 2/5/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
what i got out of it is that two of things that he considers most
important
are
a) not having to recompile to see your changes
this wont work for wicket. the closest you get to this are jsps that are
recompiled when changed and do not depend on session state.
after jsps there are frameworks that externalize state away from object
instances, like tapestry 5, but even they break down sometimes because
when
you add fields those fields might need to be initialized to something
meaningful.
Speaking of Tapestry 5, they claim a total codebase rewrite and it looks
like Wicket had a significant influence on that rewrite. 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? 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 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
* Component classes are no longer abstract
* Component configuration is based on Java annotations, not external XML
files
* Changes to page and component classes are picked up immediately
* URLs are shorter, "prettier", and case-insensitive
* Blazing Speed: Code paths have been simplified and runtime reflection
is all but eliminated
* Simplfied coding model, based on convention over configuration
principles
* Built-in BeanEditForm component for building simple create/update UIs
* Many, many, many other improvements too numerous to mention.
