Hi people:
As jcubic begin by templates (final step) i prefer start on the
architecture of new aiki / apps.
To render a page these steps must be made:
0) Load config
1) cache, triggers and logs
2) Create aiki object, connection to database..
3) session / authenticate users.
4) determine / site / view / language.
5) engine generate content
6) output content.
7) cache and other transformations.
Others:
8) libraries.
9) css-framework.
In depth:
======
0) load configuration (or call to installer).
Load all core configs, without a database connection or knowing site / view.
Posible improvements: load production configs, and develop configs (like
zend framework).
In aiki requires:
- delete old config var.
- add a library to edit config vars, and write them in a file. Adding a new
config var must be to easy as 'describe' the new var:
$config["cache-css"] = array("label"=>"Use cache for css",
"type"=>"boolean", "default"=>false) // this is ONLY A EXAMPLE.
In a application we can use:
http://devzone.zend.com/1792/manipulating-configuration-data-with-zend_config/
1) Trigger, cache, logs.
Cache is necessary to improve benchmark but have a disadvantage: for
example, you can't count hits for one image. One solution can be add a
trigger system like:
triggers = array (
"clipart/view/@id/*", "UPDATE hits=hits+1 WHERE image_id=@id"), // make
a SQL query.
Alternatives:
- no cache: use a third part software.
- no triggers. Triggers requires database connection and some aiki
functions, slowing cache.
- for logs: no logs, we can use google analytics, or server stats.
In aiki framework, we must:
- join all caches (html, css, widgets) in a unique cache.
- a new triggers library.
- or remove cache and logs.
In a application we can use:
- http://framework.zend.com/manual/en/zend.cache.html
2) Create aiki object and making connection.
No necessary in a application, but some state values must be saved.
3) Session / Users
Aiki implementation of user (membership.php) is obscure.
In a application we can use:
See http://framework.zend.com/manual/en/zend.auth.html/
4) check url to set site / views / language and AJAX.
Alternatives:
- no sites, no views,
- no languages.
Changes in aiki.
- In site library we add new functions: export_site, import_site,
unload_site. The installer requires changes too.
- add ajax and language detection by code.
- convert admin in a site, that can exported / imported (changes can easily
included in repo).
- a directory to save aiki default sites: admin, openclipart, ofl, demo.
In application this in unnecessary (only a router is required, and zend
have one and slim too.).
5) Plugins and extensions.
In application this in unnecessary.
6) Engine
Forget (Deprecated) old engine because it is unstable, and too hard to
work. Try to simplify new engines and routes (widget selection):
Work on simpler engines:
- purephp.
- moustauche + sql.
- engine2 ..
All engines must generate a object that will be echoed by output library.
This object will have a headers array and body array
and as optional a template.
Output can be:
- a png / svg (a non html file)
- a rss / atom / xml.
- ajax.
- json. encode.
- a html (in this case can have a template)
For example:
engine generate:
"headers" => array ("meta", "keyword" , "..")
"body" => array
"main" => "here you content"
"title" =>" my first page"
"aside" => "picture of day"
output=>"template"
template=
"<html><title><%title%><title><body><header>...</header><%main%><aside><%aside%></aside>..."
Aiki requires:
- rewrite engines (except old).
- rewrite output library. Add a simple template engine (or use smarty,
mustache )
A application only need a good way to generate html using a basic template
or after detect an ajax request, sending partial data or json encoded.
7) cache output.
If there is not user logged, cache the content for next query.
---- pager is rendered ---
8) Other libraries.
Foms.php, records.php and other library will overwritten by new controls
(form 2). Unused libraries will be removed. Unclear code and
'backward compatibility' code will be deleted. Tests will be added to every
library.
Membership must be rewritten too.
In application we can use:
See: http://framework.zend.com/manual/en/zend.form.forms.html
9) CSS framework
bootstrap (twitter), blueprint.
Conclusions:
--------------------
- Zend is a good candidate for framework.
- {{Mustache}} resolve one important problem ( generating widget ) but only
one. It's possible integrate mustache in an engine ( it can be superb)
- we have two alternatives still: clean aiki code or begin from scratch.
I don't know what to do. We need a change, but which?
close aiki and begin again? In the past, changing from ccHost to aiki
didn't resolve development problems.
do we have now the solution? a few months ago, we had a solution for
aiki: new engine and new admin...
Modularity is the key factor for success. Every library must work
almost independently
and have a clear role.
Engines and library must be testable (that why mustache can solve a lot of
problems..it is tested!!!).
does resolve changing to aiki resol
_______________________________________________
Mailing list: https://launchpad.net/~aikiframework-devel
Post to : [email protected]
Unsubscribe : https://launchpad.net/~aikiframework-devel
More help : https://help.launchpad.net/ListHelp
