> 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.
>
Tassel really serves a bit of a different purpose than Tacos. Tell me...
how does one go about contributing a component to tacos?
Components in tassel are definitely "use at your own risk"; different
people have contributed different components at various stages of
maturity. Those authors are responsible for maintaining their components;
Tassel just provides a place where that can be done. That said, to
classify all of them as "buggy" is really not very fair. There are a
total of 36 components sitting in tassel right now (33 unique ones; 3 are
tapestry-4 versions of another component). Is there some overlap in what
components are present? Sure.. there's a "tabset" component and a
"tabpanel" component; both are for making "tabbed panes", although they
each go about it in a different way; different strokes for different
folks, to quote the axiom. Similarly, having both the tacos approach
(highly structured, single library, etc.) and the tassel approach (loose
structure; loose coupling between components) is, imo, a good thing. I
think that anything that gets more people to contribute components to the
community as a whole is a good thing.
Incidentally "we" don't call it "community support"; we don't call it
anything. We don't guarantee any support. Things in tassel are there on a
"take it or leave it" basis, although authors are free to update their
componetns, correspond with users, etc. if they desire (and most do).
Tassel is a place for very busy people to quickly and easily make
components, code, etc. available for reuse by others, with as little
red-tape as possible. Some of us don't have time for red-tape when all we
want to do is make a charity donation.
Robert
> 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?
>
> 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 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...
>
> --
> Ing. Leonardo Quijano Vincenzi
> DTQ Software
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
