<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Aukyla PHP Framework</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link rel="StyleSheet" href="auton.css" type="text/css" media="screen">
</head>
<body>
<div id="mainmenu">
<a href="http://www.auton.nl/" class="home">Home</a>
</div>
<div id="submenu">
<a class="logo" href="http://www.auton.nl/"></a>
<div class="head">Ads</div>
<a href="http://sourceforge.net/"><img src="http://sourceforge.net/sflogo.php?group_id=116358&type=1" alt="SourceForge.net Logo" style="padding: 2px 4px; width: 88px; height: 31px; border: 0px"></a>
<a href="http://getfirefox.com/" title="Get Firefox - The Browser, Reloaded."><img src="http://www.mozilla.org/products/firefox/buttons/getfirefox_small.png" alt="Get Firefox" style="width: 110px; height: 32px; border: 0px"></a>
</div>
<div id="main">
<div class="qindex"><a class="qindexHL" href="index.html">Main Page</a> | <a class="qindex" href="hierarchy.html">Class Hierarchy</a> | <a class="qindex" href="classes.html">Alphabetical List</a> | <a class="qindex" href="annotated.html">Class List</a> | <a class="qindex" href="files.html">File List</a> | <a class="qindex" href="functions.html">Class Members</a></div>
<h1>Introduction to the Aukyla PHP Framework</h1>
<p>Okay, you probably could have guessed the Aukyla PHP Framework is a
framework for developing PHP applications. But, the Aukyla PHP Framework
strives to be a little bit more than that. Also, its approach differs a bit
from most traditional frameworks. Let me explain what I mean with this.</p>
<p>Whereas most frameworks center around their library of classes and let you
sort out the rest yourself, the Aukyla PHP Framework tries to guide you into
a certain way of developing. While Aukyla also offers a rich wealth of
classes, it's not its main priority. Therefore, Aukyla does not try to offer
a class or a function for every possible use, but rather makes sure the
common usage of its classes is straightforward, is well integrated and makes
you, as a developer, feel comfortable with them. By laying out the
underlying directory structure that can be used by applications, by
providing ready to use interfaces to add new functionality, and by setting
guidelines on how to write a good Aukyla application, you are steadily
guided toward your goal: writing your own Aukyla application. This
application will then be easily deployable on other Aukyla installations and
will be able to integrate with other Aukyla applications. Please note there
is a strong emphasis in the Aukyla PHP Framework on being able to mix and
match multiple applications within one installation, providing access to
multiple applications at once through a single interface and letting
applications transparently interact with each other.</p>
<p>The Aukyla PHP Framework is also very plugin-oriented. This makes it easy to
extend Aukyla with new functionality, connect it to other systems and read
external file formats. All these plugins can then be transparently used by
all Aukyla applications running on top of it. By being very extensible,
Aukyla gives you a whole range of possibilities to extend or adjust Aukyla's
functionality where you see fit. If needed, you can add functionality you
think is missing or you can decide to link to other systems which provide
some functionality.</p>
<h2>About applications and frontends</h2>
<p>In order to reach its goal to have multiple applications all running and
interacting with each other, Aukyla makes a distinction between applications
and frontends. Basically, an application is a set of classes that implement
a certain functionality, like document management, a webforum or something
else. An application usually provides an interface in the form of a widget,
but it doesn't concern itself with anything out of its scope. Through the
use of Aukyla's class library, application can interact with each other,
even though they may not be aware of it.</p>
<p>A frontend is basically a special kind of plugin, but there's always only
one frontend activated. This frontend provides the final interface with
which the user can interact, it takes care of building a main window,
creating menu's, etcetera. The frontend is also the one who determines which
applications it embeds into its interface. As a result, if you write a new
application, you need to write at least one frontend which makes use of it.
Of course, you can also extend an existing frontend to add the application
to its interface. Because frontends generally don't provide much
functionality of themselves, they tend to be a magnitude smaller than a
serious application.</p>
<h2>What the Aukyla PHP Framework has to offer</h2>
<p>While all this may sound nice and wonderful, you may be curious to what the
Aukyla PHP Framework in its current form has to offer, and to some of the
more technical details behind it.</p>
<h3>Configuration and login management</h3>
<p>Two fundamental things which were part of the very first Aukyla classes, are
its configuration and login management systems, provided by the Config and
Login classes, respectively.</p>
<p>Aukyla's configuration system is an advanced, two-dimensional system. It has
a dimension to load the configuration of every application you want, and it
has a dimension to load every user's configuration, allowing for any
combination of application- and user-specific variables. The configuration
system also allows direct access to global variables (variables which are
neither application- nor user-specific), it gives access to request
variables and it's central to determining which frontend is to be activated,
what language is to be used, among many other things.</p>
<p>The Login class is responsible for managing user sessions, including storage
of session variables. Even though the Login class provides the public API to
getting information from users and groups and provides the actual login
mechanism, user authentication is handed over to a LoginHandler class. A
LoginHandler class is a helper class which retrieves usernames, password
information and group relations and checks whether they are ok. One
LoginHandler is bundled with Aukyla which uses plain UNIX-like passwd and
group files for retrieving this information.</p>
<h3>Interface building using Widgets</h3>
<p>If you are building an interface with Aukyla, the Widget is a very important
aspect. A widget is essentialy a building block in your interface, like a
menu, an input field, a button or a label. Container widgets can contain
other widgets, for instance a Menu widget can contain MenuItem widget.
Aukyla already provides a wide range of widgets to use and new widgets are
created easily.</p>
<p>If you want to create a new interface, you start by creating a MainWindow
(which is done within the frontend), then you add other widgets to it, like
a Menu, probably a Form or two and usually some widgets provided by an
application. The application then populates its own widget with other
widgets to give it some real content. Applications can also populate the
menu provided by the frontend, or create their own menu. When all the
widgets have been build up and initialized, the entire widget tree is
written as an Aukyla-defined XML schema to a buffer which is then converted
using a stylesheet to any format you wish. Currently, output converters are
supplied for both HTML and XHTML output, but a Mozilla XUL output converter
is also planned.</p>
<h3>Form building</h3>
<p>An area of special interest when building interfaces, is form building.
Aukyla provides the Form class to create a form after which you can populate
it with widgets, most importantly: input widgets. Input widgets are things
like text fields, password fields, selection boxes, checkboxes and buttons.
Aukyla helps you by providing functions for specifying which input widgets
are required to submit the form and Aukyla will generate JavaScript to keep
the user from submitting incomplete forms. Also, special functions are
provided to automatically align the widgets in a grid and to easily retrieve
the submitted data (using the Config class).</p>
<h3>Data storage using Local URI's</h3>
<p>You may be familiar with PHP file streams. PHP file streams provide a means
to access files in a universal way through a URI. Aukyla's Local URI's
provide an powerful extension to this idea. Local URI's are called that way
because they are most often used to access local storage locations, though
they are not limited to this purpose. Local URI's are more powerful than
file streams because they provide advanced access controls (which makes them
so useful for local storage locations) and meta-data controls. Local URI's
use namespaces to discover which storage handler is to be used, in the way
the protocol to be used for accessing a regular URI is determined by its URI
scheme. Though Local URI's are backwards compatible with PHP file streams
and can be used in regular PHP file operations, Aukyla provides a URI class
which is specialized in handling Local URI's. This class is able to
automatically load a URI namespace handler when needed, it does automatic
access permission checking (thus denying any unauthorized operation) and
it's the only way to make use of a Local URI's access or meta-date controls.
As a security measure, the URI class does not provide access to local files
or PHP file streams directly, so only data which is made available
explicitly through a URI namespace is available. URI namespace handler are
created easily by implementing the URINamespace class. Ready to use
namespaces are tmp:// for storing temporary files which are saved during a
user's session and upload:// for accessing uploaded files.</p>
<p>Finally, if two applications use Local URI namespaces to store their
internal data, they can transparently work with each others data as well by
providing them URI's using each others namespace. By using the URI class,
it's guaranteed no user can access or manipulate data for which has no
permission.</p>
<h3>Document viewers and editors</h3>
<p>Aukyla provides some very high level widgets in the form of document viewers
and editors. Viewers are readily available for plain text, HTML and
OpenOffice.org Writer documents, PNG images and resource locations (aka
shortcuts). Editors are available for plain text, HTML documents and
resource locations. (I have to honoustly admit the HTML viewer and editor
are still far from perfect.)</p>
<p>Document viewers and editors work directly with Local URI's. This makes
inline viewing and editing of documents stored in a Local URI namespace a
breeze.</p>
<h2>Namespaces</h2>
<p>Many frameworks and libraries namespace their classes in order to not
collide with names of classes the user of that framework or library uses.
Aukyla explicitly does not namespace its classes. By not using namespaces,
Aukyla forces the developer to use namespaces instead. While this may seem
counter-intuitive, it has a huge benefit. Because Aukyla developers will
have to use namespaces to write safe Aukyla applications, possible name
collissions between seperate applications are eliminated. And so Aukyla can
make true on its promise to be able to combine multiple applications in one
environment (even from multiple vendors).</p>
<p>Because name collissions can occur in many places, it's important to be
consistent in using namespaces. When you start developing you should pick a
unique namespace which you can then use throughout your programs. Often your
namespace will be something like (an abbreviation of) your comany's name.
I'll use the Auton Document Management System (which is developed by Aukyla
Software) as an example throughout this section. The Auton Document
Management System uses the âADMSâ namespace. Namespaces are
case-insensitive. So if you have the âADMSâ namespace, you may also use
âadmsâ when appropriate.</p>
<p>The most notable places you need to use namespaces are:</p>
<ul>
<li>Class names. Because PHP has no real namespaces, you will have to use a
prefix for namespacing your classes. You should use your namespace appended
with an underscore as prefix. For example, a class which you would like to
call âApplicationâ, would be named âADMS_Applicationâ if you use the âADMSâ
namespace.</li>
<li>Global and session variables and constants. The same applies here as for
class names. Prefix all your global and session variables and constants.
(Please note that using static variables is often a preferred method to
using global variables.)</li>
<li>Get, Post and Cookie variable names. If your application uses variables
which are send as variables to the server when a page is loaded, you should
prefix them to avoid collissions with variables from other applications
which are send to the server as well. You should be aware that any IDs you
set on input widgets are also used as that input's name which is send as
Post variable when a Form is submitted. So any IDs which may be used as a
reference when submitting Form data should be namespaced as well.</li>
<li>As mentioned before, Local URI's use namespaces to determine which
handler to use. This namespace can equal the namespace of your application,
but may also be a namespace which is simply prefixed with your application's
namespace. For example, ADMS uses ADMS://, ADMS_Search:// and
ADMS_History:// as its Local URI namespaces.</li>
<li>Signal names. If your application emits signals for use with plugins,
the signal names should be namespaced as well. A full signal name with
namespace consists of the namespace followed by a double double colon,
followed by the signal name. For instance: âADMS::DocumentCreatedâ.</li>
</ul>
<p>Finally, your application's configuration should be named like your
namespace with a â.confâ extension. For example, ADMS uses âadms.confâ as
configuration file.</p>
</div>
</body>
</html>