I don't mean to butt in, but the "Wicket" comparison is something that
hits particularly close to home for me as I've personally suffered
through many years of the abomination known as "Swing".
Once you've used a real GUI toolkit you'll find the differences to be
almost unacceptable. It's certainly a way to do programming, but not
really one that I like. In fact I'm really wholeheartedly against it.
Saying java is a static language isn't entirely true anymore either..
People have managed to start blurring the lines some, such as the
introduction of Annotations. (and the somewhat failed introduction of
generics, still better than void pointers I guess...)
I think the concepts of the java programming language are going to be
whatever we decide they are. Like any good artist Howard has learned
from other languages / frameworks / etc - taking the good and leaving
the bad.
All that being said, I hope you know I only say it in the friendly
sort of academic back and forth sort of way and nothing else. ..
On 1/20/07, Kent Tong <[EMAIL PROTECTED]> wrote:
Howard Lewis Ship <hlship <at> gmail.com> writes:
> Anything is workable. Is this Tapestry? It doesn't feel like it,
> more like a step closer to Wicket.
Well, I think this is not a valid argument. I think we need to make
Tapestry better by making it easier for people to develop web apps. If
an idea helps, then we should do it, otherwise don't. Whether this
idea is similar to one in another product is totally unimportant to
me (unless it is patented).
In fact, Wicket is just a refactoring of Tapestry. If I'm not mistaken,
T5 is also taking a lot of ideas from RoR.
T5 will not be the same as Wicket. T5 has a lot more than Wicket (AFAIK as
I don't know much about Wicket): static page structure (scalability), auto
class reloading, no duplicated component hierarchies in templates and code,
and etc.
> I can see the appeal of this in one way, it looks a lo more like Swing.
I think it is more than looking like Swing; it is relying on the concepts
in the Java language.
> But it's so asymmetric ...
>
> There's more code to write. If a property ever changes from
> set-and-forget to read/write or even read-on-demand, it may affect
> existing code.
This is true. But then there will be compile errors. When changing the
API, what more can we hope for? If we're using a binding, there won't
be compile errors, but only runtime errors (eg, when a literal binding
is passed to a parameter that is later changed to read/write).
> Many convieniences and automatic conversions are lost.
The point about automatic conversion is interesting. It is not something
not in Java but is in some dynamic languages (php). I am not sure if Java
programmers prefer writing code like:
int i = "100";
However, smart conversion as implemented in T5 is very handy. We could
use it like:
import static org.apache.tapestry.SmartConverter.convert;
void setupLoop(Loop loop) {
loop.setSource(convert(new String[]{"a", "b"})); //Convert to Iterable
}
In addition, as SmartConverter is just a regular Java class. It is
very easy to write, understand and use.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
