Re: BImage ?

Jacob Kjome <[email protected]> Tue, 12 Dec 2006 13:12:15 -0600
Newsgroups gmane.comp.java.enhydra.barracuda.general
Message-ID <[email protected]>
This is a multi-part message in MIME format...

------------=_1165950777-18037-134
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Quoting Franck Routier <[email protected]>:

> Jacob Kjome a =E9crit :
> > I haven't looked at the stuff in a while, but I'll give a little backgr=
ound
> on
> > why I added the marker interface.  There had been some users that wante=
d to
> > write custom components that failed to render.  They failed because the
> > rendering code didn't have a generic way of reacting to complex compone=
nts
> > generically.  I took at look at the existing code and found that BList,
> BTable,
> > and BTemplate were specifically called out as exceptions to certain
> rendering
> > logic.  So, I decided to create the BCompundComponent interface as a way
> for
> > the rendering code to recognize custom compound components in the same =
way
> it
> > does the core compound component exceptions.  So, I didn't change the
> rendering
> > logic.  I only made it so it wasn't so unforgiving to custom components.
> >
> Well, I have now a working example of composed, or nested, components.
> Hurrah ! :-)
>
> So I can basically do somethig like this in a BTemplateModel :
>
> if (key.equals("Recurs")){
>                 AInput bi =3D new AInput(BInput.TEXT,"Nested_AInput","Val=
ue");
>                 BImage img =3D new BImage("Nested
> image","images/stade.png","15","15");
>                 bi.addChild(img);
>                 return new BLabel("Nested label : ",bi);  // this
> constructor adds bi as a child to BLabel
>
> and it will happily render as :
>
> <LABEL for=3D"Nested_AInput">Nested label : <INPUT type=3D"text"
> value=3D"Value"><IMG alt=3D"Nested image" height=3D"15" src=3D"images/sta=
de.png"
> title=3D"Nested image" width=3D"15"></LABEL>
>
> Great.
> Now, what did I do to obtain that ?..
>
> 1) I had to implement BCompoundComponent on every nested component (and
> on the parent component as well).
>
> This is especially unconvinient as you can't tell in advance if a
> BComponent will be nested or not (and it can be sometimes, and not some
> other times).
> That is why you can see a AInput above : it is a BInput implementing
> BCompoundComponent.
> So there would be a first modification of BContainer and
> AbstractBCompnent, allowing to dynacally setCompound(true) when nesting
> a component.

I had considered using a method that each component would implement, but we=
nt
with the marker interface because it's a burden to force components that ar=
en't
something to declare that they aren't that something.  It's much less burde=
nsome
to simply declare that you are something and not bother anyone else that do=
esn't
care.  However, it looks as this is more dynamic and we might have to provi=
de a
way to declare this for arbitrary components, even ones that aren't,
themselves, compound.  But I would hope that we could do it in a way where =
no
one is forced to call setCompound(true) externally.  Maybe this gets set
internal to addChild()?

>
> 2) I had to implement createDefaultNode in the renderers of the
> components I used, and to recursively call createDefaultNode on every chi=
ld.
>

Interesting.  Should this be default behavior so no one has to override the
method?

> As I only have a single node at first (the one with the
> Dir::Get_Data.Tests.Recurs directive), I need to create children nodes
> of the right types. And I need to give each child, and each child of the
> children, a chance to get in.
>

Hmm... "children of the right nodes".  I suppose the override might be
necessary?

> There could be another evolution here : either create another interface
> (NestableComponent) to make sure every nested component implements this
> behaviour, and implement it on some components or make this the default
> for every BComponent.
>

If everything is nestable, then the interface is redundant, so we'd just pr=
ovide
BComponent with the necessary functionality and every other component will =
just
pick it up.  We need to be concerned about backward compatibility as well.

Of course, the whole BCompoundComponent and BNestableComponent stuff is jus=
t a
workaround for rendering code that probably could be modified in a way wher=
e it
doesn't have to make these distinctions.  I think we should look into this
possibility first thing.  I would be quite happy to deprecate
BCompoundComponent in favor of a more general solution to the rendering cod=
e.

> Not sure for the 2nd point...
> > The solution may have been naive on my part because I can't say that I
> really
> > dug in to understand the reasons why said core components were exceptio=
ns
> in
> > rendering; I only genericized their treatment.  Why the rendering code =
is
> the
> > way it is, is something to research and/or bring up with Christian or o=
ther
> > original writers of that code.  As you found, the code is very complex,=
 and
> > simplification may be the order of the day.
> >
> As I understand it, the problem is that these components iteratively add
> child nodes, andTemplateHelper also tries to do this to catch any
> embedded directive in the nodes returned by its model. Doing both seems
> to lead to StackOverflow... Humm... This is still a bit unclear to me,
> but I'm positive on the StackOverflow ! :)

This is why I didn't attempt to modify the template helper code.  It's just=
 too
confusing.  I just worked with what was there and genericized is slightly. =
 It
should probably be studied and rewritten.  I don't know if you care to take
that on?  I have no time for it at the moment.

> > BTW, if you decide to really start digging into Barracuda, I would
> certainly
> > consider proposing a vote for committer status.  Barracuda could use so=
me
> more
> > active development.  Let me know if you are interested, for starters.
> >
> I will certainly dig into Barracuda, as it will be part of a major
> project to us here at work. So I will have time to do this, and would be
> willing to help.
> So yes, I would be interested.
>

Excellent.  I'll try to get a vote started within the week.

Jake

> Regards,
>
> Franck
>
>





------------=_1165950777-18037-134
Content-Type: text/plain; name="message-footer.txt"
Content-Disposition: inline; filename="message-footer.txt"
Content-Transfer-Encoding: 8bit



--

Barracuda mailing list

[email protected]

http://www.objectweb.org/wws/lists/projects/barracuda


------------=_1165950777-18037-134--