Your SilverSmith Questions Answered

I’ve been quite taken with the stir that has been created off my recent preview of the SilverSmith framework for SilverStripe. Naturally, a lot of you have questions, many of which I have answers to, while others are still not known. As you may have noticed, it isn’t often that I comment on my own blog posts, so I thought I would take this opportunity to address some of the most commonly asked questions I have received.

When can I get my hands on this thing?

This has literally been, word-for-word, the most common question I’ve received, which shouldn’t be much of a surprise. While I continue to use SilverSmith on many projects of varying degrees of complexity, it is not fit for release at this point for a few reasons. First, there is no validation in place for the YAML, so if a node is out of place or you forget a required field, the result is a completely obscure runtime error that doesn’t suggest anything about your YAML specifically. This can be a huge pain point for users who are new to the syntax, and even as the author of the framework, I have a hard time debugging a lot of the time. If I were to release the project today, I would doubtless be inundated with support requests for obscure errors and I would lose a lot of time proofing everyone’s YAML, which would be time better spent on improving the framework. So SilverSmith will not see the light of day until a good validator is in place.

Secondly, the UI and javascript are just hanging on by a thread. I build this project in the spirit of rapid deployment and agile development, so the goal was to just get something working as fast as possible and worry about the details later. Now that there is some community interest and the word is out, it’s time to give it a more sturdy and usable UI.

So, when can you get your hands on this thing? Well, one of my development partners is working on the design and HTML for the UI as we speak, which will open up the door for me to start improving the codebase and add a validator. A conservative estimate is that we’ll go alpha in 60-90 days.

Is this just another SilverStripe module?

Yes and no. There are two components to the installation — the frontend, which is the part you can see, including the YAML editor, save/build buttons, etc., will be a native SilverStripe module just like anything else. You will drop it into your SilverStripe root, run a build, and you will have access to that interface. The backend, which is where all the magic happens including code writing and template generation, will live remotely as a web service. I’m still in talks with my partners about how exactly this will work — probably with a RESTful API, but suffice it to say it will be secure, and free of charge, at least initially.

Will this or should this be bundled into 3.0?

My reaction to both notions is no. I don’t want to get tangled up in a development stream with the folks in NZ. I think they have plenty to think about with all of the rapid development on SS 3.0, and it’s not appropriate to be introducing an idea that, although highly valuable, is far from being stable and hasn’t had any sort of peer review. What makes SilverStripe great is its openness to community development, and I’m taking that as far as I can with this project.

That said, if they ever come knocking on my door, I won’t leave them out in the cold.

The concept of defining a project with YAML seems conducive to sharing. Will there be a YAML library?

I’ve thought a lot about this, and I definitely see it as high-value item to have in our plans. It would be quick and easy to paste a block of text authored by another developer, and instantly have all of his code. The major advantage of this approach is that code could be easily modified and tailored to a user’s specific needs and distribution would be very streamlined.

Think of these snippets like the PHP counterpart to a theme. Themes are great, especially for those of us who don’t like to design. We get all of the design elements and typography we need, and we just have to massage it to fit our specific client. Imagine that the same way we have themes for specific business sectors or use cases, we also have YAML blueprints, for instance, “Law firm brochure site”, “Simple e-commerce site”, or “Resource library.” These could all be installed into the project generator and tailored very easily in the YAML (or the GUI that will be added soon). Further, distribution would be a snap, because, unlike the module managers we see in WordPress or the hypothetical package manager for SS 3.0, we don’t need a set of instructions or any unpacking tools. All we need to do is read some text off a file on a remote URL. That’s it! No downloading necessary.

The spirit of SilverSmith is about getting developers to a much more advanced starting point. It’s about jumpstarting projects and automating the simple things that cost us time. I think the idea of a shared YAML library has a ton of potential and it opens up SilverStripe to a whole new market.

Do you need translators?

Absolutely. Except for French, my second language. I’ll be seeking out some eager polyglots once we have a final UI ironed out.