Leonardo Quijano Vincenzi wrote:
Totally -1 on having lots of distributed libraries, like Tassel.
"Community support" they call it but it's really a ton of unsupported,
buggy components that could be better done under a couple of large
libraries.
Now, I haven't said "Integrate Dojo with Tapestry". I'm talking about
component composition, Javascript and Ajax support should be added like
Tapestry currently does with validators, in an optional way. What's the
point of having a TextField and a separate Autocompleter component ? Why
don't add the autocomplete functionality to an existing TextField with a
render contribution?
:) currently TextField has 7 parameters. know how many autocompleter
has? 13 !, yes 13 !
now thats a fine component for the tapestry code base :)
That's orthogonality and it's something Tapestry is lacking. It doesn't
mean it has to be on the main codebase. It could be in the contrib
project (what's the point of the current Contrib ?? why aren't those
components in the core?). Actually I'm +1 on having a Tapestry-Core and
a Tapestry-Components base. Plus Tapestry-Annotations and
Tapestry-Portlets.
Tapestry-Components would have standard components with optional Ajax
bindings. I don't know if that's too hard to design, but from a
developer point of view is far easier to turn a switch on than to change
all textfields in your application
Maybe I got this wrong, but is that not the idea of a component? to
encapsulate functionality - so you want other or additional
functionality, you use another component -
Or should TextField be there for all-use-cases-what-so-ever and there be
no other text field component on earth?
Keep it small and functional, deliver the basic functionality, and not
the swissknife "can-do-everything-but-just-almost" - ever tried to
actually use the saw in a swiss knife?
Now when you decide to use ajax - do you "change all textfields in your
application" ? sure if you use it for each and every input. good luck
with it then... :)
just because someone is still making
"Web 1.0" apps.
e.g. : it should evolve to allow partial page rendering, making tacos
life much easier, but keep the implementation of components to others,
just like in the case of JSF...
One of the main strengths of Tapestry, IMO, is that it always had a very
strong core components base. Delegating the implementation to third
parties would start the JSF syndrome: a very "powerful" core framework,
no useful components (so I tried using JSF six months ago and couldn't
find a Table component that allowed for radio button selections!). That
can change later, but then we have several uncompatible third-party
libraries ("I have this on X, that on Y, but nobody gives me all!")
I repeat, *it doesn't have to be in the core*. Moreover, I think the
core should have no components! That would be done in
Tapestry-Components, as I said. It could even have different committers,
or whatever...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
