Hmm well...I could agree that doing things like what are done with Block and
RenderBlock could be a little easier, but it's not on my radar screen. I'm
mostly coding exactly what I need to build my own employers products and
nothing more.. ..(maybe a little bit more, but not too much..)
Of course that's the great thing about open source projects. If something's
not getting done that needs to be done chances are good that eventually one
of those users will turn into a developer and contribute some code :)
On 1/30/06, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> 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)
>
> --
> 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]
>
>
