You do have an argument on that kind of Swing development. But usually
dynamic component generation is used when you need to do some kind of
reflection-based page generation. For example, if I want to do a
simple-CRUD app (like the Trails guys are doing, I think), I might need
to present different kind of components depending on an object's type. A
DatePicker for date, a text field for names, some spinner up-down button
for integers, etc. Maybe I'd like to make it even more powerful and
include a custom-made component for a business object ("put some
textfields for the Address object, please"), etc... Maybe I just use a
"component-type registry" that maps something like this:
[ Date -> DatePicker ]
[ Integer -> Up/Down Control linked with Textfield ]
[ String -> Textfield ]
Or even a better kind of mapping infrastructure. Maybe I annotate a
String property with "@Long", and I want to generate a TextArea for that.
That's the kind of stuff you can't usually do with static models. It's a
case of a limited model limiting our thinking ability.
Now, I *really* don't think Swing is a good example of what I would be
looking for. Rather, what I look for is non-intrusiveness. You can reach
that when you can just say "put a XX component here", and you can say
that in your template or in your Java code. Templates are for fixed
pages, Java code would be usually used for runtime generation, as the
example I gave above.
For the people who say "It's too hard and I just don't care", well...
somebody *will* care someday and it might be our competition ;). And
it's not that hard. I'd vote for a focus on simplifying the internal
Tapestry structure while maintaining its strength, and *then* see what
esoteric features it would grow on its own. Maybe dynamic generation is
not as hard and not as un-scalable as you people think (and don't tell
me to go Wicket myself. I'm sick of having 300+ web frameworks while
.NET only has one or two)
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Jesse Kuhnert wrote:
This argument can really drive you nuts sometimes :) I don't think Howard
needs to blog about this, but I think I have a good example that I can use
against the very frameworks that purport to be more like swing mvc ....
Basically, tapestry is as close as you can get to a real component model, at
least in java, and one that most closely resembles the real world
implmentation details of doing things in swing/web. No lie :)
Has anyone every played with a swing Grid before? Or a JList? Do you think
they call JList.add(new SomeUIComponent()) for each item in the list/grid?
No, they create one JLabel/or button/or whatever you like, and they use it
as a "stamp" to render everything, all the while magically changing out the
variable binding values for each loop without anyone being the wiser, just
like tapestry does.
So really the question is, why have these other frameworks taken only the
high level design concepts of things like swing, but completely fouled up
the actual implementation details?
j
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
