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]
