iBATIS.js

[Ted Husted <hu...@apache.org>]

The last few months, I've been working primarily in JavaScript,
hooking up an AJAX frontend to the database facade we use on the
back-end. Behind the facade, we have a business application framework
that utilizes iBATIS, Commons Chain, and Spring, with JSON-RPC as
glueware between the backend and frontend. (We're working in C#, but
the Java versions would work just as well.)

I have an itch to convert our backend framework to JavaScript,
probably by porting the functionality to JScript and/or Rhino. I'm in
crunch mode for a release right now, but after this release ships, my
team will be on hiatus over the summer, giving me the chance to work
on porting the backend framework.

My itch is to merge the utility of these three libraries (iBATIS,
Spring, Chain) into a single coherent API, so that we're not flipping
between configurations. One approach might be to port iBATIS first,
and try to keep it as a distinct entity that we could host here. The
rest of what I want to do might be able to extend from that base.

A tipping point would be whether anyone hereabouts would be interested
in an iBATIS.js for JScript and/or Rhino, so this is me asking :)

-Ted.

Re: iBATIS.js

[Ted Husted <hu...@apache.org>]

That sounds quite interesting, Clinton. I'll look forward to it.

In the framework we use now ("Anvil"), the frontend calls into a
business facade (aka a set of services), that invoke a command, which
may actually be a chain of commands. Some of the commands delegate
directly to an iBATIS mapping, others don't touch iBATIS, and several
will retrieve the data and massage it before passing it back. The
commands pass around a context, and each command will place its
outcome into the context under its own name. When the context is
passed back, it may contain several datasets. A common use case for
multiple datasets is populating several select controls. A set of
"controller" commands also handle server-side validation and
formatting for us.

iBATIS is a key component, and our lowest-level component, but it is
only one component. Right now, we're using three layers of
configuration, which I would like to reduce to one layer, preferably
in JavaScript object-literal notation (JSON).

We've been using the framework in production for over a year, and this
is that third major release that uses it. To cope with Ajax, we
swapped in a JSON-RPC facade (via Jayrock), and the rest remained the
same. But, I'd like to reduce the churn needed to program the
framework by flattening the configuration.

-Ted.

On 6/11/07, Clinton Begin <cl...@gmail.com> wrote:
> LOL, dude, I've been doing iBATIS Javascript demos at my last few
> conferences.
>
> I used a bridge approach.  A generic servlet that acts as a gateway to
> iBATIS.  So you write SQL Map files and config as you normally would.  Then
> set up the gateway servlet.  Done.  No Java code.
>
> You can then call mapped statements by making typical XHR requests via your
> favourite framework (Prototype in my case).  You send url encoded paramters
> (GET or POST) to make a request, and get XML back.  I did a little tweaking
> within the servlet to merge the XML results into a single document (instead
> of a list of documents).
>
> But it actually works very well.  It's not production ready, and a
> JavaScript API mirroring the Java interface would be awesome and easy to do.
>  JSON support would also be inevitable and also easy.
>
> I'll find somewhere to post it this evening for peer review.

Re: iBATIS.js

[Clinton Begin <cl...@gmail.com>]

LOL, dude, I've been doing iBATIS Javascript demos at my last few
conferences.

I used a bridge approach.  A generic servlet that acts as a gateway to
iBATIS.  So you write SQL Map files and config as you normally would.  Then
set up the gateway servlet.  Done.  No Java code.

You can then call mapped statements by making typical XHR requests via your
favourite framework (Prototype in my case).  You send url encoded paramters
(GET or POST) to make a request, and get XML back.  I did a little tweaking
within the servlet to merge the XML results into a single document (instead
of a list of documents).

But it actually works very well.  It's not production ready, and a
JavaScript API mirroring the Java interface would be awesome and easy to
do.  JSON support would also be inevitable and also easy.

I'll find somewhere to post it this evening for peer review.

Clinton

On 6/11/07, Ted Husted <hu...@apache.org> wrote:
>
> The last few months, I've been working primarily in JavaScript,
> hooking up an AJAX frontend to the database facade we use on the
> back-end. Behind the facade, we have a business application framework
> that utilizes iBATIS, Commons Chain, and Spring, with JSON-RPC as
> glueware between the backend and frontend. (We're working in C#, but
> the Java versions would work just as well.)
>
> I have an itch to convert our backend framework to JavaScript,
> probably by porting the functionality to JScript and/or Rhino. I'm in
> crunch mode for a release right now, but after this release ships, my
> team will be on hiatus over the summer, giving me the chance to work
> on porting the backend framework.
>
> My itch is to merge the utility of these three libraries (iBATIS,
> Spring, Chain) into a single coherent API, so that we're not flipping
> between configurations. One approach might be to port iBATIS first,
> and try to keep it as a distinct entity that we could host here. The
> rest of what I want to do might be able to extend from that base.
>
> A tipping point would be whether anyone hereabouts would be interested
> in an iBATIS.js for JScript and/or Rhino, so this is me asking :)
>
> -Ted.
>