RE: Additional change to DefaultViewHandler proposal...

Hi Kirk,

> At the end of the day.
> The biggest problem I have is trying to get them to bite on XMLC.
> Until XMLC becomes more 'mainstream'...we definately need to
> provide for alternatives.

I agree with your sentiment. It seems to me that a lot of folks are leery of
XMLC - IMHO, I don't think this is due to technical issues so much as to the
way Lutris handled things (or failed to handle them). In our case, Barracuda
really doesn't gain a whole lot from XMLC, other than its a really easy way
to get *ML pages loaded as DOM - we really don't benefit much from the
lazydom stuff, or from the ability to have XMLC objects implement marker
interfaces, or from the ability to have setter/getter convenience methods,
etc. That said, I think we should always try to support XMLC (I don't see
any reason why we _couldn't_ unless development there can't keep up.

Where I'd really like to see us go is with a replacement approach -
basically something to load DOMs from various sources, something to
implement some kind of DOM caching strategy (for performance), and then
something to render the DOMs back out to the browsers. Write those pieces,
and we are no longer tied to XMLC. This is definitely on my todo list (Shawn
and I talked about it a bit over Christmas), but realistically its not going
to happen until we get through our current project here - mid to end of the
summer, probably. Now if someone else wants to work on this sooner...I'd
love to offer guidance/pointers.

One of the other benefits of such an approach is that it would allow us to
do is keep up with the Xerces libraries a lot easier.

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 Kirk Daries
  Sent: Thursday, March 06, 2003 2:47 AM
  To: [email protected]
  Subject: RE: [Barracuda] Additional change to DefaultViewHandler
proposal...


  Hi Jake,

  +1 from me.

  Although... I'd still like Barracuda to support multiple presentation
technologies.
  It's easier to sell Barracuda if it supports JSP, XSLT, ~append relevant
technology here~, etc etc
  Alot of developers I've spoken to won't touch Barracuda because they
consider XMLC to be a third party technology/tool
  that can disappear and leave them stranded.

  I for one, would like to see that dream (multiple presentation
technologies) come to fruition....to ease all those doubts...
  Then Barracuda would truly be marketable.

  I've tried in the past to convince various developers of the following:
  The brilliant event model. Event bubbling, etc
  I've gone on and on about code seperation...
  Why one shouldn't 'code' within your JSP pages.
  etc
  etc

  At the end of the day.
  The biggest problem I have is trying to get them to bite on XMLC.
  Until XMLC becomes more 'mainstream'...we definately need to provide for
alternatives.

  Regards
  KD

  Ps.
  Dont' get me wrong. I love XMLC. It's just selling it to other ppl that's
so hard.


    -----Original Message-----
    From: Jacob Kjome [mailto:[email protected]]
    Sent: 06 March 2003 09:09
    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