Location: PHPKode > projects > Aukyla Document Management System > doc/html/introduction.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
    <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">

    <div id="mainmenu">
      <a href="http://www.auton.nl/" class="home">Home</a>
    <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&amp;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 id="main">
      <div class="qindex"><a class="qindexHL" href="index.html">Main&nbsp;Page</a> | <a class="qindex" href="hierarchy.html">Class&nbsp;Hierarchy</a> | <a class="qindex" href="classes.html">Alphabetical&nbsp;List</a> | <a class="qindex" href="annotated.html">Class&nbsp;List</a> | <a class="qindex" href="files.html">File&nbsp;List</a> | <a class="qindex" href="functions.html">Class&nbsp;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

      <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


      <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>

        <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”
        <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>

      <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>
Return current item: Aukyla Document Management System