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

There is actually an example in the Barracuda tree call BConfig. Basically,
this is a sample app that reuses DOMs / component hierarchies across
multiple requests. What happens is that as a component is bound to the DOM,
that component may be set to visible/invisible; the portion of the DOM would
either show or be hidden accordingly on subsequent renders. The key to
understanding this is to think of a DOM as being mainpulated/rendered
multiple times, rather than simply discarded after the first (and only)
render.

The reason for building this was to demonstrate that it could be done, as it
makes it possible to adopt a lightweight component approach, where you reuse
components across multiple requests; in practice, we find we rarely have a
need to do it - we almost create new DOM / component hierarchies on a per
request basis. That said, I don't really want to lose support for that
functionality at this point as it might impact people who are using it. So
the XMLC renderer needs to support the notion of invisible nodes, or we will
have to keep a copy/extend that functionality in Barracuda.

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
> David Li
> Sent: Tuesday, January 28, 2003 10:38 AM
> To: xmlc@xxxxxxxxxxx
> Subject: Re: Re[2]: Xmlc: Moving XMLC to ObjectWeb's SF
>
>
> Christian,
>
>    Could you give more examples on the reusing of DOM? I have a patch
> sent to me by Chris Webb and the patch will enable creating of multiple
> LazyDOM template. I am not sure if this accomplish the same thing as
> your reusing DOM.
>
> Thanks.
>
> David
>
>
>
> On Wednesday, Jan 29, 2003, at 01:14 Asia/Shanghai, Christian Cryder
> wrote:
>
> >> 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
> >
> > _______________________________________________
> > XMLC mailing list
> > XMLC@xxxxxxxxxxx
> > http://www.enhydra.org/mailman/listinfo.cgi/xmlc
>
> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc