Don't get me wrong. I think I can see how Block/RenderBlock may not be quite
as obvious to use based on recent mailing list posts I've responded to.
I just don't have time to gather requirements/use cases. Ie, is this a
matter of documentation, or is there something else missing that is required
to make this better? (other than generic pie in the sky statements ;) )
On 1/30/06, Robert Zeigler <[EMAIL PROTECTED]> wrote:
>
> 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]
>
>
