Re: Re: Re: little extension of BLink

Jacob Kjome <[email protected]> wrote:

> We could solve this be
> making a BComponent for every tag in HTML (or any other markup we
> support).  However, I'd say that is overkill as well and leaves us
> with a glut of BComponents.
I agree. It is overkill to have a component for every HTML tag. On drawback
is that this would reduce Barracuda to HTML. On the other side there are
only few componets which make sense without thinking about the markup
language. What I want to say is that sooner or later you need components
which are focused (maybe limited) to a certain markup language.

>  What if you change the element from <p>
> to <h1>?  In Barracuda, that means you continue returning a BText
> component and it doesn't matter.  In another component-based
> framework, that might mean forcing server-side code to change from
> PComponent to H1Component.  That is certainly not desireable or
> flexible.
For this example I agree with you. A text component should render on any tag
which contains text of any kind. But in general I wouln'd agree. Think of an
image or an menu. It only make sense to bind such components to special
elements.

> We're all ears on any ideas on how to improve Barracuda components.
> Let us know your ideas.
Well, Barracudas component model is pretty smart. Only Baction and BLink
should be redesigned and made clearer as I sad in former answer.
The other information which I can give is that I currently work on some new
components. To list some of them: BMessage (counterpart of JOptionPane),
BMenu (counterpart of JMenu), BImage (<img>), BLogin (just a composite which
renders as a small login dialog), BFrame (decorator enclosing any
BComponent). Also I try to develop a new concept, that is "no directives"
(really no logic in markup template). But at the moment they in a very early
state, i. e. it is much to early to make them public. When the time is right
I want to contribute them to the project.

Regards,
Thorsten