09.03
I have upgraded the blog to run the alpha version of our next version, 6.1.2. This version is a big rewrite of the internals of isite.
Before the index.xsp main page was responsible for everything, parsing urls, and rendering responses. This meant that the url-scheme was hardcoded, either /* or /artikler/* (with some exceptions for /tjenester og /organisasjon). It also meant that there was only one way to respond with data, namely html.
In this release, we are splitting the code up into several smaller pieces.
- A url-router. This takes an incoming url and match agains a list of registered patterns, before calling a
- Controller. These are responsible for getting data, and showing them into a
- View. The view looks at the Accept header (or url-config) to see what content type is accepted, and deliver this trough
- Renderers. For now we are supporting Html and Json renderers, but it's easy to add more renderers, for example xml and pdf.
Renderers are also used to render redirections, and css and js.
What this means in "real life" is that we can split up different url's into different controllers:
/ -> Frontpage.index()
/{page} -> Page.index()
/id/{page} -> Page.id()
We can also send config paramters with the patterns, for example:
/stuff -> Page.index(page:'some-stuff', language: 'no', type:'text/xml')
A controller is a class written in Groovy. You can store these in any external jar-file, and easilly include these by referring them in the config. The system will dynamically load them. A controller must inherit from the base Controller class, and any method must return a void.
package no.wpc.isite.controllers
import no.wpc.isite.mvc.*;
class Hello extends Controller{
def index() {
fields["hello"] = "world"
}
}
Above is a simple example implementing a HelloWorld controller. To use this, we just have to set up a url to map to it:
/any-page -> Hello.index()
To connect it to a view, we now have several ways of doing this. For "standard" article types, you can look either in the article itself, or if not found, it will look for the standard site template. A second option is to provide a parameter with the router setup, template: 'my-template'. This will override any of the other methods. For applications, it makes sens to let the framework select a template. By default, it will look in the view.Hello folder, and it will look for a file named index.ftl. If you have specified that you wanted Json, it would have simply returned the "fields" map with its values.
I think this really changes the way iSite works, and makes it a lot easier to now start implementing applications on top of the framework. Stay tuned.