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 On 1/30/06, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote: > > Ok, some issues that concern me currently with Tapestry related to this: > > 1) Component IDs. They're still not clear. Using "idPath" to uniquely > identify a component still seems like a hack, and using fixed literals > such as "<span id="componentX" jwcid="@Any" />" doesn't work when > reusing components. There are no ids for looped components either. > > There are 2 ways (I think) of propery naming components: > a) Use a global sequence number to identify repeated components. For > exaple, "mytextfield_0", "mytextfield_1". That approach is simpler but > it doesn't work with any kind of dynamic component generation. > b) Use a hierarchical approach to naming. For example: > "mycomponent_mytextfield". But we need a proper separator (not a dot! i > think it causes problems with Javacript). > > 2) The use of abstract classes. But I think that's getting handled, > right? I just wonder if anyone has thought of using CGLIB proxy > generation instead of abstract subclassing. > > So, as Geoff says, this discussion might have happened several times in > the last 5 years. Wouldn't it be because it still doesn't feel natural? > I just hope we don't commit the same mistake of EJB 2.x. It may be > easier for JSF to be more scalable, but dynamic, than to Tapestry to do > the opposite. > > (In any case, I urge anyone who knows exactly why having a runtime > component model limits scalability to refresh our memories. Maybe I just > haven't read all of Howard's blog). > > -- > Ing. Leonardo Quijano Vincenzi > DTQ Software > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
