If you’re curious about the technical details, the core of the frontend is a 5 layer cake. I can’t draw a picture of a cake, but I can describe it in words. At the bottom we have the Screen, which is really just used to encapsulate the whole process in one object and provide a standard connection interface to talk back to the Concerto server. On top of the Screen we draw a Template, which right now consists of a huge image background (perhaps it could be HTML-based in the future) and bunch of Positions. Each position represents one block on the screen, you see them in the backend when you’re previewing templates that show where your content will go. Positions have a location to be shown and some styles, but most importantly they have a Field. A field is where the Content ends up getting fetched, rendered, and transitioned into place. They do most of the heavy lifting after the initial HTML scaffolding is setup.
To recap: Screen > Template > Positions > Field > Content.
In Concerto 1 there isn’t really any sort of layered cake in use, it’s much more like a fruitcake. You can kind of see the different bits and pieces if you look really hard, but it’s mainly one big monolithic structure.
What does this mean besides a lot of extra files to manage when you’re working on the frontend? Well for starters it let me refactor the code base to support what we call “mini screens” in about 20 minutes. A mini screen is just that, a small screen that doesn’t take over the entire window. You can see one when you visit http://concerto.rpi.edu right on the homepage, but in V1 that shares a completely different codebase (with an included memory leak for IE users) than the actual screen frontend. Not so in Concerto 2, you can have a lot of screens on the same page without any additional work.