Re: Why does Barracuda choose the way to parse the whole page (*ML) to a doc?

Xue-Feng Yang <[email protected]>
Newsgroups gmane.comp.java.enhydra.barracuda.general
Message-ID <[email protected]>
 --- Jacob Kjome <[email protected]> wrote: > 
> Hi Xue-Feng,
> 
> See comments below...
> 
> 
> I should be a bit more clear on this.  The Barracuda
> *component* model 
> expects a w3c compliant dom.  The event model and
> the forms model are 
> utterly disconnected from the component model (and
> from each 
> other).  Therefore, if you like the event framework,
> then use that and use 
> whatever presentation strategy you like.  If you use
> the Barracuda 
> component model, at least as it stands currently,
> then you are going to 
> deal with w3c dom.  This doesn't prevent you from
> building your own 
> component model.  Use whatever strategy you like. 
> That is the beauty of 
> Barracuda.  It doesn't tie you into any one
> presentation strategy.  There 
> are people that use JSP with Barracuda, although I
> can't fathom why?
> 

Yeah, I may make my own. I am still evaluating some
available frameworks now.

> The basic point is, if you believe that the w3c dom
> is simply a dog in 
> performance, then use something else.
> 
> 
> Well, in a page that contains one dynamic data
> member, utilizing XMLC's 
> LazyDOM won't automatically open all 1,000,000 nodes
> just to modify that 
> one node.  

I think you misunderstand here. It is true that you
can modify LazyDOM without openning other nodes, but
when you get the updated page from LazyDOM, you must
parse all of the nodes. That is painful.

>This is, of course, not the default
> behavior of most w3c 
> compliant dom models.  I think Xerces2 has one as
> well, but I'm unfamiliar 
> with it.  The DOM does have its caveats, but there
> are many people who have 
> used it successfully with reasonable performance. 
> The big draw of the DOM 
> (and XMLC specifically) is allowing for the clean
> separation of *ML 
> developers from the Java developers (and the
> fine-grained control the 
> developer has over the DOM document).  I assume your
> "sqeezing" strategy 
> doesn't give that up, does it?  If it does, then we
> are talking apples and 
> oranges.  Surely there presentation strategies that
> provide for better 
> runtime performance than the dom, but most give up
> the clean separation 
> that the dom provides in order to achieve the better
> performance.  That's a 
> deal breaker for me.
> 
> BTW, do you have working software that implements
> your "squeezing" 
> idea?  

Yes, of course. I am an expert on parsers and
compilers. I wrote some parsers on XML, EDI and Cobol.
I also a Senior Technical Architect on J2EE, and a
professor. I am very interested in to making some good
framework and its related (design/development/testing)
tools.  

>Like I said above, you can use any
> presentation strategy you 
> want.  Barracuda's event model is more than
> compelling on its own.  Use it, 
> discard the rest, and implement a component model
> using your squeezing 
> strategy.  

It is relatively easy to have some beautiful
frameworks. However, it is very difficult to have both
beautiful and good performance. Since much deep
algorithms will be involved in later case.
Unfortunately, most developers don't understand these.
I saw a very good J2EE framework for the financial
industry. The performance of one implementation I saw
was not very good. 

>I'm sure people here would be interested
> in that.  Contributions 
> are always welcome.
> 

It might be a good project for my students.

>
> Jake
> 
> >
>  

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca
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.