RE: Additional change to DefaultViewHandler proposal...

Hi Christian,

See comments below...

At 04:03 PM 3/6/2003 -0500, you wrote:
>I replied directly to Jake and Diez already on this, but I figured I would 
>send my response here as well for others to comment on too:
>
>Ok, I've just looked at the code in DevaultViewHandler...it seems to me 
>that the OutputOptions stuff is actually specific to the DOMWriter, so we 
>shouldn't actually need an additional method in DefaultViewHandler, you 
>would just override getDOMWriter() to return an instance of 
>DefaultDOMWriter that uses your specific options.
>
>That make sense? Or am I missing something?

Actually, I think, you might be missing something (unless I still am?).  If 
you look at DefaultDOMWriter, there is no way to set OutputOptions other 
than via the various write() methods.  DefaultDOMWriter#write() is called 
inside handleViewEvent().  So, if we don't add getOutputOptions() to 
DefaultViewHandler, we'll at least have to modify DefaultDOMWriter() to 
allow for setting custom OutputOptions outside the write() methods.  Isn't 
that right?

Here is an example of how OutputOptions are set...

//get the output options
OutputOptions oo = 
DefaultDOMWriter.getDefaultOutputOptions(theXMLCDocument.getOwnerDocument());

//add doctype - need to do here because XMLC can't yet add the one embedded 
in the html to the DOM
oo.setOmitDocType(false);
oo.setPublicId("-//W3C//DTD HTML 4.01//EN");
oo.setSystemId("http://www.w3.org/TR/html401/strict.dtd");

//now render the DOM
new DefaultDOMWriter().write(theXMLCDocument, context.getResponse(), oo);


So, how do we want to approach this?

One thing to think about is the issue of moving modifications that we made 
to the util.dom.* and util.dom.io.* back into XMLC.  Or, since it seems 
like Richard and David have already made a number of updates since we 
pulled these classes out into Barracuda, maybe we should see if they work 
for us well enough.  I think stuff like the "visdom" in HTMLFormatter and 
XMLFormatter have already been moved into XMLC for Barraucda's specific 
benefit.  And synchronizing with the XMLC stuff would fix the following 
issue...

<quote name="Zhihai Li">
Thank you for your reply and recommendation.
But  the problem here is we didn't use Barracuda Event Model part, we only 
utilize Barracuda Components Models with XMLC for our view.

And If  some of the dom.* and dom.io.* classes  are XMLC specific , may be 
the community  can make it a utility package as the integration with XMLC. 
Since Barracuda Component Model is one of the best tool to control the XMLC 
DOM Rending.

For example, If BaseDOMFormatter can recognize the XMLC DomumentInfo , Even 
we only use  Barracuda Components Models , the BaseDOMFormatter  will help 
us to do the URLRewritting . and DefaultDOMWriter can take different 
OutputOptions and  help us to rendering the DOM tree.
</quote>

Anyway, a few things to think about there.  Let me know your thoughts.

Jake


>Christian
>
>----------------------------------------------
>Christian Cryder [[email protected]]
>Internet Architect, ATMReports.com
>Barracuda - <http://barracudamvc.org/>http://barracudamvc.org
>----------------------------------------------
>"Coffee? I could quit anytime, just not today"
>-----Original Message-----
>From: [email protected] 
>[mailto:[email protected]]On Behalf Of Jacob Kjome
>Sent: Thursday, March 06, 2003 2:09 AM
>To: [email protected]
>Subject: [Barracuda] Additional change to DefaultViewHandler proposal...
>
>
>Hi everyone,
>
>I was wondering about whether we might want to add some functionality to 
>DefaultViewHandler as long as we are modifying things there.   What I 
>would like to see is a way to set OutputOptions and for the code in 
>handleViewEvent() to pick that up when using the DOMWriter to write out 
>the response.
>
>Currently, there is....
>public DOMWriter getDOMWriter()
>
>I propose adding...
>public OutputOptions getOutputOptions()
>
>Then, the code in handleViewEvent() which does this...
>this.getDOMWriter().write(doc, vec.getResponse());
>
>would, instead, do this...
>this.getDOMWriter().write(doc, vec.getResponse(), this.getOutputOptions());
>
>
>This allows us to avoid overriding handleViewEvent(), which has a number 
>of intricacies, simply to add custom OutputOptions.
>
>This would be immensely helpful in the context of Diez' Pages model and 
>other areas, I'm sure.   It shouldn't cause any grief because no ones app 
>would break with this change since it only adds a new method which is 
>really only used internally by the implemented handleViewEvent().  And it 
>doesn't take away anything.
>
>
>Any objections to something like this?  One might argue that this creates 
>a dependency upon XMLC.  Barracuda is supposed to allow the use of any DOM 
>tree, not just XMLC.  However, in practice, I don't know if anyone out 
>there uses Barracuda without using XMLC.  Plus, I think there actually are 
>a few places in the code that already create dependencies on XMLC.  So, 
>I'm not sure this is a big problem.  Thoughts?
>
>Jake
>
>
>At 02:58 PM 3/5/2003 -0500, you wrote:
>>Can people do a quick check on their Barracuda related code for me...I'd
>>like you to search for 'preCompRender' and 'postCompRender'.
>>
>>Right now the signatures look like this:
>>
>>     public void preCompRender(BComponent root, ViewContext vc) {
>>     public void postCompRender(BComponent root, ViewContext vc) {
>>
>>I'd like to change it to be
>>
>>     public void preCompRender(BComponent root) {
>>     public void postCompRender(BComponent root) {
>>
>>This would require everyone to do a search and replace on the code above (if
>>they have it implemented...I'm guessing most people don't). Then, if those
>>methods were using a reference to ViewContext vc, you'd have to call the
>>(soon to be added) getViewContext() method.
>>
>>Would this be a hardship for anyone?
>>
>>Let me know as soon as possible...
>>
>>Thanks,
>>Christian
>>
>>----------------------------------------------
>>Christian Cryder [[email protected]]
>>Internet Architect, ATMReports.com
>>Barracuda - http://barracudamvc.org
>>----------------------------------------------
>>"Coffee? I could quit anytime, just not today"
>>
>>_______________________________________________
>>Barracuda mailing list
>>[email protected]
>>http://barracudamvc.org/lists/listinfo/barracuda