logo       

Re: Case Study: XMLC vs. Velocity: msg#00099

java.enhydra.xmlc

Subject: Re: Case Study: XMLC vs. Velocity

Hi David,

At 08:44 AM 9/17/2003 -0400, you wrote:
On Wednesday 17 September 2003 08:22, Christian Cryder wrote:
> > I wonder if we should try to work on a higher level API over the DOM
> > based approach and try to reduce the high initial learning curve and
> > also the tedious low level DOM manipulation.
>
> Barracuda, my friends! :-)

That was my first thought, but doesn't Barracuda include a lot of "other
stuff" beside HTML generation - event handling,etc.?

Please explain what you mean that Barracuda doesn't handle "event handling". It most certainly does, unless your definition of "event handling" is different than mine.

Barracuda is has:

A component framework
An event handling framework
A form mapping framework

Each of these is built to be able to be used completely separately from the others so you can pick and choose what you want to use. Heck, you could use the form mapping framework with a Jakarta Struts as your presentation framework if you wanted. So, again, either your idea of Barracuda is very skewed and you should do a bit more research, or I don't understand what you mean by "event handling".

Jake

>
> Christian
> ----------------------------------------------
> Christian Cryder
> Internet Architect, ATMReports.com
> Project Chair, BarracudaMVC - http://barracudamvc.org
> ----------------------------------------------
> "Coffee? I could quit anytime, just not today"
>
> > -----Original Message-----
> > From: xmlc-admin@xxxxxxxxxxx [mailto:xmlc-admin@xxxxxxxxxxx]On Behalf Of
> > David Li
> > Sent: Wednesday, September 17, 2003 5:18 AM
> > To: xmlc@xxxxxxxxxxx
> > Subject: Re: Xmlc: Case Study: XMLC vs. Velocity
> >
> >
> > High initial learning curve seems to be the most often cited of the
> > disadvantage of XMLC. I guess the same would apply to other DOM based
> > presentation framework system such as Jivan. I remember someone mention
> > in this list about Sun's updating the J2EE blue print to acknowledge
> > the DOM based approach (can someone provide the link?).
> >
> > I wonder if we should try to work on a higher level API over the DOM
> > based approach and try to reduce the high initial learning curve and
> > also the tedious low level DOM manipulation.
> >
> > David Li
> >
> > On Tuesday, Sep 16, 2003, at 07:51 Asia/Tokyo, Stefan Flick wrote:
> > > It funny to find out that other developers have the same acceptance
> > > problems
> > > with XMLC. The company I worked for started our project about four
> > > years
> > > ago. It was the first web-project and there for we have the free choice
> > > of the technologie. We start with Servlet/JSP but I switched to XMLC in
> > > early 2001. Meanwhile a bunch of other web-related project starts and
> > > guess what - not one of them uses (or reuses) our existing, well tested
> > > XMLC framework. They prefer JSP/Taglib or XSLT because of the
> > > complexity
> > > of DOM navigation and all the arguments you figure out...
> > > ...and run into a lot of problems. As we compare the stability and the
> > > performance of the different web-apps/web-app-technologies we figure
> > > out, that the XMLC way seams to be harder for the developers (in the
> > > beginning), but the result is a high performance and really stable
> > > web-app.
> > > Meanwhile our project becomes a "development platform standard" and new
> > > projects has to follow the XMLC way :)
> >
> > _______________________________________________
> > XMLC mailing list
> > XMLC@xxxxxxxxxxx
> > http://www.enhydra.org/mailman/listinfo.cgi/xmlc
>
> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc

_______________________________________________
XMLC mailing list
XMLC@xxxxxxxxxxx
http://www.enhydra.org/mailman/listinfo.cgi/xmlc


<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise