Interesting; I'm already doing this with tapestry 3.0.3. I have entire
pages and varying-length forms, the contents of which are highly dynamic
and determined at runtime based on the type of object being rendered
(upload fields, multiple text fields, text, radio buttons, checkboxes,
date pickers, you name it). It's also done in such a fashion that one
could conceivably drop a jar in with components that the rendering page
never knew about and have things work properly. This is all done with
no hacking to the framework. I'm not seeing what adding "Dynamic
Components" will get me.
Any solution that winds up relying on reflection is going to be arguably
as complex (and probably wind up more complex) than a solution that can
be obtained in the here and now using things like Block/RenderBlock.
Cheers.
Robert
Leonardo Quijano Vincenzi wrote:
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)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
