On Fri, Jun 11, 2010 at 10:56 PM, Jacob Beard <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
