A while ago I wrote an entry on architectures and the MVC design pattern and announced the release of a very basic architecture for ColdFusion web applications. A reason for this is that I found a lot of people (customers, fellow developers and web designers) still don’t care about the architecture of an application and tend to use what I call “page scripting” – which means taking an HTML page and adding some queries, CFOUTPUTs and some other CF stuff to it.Well – that’s neither forbidden nor bad at all – it does well if you write a guestbook for your webpage, maybe it does well if you develop a smaller business application on your own. But it probably will put you in trouble when dealing with large-scale apps or team-development. You might be ready for a framework like Fusebox or Mach II then.
An often uprising and understandable issue with these frameworks is their complexity. Like always in the world, using a framework is a trade-off between the ease-of-use of a language and aspects of scalability, portability, reuse and maintaining a web application. If you’re really heading towards the league of large-scaled applications, I strongly recommend using a framework like Fusebox or Mach II.
So far for the theory. This entry is on “SiAr” which is the synonym for Simple Architecture. SiAr is far away from being a complete framework or pattern, and it probably never will be something like this. It’s more of an example application following a certain way of structuring and setting up your application. The audience for SiAr is a typical junior web developer who got some ColdFusion experience already and wants to gain some ideas of how to improve the architecture of his applications but who fears the complexity of complete frameworks.
The base idea of SiAr is the MVC pattern and separation of concerns. Following this, there are several file types. Firstly there is an index.cfm which is responsible for controlling the application flow. Besides that there are action files (with an act_ perfix) which fetch data from an underlying data layer. The natural implementation of the data layer might be a set of business-related ColdFusion components. The action files are also responsible for delivering the fetched data to the presentation layer consisting of display files (with a dsp_ prefix). They should consist of HTML/CSS as much as possible and just use output-related ColdFusion code (for example to loop over a query etc.).
At this point there might be some or a lot of people looking up from reading and remembering back to the Fusebox 2 days. Yepp guys, you’re right. SiAr is following a lot of concepts of the Fusebox 2 approach which I was a big fan of. But SiAr takes additional complexity from Fusebox 2 and starts even more low level (and with a bigger dependency between the modules, which is usually bad). Additionally it’s using CFCs and/or XML for data fetching.
Within the Application.cfm the datasource and the CFC references are being defined. The application itself makes use of ColdFusions session management by passing the URL-token around via links and form actions. The shared scope variables structure is a little bit tricky in the example application but not because of some odd SiAr requirements, its because I wanted to test some stuff concerning message handling/passing and monitoring active sessions.
SiAr and the example applications is based on the request scope to avoid locking issues during the application. When the first request approaches the application, the app tries to find a structure session.stClient containing the login data of the user. Usually this is not available so CF calls the index.cfm and ends up the is ACTION=LOGIN case. That one includes dsp_login.cfm which is just a basic login form.
Submitting the form requests the index.cfm (again and as always), this time passing the value CHECKLOGIN for the parameter ACTION. This means that after parsing the Application.cfm, you’ll end up in the CHECKLOGIN case of the index.cfm. The first action there is to include the act_checklogin.cfm template which does some basic checking of the login information and – that’s more important – creates the stClient structure. After the successful inclusion of the template your user is forwarded to the index.cfm template again, passing ACTION=LIST (if the login was successful) or ACTION=LOGIN (if the login failed).
Now the whole process starts over again. Index.cfm is being requested, this time there is the session.stClient structure so that the Application.cfm has some work to do. Back to index.cfm the ACTION parameter is evaluated and for example the LIST case is called which would call an action page and a display page afterwards.
Let’s have a look into the act_list.cfm. This is a quite simple one as it just creates an instance of a CFC (a representation of a customer object in this case) and calls the method “getCustomerList” which delivers a simple query resultset. As we just deal with included templates within the index.cfm, the qKunden variable is available for the dsp_list.cfm page also. This template is basically HTML which assumes that the qKunden variable exists to loop over it for generating output etc. By the way, on that point we run into one of the drawbacks of SiAr as a simple approach now: a quite tight coupling between the different parts of the application.
A possible solution might be to define a naming standard for exchanging data between the action and the display files. An advantage of this approach is that you’re able to use different data fetching mechanisms besides ColdFusion components. I just played with ColdFusions XML functions a bit and that ended up with the act_edit.cfm. It just takes a query, converts it to XML (using the Query2XML CFC from a former DRK) and parses the XML data to several form variables to use in the edit form.
Well, so far for this now. As stated above, this is NOT a framework and it is not intended to become one. It’s more of a playground for people who are just thinking of getting started in dealing with frameworks and architectures. I’d appreciate any form of feedback of people having a look into it.
To install, you’ll just need to download the zipfile. It contains a folder structure to place in your webroot. You might need to adjust the paths to the components in the Application.cfm file. The database structure is quite simple and delivered as a mysql export file. The datasource in ColdFusion has to be adjusted to the varaible in the Application.cfm also. Login to use for the application is test/test.
The app itself is simple. After logging in, you’ll end up on the list page where all customers are listed. They are displayed in packages of five with a paging function in the lower right corner. The button “Neu” creates a new customer, the button “Bearbeiten” edits the just selected customer, same with “Löschen” for deleting customers.
Comments on this entry are closed.