Please input on new buildtools config file specification

[Maurits Lamers]

Hello all,

As you have heard I have decided to redesign the nodejs build-tools from the ground up.

For the people familiar with the original Garçon port, a few of the architecture changes are

- file/framework/app representation broken away from the devserver representation and the save (build) representation

- except for the file/framework/app representation and some basics, everything is designed to be a plugin (this includes both the dev server as well as saving/building). This will allow people to install extra functionality such as slicing (which has binary dependencies) and/or compass (which requires ruby to work correctly) separately (and outside of the buildtools themselves), but also to adjust the way the build tools eventually write out their files.

- Code is much more SC style (using observers for example).

I decided last week to open up the development, so if you are interested in following or participating, you can find the project at https://github.com/mauritslamers/build-tools.

The reason I am working in a personal repo for the moment is that I didn't want to replace the current sproutcore/build-tools repo (which sort of works) with something that doesn't work at all.

At this point of development I am running into a design decision about the config file API on which I would love your input. 

As already has been discussed, the config file format will be json by default, but can be more like the current garçon configuration if desired. Also discussed is that apps and frameworks should be able to have "inner" configuration files, which enables dependency configuration etc. This will also be possible in the new build tools.

When looking into the current format of the abbot Buildtools in SC master, I found that the current format is a bit confusing from a design perspective (but this might be my lack of understanding of how it was designed, so if you have input on that, I'd love to hear it!).

Abbot puts the configuration of a framework in two places, the first being a Buildfile one directory level above the framework itself and the second a Buildfile inside the framework directory. 

Having configuration files on those levels is something I most certainly want to keep. However, what is configured exactly on which level is a different matter. 

Currently, dependencies seem to be defined not on the framework level, but one level above (see https://github.com/sproutcore/sproutcore/blob/master/Buildfile#L28). Design wise I would have expected frameworks to declare their own dependencies. 

I also see that the syntax used for frameworks and paths differ. For paths "sproutcore:[path]" is used, but for frameworks "sproutcore/datastore". While I think I understand why a difference is made, from the build-tools perspective having just one syntax is much easier, and also allows for more fine grained control. The easiest would be a relative path syntax, such as "sproutcore/frameworks/datastore", also because hardcoding paths in the build tools feels wrong. The downside of course is that if you load extra frameworks (such as experimental) in your app, and we decide to rename the frameworks folder into libraries (or lib), your config files need to be adjusted.

Then there is the additional information about layout (which feels as a misnomer btw).

What I would love to have your input about is: 

- place to define dependencies: My proposal is to move the dependency information to the framework level, and to design a syntax which enables referencing the different libraries/frameworks. One option could be to copy the Java library syntax  ( for example { "ref": "sproutcore.datastore", "dependencies": ["sproutcore.runtime"] } ).

In this way it would also be possible to add framework configuration in say the app level config file.

- use a single syntax for file or framework inclusion: my proposal is to use relative paths, as it can be copied as part of the hash used to create a framework (Framework.create({ path: config.path}); ). Part of the reasoning to use paths is that the buildtools now do not scan folders by a certain name (such as frameworks), as it is not necessary to include photoshop files or other design documentation in the build or devserver environment, and including frameworks you don't want to have included is annoying.

- What to do with the layout/default loading page: as we can no longer use rhtml without writing or including a parser for it, should we use something nodejs based which is similar, or should we go for something else? Currently I have been using a class to generate the HTML (see lib/HtmlFile.js) which generates the HTML using the configured scripts, stylesheets and other information.

Thanks in advance for your ideas!

cheers

Maurits

[Topher Fangio]

Hi Maurits,

Unfortunately, I do not know enough about the build tools to provide a response to your first two questions, however, I do have an opinion about the rhtml issue so I thought I would share.

If we're moving to node, I think we should move to node and get rid of anything ruby-related. I think this would provide a more consistent experience. Particularly, the argument for node-based build tools was that the framework was JavaScript, so the build tools should be as well. I think we should stick with that decision when we come across other, similar issues.

Anyway, that's my two cents. Hope it helps :-)

--

Topher Fangio

System Architect
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

--
You received this message because you are subscribed to the Google Groups "SproutCore Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sproutcore-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Maurits Lamers]

Topher,

Thanks for your feedback! 

Do you also have some idea or opinios about what kind of thing should replace the rhtml? Should it be something similar, like an html file that can be parsed, or something more programmable, like a kind of SC.View like object, with a render function?

cheers

Maurits

[Topher Fangio]

Personally, I like the HTML part of it, so I would suggest something similar. I've used EJS and found it really easy to use because it's just plain JavaScript. However, there are a lot of other template engines we could consider. Should we make a list and get some feedback on it?

One more about the HTML file though is this: unless you know what you're doing and and know where to find it, it's kinda hard to add that file to your own project so that you can override things. It would be cool if the new tools had a command to generate it for you :-)

Sent from my iPhone