RE: Additional change to DefaultViewHandler proposal...

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?

Christian

----------------------------------------------
Christian Cryder [[email protected]]
Internet Architect, ATMReports.com
Barracuda - 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