RE: Re[2]: Moving XMLC to ObjectWeb's SF

> Hmmmm. I'm not really sure if I want to do this, as node
> visibility is pretty much Barracuda specific - in most
> other XMLC applications, you'd simply delete the node from
> the DOM if it is not supposed to show up in the rendered
> document. On the other hand, I don't see how implementing this
> feature would hurt in any way.

Right. It is Barracuda specific. The problem is, Barracuda needs to support
the notion of reusing DOMs, which means rather than removing items from the
DOM, we have to have a way to flag them as invisible (so that we can set
them back to visible later). When we first did this, trying to actually
remove nodes and then put them back in after render proved pretty
cumbersome. So...that's the rationale (for better or worse ;-)

Like you say, though, implementing this probably wouldn't hurt anyone else
(unless someone just happened to start setting Node attributes to
'visdom="false"'...)

Christian

----------------------------------------------
Christian Cryder [christianc@xxxxxxxxxxxxxx]
Internet Architect, ATMReports.com
Barracuda - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"

> -----Original Message-----
> From: xmlc-admin@xxxxxxxxxxx [mailto:xmlc-admin@xxxxxxxxxxx]On Behalf Of
> Richard Kunze
> Sent: Tuesday, January 28, 2003 8:54 AM
> To: xmlc@xxxxxxxxxxx
> Subject: Re: Re[2]: Xmlc: Moving XMLC to ObjectWeb's SF
>
>
> Hi Christian,
>
> On Tuesday 28 January 2003 16:25, Christian Cryder wrote:
> > Barracuda includes its own copy of the XMLC io package
> > (org.enhydra.barracuda.core.util.dom.io). We did this waaaaay
> back because
> > Barracuda needed to extend the default rendering mechanism very
> slightly -
> > basically, we need the ability to flag a node as "not visible"
> and have the
> > renderer skip it. If you check out the latest Barracuda from cvs
> > (http://barracudamvc.org/Barracuda/docs/cvs.html), and search the above
> > package for "//csc" you will see everything that we touched there; even
> > though there are only a couple of classes that actually got modified, I
> > think we had to port the whole package because of variable protection
> > issues.
>
> I'll have a look at it, although I can't manage this right away.
> I guess it's
> probably best to integrate this into XMLC (no need to duplicate
> the effort)
> or at least make it easier to extend (provide public/protected
> hooks to the
> necessary information).
>
> > As mentioned above, this package could be eliminated entirely from
> > Barracuda, provided the changes described above (node
> visibility) could be
> > rolled back into XMLC.
>
> Hmmmm. I'm not really sure if I want to do this, as node
> visibility is pretty
> much Barracuda specific - in most other XMLC applications, you'd simply
> delete the node from the DOM if it is not supposed to show up in
> the rendered
> document. On the other hand, I don't see how implementing this
> feature would
> hurt in any way.
>
> So, what's the general opinion on this?
>
> Bye,
>
> Richard
> --
> Richard Kunze
>
> [ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
> Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1
> http://www.tivano.de, kunze@xxxxxxxxx
>
>
> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc