[Apc-aa-coders] AA cleanup for v3.0?

[Honza M. <hon...@ec...>]

Hi,
 
   I know, that the AA meeting in Umag should be more about
organisational things. Anyway, there are some questions we could think
about for next version of AA.

   Following questions are just about inner AA structure and cleanup -
not about new features. The points also answers the question, what does
it mean AA cleanup. 

Sorry for technical language (if I can call it this way) - it is more
for AA developers, than for AA users.



*PHP5*
I would suggest AA v3.0 will use PHP5. Reasons:
  - we can use better error handling (exceptions)
  - we can use "lazy initialization" of objects for quicker code
    (http://www.zend.com/zend/php5/php5-LazyInit.php)
  - we can use autoloading of class definitions for quicker code
    (http://www.sitepoint.com/article/coming-soon-webserver-near/10)
  - also PHP5 have much better object model, which is very helpfull if
    we want to modularise AA and create new APIs

Disadvantages
  - will not be runing on php4, but I think it doesn't matter so much 
     - PHP5 will be standard in the time of AA 3.0 release (in fact it
       becames standard right now)
     - AA focus is mainly as framework for rapid webdevelopment and I do
       not expect the people working in the field of webdevelopment will
       not have access to PHP5


*Register Globals Off*
Use $_POST, $_GET, $_REQUEST superglobal variables instead of current
$GLOBALS array with Register Globals On. Add range checking for all
those variables for better security, SQL injections, ....


*Magic Quotes Off*
Current AA works with Magic Quotes On as well as with Magic Quotes Off
and I want to stay with that. The change would be, that we will use
Magic Quotes Off by default and the code will expect, that the variables
are not quoted. 


*Cleanup*
 - Beautify the code to be compliant with coding standards 
   (indentation 4 spaces, standardise naming of
   functions/methods/variables, enclose keys in association arrays to
   apostrophes ($cont[value] -> $cont['value']), ...)
 - convert most structures to classes (conds/sort/group class, ...)
 - convert all comments and function description to phpDoc
 - remove post2shtml where not necessary
 - use factory() method of some objects (slices - so the slice is only
   once in memory)


*What to throw away*
There are some features in AA, which is not used by most of AA users.
Some of them haven't good design or stay on presumptions, which are not
valid in current AA. I think we should identify such features and
decide, if we will maintain it in the future (with all its costs),
rewrite it, or just drop it.
My candidates are:
  - migration script from AA 1.2 to AA 1.6 (misc/oldDb2Db)
  - current filemanager feature (does it use anyone?) we can drop it or
    rewrite to use FTP
  - category mapping for cross-server feeding and maybe whole idea of
    Parent Categories
  - tagged ids (which is good idea, but the implementation do not allow
    database relation between items.


*Metastructure database*
Current AA uses database abstraction layer, which in theory allows to
migrate to another database engine, but in praxis it is not so easy task
(as we learnt from migration to MS SQL in one project). This switch
should allow to make SQL queries db independent. This change will also
allow users to use tablenames with custom prefixes.
We should also create 'highlight' field as normal field in field/content
table and not in item table (which sometimes complicates things)


*Filenames*
Change php3 extension to php, change some include filenames in order we
can use __autoload() functionality.
(http://www.sitepoint.com/article/coming-soon-webserver-near/10)


*Subversion*
The question is about switching from CVS to Subversion version control
system. With Subversion we will be able to rename the files more easily.
Unfortunately Sourceforge do not support SVN, yet, so probably will wait
for its support.


*Remove Packed IDs*
Using packed ids (16 characters long binary strings) in the database
wasn't the best design decision we ever made. It complicate debugging
quite a lot and is hard to explain new coders, why we do it. I think it
should not be so big problem to convert all ids to unpacked - 32
character hexadecimals. If we create one clever DB conversion script,
then backward compatibility should remain in most cases.


*UTF-8 language files*
Create UTF-8 language files as variant to current ones. Mixing languages
on one page would be much easier.


*HTML class for Admin pages*
All admin pages currently consist of calling general AA functions to
display checkboxes, textinputs, ... We can generalise it a bit more and
use special class, which will generate all admin page based on the
parameters you pass to it. It would be something like tabledit class in
current AA. The advantages are 
   - the setup of new page will be quite easy
   - it will be easy to change design (of skin)
   - it allow to add "plugin page" in the future
   - it will handle all common problems which we do separately on each
     admin apge right now (displaying menu, checking permissions, react
     to 'Cancel' button, ...
   - it could handle all status (session) variables (like slice_id), so
     in theory we can remove the problems with using two different
     browser windows with the same session id.
Could we use PEAR?
Should we use cookies for state variables?


*Debug*
Better debug functions based on cookies (so the debug informations will
be shown only to developer.


*...*

      Honza