How we are using Barracuda - [was - Additional change to DefaultViewHandler proposal...]

"James Carnegie" <[email protected]>
Newsgroups gmane.comp.java.enhydra.barracuda.general
Message-ID <002701c2e48f$fbdac530$139dbdc0@somnus>
Hi Christian et al,
 
A few words on how we are using Barracuda outside the web paradigm
then...
 
We are working on our new Prestel screen scraping technology (urgh I
know) which exposes an xml interface (often consumed by our Barracuda
web apps :) ). Barracuda provides a robust event framework that fits
brilliantly into the request/response nature of our design. When the
system receives an xml request, a Barracuda event is fired. The handler
for that event fires a response event that outputs a character onto the
Prestel screen. When something happens on the Prestel screen as a
response to a user request, another request event is fired. The handler
for this event will fire a response event whose handler will generate an
xml response to the user. Hence, there are 2 request/response cycles in
our system for each user request/response cycle. 
 
So we are not using much of Barracuda, but the parts we are using are
serving us well.
 
James.
 
P.S. The concept of Exceptional and Polymorphic Events is so useful in
our system that it also deserves a mention. :)

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Christian Cryder
Sent: 06 March 2003 21:12
To: [email protected]
Subject: RE: [Barracuda] Additional change to DefaultViewHandler
proposal...


Hi James,
 
Hey, this is great. I'd love to hear more about what you're doing (how
you're using Barracuda), if you can share it with us!
 
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 James Carnegie
Sent: Thursday, March 06, 2003 4:34 AM
To: [email protected]
Subject: RE: [Barracuda] Additional change to DefaultViewHandler
proposal...


Hi Jake,
 
We are using the Barracuda Event Model for something unrelated to HTTP
and HTML. I don't suppose dependency of the DOM related stuff on XMLC
would be a problem for us since we don't even use those classes. Just
thought everyone might be interested to know that we are using Barracuda
in a different context.
 
regards,
James.
 

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Jacob Kjome
Sent: 06 March 2003 07: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 <http://barracudamvc.org/> 
----------------------------------------------
"Coffee? I could quit anytime, just not today"

_______________________________________________
Barracuda mailing list
[email protected]
http://barracudamvc.org/lists/listinfo/barracuda
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.