RE: basic question..

Thanks for you quick answer.
 
So let me just ensure I understand then.
 
The role of the view event handler is to interact with the Business
model to access or derive data required to populate the Component model
with the relevant data required to render then view.
 
Am I right in making this distinction between the business model (which
is what I have been thinking of as the model) and the Component model?
 
Cheers,
 
Pete

________________________________

From: Christian Cryder [mailto:[email protected]] 
Sent: Wednesday, 6 April 2005 5:37 PM
To: [email protected]
Subject: Re: [barracuda] basic question..


[email protected] wrote: 

	Firstly, let me apologise for posting such a basic question
here, but since there isn't a users list it seems the only option.
	  

Hi Peter - no need to apologize. This is the only list, so you are
asking in the right place. Welcome! :-)


	As far as I can tell in the examples, every time we handle a
view event, we instantiate a new model object. Am I correct or have I
overlooked something?
	
	Assuming this is the case, what sort of performance impact
should I expect for a high traffic application?
	  


Well, with any event (control or view), you have to provide an
_instance_ of the event handler. This means you can write code within
those handlers that doesn't have to worry about being threadsafe (as
long as you aren't accessing static or class variables). That also keeps
the "weight" (footprint) of the webapp very light - basically, the only
thing that sits in memory are factories to instantiate handlers. As
events come in, the factories (which are threadsafe) spawn instances of
handler objects to handle the requests. When the request is complete,
those objects can be gc'd.

SO...within a particular handler (ie. a view handler), you typically
instantiate a component (ie. BTemplate component to process the page),
attach models to that component and then let the sucker render.
Typically then, each event fired by a user request will end up getting
handled by components/models that are their own objects.

Now I say typically because that's the easiest way to do it, and that's
the way most of us probably go about things. But Barracuda does not
require you to do that - you can easily have a "shared model" or a
"model pool" - the only thing is, if you do this you need to take
appropriate measures to make sure those shared objects are threadsafe;
as long as every request has its own instances of the models then you
don't have to worry about that.

So the bottom line is - the framework will let you do it however you
want to.

Regarding performance, I don't think you're going to run into problems
(at least not any more significant than any other web framework). I
don't know what kind of traffic you need to deal with, but you'll
obviously want to do some initial testing to make sure it meets your
requirements (and if you run into problems, please let us know about
them - I'd be very surprised if there are any fundamental scalability
problems with the framework)

In terms of performance, I don't think you are going to get nailed by
instantiating individual copies of models (unless those models are
extremely expensive to create, or have a very large footprint).

In our experience, performance issues hinge around the DOM - basically,
by using a DOM based template approach you end up having to parse the
"template" a couple of times (which is obviously going to be slightly
slower than something like Struts which is just reading the file and
processing it as text). But this doesn't seem to be a huge hit in our
experience (certainly nowhere near those approaches that use XSL
transformations to convert from DOM to final output).

The second area is more significant - because the DOM has to stay in
memory before it is rendered, if you have a very large page (say 30000
rows of data), you are going to find your server running out of memory
(of course, you will also find your client browsers barfing too on pages
this large - its a factor of the DOM, not Barracuda per se).
Fortunately, we have ways around this limitation, at least on the server
side. Basically, you can use a BlockIterator component, which processes
templates in chunks - and each chunk (corresponding to a row or block of
data) will get parsed, processed w/ a BTemplate, and then rendered back
to the browser immediately. So we use this approach for all of our
reports where we could be generating thousands of rows of data. If you
get to the point of needing some examples here, holler.



	Perhaps it's because I have never done any swing development,
but my understanding of the 'model' in MVC was more along the lines of
the business model which has a life seperate from the user interface. In
this case, when I look at the DiscRack app, I'm confused about the way
the actually objects 'contained' in the model are retrieved within the
event handler which then instantiates the model and passes in these
objects.
	  

Part of the problem with the term 'Model' in webappland is that it
generally means something completely different than what it means in
client-server land (like Struts).

Here are two links that may be helpful:
http://barracudamvc.org/Barracuda/docs/barracuda_vs_struts.html#CC_Flow_
MVC
http://barracudamvc.org/Barracuda/docs/comp/mvc.html

The key point to realize is that Barracuda provides both Model 2 "flow
control model" (event layer) and Swinglike MVC "component models"
(component layers). I'm not aware of any other framework that really
makes this distinction (but its been a while since I've looked).



	I'm fairly certain that I'm right in saying that I could have a
seperate model class which would provide the facility for the event
class to specify the 'query' details without actually ever handling the
data objects (I'm thinking of using Hibernate in this context). This
would seem to me to give a better seperation of M from VC.
	  

In regard to this last question, one of the biggest benefits of
Barracuda is that it is cleanly layered. So you can use as much or as
little of it as you desire. This makes it relatively straightforward to
integrate with other technologies (provided they are actually layered
well enough themselves).

Thanks for checking out the framework - please feel free to holler if
you have further questions.

Christian


________________________________

Christian Cryder
Internet Architect, ATMReports.com	
________________________________

"Coffee? I could quit anytime, just not today"
http://seelifedifferently.blogspot.com
<http://seelifedifferently.blogspot.com>