Artaengine is a set of nimble lightweight PHP classes and programming approaches that can be used as a small lightweight framework for your PHP applications. Artaengine solutions are designed to be object oriented, simple, clean and fast. It's free and open source anyone can change, customize or participate in the project.
Did you ever think things could be seen and created much less complex? Ever downloaded a library and felt its abusing or over using OOP? like choking under tons of classes, methods, functions, objects and codes? Feel that the data is being passed like a ball in a football match? Trying to track something but felt trapped in a maze?
One of the ideas behind Artaengine is to avoid repeat and complexity but keep things simple and minimal. The existence of each class, method, pattern, etc. has been carefully thought through. The critical parts have been carefully analyzed to be resource and performance efficient. It is supposed to be handy and to help the developers not to make their life harder. It should be for the sake of the project not for the sake of the frame.
The rest of this page will introduce the main features of an Artaengine based application. When I'm looking for a framework, tool, library, etc. I will start to read the documents and if I don't understand the thing and dont have it working in less than an hour I will just throw it away, and that is what I suggest here, leave this website as soon as you feel things got weird :)
Below is a brief list of features that Artaengine provides for an applications:
An elegant and flexible way of routing/map requests to handlers plus six special handlers that can be defined to handle events like exceptions, page not found. Continue reading...
On demand resources
Artaengine does not create a load of instances or force any of the folowing features to be necessarily used. All resources and instances can be integrated when required or fetched and used on demand.
Request and Response
A set of rich instances and methods for processing requests and responses which blend into the handlers.
It is possible to put permissions on routes (URLs which map to a handler), handlers and PHP classes. A default built-in or a custom principal will decide whether to give or deny access. Continue reading...
Browser (front-end components)
A factory pattern and database interface allows making connections to databases and creating abstract or advanced database access objects. Currently only PostgreSQL and MySQL DBMSes have been implemented. The interface is database independent. The interface lets toggling between DBMSes as easy as just changing the connection configs without the need to change the project source codes. Thanks to the factory pattern, instances are only created on demand, making applications resource and performance wise. Continue reading...
Lets you to define everything related to data entities in basic classes. Database will be created and synchronized automatically. You can access data and manipulate data with instances of this classes. Also a set of additional classes let a lot of flexibility and automation to be done on the models. For example data validation table, form, search form generators. Continue reading...
A factory pattern and interface lets to setup and employ template engined. A template can simply be a PHP file. PHPTAL and Smarty template engines are supported and can be used. Thanks to the factory pattern, template engine objects are only created when rendering a template is been asked for. Using templates has been embedded within the Response. What you write in the factory and how you set data to the Factory/Response context is completely independent from the output shape. No matter what will be the output format (JSON, template, PHP, file, etc.) the logics which provide the output are separated from how it will be send or represented. Changing the output(response) shape is as easy as changing few configs or one line of code. Continue reading...
A factory pattern and interface lets to setup and create object(s) to access UPC/XCache/MemCache engines. Thanks to the factory pattern, objects are only created on demand. The interface brings the flexibility to change engines without the need to change source codes.
Artaengine applications can be made multi lingual. Turn on i18n in the application configuration and add the available locales. Artaengine will set up gettext, create the locale directories and create empty po files. All translatable labels and tokens used in data models and templates will be ripped out and put into a file to make them visible to a tool like poedit. Data models fully support multi language. You can mark a data property to be language sensitive so data storage and querying can be language aware.
This tool is an Artaengine application itself. With this tool you can create a new project in just a few minutes without writing a line of code or even knowing much about Artaengine. This tool is capable of doing all the application setup steps explained in the tutorials in a GUI. You can also create/edit data models, map URLs to factories and buildout applications with this tool. Continue reading...
Read below and find out what an Artaengine based application looks like and what components it can have.
Factories, requests and responds
In an Artaengine application all requests (except requests to static resource files such as JS, CSS, images, etc.) go to to one PHP file which calls Arta::start(config) method.
Application configurations which can be inside an ini file or an array are passed to this method.
There can be a lot of things defined inside this application configuration such as file paths which contain other configs, application components, database configs, template engine configs, multi language configs, etc.
One of the configuration items points to a config file containing a dictionary which routes (maps) URLs and URL patterns to PHP functions or methods that must handle the requests. This handlers are called "factories".
A Request object is passed to a factory as the first argument.
If factory or factories are class methods then the class can inherit from class Response, which makes response the context of the class. Any variable set on fly to the class contest (setter) will be included in the response. Response can be in various shapes template(in this case the context variables are available to the template), JSON, file, download, etc. Otherwise if needed a Response object can be created manually.
Browser or front-end components
A website may have files which are send to the browser, JS, CSS, images, etc. Lets call them all "static resources".
Contents (HTML, XML, etc.) can be put inside templates as PHP files, PHPTAL or Smarty templates. Lets call them all "templates".
The resources and templates together are another component of an Artaengine application called browser.
The browser items are accessible inside a factory via a Response object (as mentioned before this can be the factory context).
A dictionary can be defined as an XML file or an array which is called "Browser dictionary". This dictionary maps files to keys which can be in an hierarchy order, on each map there can be options such as compressing (for JS and CSS files). The keys are used inside factories to access the files.
An application will probably use databases. Database connections can be defined in the application configuration file. A database abstract object will be available on demand to access the database whenever wherever inside the application.
A more elegant and simple way for handling data is to create classes for data entities and use object instances of this classes to access data. This classes are called "models".
Artaengine lets you define all aspects of a data entity like data properties, methods, actions and events inside a class keeping all the complexities related to that entity within the class. As each model inherits from the Artaengine class Model, it will have all the essential actions.
Artaengine will buid all the database relations which are needed to represent the models. Objects of model classes are used to manipulate and query data. A model object is iterative and can be directly used in loop blocks and templates to fetch data.
An application may contains independent parts which are called modules. As modules are independent from applications they can be reused in different applications, they can have their own factories, browser, models and configurations and even sub modules. Each sub module is a complete module too.
This scheme will be implemented in Artaengine 2.0.0
An Artaengine application would look like the image shown below. The thick lines show flows and the thin lines show use cases.
Note that depending on how you see things and how you use Artaengine, you can use it as an MVC framework, and the data modeling can be seen as an ORM.