Re: BImage ?

This is a multi-part message in MIME format...

------------=_1166001828-3131-31
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,


Jacob Kjome a =E9crit :
> I had considered using a method that each component would implement, but =
went
> with the marker interface because it's a burden to force components that =
aren't
> something to declare that they aren't that something.  It's much less bur=
densome
> to simply declare that you are something and not bother anyone else that =
doesn't
> care.
Well, the way I do it is by adding two methods in BContainer interface=20
(isCompound, setCompound) and implementing it in AbstractBComponent,=20
defaulting to false.
So, as far as each component extends BComponent (or even=20
AbstractBComponent, but there are places in Barracuda where BComponent=20
is assumed...), then it doesn't have to care about it.
Then the other changes are only in :
- BList and TemplateHelper, to call isCompound instead of checking if=20
BCompoundComponent is implemented
- BList, BTemplate and BTable, to override AbstractBComponent value of=20
isCompound and set it to true.

Just doing that doesn't break anything (at least, the test suite still=20
passes).
>   However, it looks as this is more dynamic and we might have to provide 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 wher=
e no
> one is forced to call setCompound(true) externally.  Maybe this gets set
> internal to addChild()?
>=20=20=20
Right now, I can't put it in addChild, because you can add children=20
without actually making a component compound... That is what=20
TemplateHelper does to parse embedded directives...
So I added a addCompoundChild method that set compound status and calls=20
addChild.
This is not very satisfying although. But to go further, I would have to=20
"clean up" TemplateHelper, and I am not sure it is even possible (after=20
all, what is done is quite complicated)...
>=20=20=20
>> 2) I had to implement createDefaultNode in the renderers of the
>> components I used, and to recursively call createDefaultNode on every ch=
ild.
>>
>>=20=20=20=20=20
>
> Interesting.  Should this be default behavior so no one has to override t=
he
> method?
>=20=20=20
I think so, but then you would have to split the method, as only the=20
final BComponent knows what type of node it would rather render into.
So one could imagine a default implementation of createDefaultNode that=20
implement recursivity, and ask the actual component what king of node it=20
wants.

The other way is to make sure each component that overrides the method=20
calls it on children... Right now, most components don't implement=20
createDefaultNode.
>=20=20=20
>> 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.
>>
>>=20=20=20=20=20
>
> Hmm... "children of the right nodes".  I suppose the override might be
> necessary?
>=20=20=20
Yep. See before... But it could be a good idea to separate the two=20
concerns : create a default node and tell what type of node would fit...
> If everything is nestable, then the interface is redundant, so we'd just =
provide
> BComponent with the necessary functionality and every other component wil=
l just
> pick it up.  We need to be concerned about backward compatibility as well.
>
> Of course, the whole BCompoundComponent and BNestableComponent stuff is j=
ust a
> workaround for rendering code that probably could be modified in a way wh=
ere 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 c=
ode.
> This is why I didn't attempt to modify the template helper code.  It's ju=
st 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 ta=
ke
> that on?  I have no time for it at the moment.
>=20=20=20
I will dig into it, but this is a big piece... I'll keep you informed.
>
> Excellent.  I'll try to get a vote started within the week.
>
>=20=20=20
Great.


Regards,
Franck


------------=_1166001828-3131-31
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


------------=_1166001828-3131-31--