Getting started

Marc Brevoort

Getting started

Preparation

Before you can use Solutigo, you'll need to have a LAMP server installed (i.e. Linux, Apache, MySQL and PHP). Don't worry if you prefer tying in your application into another DBMS; we'll get to that bit later. However, for some bits and bobs, Solutigo will use MySQL by default.

Setting up Solutigo

As Solutigo is mainly a source library, setting it up is as simple as unpacking it to a directory of your choice. For security reasons, this directory should ideally reside out of the reach of any browsers accessing the web server.

You'll need to set up your web server to point to the actual application that you wish to run. Typically, using Apache virtual hosts would be recommended, unless you only plan tun run one application on the server. Using virtual hosts, however, a single web server should typically be able to host many different applications.

Understanding how Solutigo is structured

A Solutigo application is normally expected to follow a certain directory structure. This will result in applications that share the same basic structure, making them more maintenance-friendly to those who are familiar with that structure. Relative to the document root of the application, a Solutigo application will typically have the following directories:

admin/

Links to the back-end of the application - assuming there is a distinction between those administering the application, and those who are merely plain users.

components/

Contains application-specific extensions. A component can contain other components. Components may include things that typically will be displayed on every page of the application. Examples are a login/logout box displaying the user name, a short text snippet showing the current date/time, and so on.

config/

The configuration directory for the application. This config directory should contain a file called "lib.php". This file should set both the application path and the library path, and proceeds to load the Solutigo library from that library path. The library, in turn, will load the rest of the configuration which should also reside in the config directory of the application, and which will typically contain login credentials for the default database.

A typical lib.php would look as follows:

<?
    $GLOBALS["library_path"]="/path/to/solutigo/lib/";
    $GLOBALS["app_path"]=getcwd();
    require_once($GLOBALS["library_path"]."lib.php");
?>

content/

This directory contains the actual content that you'll be wanting to display.
For a website, this would be the bit that varies while the rest of the website layout stays the same across pages. A typical page would link in to the content via a component.
To get a bit more understanding about this, this is what a typical page would look like:

<?
    require_once($_SERVER["DOCUMENT_ROOT"]."/config/lib.php");
    $framework=new component("main",array("page"=>"welcome"));
    $framework->render();
?>

The bit above states -
1. We're using the Solutigo library;
2. We're telling this library to create a new component. The code of the component will
be found in the directory components/main.php
3. We're telling the component that the page (content) to display will be "welcome", which means that welcome.php will be loaded from the content/ directory.

Notice that we haven't said anything yet about how a component is structured.
A typical component file will reside in the components/ directory and will look as follows:

<?
    $this->setparam("template","main");
    $stylesheetfile=$GLOBALS["app_path"]."/template/style.php";
    $this->setparam('style',file_run_contents($stylesheetfile));
    $this->setparam('formaction',"");
    $this->add(new component("logobar"));
    $this->add(new component("navigator"));
    $this->add(new component("footer"));
    $content=$GLOBALS["app_path"]."/content/".$this->getparam('page').".php";
    $this->setparam('content',file_run_contents($content,$this));
?>

In turn, this shows that a component can contain other components, which will be structured in the same way as the main component. The page "welcome.php" will be loaded from the content/ directory, whilst the stylesheet for the site is loaded from template/style.php (relative to the application path). One more thing about components is that the way components look is largely defined by files in the template/ directory. For example, the above component sets its template property to "main", which means that there should be a file called template/main.php showing the general layout of the component in question.
This layout is simply plain HTML with placeholders for further content, as described below under the template/ directory explanation.

images/

Contains any images that you define as needed for your site.

template/

As mentioned before, this directory will contain layout templates for the components. Templates are very dumb entities; they're merely HTML files with some [bracketed] place holders for content.

<html>
<head>
[style]
<title>My first Solutigo Web Application</title>
</head>
<body><form name="form" id="form" method="post" action="[formaction]">[logobar]
[navigator]
[content]
[footer]</form></body>
</html>

As you can see, the general framework layout is starting to come together now. It may be a bit much to take in at this time, but this application structure will allow you to very easily change things to the layout or the code without changes to the former affecting the latter too much (and vice versa). Once you're happy with your default framework, I suggest you save a copy of it and use it as base for further projects. Meanwhile, we can start focusing on the actual application. Next time around, your basic framework layout will cost you even less time.

One more thing - the template/ directory may contain code for the rendering engines of various field types. Without going into too much detail at the moment, this permits you to define new field types which have cleverness built-in for things such as email fields (including automated validation on the content) or perhaps even project code fields (specific to your company), and so on. Or perhaps you have a company-standard date picker that you like better than the one built into Solutigo - nothing stops you from using your own instead.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks