commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <rahul.akol...@gmail.com>
Subject Re: [scxml-js][all] seeking guidance on layout of XSLT-based project
Date Sun, 13 Jun 2010 00:17:52 GMT
On Fri, Jun 11, 2010 at 10:56 PM, Jacob Beard <jbeard4@cs.mcgill.ca> wrote:
> Hi,
>
> Over the last two weeks, I've done some major refactoring to the
> scxml-js project. Primarily, I've moved some code around to make the
> architectural components more pure, and I've change the primary
> implementation language from JavaScript and E4X to XSLT. I think it
> would be useful to resume the dialog about how the scxml-js project
> layout should be structured.
>
> Right now, there are three main components:
> * a front-end which is responsible for accepting compiler options and
> SCXML documents, and invoking the middle tier and back-end components
> * a middle tier, which implements the main compiler logic, and is
> responsible for generating an intermediate representation (IR) which
> is easy to generate code from
> * various back-ends, which accept the IR and generate executable code
> in a particular programming language.
>
> There are two languages currently used in implementation of scxml-js:
> * The middle tier and JavaScript back-end are implemented entirely in XSLT.
> * The front-end is currently implemented in JavaScript, targeting
> Rhino. This is a very thin layer, though, and could be implemented in
> any language, from bash to Java. However, a JavaScript front-end will
> be needed when targeting the browser environment, so it might just
> make sense to maintain only one front-end, and have it be written in
> JavaScript.
>
> The scxml-js build system is still written in JavaScript, targeting Rhino.
>
> I'm now trying to determine how a multi-language, but primarily
> xslt-based project could best be structured. In particular, it's still
> unclear to me whether Maven would be able to play useful role in this
> project.
>
<snip/>

Yes, unclear from a build and test point of view. Though at the least,
Maven will be useful for:

(a) Creating and deploying a website with the Commons look and feel
(b) If and when any of the code is ready for a release, it will help
with the release mechanics (creation of distros, staging etc.)

I intend to add simple websites for the GSoC projects soon (so there
will be a Maven POM in place for the site, and we can see if that can
evolve the Maven build into something more useful over time).


> I'm currently only aware of one other project where the primary
> implementation language is XSLT, and that's Docbook:
> https://svn.apache.org/repos/asf/commons/sandbox/gsoc/2010/scxml-js/trunk/
>
> It's difficult to understand at a glance out how Docbook is
> structured, however.
>
<snap/>

You've probably pasted the scxml-js trunk URL above in error. In any
case, another project that has an XSLT impl, is meant for execution in
web browsers and implements a W3C spec is XSLTForms:

  http://www.agencexml.com/xsltforms

Given the similarities, might be useful to look at it.


> For right now, I'd like to propose that I keep the project structured
> the same as it is now (see
> https://svn.apache.org/repos/asf/commons/sandbox/gsoc/2010/scxml-js/trunk/),
> but add the following directories to store the xslt middle tier and
> back-end:
>
> src/
>        xslt/
>                ir-compiler/
>
>                backends/
>                        js/
>
<snip/>

Seems reasonable at the moment (I see you've checked in code along these lines).

-Rahul


> If anyone has any ideas about this, I'd greatly appreciate it if you
> could let me know. Thanks,
>
> Jake
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message