commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Beard <jbea...@cs.mcgill.ca>
Subject [scxml-js][all] seeking guidance on layout of XSLT-based project
Date Sat, 12 Jun 2010 02:56:38 GMT
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.

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.

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/


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