RE: Case Study: XMLC vs. Velocity

Hi David,

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

Yes, it does, but its designed to be used in layers, so you can pick and
choose which parts you want.

Barracuda has 4 main 'layers':

a) event model - for flow control really, getting client requests to the
appropriate spot in your code that is supposed to handle them

b) forms model - for making it easy to work with client http parameters (ie.
what they submitted along with the request/form) by mapping those parms to
first class java objects and performing validation on them

c) component model - for making it easy to actually manipulate the DOM as
you are preparing to render the page. This is where you can use the
Barracuda components: BAction, BLink, BInput, BToggleButton, BText, BSelect,
BList, BScript (and the easiest way to do this is with a master BTemplate
component driving everything). There is also a BTable component, but in
practice it rarely gets used anymore since the BTemplate approach pretty
much makes it obsolete.

Using the BTemplate approach, pretty much all you have to do is embed a few
very simple directives in your markup (and yes, this is the part that XMLC
purists will object to - the point here, however, is that BTemplate is just
another component; you don't have to use it if you don't want to...the other
components continue to work just fine if you want to manually bind them to
DOM nodes). If you can live with using directives (Get_Data, Set_Attr, and
Iterate), then pretty much all you have to do is implement a model that
processes directive keys...for instance:

    public Object getItem(String key) {

        //simple text example
        if (key.equals(ISO_NAME)) ||
            key.equals(ISO_LOCATION) {
            return rptmap.get(key);

        //formatted text example
        } else if (key.equals(ISO_AMT)) {
            BigDecimal bd = (BigDecimal) rptmap.get(key);
            return (bd!=null ? nfAmt.format(bd) : "???");

        //BLink example (works for links, buttons, inputs, etc)
        } else if (key.equals(ISO_LINK)) {
            BLink blink = new BLink(null, new GetBusinessDetail());
            blink.setParam(BusinessMap.BUSINESS_ID, rptmap.get(ISO_ID));
            return blink;

        //if the page has multiple pages, insert the "page links" DOM,
        //which in turn has directives for FIRST_LINK, etc
        } else if (key.equals(PAGE_LINKS)) {
            try {
                DOMLoader dl = DefaultDOMLoader.getGlobalInstance()
                Document page = dl.getDOM(CommonHTML.class);
                //return page.getElementById(NODE_ID);
                return
vc.getElementFactory().getDocument().importNode(page.getElementById(NODE_ID)
, true);
            } catch(IOException e) {
                return "Unexpected Error!";
            }

        //get a link to another page
        } else if (key.equals(FIRST_LINK)) {
            BLink blink = new BLink(null, "");
            blink.setParam(PageManager.CMD_SET_PAGE, PageManager.VAL_FIRST);
            if (!pman.hasPrevious()) blink.setEnabled(false);
            return blink;

        }

The point in all this is that Barracuda makes it _very_ simple to work with
the DOM. The only place I ever deal with DOM specific code any more is when
I have to import a chunk in from a common location (ie. for page liks or
something like that), and places like these are actually abstracted out into
common models, so there's really only a handful if instances in our app.
Everywhere else, its just providing data/components in response to
directives - and the structure of the markup is really irrelevant (and can
change without breaking the app).

As an example of this, we can create 2 different chunks of markup for a
report - one for HTML, one for XML (which we can then convert into a .csv
format for Excel, for instance). The code to handle both of these things -
each of which has _significantly different structure_ is identical: its the
same model, which handles the same set of directives. The only difference is
that we choose a different template to process up front.

Ok, last "layer" within Barracuda...

d) localization - basically, its real easy to create localized variants of
your primary mockup, while still retaining only one mockup. You take the
master mockup, then you create a set of properties files that match the
primary text to different locale texts. Barracuda sees this at compile time,
generates multiple mockups (one for each locale, all derived from teh
primary mockup, but with the localized text substituted in), and then
compiles each as a separate XMLC object... FooHTML, FooHTML_de, FooHTML_es,
etc. Then, all you do in your code is say "use FooHTML" and the dom loader
is smart enough to a) look at the clients locale, b) find the closest
matching template and c) use that instead. Its all transparent to your code
though. There's and excellent example of how this works on the Barracuda
website.

So at any rate...this has turned into a rather long email, but that's the
basic overview of Barracuda. Its split into layers so you are free to pick
and choose what you want to use - as little or as much of each. The point of
my writing is just to say that if you are looking for a simpler way to work
with the DOM, while still retaining the benefits of XMLC, I think we've
already made a pretty hefty start on that task! (But hey...you're free to
roll another solution ;-)

Ok, I've gotta get back to work...

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 Corbin
> Sent: Wednesday, September 17, 2003 8:45 AM
> To: xmlc@xxxxxxxxxxx; Christian Cryder
> Subject: Re: Xmlc: Case Study: XMLC vs. Velocity
>
>
> 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.?
>
> >
> > 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