Enterprise Components

Planning and implementation

The Core Team

Revision 0.4 – Jul. 15, 2005

Table of Contents

1 Introduction	7

1.1 Goals	7

1.2 Time line	7

1.3 Prerequisites	8

1.4 Phases	8

1.5 Expected problems	8

2 Information Gathering Phase	9

2.1 Review of existing application frameworks	9

2.1.1 Result	9

Template for documenting each library	9

Template for documenting each library part	9

Special PEAR documentation	10

2.1.2 Expected time usage	10

2.2 Review the current state of the eZ publish libraries	10

2.2.1 Result	10

2.2.2 Expected time usage	10

2.3 Review eZ publish	10

2.3.1 Result	11

2.3.2 Expected time usage	11

2.4 Find the correct test system	11

2.4.1 Expected time usage	11

2.4.2 Result	11

2.5 Find the correct UML tool to use	11

2.5.1 Expected time usage	11

2.5.2 Result	11

3 Planning Phase	11

3.1 Set up library programming guidelines	12

3.1.1 Result	12

3.1.2 Expected time usage	12

3.2 Move to PHP 5 and PHP 5.2 planning	12

3.2.1 Result	12

3.2.2 Expected time usage	13

3.3 Go through the data contained in the information gathering phase	13

3.3.1 Result	13

3.3.2 Expected time usage	13

3.4 Plan the new library	13

3.4.1 Result	14

3.4.2 Expected time usage	14

3.5 Documentation planning	14

3.5.1 Result	14

3.5.2 Expected time usage	14

4 Execution phase	14

4.1 Coding	14

4.1.1 Estimated time usage	15

4.2 Documentation writing	16

5 Resource planning	16

5.1 Core team resources	16

5.1.1 Predefined projects	17

5.1.2 Available resources	17

5.2 Time planning	17

6 Meetings	18

6.1 June 7	18

6.1.1 Decisions	18

Unit test system	18

SRM functionality	19

UML tool	19

Timeplanning	19

6.1.2 To discuss	20

Documentation system to use?	20

7 Document revisions	20

7.1 From 0.1 to 0.2	20

7.2 From 0.2 to 0.3	20

7.3 From 0.3 to 0.4	20

8 Results of the review phase	21

8.1 PEAR review	21

8.1.1 Package Structure:	21

a flat directory structure instead of a deep	21

8.1.2 PEAR packages	22

PEAR base classes	22

PEAR installer	22

liveUser	22

Config	23

Console_Getopt	23

Console_Table	24

DB::DSN	24

DB::Prepare, DB::AutoPrepare	24

DB_DataObject	24

Calendar	25

Contact_Vcard_Build, Contact_Vcard_Parse	25

File_Archive	25

File	25

HTML_Menu	25

HTML_QuickForm	26

HTML_QuickForm_Controller	26

HTML_Template_Flexy	26

HTML_Template_IT, HTML_Template_Sigma	27

HTML_TreeMenu	27

HTTP_Download	27

I18Nv2	27

Translation2	27

Logging	28

Mail_IMAP	28

Net_Server	29

PHP_Compat	29

Structures_DataGrid	29

Text_Wiki	30

VersionControl_SVN	30

XML_sql2xml	30

XML_Beautifier	30

XML_Serializer	31

XML_RPC	31

Search_Mnogosearch	31

Other less interesting packages	31

8.2 HORDE review	33

8.2.1 Installation script of horde:	33

8.2.2 General discussion	33

8.2.3 Components in Horde	34

File_PDF	34

Auth	34

Prefs	35

Data	35

DataTree & DataTree_sql	35

Editor	35

Form	35

Graph	35

iCalendar	36

Maintainance	36

MIME	36

MIME_Viewer	36

Mobile	36

RelationShip_Manager	37

Horde_RPC	37

SyncML	37

Text	37

IMSP	37

Net_SMS	38

Text_reST	38

VFS API for abstracted file storage and access.	38

less interesting packages	38

9 Results planning phase	40

9.1 Global decisions	40

9.1.1 What do we need to do	40

9.1.2 What the Component library actually is	41

9.1.3 Packing and Installer	41

9.1.4 Configuration Discussion	41

9.1.5 Debugging	41

9.1.6 List with things that a web app needs	41

9.1.7 Functionality to move the library to kernel	43

9.1.8 Things we move from kernel to the library	44

9.2 Package Groups with original classes and dependencies	45

9.2.1 PDF	45

9.2.2 Request Handling	46

9.2.3 System Information	46

9.2.4 Translation	46

9.2.5 Archive	47

9.2.6 Date	48

9.2.7 Database	48

9.2.8 Database Schema	49

9.2.9 Debug	49

9.2.10 File	49

9.2.11 FileInfo	50

9.2.12 Image Analyser	50

9.2.13 Image Handler	50

9.2.14 Image Creation	51

9.2.15 User Input Handler	51

9.2.16 Uploaded File	52

9.2.17 Wizard	52

9.2.18 WebDAV	52

9.2.19 WebTools	52

9.2.20 Configuration	52

9.2.21 Locale [l]	52

9.2.22 Logging	53

9.2.23 Mail	53

9.2.24 Application Framework	53

9.2.25 PTKPHPC	53

9.2.26 Template	54

9.2.27 Session	58

9.2.28 TextUtils	58

9.2.29 Cache	59

9.2.30 PersistentDataObject	59

9.2.31 ConsoleTools	59

9.3 Graphical representation of the dependencies	60

9.4 Depency Discussion	61

9.5 Small discussions about little points	65

9.5.1 Form input handling and filtering.	65

9.5.2 Logging and audit trail? (eZLog)	65

9.5.3 Access Methods (eZSys)	65

9.5.4 Sessions	65

9.5.5 Tools vs. Utils in packagenames	66

9.6 Refactorlist discussions	66

10 Components design version 0.1	74

10.1 Packaging	74

10.2 Functionality in the first version	74

10.3 Dependencies between the packages	79

10.4 Comments	81

Introduction

eZ publish has a vast array of general libraries which are currently only used by eZ publish. Enterprise Components is a new product from eZ systems which is built around these libraries. This document describes the process of moving out the libraries and creating a good and solid foundation for PHP application development.

Additionally the separation of the library will be the first step towards eZ publish 4.0. After the first phase of moving out the library and making it a separate product we will also update it with the tools we need for eZ publish 4.0.

The new library will be released under the LGPL license and will not maintain backwards compatibility with the existing libraries.

Goals

There are two types of goals. The goals of the library itself, and the goals of the development process. The goals of the moving out process should ultimately lead us to the goals of the library. All the goals are derived from the recognition that a library needs to be well documented and of good quality order to be accepted by the development community.

Library goals:

Provide a solid platform for PHP application development. This first version will concentrate on low level functionality only. We may decide to move on to higher level functionality later like GUI functions.

Clean and simple API

Keep backward compatibility for longer periods of time

Stable and few regressions

Goals of the development process:

Move to PHP 5

Thoroughly plan the product to get a top notch API for the library.

Thoroughly tested. All code should be covered by unit tests PRIOR to implementation

Make sure we keep the product open enough for future development

Do proper documentation during the development.

Time line

The project does not have an exact time line yet. However the following parameters are known:

Project start: June 20. - right after the summer conference

Project end: Dec. 2005. The sooner the better, however we should not sacrifice quality for time to marked. This includes the time needed to set up proper testing systems.

Normally debugging takes about 50% of the development time. However, libraries are a bit different and since we are planning on extensive unit testing. As a result we have decided that the testing period should indeed be as long as 50% of the total development time, but with less resources than the actual planning and implementation. These resources will be used for 4.0 planning instead.

Prerequisites

Before the Enterprise Components can be implemented we need to have a much better testing system planned and implemented. For the library the most vital form of testing is unit testing. The testing project should include thorough testing of phpunit2 so we can choose if we want to use it or continue to use our own testing unit test system.

Phases

The process of developing the library has been split into three phases. Each phase will be described in detail in separate chapters.

Information gathering

Planning

Execution

Additionally, after the translation to Enterprise Components the product needs to be maintained.

Maintenance / development of the finished product (bug fixing?) This phase is not described yet in this document.

Expected problems

Creating a new product from an existing library is of course a challenging process where we will meet several problems. The problems we expect to deal with are

Dependencies between the libraries and to eZ publish itself. In order to make the libraries lightweight and of general purpose we need to remove these dependencies.

Incomplete code. Several of the existing library parts have only been partially implemented to satisfy the needs we had for the functionality when it was created. Such code must be located and removed or finished properly.

Missing functionality. In a general purpose application framework some functionality can be considered a minimum. We expect that some functionality has to be made in order to make this minimum.

Missing documentation. Many of the current libraries are not documented properly or at all. Obviously, this has to be rectified.

API inconsistency. The current implementation has been written by several different persons without being properly planned and synchronized.

Information Gathering Phase

The information gathering phase provides us with the means to thoroughly design the library. It should give us detailed background information on the status of our current code and other similar projects that we can draw experience from.

Review of existing application frameworks

In order to make a good application framework we should look at what other people have done before us. This includes existing PHP libraries and other successful libraries.

Existing libraries that we should definitely take a look at:

PEAR and the PEAR installation and packaging system.

Horde

Java framework

.NET framework

Result

The result of the reviews should be a document describing the following things

A brief overview of the library. What does it cover. What does it not cover.

Pros/cons of the library. Are there any major problems with it?

Recommendations: which parts are worth drawing experience from. Which parts should we also have. Which mistakes should we avoid doing.

Template for documenting each library

Library Name:

Documentation URL:

General comments:

Template for documenting each library part

Library part name:

Documentation URL(s):

Matches eZ publish lib: no/what part

Comments about library part: (How does it match, why is it interesting, is the API useful for us to look at? what does this library do that we do not..)

Special PEAR documentation

General package structure:

- how to create a PEAR package in order for it to be recognized

Install system:

- how does this installer system work

Expected time usage

One week per reviewed framework. For the PEAR framework another couple of days is needed to review the installation and packaging system.

Review the current state of the eZ publish libraries

The purpose of this work is to get a good overview of the current state of the eZ publish libraries. The most important aspects are:

create a good overview over the classes and the functionality currently found in the library.

locate unfinished code

locate cross-library dependencies

locate dependencies on eZ publish itself

locate eZ publish specific code that should be removed from the library

Result

The result of the reviewing phase should be a document describing the above aspects in addition to a complete UML diagram of the classes in the diagram. Additionally the reviewers should go through all the code and put inline comments in the spots where any of the above mentioned problems occur.

Expected time usage

Two persons working for two to three weeks.

Review eZ publish

Currently there might be some code in eZ publish which is general and that should be moved into the library. This includes eZ persistent object and the some of the javascripts. The objective of this review is to locate all general code in eZ publish that should be moved into the library.

Result

A document describing the parts of eZ publish that can/should be moved into the library.

Expected time usage

One person for one week.

Find the correct test system

We need to chose the correct unit test system to use for the libraries. We are reviewing and choosing between:

SimpleTest

PHPUnit2

Expected time usage

One person for one week

Result

Select the unit test system that we want to use.

Find the correct UML tool to use

We need to find out the correct UML tool to use and for exactly what purposes we are going to use it. Example: are we going to use it during development only or is it also going to be used afterwards to maintain the library. An option is to use it for maintenance of the large library parts only.

Expected time usage

Result

A list of tools we have considered and which one we have chosen

How we are going to use the tool.

Planning Phase

The planning phase should result in a complete plan of what we are going to implement and how we are planning to do it. This includes guidelines on how to move the old library code to PHP 5 and a UML diagram describing at least the complete API of the new library.

Set up library programming guidelines

When creating and programming a library with many different persons working on the project it is important that we have clear programming guidelines. These guidelines should tell the programmers not only what finished code should look like but how to create proper code and documentation.

These guidelines will be reflected in the API design that we produce. However, this document will also guide future library development in the right direction.

Result

The result of the guidelines research should be a document describing the following:

How to do error handling (use of exceptions)

Coding style.

Naming schemes for variable names, function names, class names, package names etc.

How to document the code.

Programming order (document, write unit tests, implement code)

Checklist to find out if code is finished.

Are all functions properly documented?

Are all classes properly documented?

Are all dependencies properly documented?

Are unit tests for all functions finished?

Etc..

Expected time usage

One person for two weeks.

Move to PHP 5 and PHP 5.2 planning

The new library will be based on PHP 5. PHP 5 contains more advanced OO features compared to PHP 4 in addition to a more advanced library. The actual porting of the library will be done by several people with little or no past experience with PHP 5. To get everyone up to speed quickly a PHP5 guideline document needs to be written.

Result

A porting to PHP5 guideline document. The document should either describe or point the reader to information about

important syntactical changes

important new library functions that we should utilize

Common eZ publish issues when porting (statics, references. Exceptions...)

Planning of new functionality that will be present in PHP 5.2 and how it may affect the library.

Expected time usage

One person for two weeks.

Go through the data contained in the information gathering phase

Based on the data gathered in the information gathering step we need to conclude how we want to build up the new library. It is important that we do not over commit ourselves and end up with too little time to do things properly. Everything that we can't do in the suggested time frame will have to be postponed to a later stage.

Result

A document describing the decisions on the following issues:

Features we need to have in the new library

Features that should be removed from the library

Features that should be postponed to later versions of the library.

Features that should be moved from eZ publish into the library.

If we are going to use the PEAR packaging system or if we are going to how our own system.

Expected time usage

There is not much actual work to be done. However, most of the core group will be used for meetings in addition to the resulting document that has to be written. In total this process will take about a week.

Plan the new library

Planning a new library is a large amount of work. The goal of the planning phase is to have a complete UML diagram and descriptions of the new library.

Things to consider:

Layout of class API's

Usage of namespaces / packages?

Directory structure of files

Dependency planning. We must be very careful not to make the various libraries to dependent on each other. Also we should avoid circular dependencies.

Result

The result of this planning should be a UML diagram containing the API of the new library in addition to a document describing the order in which the various libraries should be ported.

Expected time usage

3-4 weeks all resources.

The real amount of time used to plan is of course much less. However, when planning libraries that we can not change for a long time it is important that we have some time to consider if we are doing things the right way. We may even consider making the API's public so people can comment on them before we start implementing things.

Documentation planning

The current documentation project covers the working of eZ publish itself. The new library will require even more documentation which should be integrated with the documentation project.

Result

The planning of the documentation changes should include descriptions of:

How to integrate the (doxygen generated) in-line documentation of the API in the existing documentation. (note: only the API any underlying classes should not be available in the documentation)

Plan the needed overall documentation and the tutorials needed for the libraries.

Expected time usage

One person for one week

Execution phase

The execution phase is the phase where the actual coding work is done and the documentation is written. The planning phase should provide us with an exact description of the result which should give us an excellent overview of what we should do. Since the planning phase will show us exactly what we want to do the text here only roughly describes how this phase will be implemented.

Coding

The various parts of the library will be ported one by one. The order will be based on the UML diagram and the library dependency document, starting with the libraries that have no dependencies.

Each part will be ported in the following way:

Unit tests will be written for the various classes of the library part.

The part will be moved to the new library and any wrong dependencies are removed.

The part is moved to PHP 5.

The part is completed to conform with the UML diagram and the unit tests.

Additionally some new parts will have to be made from scratch.

Estimated time usage

Estimating the time needed to port all the libraries, removing the dependencies and upgrading it to the new interface, and fixing the documentation in addition to writing the unit tests is extremely difficult. Not only because the amount of work is big and has many variables but because we are partially going onto unknown grounds (PHP5). Also the library parts are of different sizes so it next to impossible to say something about porting one part and then multiplying it.

However, the library currently consists of the following parts:

ezdb – This library will eventually change but has to be ported for now. Two weeks.

ezdbschema – Stays. Two weeks.

ezfile – File abstraction library. Still needs quite some work to be complete. Three weeks.

ezi18n – Translation system in addition to the character conversion system. The need for the character conversion system will be removed when this functionality is implemented in PHP. If we keep it as it is currently, two weeks.

Since this functionality depends on PHP5 functionality that doesn't exist yet we have to postpone implementation as much as possible. However this functionality should be reviewed early.

ezimage – Needs to be updated to use the new PIMP system present in PHP5. Update: the PIMP system is nowhere near ready for PHP5. We should continue using the existing system which makes the need for upgrade much smaller: three weeks.

ezlocale - Two weeks.

ezpdf – Currently not documented at all. Two – three weeks. There are many bugs in this module so we expect another two weeks of fixing.

ezsoap – Two weeks

eztemplate – Biggest single part of the library. Four to five weeks.

ezutils – This part consists many small utilities. It is definitely the part requiring a cleanup. Also the most probably part to be expanded. Four weeks.

ezwebdav – Two weeks.

ezxml – PHP5 has new XML functionality and the ezxml part will be removed.

SRM – To be defined

Stuff from eZ publish – To be defined.

In total 27 weeks.

In addition the above work we have work related to code moved out from eZ publish and new code. A very conservative estimate would be 8 weeks of development.

In total, 35 development weeks or around 8 weeks with five people. (there is always some overhead)

Documentation writing

Documentation of the libraries will be written by the authors of the various library parts. When a part is considered done the people responsible for the documentation will go through the inline documentation and verify that it is ok. Additionally any work necessary to integrate the in-line documentation has to be done. At last the tutorials and the general information about the libraries have to be written.

Resource planning

All of the above work will be performed by the core team. However, some resources are preoccupied with other tasks. This chapter describes the various resources available to the core team and how they will be used for the Enterprise Components project.

Core team resources

The following people are part of the core team and available to use. This list displays the Ukrainians either on the bug team or on the Components team. In real life they will be sharing their time on the various parts.

JB	50 %, will also use a lot of eZ publish 4.0 planning
FH	0%, will also use a lot of time on eZ publish 4.0 and the documentation
DR	70% (rest is PHP work)
RB	100%, no other occupations
BH	0% until he leaves for Oslo, will be doing doc until then.
TH	0%, Thomas is not a programmer and will only be involved briefly in the documentation part.
KS	100% Team
RL	100% Team
DL	0% Bug team
VS	0% Bug team
SP	0% Bug team
AK	0% Online Editor
Girl	0% Bug team
German dude	50%, Implementation only

Predefined projects

The following projects need resources from the core team. These resources will not be available for the Enterprise Components project.

Bug fixing team: Starting in late march there will be a bug team constantly working on resolving bugs in eZ publish and the libraries. If the Enterprise product is launched we need three people on the bug team. If not we may decide to use two people. These resources will be taken from the Ukrainian office.

The 3.6 period started a new focus on documentation. The documentation should be continued to be improved during the development of the Enterprise Components with one person.

Available resources

The total amount of available resources for the Enterprise Components project is: three persons 50% and three person 100% in total.

Time planning

This time planning is based on the estimates made above. There should be enough room for the planning and implementation of the new test systems. However, some more time may be needed for planning of eZ publish 4.0. Vacations may also postpone some of the deadlines.

The time planning is attached as a separate spreadsheet.

Meetings

June 7

Went through this document and decided the next meeting: friday 10.00. We will then present:

The various UML tools that are out there (amos)

The various unit testing tools and their differences.(ray)

The status of Dericks SRM system.(derick)

An updated time planning (fh)

We should make decisions on:

What UML tool to use or any further investigation

What testing tool to use or any further investigation

Define how much time we need to use for the SRM system

Agree on the final time planning of the components.

Decisions

Unit test system

Last meeting we briefly discussed the available unit testing systems. Raymond presented the two systems we considered the best choices (SimpleTest and PHPUnit2) in order for us to make a choice.

SimpleTest has support for mock objects and generally has somewhat better documentation. Still our choice for PHPUnit2 was clear because:

support for code coverage

part of PEAR, makes us more compatible with PEAR and it means that the project has a higher success probability.

native PHP5 app with support for exceptions etc.

Additionally they are working on mock object support and better documentation. For the web testing that we have discussed we will probably still use SimpleTest (the web testing functionality is a separate part of Simpletest)

SRM functionality

Derick gave us an introduction to how his SRM functionality works and the status of the project. The short summary is:

close to releasable (needs more testing and some functionality)

support for moving objects between client and server

support for RPC on objects on the server

Basically we decided to let SRM be a part of the library. Derick will go over the SRM code and create:

a list of features that still need to be implemented (async stuff, timed events, internal object communication)

a time estimate on how much work it is to create a first version.

Also, there are some licensing issues. We have to go through and see what licenses and copyright issues we might have.

UML tool

Amos presented various the various UML tools that are available to us. Most of them were closed source and written in Java (read: slow as a snail). We found a very nice although close source tool on windows named Enterprise Architect. We decided to go for this as it supports import and export of PHP 5 code in addition to feeling “nice”.

Timeplanning

We tried to set up a timeplan for the project. Unfortunately vacations fall in the period that we need everyone to be present. Frederik will discuss the issue with Aleksander so we can find a sollution. This must be set up before I leave on vacation next week.

However, the review part has been set. Until next meeting everyone with a specific review task should go though it and make a detailed list of subtasks.

Amos: eZ publish review, eZ publish library review

Derick: eZ publish library review (together with amos)

Frederik: .NET and Java review

Raymond: PEAR and Horde review

To discuss

Documentation system to use?

We have two competing products:

Doxygen

PHPDoc

We have always used Doxygen, but PHPDoc is getting more mature and has native PHP support and is used by PEAR. Is there anyone with experience with PHPDoc and Doxygen who can tell us about it? All comments are welcome.

Document revisions

From 0.1 to 0.2

Added note about not being backwards compatible.

Added review of the PEAR installation and packaging system.

Set up library programming guidelines chapter was decided to be necessary. It is completed and added into the time line.

Added note and time for research of PHP 5.2 features.

Added three weeks to the implementation time. This is time that we consider will be used for vacation. Together with the extra week needed for the lib programming guidelines and PEAR review this adds another four weeks to the total development time.

From 0.2 to 0.3

Fixed various spelling mistakes

Updated resources list

From 0.3 to 0.4

Added planning results.

Added review results

Results of the review phase

PEAR review

Interesting way to install the manager (or installer):

lynx -source http://go-pear.org/ | php

Package Structure:

Names of the packages are like: <Category>_<Name>. Each package has its own

release number and maintainer.

package.xml contains all the information needed for a package. Use:

pear install PEAR_PackageFileManager

To generate a new package.xml.

(http://pear.php.net/manual/en/developers.packagedef.php)

http://pear.php.net/manual/en/guide.developers.package2.channel.php Channels

are a systemized way of differentiating between different download sources.

One such download source is pear.php.net, another is pecl.php.net, and there

are several third party channels slowly springing up around the net.

To distribute our packages we need a channel server, and this requires PHP5.

http://www.schlitt.info/applications/blog/index.php?/archives/308-Set-up-your-own-PEAR-channel.html

a flat directory structure instead of a deep

In CVS, PEAR code is organized by package instead of hierarchical like it

would finally be installed. For example, if you want to use the XML_RPC

class, you include "XML/RPC.php". It's easy to think that in CVS, this file

should be in pear/XML/RPC.php, but that's not the case. XML_RPC is an

independent package with its own directory in CVS, in this case the RPC.php

file is actually located at pear/XML_RPC/RPC.php. The package description

file (package.xml) is used to say where the files should finally be

installed.

The reason CVS is organized this way is that it makes package administration

much easier.

A package itself can have its own directories.

PEAR packages

PEAR base classes

http://pear.php.net/manual/en/core.pear.php

PEAR base class supports (emulated) destructors (underscore class name) and

Error handling. Two variations are available for error handling. The

advanced method has forward compatibility with PHP 5.

PEAR installer

http://pear.php.net/manual/en/core.ppm.php

Might be handy when we will adapt the PEAR installer itself.

liveUser

http://pear.php.net/manual/en/package.authentication.liveuser.liveuser-summary.php

http://pear.limbourg.com

LiveUser purpose is to provide a flexible and extensible framework to be used

for authentication and authorization schemes. It does not aim at being the

"One-true-solution" but rather providing the means to achieve what you need.

Three permission systems are available: Simple, Medium, and Complex. The first

is the fastest, and the last one has the most options. It is always possible

to switch permission system. Interesting features are:

- Every Right may imply another Right. For example « WRITE » may imply « READ ».

Thus giving the « WRITE » right to a user will also mean he automatically has

the « READ » right.

- Can specify where the user and passwords are stored in the database. (So you

don't have to modify your existing database structure, to use this

framework.)

Config

http://pear.php.net/manual/en/package.configuration.config.intro.php

Config helps you manipulate your configuration whether they are stored in XML

files, PHP arrays or other kind of datasources.

It reads the config files, and stores it as a bunch of Config_Containers.

Comments and blanklines are also stored as a Config_Container. The renderer

can write any of the supported config files back. So changing and converting

the config should be a piece of cake.

Probably, eZ ini is supported, otherwise you can write your own config syntax.

Console_Getopt

http://pear.php.net/manual/en/package.console.console-getopt.intro-options.php

Defining and processing options. Like we do it in our scripts.

Defining short options like: $shortopt = "ql:o::"; l has a parameter; o can

have a parameter. Long options are defined in an array.

Console_Table

http://pear.php.net/manual/en/package.console.console-table.php

Get an ASCII art table. Might be handy for our output.

DB::DSN

http://pear.php.net/manual/en/package.database.db.intro-dsn.php

DSN is an abbr. for Data Source Name. This string specifies the database to

use. We can use the same structure in our command line scripts:

phptype(dbsyntax)://username:password@protocol+hostspec/database?option=value

DB::Prepare, DB::AutoPrepare

http://pear.php.net/manual/en/package.database.db.intro-auto.php

Write your query in a way that the variable data is a question mark. A

specific command is used to replace the question marks with actual data, and

execute the query. This is handy when multiple databases (with different

syntax) are supported.

AutoPrepare is a better maintainable way to write down the template-query.

Less chance for bugs.

DB_DataObject

http://pear.php.net/manual/en/package.database.db-dataobject.intro-purpose.php

Write your database tables as objects. Instead of querying a table, you can

access a datamember from the object. DB_DataObject has an autobuild script to

generate those classes.

Specific select queries are still possible. A JOIN mechanism makes it possible

to auto join tables.

Calendar

http://pear.php.net/manual/en/package.datetime.calendar.intro-purpose.php

This might be interesting for the Calendar.

I think that this calendar functionality is over-object-orientated.

Contact_Vcard_Build, Contact_Vcard_Parse

http://wiki.ciaweb.net/yawiki/index.php?wiki=Contact_Vcard&page=ContactVcardParse

If we want to support v_cards, this is interesting. They got a parser plus

reader.

File_Archive

http://pear.php.net/manual/en/package.fileformats.file-archive.php

http://poocl.la-grotte.org/

Compress, decompress, and modify tar, tgz, tbz, and zip.

File

http://pear.php.net/manual/en/package.filesystem.file.php

Object oriented implementation of the file functions in PHP.

HTML_Menu

http://pear.php.net/manual/en/package.html.html-menu.php

Write the menu structure in an array, and this function will present the menu

in the format specified by the Renderer. Multiple renderers are available.

HTML_QuickForm

http://pear.php.net/manual/en/package.html.html-quickform.tutorial.php

http://www.thelinuxconsultancy.co.uk/quickform.php

Quickform helps you to create and validate forms. Various renderers, including

Smarty renderer, are available to create the HTML or template output.

HTML_QuickForm_Controller

http://pear.php.net/manual/en/package.html.html-quickform-controller.intro.php

This allows to fairly easy build very complex forms consisting of several

pages (think wizards and such).

Even more interesting... Nice disclaimer:

The package is so complex! I don't understand anything!

Sorry, HTML_QuickForm_Controller is not intended for PHP newbies. If you don't

understand what classes are, if you have no prior experience with QuickForm,

if you are a fan of copy-paste programming then this package is not for you.

The package is indeed complex, but so are the problems it is trying to solve.

Try to rewrite any of the enclosed multipage form examples without using such

a package and you'll see what we mean.

HTML_Template_Flexy

http://pear.php.net/manual/en/package.html.html-template-flexy.attribute.input.php

Another Template language.. Only funny thing is that <INPUT NAME"name"> is

recognized as a language element. Automatically default values can be added.

HTML_Template_IT, HTML_Template_Sigma

http://pear.php.net/manual/en/package.html.html-template-it.intro.php

http://pear.php.net/manual/en/package.html.html-template-sigma.intro-syntax.php

Template language that uses HTML comments (<!-- my comment -->) as language

elements.

HTML_TreeMenu

http://www.wiki.cc/php?title=HTML_TreeMenu

Class to create either a DHTML (javascript) or a listbox menu. The

class will generate HTML. Javascript files should be installed as well.

HTTP_Download

http://pear.php.net/manual/en/package.http.http-download.intro.php

HTTP_Download provides an interface to easily send any arbitrary data to HTTP

clients. HTTP_Download can gain its data from variables, files or stream

resources.

This package contains also functions to limit the bandwidth per file.

I18Nv2

http://pear.php.net/manual/en/package.internationalization.i18nv2.intro.php

The work on I18Nv2 has actually started as a refactoring of I18N, but after

some time I figured out that too many BC breaking changes were applied, so the

release of a new major version was suggested.

Translation2

http://pear.php.net/manual/en/package.internationalization.translation2.intro.php

Translation2 is a class for multilingual applications management. It provides

an easy way to retrieve all the strings for a multilingual site from a data

source (i.e. db). The API is designed to be clean, simple to use, yet powerful

and extensible. A Translation2_Admin class is provided to easily manage

translations (add/remove a language, add/remove a string).

Table structure is:

Langs table: Contains all the languages, and descriptions.

Strings table: Contains for each string ID different translations of the

string. (Each column represents a language.)

Logging

http://pear.php.net/manual/en/package.logging.log.php

http://www.indelible.org/pear/Log/guide.php

Logging class, contains:

- factory / singleton to get a log instance.

- Priority (severity?) can given to a log message.

- Masks can be used for more specific priorties.

- Many handlers: Console, Display, Error_log, File, Mail, Null, Database, Syslog.

Mail_IMAP

http://pear.php.net/manual/en/package.mail.mail-imap.intro.php

http://www.spicypeanut.net/index.html?content=Mail_IMAP/index&sid=40e342be7b6063c8d33314a29cf53147

Mail_IMAP provides an object-oriented backend for working with the PHP

c-client (imap) extension. The c-client extension provides functionality for

connecting to IMAP, POP3 or NNTP mailboxes. Mail_IMAP acts as a wrapper for

the most used c-client functions providing parsing of multipart messages,

intelligent message body retrieval as well as header parsing and retrieval.

Maybe not that interesting, because it needs the c-client extension.

Net_Server

http://pear.php.net/manual/en/package.networking.net-server.intro.php

Net_Server provides an interface to create daemon application based on the

sockets extension of PHP 4. In order to use Net_Server you need a PHP version

greater or equal PHP 4.2, it is meant to be used with PHP-CLI.

Maybe we can make somekind of eZ publish deamon that keeps track of the

authorized users, etc. The stuff Derick is working on.

PHP_Compat

http://pear.php.net/manual/en/package.php.php-compat.intro.php

Provides missing functionality in the form of functions and constants for

older versions of PHP.

This way we can use the latest version of PHP with all it's functions.

This package contains also functions for PHP 5.0 and 5.1.

Structures_DataGrid

http://pear.php.net/manual/en/package.structures.structures-datagrid.intro.php

Structures_DataGrid is a package with the purpose of rendering a data set into

a tabular structure in a specific output format. Possible output formats are

(X)HTML, XML, XUL, Excel .xls spreadsheets, CSV, or console tables.

The datagrid can be assigned to an DB_DataObject or DB_Result. So the datagrid

can retrieve the needed information itself.

Moral of the story: If DB is a nice object, we can use it in other (higher

level) API's. In eZ Publish it could be an EzPersistentObject.

Text_Wiki

http://wiki.ciaweb.net/yawiki/index.php?wiki=Text_Wiki

The Text_Wiki package allows you to transform text structured using Wiki rules

into any defined target output format, such as XHTML, RTF, LaTeX, and so on.

Maybe we can support it as an input format.

VersionControl_SVN

http://pear.php.net/manual/en/package.tools.versioncontrol-svn.php

VersionControl_SVN is a simple Object-Oriented interface for the svn

command-line application that makes up the core of Subversion, a

free/open-source version control system.

Store (and versioning) your files from your CMS in SVN.

XML_sql2xml

http://pear.php.net/manual/en/package.xml.xml-sql2xml.intro-simple.php

Write a table as an XML document. Maybe we can use something similar as import

and export functionality.

XML_Beautifier

http://pear.php.net/manual/en/package.xml.xml-beautifier.php

Make an XML document better readable for humans.

XML_Serializer

http://pear.php.net/manual/en/package.xml.xml-serializer.php

XML_Serializer serializes complex data structures like arrays or object as

XML documents.

XML_RPC

http://pear.php.net/manual/en/package.webservices.xml-rpc.intro.php

http://www.xmlrpc.com/

Search_Mnogosearch

http://search.mnogo.ru/doc/

Pear has a wrapper class for the Mnogosearch engine. Maybe we can use this

engine.

Other less interesting packages

Benchmark

Cache_Lite (Nice to have a Cache class, that's about it. Needs to start PHP anyway.)

Date_Holidays

Crypt_Chap

Event_Dispatcher Like the design pattern. With PHP 5, we can do cooler things.

File_DICOM Haha, storing X-ray images. Good thinking, Pear.

File_Fstab

File_Passwd

MP3_Id

Spreadsheet_Excel_Writer We use OpenOffice, and thereby it writes to an old file format (BIFF5).

Archive_Tar	PHP implementation of tar. If the extensions bzip and gzip are installed, the

package can also handle compressed tars. Quite cool, but not really usefull

for us.

File_Find Find a file with a certain pattern.

File_SMBPasswd

File_SearchReplace

File_HtAccess	Class to write .htaccess files. Unfortunately, it only supports writing passwords.

HTML_Form	Simple class to create forms. No template compiler support.

HTML_Table

HTML_Template_Xipe	Template engine without documentation.

Pager	Devide output over multiple pages, links back and forth are created automatically.

Pager_Sliding	Deprecated.

HTTP	Contains: Date, head, negotiateLanguage, and redirect classes.

HTTP_Client	High level API for HTTP_Request

HTTP_Request GET and POST a webpage. (Can create a proxy)

Image_graph	Create a graph.

Image_text	Text in image manipulation.

Mail	Mail class to send mail using smtp, sendmail or the php mail() function.

Mail_Mime	Package to enable easy creation of complex multipart emails.

Mail_Queue	Queue mail in the database, and use a cronjob to send them. ZzzZZz..

Net_CheckIP	Check an IP address.

Net_DNS DNS querying and packet parsing.

Net_DNSBL	Check whether an IP is listed in the DNS Blacklist. (I think this is useless to prevent a DoS attack, far far too slow.)

Net_Finger	Finger your users.

Net_FTP	OO wrapper for the PHP FTP functions.

Net_GameServerQuery	Consists of a number of classes for connecting to, and parsing information from any game server

Net_Geo	Get geo location of an IP number.

Net_Ipv4	Conversions to another format of an IP4 number.

Net_Ipv6	Compress, decompress IPv6 nrs.

Net_NNTP	Deprecated.

Net_NNTP_Client	Connect to a newsserver.

Net_Ping	Execute a ping command.

Net_POP3	POP3 connection.

Net_Portscan	Check available services on a target machine.

Net_SmartIRC	A PHP class for communication with IRC networks, which conforms to the RFC 2812 (IRC protocol).

Net_SMTP	SMTP authentication mechanism.

Net_Socket	Create a socket connection to a server.

Net_Traceroute	Wrapper class for traceroute calls.

Net_Whois	Does a whois query.

phpDocumentor	This package provides automatic documenting of PHP code API directly from the source.

PHPUnit	PHP unit testing.

Stream_Var	Handle variables as if it was a file.

Structures_Graph	Package for creating and manipulating graph datastructures.

Structures_Tree	Not available, not interesting.

ProcWatch	A small collection of classes to ease monitoring of system processes.

Text_Password	Create pronouncable, unpronouncable or obsecure passwords.

Services_Ebay	Access the Ebay services (sandbox, etc).

HORDE review

Installation script of horde:

http://cvs.horde.org/co.php/framework/install-packages.php?r=1.14.10.1

General discussion

Horde Library (uses PEAR and is going to be available as a PEAR channel.)

Horde Framework (Build upon the Library.)

Horde Applications (Build upon the Framework.)

This is pretty close to eZ Publish:

eZ Components

eZ CMS

Website

Versions 1.0 and 1.2 were completely useless as a framework, and could only be

used in combination with IMP (webmail). We have to make sure that we don't

make the same mistake. (Or the mistake is already in the current library.)

New applications based on the Horde, should have a specific structure. (More

or less how our extensions look like.) We should have these kind of standards

as well. This structure or skeleton can be retrieved via CVS.

Horde has not much documentation (just like PEAR). And is quite hard to

install.

Components in Horde

File_PDF

The File_PDF class provides a PHP-only implementation of a PDF library. No

external libs or PHP extensions are required. (Based on FPDF.)

This class is cleaner implemented then 'our' implementation.

Auth

Provides basic functions to add, remove, update, list, and test for

authentication of users. Class overrides provide also: FTP, IMAP, LDAP, SMB,

SQL, etc.

Prefs

Looks like storing <input> HTML tags info to database or session.

Data

Data class is an abstract class which provides the interface for importing and

exporting data between horde and external applications. The implemented data

formats are: CSV, icalendar, imc, outlookcsv, tsv, vcard, vnote, vtodo,

Palm_databook.

DataTree & DataTree_sql

Store objects to a tree. Like we treat the content_tree, but not really

optimized to get quickly all children from a certain parent. (Like our root

string: 2/3/12/4).

Editor

The Editor package provides an rte editor for the Horde Application *Framework*.

The source code comes from: http://www.dynarch.com/projects/htmlarea/

Form

Class to create and validate forms. Looks a bit like QuickForm from PEAR.

Graph

Provides a set of graph backends and methods for creating graphs as HTML tables, SVG images, etc.

Not much code and relies on PEAR.

iCalendar

Import calendars from different formats: vCalendar, vtodo, vnote, vjournal,

etc. Not really interesting.

Maintainance

Upon login of a (specific) user one or more maintainance tasks can be

triggered to run. This can be done: yearly, monthly, weekly, dayly, every

login.

MIME

Determine MIME type for various content.

MIME_Viewer

[horde]/lib/MIME

The MIME_Viewer class provides an abstracted interface to render out MIME types into HTML format.

29 different Mimes are supported. Like: msword, css, php, zip, rar, tgz,

vcard, pdf, etc.

Mobile

Class to generate content for your mobile: WML, HDML, CHTML. Isn't this cool?

Perm & Perm_DataTree

Perm_DataTree adds the permission system to the data tree. Perms keeps track

of the user permissions.

RelationShip_Manager

Create relationships among objectIDs. The relationships are stored in the data

tree.

Horde_RPC

This is an abstract class. Implemented RPCs are: Soap, syncml, webdav, xmlrpc.

SyncML

Implementation of SyncML. For those (including me) who do not know what that

is, wikipedia says:

SyncML (Synchronization Markup Language) is a platform-independent information

synchronization standard. Existing synchronization solutions have mostly been

somewhat vendor-, application- or operating system specific. The purpose of

SyncML is to change this by offering an open standard as a replacement.

Several major companies such as Nokia, Sony Ericsson and Siemens AG already

support SyncML in their products.

Text

Several classes to cleanup text or to convert it to HTML.

IMSP

Internet Message Support Protocol, the services that IMSP provides are

extended mailbox management, configuration options, and address books.

Net_SMS

Implements an SMS service based upon some commercial SMS providers:

clickatell, sms2email, and vodafone_italy.

Text_reST

Don't know.

The Text_reST class represents a parse node of a reStructuredText document and

provides an API for parsing reStructuredText documents.

VFS API for abstracted file storage and access.

Generic way to read and write to fi]es, database, and ftp.

Would be really handy if it had something like rollback.

less interesting packages

Image	Draw and modify images from different formats: gd, png, rgb,

svg, ImageMagic, swf (uses Ming).

MIME	Classes to handle MIME

Notification	Observer pattern for raising and showing messages.

Perm	Assign permissions to a category.

Secret	Write stuff encrypted to a cookie

Templates	2.2.8: Templates are just HTML with PHP-tags (with PHP code). 3.0: simple find and replace template parser.

Horde_Browser	The Browser class provides capability information for the current web client.

CLI	AFAIK: Minimal CLI implementation.

Compress	gzip, tar, tnef, zip, dbx compression.

Cypher	Cipher class provides a common abstracted interface to various Ciphers for encryption of arbitrary length pieces of data.

Date	Some date functions.

Group	Add groups to the datatree.

History	Add History objects to the datatree.

Identity	Read all user identies from the Prefs. (And then?? )

IMAP	IMAP implementation.

LDAP	2 static LDAP functions. (Where is the rest?)

NLS	Provide Native Language Support. Includes methods to detect timezones, and hostname to country lookups.

Scheduler_cron	Cron replacement in a CLI script.

Horde_search	Implements only the google, search-tha-web beta API.

Serialize	Transforms data to other data (eg. gzip, urlencode). Don't think that it handle data-structures.

SessionHandler	Handle and store sessions in: MySQL, SQL, Oracle, PSQL.

SessionObject	Store objects into a session.

Share	Store shares to the data tree. Couldn't find the exact meaning of a share.

SQL	Some static functions to help you with your SQL.

Test	Script to test Horde.

Timer	Simple interface to time functions.

Token	Write 'tokens' to the database or file. Token = (address, id, timestamp)

Tree	View a tree in HTML or in another renderer.

Horde_UI_*	Several classes to help you to create HTML: Table, Tabs, Pager, etc.

Horde_Util	Several classes to help you in the PHP code.

Text_Diff	Find some diffs.

VC	Version control wrappers

VFS_ISO	Write and read from an ISO. Is not a subclass from VFS, so it uses other functions.

XML_*	More XML classes. Bad documented like the rest.

Results planning phase

Global decisions

What do we need to do

- Decide on a higher level what things we want in our library, for example do we only want simple building blocks, but also things that define more of how an application should work. Discussed and finalized in:9.1.2.

- Create a list of typical functionality that developers will need when building a PHP application. Discussed in9.1.6.

- Go over the list created in the above step and see what we need to add / or not or what is missing. Also discussed in 9.1.6

- Packaging. Discussed and finalized in: 9.1.3.

- Discuss what we want to move out of the current library to the kernel, remove altogether and add. We'll go through Frederiks and Rays list with java/.dot/pear/horde reviews and see if they found something interesting there, and other general ideas we might come up with.

- Creating a diagram of current dependencies, and what dependencies we want to have left in our final library. Also discuss how we want to do configuration settings. The original dependencies are listed in 9.2, and they are discussed in 9.4. What to do with configuration dependencies is discussed in 9.1.4.

- Go over Amos' diagram to specify inter-package dependencies

- Make a list with things we want to refactor, and in which way we want to do that. Done in9.6

- See which parts of our library can be better done with PHP functionality instead, what we want to rely on being there and how/if we want to do fallback to our implementation.

- Add description for all packages.

- Discuss filestructure, classnaming and other coding standards.

What the Component library actually is

horde goes higher level than normal and we should stay away from that, we might want to put up the module/view thing up later, but we don't have resources.

in the components we should not have anyuthing that requires a table in the database. we have nothing against more higher level things like the MVC or the permission system we have anything against index.php in a component (An application) a javascript lib to ajax component as one component later can be considered components should have as littel depcs as possible no inter-dependendant

Packing and Installer

We discussed very briefly which package system and installer we're going to use for the components, and decided to go with the PEAR installer and Package system.

Configuration Discussion

Pass config settings to constructor if not too many and useful. Another good idea is to pass an array of settings to the "config()" or something method and no tiny method to set each setting. Perhaps adding constants for setting names is a good idea either. We need to check per class what we want, as long as we stay consistent in what we do. Also, how we use eZINI to pass settings to objects. By doing so we can remove all dependencies on the eZINI class.

Debugging

Instead of creating a debug class, we'll create a debug handler that sits on top of PHP's error handler. We then use PHP's functions trigger_error() to send information to that handler where we'll parse the message. This also would work if the error handler is not there, then PHP's normal error handler would be called. We only need to make sure that we can make Xdebug work with this. We remove the dependency on eZSys from eZDebug as we need to implement the filtering of input variables for SERVER[REMOTE_ADDR] with the filter extension in PHP.

List with things that a web app needs

Legenda:

[p] PHP solves this

[-] We do it partly

[+] We do more than it

[*] We do it

[T] TAL (Take A Look)

[X] Not in the library

Performance Enhancing Tools

caching - disk, memory, database, shared memory [-]

persistant php objects between requests [T]

clustering tools [ ]

Application Framework

Input/Output

processing input vars [p]

localization [p]

internationalization [p]

templating [+]

translations [*]

sending mail [-]

output handling: headers (cache headers, file downloads) [T]

Debugging/Logging

properly handling fatal errors [*]

error logging [*]

debugging [*]

output handling: logging [-]

development/production states of a application [T]

Web Server Interaction

cookies [p]

sessions [p,+]

redirection [*]

request path handling / vhost settings [-]

properly handling timeouts [T]

http/https session switching [X]

session management [-]

Others

console scripting [*]

configuration handling [-]

user/group permissions - authentication and authorization [ ]

search engine support [T]

Communication Tools

web services: XML-RPC interface [p]

web services: SOAP [p]

XML parsing [p]

content import [X]

content export [X]

File Processing

image analysis: exif [p]

file based permissions [p]

uploading files [*]

image analysis: gif [*]

image conversion [-]

Storage

database API "abstraction" [p]

database SQL "abstraction" [-*]

persistant objects [-]

file storage/stream (db/file) wrappers [T]

Functionality to move the library to kernel

Class eZExpiryHandler - This is a very eZ publish specific class.

Class eZExtension - This code is much more related to the kernel than the components. The components will use a plugin system where appropriate.

Class eZFunctionHandler - This class relies heavily on a specific module structure. This should be moved outside of components and reviewed for eZ publish 4.0.

Class eZHTTPPersistence - I don't see why this is an external class

Class eZModule - Since this will be reworked for eZ publish 4.0 it will be moved to the kernel until that time.

Class eZModuleFunctionInfo - This class relies heavily on a specific module structure. This should be moved outside of components and reviewed for eZ publish 4.0.

Class eZModuleOperationInfo - This class relies heavily on a specific module structure. This should be moved outside of components and reviewed for eZ publish 4.0.

Class eZOperationHandler - This class relies heavily on a specific module structure. This should be moved outside of components and reviewed for eZ publish 4.0.

Class eZOperationMemento - This class relies heavily on a specific database table. This should be moved outside of components and reviewed for eZ publish 4.0.

After more discussion we have come to the conclusion that we will try to put the module/view system into the library as well. It does need heavy refactoring though so there is still some work left on it.

Things we move from kernel to the library

We went over the lists that Jan and Derick created during the review process, and we decided on each of those suggestions whether we are going to add to the Components or not. This is the resulting list with our initial suggestions:

Class eZAutoLinkOperator - Is quite general so can be part of library.

Class eZBinaryFile - The metadata extraction code should be generalized in the library. [ deal with this later, also rename it ]

Class eZCache -	Can we find a way to move this to the library? It would need a form of plugin system to allow all kinds of caches to be added. If this is done the PHP script bin/php/ezcache.php should also be moved. [ rename, manages caches ] - we should have other code subscribe to the cache manager class, so that we have an overview, can clear etc...

Class eZContentObject - The internal memory caching might be something worth adding to the library if there is a nice way of generalising it./ Basicly we need a system ala QCache in Qt which holds a certain amount of objects in memory (controlled by max cost and cost per object). An extension in PHP might be needed to do this efficiently. [ should go in, in a limited form - we can later always add plugins for say apc and srm and what not ]

Class eZFilePasstroughHandler - The code for outputting a file (with range support) must be moved to a general class. [ ranges for download handlers should be added, also make sure we can do ranges with fpassthru/streams, http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html ]

Class eZi18nOperator - Without INI settings code it is general enough for the library. [ rename to *translation*-name component. This should be a general translation class, managing it's own caches - where it can subscribe to it - and sources etc... ]

Class eZPersistentObject - This can be placed in the library, it is pretty general. [ needs cleaning up, perhaps a different name, take a look at PEAR::DB_DataObject, add private data functionality and data interigity check ]

Class eZSimpleTagsOperator - A general operator which is quite useful for highlighting entries in	comments etc.

Class eZTemplateDesignResource - This is a quite useful resource handler for the template system.	Unfortunately it has tight bindings with the kernel, for instance INI settings for design, design file structure and override files (override.ini). [ take a look at it and try, remove old code, make sure you can configure the structure where it's found... etc ]

Class eZTemplatesStatisticsReporter - It is an interesting feature to have during template development, but relies on some kernel modules at the moment. [ Frederik says to fuck it ]

Class eZURLOperator - The operators ezurl, ezroot, ezsys, ezhttp and ezini can be moved. ezdesign and ezimage relies to much on knowledge on design structure. ext_url relies in ezurl class which uses DB tables and should not be in library. [ rename to "general url handling stuff" to create/maintain url paths with vhost/non vhost etc... perhaps integrate with ezsys ]

Class eZWordToImageOperator - All operators can be used in the library with some tweaks. [ rename to something else, all "icon" operators here too - template add-on ]

Package Groups with original classes and dependencies

The following chapters contain all the classes found in the library as of eZ publis 3.6 and their dependencies on other classes. The list is sorted by the packages the way we want to have them in Components.

PDF

Class Cezpdf [l]

eZINI

Class Cpdf [l]

eZMath, eZExecution

Class eZPDF

eZINI, eZDebug, eZDir, eZFile, eZPDFTable

Class eZPDFTable

eZINI, Cezpdf, eZMath, eZMimetype, eZSys, eZDebug

Class eZMath

No dependencies, should be merged with the others above

Request Handling

Class eZSys

eZINI, eZDir, eZDebug

Class eZURI

eZINI, eZSys

Class eZFilePasstroughHandler

eZDebug, eZExecution

Class eZURLOperator (General URL munging stuff)

/* unknown */

System Information

Class eZSysInfo

eZSys

Translation

Class eZ1337Translator [e]

eZTranslationManager, eZTranslatorHandler

Class eZBorkTranslator [e]

eZTranslationManager, eZTranslatorHandler

(Development for translations)

Class eZShuffleTranslator [e]

eZTranslatorGroup

Class eZTranslatorHandler

Class eZTranslationCache [l]

eZDebug, eZINI, eZDir, eZSys, eZTextCodec, eZPHPCreator

Class eZTranslatorManager

eZTranslatorHandler

Class eZTSTranslator

eZTranslatorHandler, eZTextCodec, eZTranslationCache, eZDebug, eZINI, eZExtension, eZDir, eZDebugSetting, eZXML

Class eZi18nOperator (Translation class)

eZINI, eZTSTranslator, eZTranslatorManager, eZTemplate, eZTemplateCompiler, eZTemplateNodeTool, kernel/common/i18n.php

Archive

Class eZArchiveHandler

eZFileHandler, eZINI

Class eZBZIP2Handler

eZCompressionHandler

Class eZCompressionHandler

eZFileHandler

Class eZGZIPCompressionHandler

/* no dependencies */

Class eZGZIPZLIBCompressionHandler

eZCompressionHandler, eZSys, eZDebug

Class eZTarArchiveHandler

/* no dependencies */

Date

Class eZDate [l]

eZLocale

Class eZDateTime [l]

eZLocale, eZDate, eZTime

Class eZTime [dp]

eZLocale

Database

Class eZDB [l]

eZDebug, eZINI, eZTextCodec, eZExtension, eZNullDB

Class eZDBInterface

/* no dependencies */

Class eZDBTool

eZDB

Class eZMySQLDB

eZINI, eZDebug, eZDBInterface, eZCharsetInfo

Class eZPostgreSQLDB

eZINI, eZDebug, eZDBInterface, eZDebugSetting

Database Schema

Class eZDBSchema

eZDB, eZINI, eZFile, eZDebug

Class eZDBSchemaChecker

No dependencies

Class eZDBSchemaInterface

eZINI, eZDebug, eZDebugSetting

Class eZLintSchema

eZDBSchemaInterface, eZDebug, eZINI

Class eZMysqlSchema

eZDBSchemaInterface, eZCharsetInfo

Class eZPgsqlSchema

eZDBSchemaInterface, eZDebug

Debug

Class eZDebug [r]

eZSys, eZDir

Class eZExecution

No external dependencies

File

Class eZDir [r]

eZINI, eZSys, eZDebug, eZFileHandler

Class eZFile

eZDebug, eZDir

Class eZFileHandler

eZSys, eZDebug, eZINI

Class eZMD5

eZFile

Class eZMimeType__ (FileInfo??)

pcre, eZDebug

FileInfo

Class MimeType__

Image Analyser

Class eZEXIFImageAnalyzer

eZMIMEType structure

Class eZGIFImageAnalyzer [l]

eZDebug, eZMIMEType structure

Class eZImageAnalyzer

eZMIMEType, eZExtension, eZDebug, eZINI

Image Handler

Class eZImageGDHandler

eZDebug, eZINI, eZSys, eZImageHandler, eZMIMEType structure

Class eZImageHandler

eZSys, eZINI, eZDebug, eZMIMEType

Class eZImageManager

eZINI, eZSys, eZExpiryHandler, eZDebug, eZExtension, eZMimeType, eZImageHandler, eZImageAnalyzer, eZDir, eZFileHandler

Class eZImageShellHandler

eZSys, eZINI, eZDebug, eZImageHandler

Image Creation

Class eZImageFont

Class eZImageInterface

eZDebug, eZDir, eZINI

Class eZImageLayer

Class eZImageObject

eZDebug

Class eZImageTextLayer

eZDebug

User Input Handler

Class eZFloatValidator [l]

eZRegExpValidator

Class eZIntegerValidator

eZRegExpValidator

Class eZInputValidator

Class eZRegExpValidator

Uploaded File

Class eZHTTPFile

eZDebug, eZINI, eZSys, eZDir, eZLog, eZMimeType, eZHTTPFile

Wizard

Class eZWizardBase

eZHTTPTool, eZDebug, eZTemplate, eZModule

Class eZWizardBaseClassLoader

eZHTTPTool, eZDebug, eZTemplate, eZModule

WebDAV

Class eZWebDAVServer

eZXML, eZMimeType, eZDir, eZSys, eZINI

WebTools

Class eZHTTPTool [d]

eZDebug, eZSessionStart, eZExecution, eZSys, eZINI

Class eZWeb [l]

Currently uses eZSys and eZDebugSetting, with the refactor this is not an issue anymore.

Configuration

Class eZINI

eZDebug, eZDir, eZTextCodec, eZLog, eZFile, eZSys

Locale [l]

Class eZLocale [l]

eZDebug, eZINI

Logging

Class eZLog

eZDir, eZSys

Mail

Class eZMail

eZTextCodec, eZINI, eZSys, eZCharsetInfo, eZPublishSDK

Class eZMailTransport

eZDebug, eZINI

Class eZSendmailTransport [r:mta transport]

eZINI, eZMail

Class eZSMTP

Class eZSMTPTransport

eZSMTP (smtp), eZINI, eZMail, eZDebug

Application Framework

Class eZModule [l]

eZINI, eZDebug, eZHTTPTool, eZProcess

PTKPHPC

Class eZPHPCreator

eZINI, eZDir, eZDebug, eZFile, eZLog

Template

Class eZTemplate

eZTemplateFileResource, eZINI, eZDebug, eZTemplateMultiPassParser, eZTemplateIncludeFunction, eZTemplateCompiler, eZTemplateNodeTool, eZAppendWarningItem

Class eZTemplateArithmeticOperator

eZTemplate, eZTemplateNodeTool

Class eZTemplateArrayOperator

eZTemplate, eZTemplateNodeTool, eZPHPCreator

Class eZTemplateAttributeOperator

eZTemplate

Class eZTemplateBlockFunction

eZTemplate, eZTemplateNodeTool, eZPHPCreator, eZDebug, $GLOBALS['eZTemplateRunOnceKeys']

Class eZTemplateCacheFunction [l]

eZTemplate, eZTemplateNodeTool, eZPHPCreator, eZINI, eZExpiryHandler, $GLOBALS['eZCurrentAccess'], eZDir, eZFile, eZSys, eZDebug, eZDB

Class eZTemplateCompiledLoop

eZTemplate, eZTemplateNodeTool, eZTemplateCompiler

Class eZTemplateCompiler

eZINI, eZDir, eZSys, eZTextCodec, eZLocale, eZHTTPTool, $GLOBALS['eZCurrentAccess'], eZPHPCreator, eZDebug, eZDebugSetting, eZTemplate, eZTemplateOptimizer, eZTemplateNodeTool

Class eZTemplateControlOperator

eZTemplate, eZTemplateNodeTool, eZPHPCreator

Class eZTemplateDebugFunction

eZTemplate, eZTemplateNodeTool, eZDebug

Class eZTemplateDefFunction

eZTemplate, eZTemplateNodeTool

Class eZTemplateDelimitFunction

eZTemplate, eZTemplateNodeTool

Class eZTemplateDigestOperator

eZTemplate, eZTemplateNodeTool

Class eZTemplateDoFunction

eZTemplate, eZTemplateNodeTool, eZTemplateCompiledLoop, eZTemplateLoop, eZDebug

Class eZTemplateExecuteOperator [r]

eZTemplate, eZTemplateNodeTool, eZPHPCreator, eZDebug, eZFunctionHandler, eZINI

(fetch functions)

Class eZTemplateFileResource

eZTemplate, eZTemplateNodeTool, eZPHPCreator, eZTemplateTreeCache, eZTemplateCompiler, eZTextCodec

Class eZTemplateForeachFunction

eZTemplate, eZTemplateNodeTool, eZTemplateCompiledLoop, eZTemplateLoop

Class eZTemplateForFunction

eZTemplate, eZTemplateNodeTool, eZPHPCreator, eZTemplateCompiledLoop, eZTemplateLoop

Class eZTemplateIfFunction

eZTemplate, eZTemplateNodeTool, eZTemplateCompiler, eZDebug

Class eZTemplateImageOperator [l]

The 'image' and 'imagefile' operators is based on code in the image library (and Image extension), if the problems there are not fixed we should move them. The 'texttoimage' is quite cool to have but it should be simplified (code wise and API wise).

Class eZTemplateImageOperator

eZTemplate, eZTemplateNodeTool, eZPHPCreator, eZINI, eZSys, eZDebug, eZImageFont, eZImageTextLayer, eZImageObject, eZImageLayer, eZDir

Class eZTemplateIncludeFunction

eZTemplate, eZTemplateNodeTool, eZTemplateCompiler

Class eZTemplateLocaleOperator

eZTemplate, eZTemplateNodeTool, eZLocale

Class eZTemplateLogicOperator

eZTemplate, eZTemplateNodeTool

Class eZTemplateLoop

eZTemplate, eZTemplateLoopSequence

Class eZTemplateMenuFunction [r]

eZTemplate, eZTemplateNodeTool, eZINI, eZTemplateCompiler

Class eZTemplateMultiPassParser

eZTemplate, eZTemplateNodeTool, eZTemplateParser, eZPHPCreator, eZDebug

Class eZTemplateNl2BrOperator

eZTemplate, eZTemplateNodeTool

Class eZTemplateOperatorElement

eZTemplate

Class eZTemplateOptimizer

eZTemplate, eZContentClass

Class eZTemplateParser

eZTemplate

Class eZTemplatePHPOperator

This needs to support multiple parameters, also maybe type checking?

Class eZTemplatePHPOperator

eZTemplate, eZTemplateNodeTool

Class eZTemplateRoot

eZTemplate

Class eZTemplateSectionFunction

eZTemplate, eZTemplateNodeTool, eZTemplateSectionIterator, eZTemplateCompiler

Class eZTemplateSequenceFunction

eZTemplate, eZTemplateNodeTool

Class eZTemplateSetFunction

eZTemplate, eZTemplateNodeTool, eZTemplateCompiler

Class eZTemplateStringOperator

eZTemplate, eZTemplateNodeTool, eZTextCodec

Class eZTemplateSwitchFunction

eZTemplate, eZTemplateNodeTool, eZTemplateCompiler

Class eZTemplateTextOperator

eZTemplate, eZTemplateNodeTool

Class eZTemplateToolbarFunction

eZTemplate, eZTemplateNodeTool, eZTemplateCompiler, eZINI

Class eZTemplateTreeCache

eZTemplate, eZINI, eZDebug, eZDir, eZTextCodec, eZPHPCreator

Class eZTemplateTypeOperator

eZTemplate, eZTemplateNodeTool

Class eZTemplateUnitOperator

eZTemplate, eZTemplateNodeTool, eZPHPCreator, eZLocale, eZINI

Class eZTemplateWhileFunction

eZTemplate, eZTemplateNodeTool, eZTemplateCompiledLoop, eZTemplateLoop, eZDebug

Class eZTemplatedesignresource

eZINI, eZDebug, eZTemplateFileResource, eZTemplate system, eZPHPCreator, eZExtension, eZSys, eZDir

Session

File ezsession.php [r]

eZDB, eZINI, kernel/classes/ezcontentclass.php

TextUtils

Class eZAutoLinkOperator (Small little util)

eZINI

Class eZSimpleTagsOperator

eZINI, eZExtension, eZTemplate system

Cache

Class eZCache (Cache manager)

eZFileHandler, eZDir, ezi18n() (kernel), eZSys, eZExpiryHandler, eZSubtreeCache

Class eZContentObject (this is the caching thing, limited form)

PersistentDataObject

Class eZPersistentObject

eZDB, eZDebug

ConsoleTools

Class eZScript (eZCLI/eZScript merger)

eZPublishSDK, eZDebug, eZCLI, eZINI, eZDebugSetting, eZExecution, eZExtension, eZDB, eZSession, eZUser, eZModule, eZTextCodec

Graphical representation of the dependencies

Depency Discussion

We went over the diagram containing the original dependencies to see where we could break dependencies, this lists documents our results ans reasoning:

eZMail Dependency

Doesn't have to rely on eZSys, as we can use php's PHP_OS constant.

eZSession Dependency

Remove dependency on eZContentClass, as that was just silly.

eZTemplateCacheFunction

Remove dependency on eZContentClass.

TextTools

Basic code in this package, and create a easier way of using simple functions in the template language. Another option might be to have a glue package template addons which provides the link between the template language and the texttool.

eZScript

Relies on sessions and DB now, but that code should be moved outside of eZScript. Is merged with eZCLI. Dependency on eZExecution is ok, as we find it useful that you can set shutdown handlers for this.

eZExecution

Should get a different name later.

WizardBase

Uses HTTP tool for input variables now, redirect dependency to input handling package (filtering). It shouldn't rely on template as a hard requirement, but other people want to use other output handlers here. We need a glue package that can tie in a wizardbasedisplayhandler which pulls in the the template dependency. Remove dep on Module::Redirection, instead use redirection and pass relative (for the app) URLs to the wizard configuration settings (ctor).

eZSysinfo

SHouldn't rely on eZSys for OS figuring out - can use PHP's constant PHP_OS for that.

eZWebDavServer

Should not use var_directory, should be specifier in the constructor But we keep/add the dependency to eZLog as we think it's silly to have tie-ins for this. We make an logging interface that allows a specific logging class to be passed to the webdav server if it implements the interface; if it doesn't we don't log. Remove depencency on eZDir - mkdir is already in PHP and instead of creating a random dir, we can create a random filename to prevent name clashes.

eZMimeType

Check and fix PHP's function for this, with an additional function to rescan a file (which we then can provide if needed).PHP now also has problems with parse errors and enabling debug - then everytning is text/plain.

eZHTTPTool

doesn't have to rely on sessions, external app should start the session. Replace &sendHTTPRequest with fopen + context. We don't want to do passthru here anyway, and we have that in another class : eZFilePasstroughHandler Remove dependency on eZSys for server port, which we likely don't use anymore.

eZFile

Should not use file seperator and ostype, as there are PHP constants for this.

eZGlibZLibCompressionHandler

should not use dl() for loading a shared extension, that also means we don't have to rely on eZsys here.

eZTranslation

Does not depend on phpcreator anymore because of var_Export in php. We for now make it depend on the cache, but we should really try to break this and come up with something better for this.

eZCache

dependency to eZSys should go, as it only uses the var directory.

eZImage

Needs to be generalized, so textotimage can be used outside the template language

eZTemplate

Now no longer depends on the ezimage operator, but here we use a tie-in too. Same for Locale and eZINI. Don't use the eZDir::path and eZDir::mkdir eZSys::cachedirectory -> we can get rid of eZFile dep. TemplateCompiler: don't readl usefullurl from ezhttptool, so we can get of ezweb package dep too if we kill the ezhttp operator, which we want to do as you should not use business logic in your app.

eZImageInterface

Remove use of ezDir::path and eZDir::mkdir.

eZIMageAnalyser

Stop relying on the mimetype structure, just use the normal file paths. createForMime() doesn't need a mimetype structure either, just the normal mime type string.

eZImageManager

Don't use eZDir:mkdir and ::DirectoryPermission

eZPDF

eZDir::mkdir and eZFile::create are not required (both have PHP equivalents)

eZPDFTable

Don't use eZSys:CacheDirectory, use a configure setting.

CPDF

stream() function should no tbe here, the application should request the data and stream it itself (or with eZPassthroughHandler)

eZTranslation

Uses eZSys::cacheDirectory and eZDir::path, this should use a configure setting in the constructor.

eZTSTranslation

Uses eZDir::path which can be removed.

eZMimeType

SPlit into a FileInfo package as "subpackage" of eZFile and a package for getting mimetypes: eZMimeType

eZHTTPFile

Don't use eZDir::mkdir eZDir::directoryPermissions and ezMimeType. Don't rely on eZLog, as that was only needed for clustering, which we want to solve with a streams hook. DOn't use eZSys:storageDirectory, should use a config variable.

eZFile

Don't use eZMimeType, use mime-type string and basename()

eZINI

Don't use eZDir::path, ::mkdir and eZFile::splitlines as for all we have PHP functions and/or constants now. Don't use eZSys::lineSeperator, we have a constant there; and ::backupFilename - this format will be set through a constructor info. The available information goes to eZSysInfo. Don't use eZLog:: as that is for clustering right now. Need to talk with wez about a generic handler for this.

eZLOG

Uses eZDir::mkdir, use PHP function. Doesn't use eZSys anyway.

eZDBSchema

Don't use eZFILE::getContents, but PHP's file_get_contents.

eZArchive

Seems to be relying on the filehandler, which is going to be replaced with streams. So we don't need this dependecy anymore.

eZImageShellHandler

Don't use eZSys::ostype, use php constant. Seperate shell stuff out of eZSys into it's own subpackage of Request Handling.

Small discussions about little points

Form input handling and filtering.

In every view/action define a list of http input variables that you expect, and filter the input too.

Discussion points:

- name

- how things are passed-on to templates:

$vars = $form->getVariables();

$template->setVars($vars);

vs.

$template->setObject($form);

Logging and audit trail? (eZLog)

We already have eZLog which does basic file logging. We need to extend that a bit so that we have multiple logging handlers.

Access Methods (eZSys)

Needs to be a reimplementation of eZSys without all the hacks and workarounds of all the stuff we have now. FastCGI should be supported too. Virtual Hosts/ non virtual hosts.

Sessions

Nothing new, just should use filtering().

Checkout: How we can use a static class.

Tools vs. Utils in packagenames

we go for *Tools instead of *Utils

Other things:

We need to check xdebug can throw another user defined error handler in the trigger_error case for our new debugging

Amos talks about xmlreader, which is cool and we can use that to replace dom, except that's not enabled by default.

Refactorlist discussions

The following list contains a discussion of all the refactoring comments from the review phase and a discussion of each comment.

Class eZArchiveHandler

Add support for zip files (maybe as PHP extension too? does a GStreamer PHP extension exist?)

Use streams, and no,there is no such php extension yet.

Class eZAutoLinkOperator

An improved version without regexps would be nice. I believe there are some bug reports on this too (or were they fixed?).

No problems as we know actually.

Class eZCLI

Currently this class handles both terminal output as well as web. It might be a good idea to split out this code into two separate classes which inherit from a common base class, or to just remove the web based code. Maybe this could help solve the problem with outputting errors and general information in classes, the same class might be used in a console script as well as a web app.

Option might be an "output handler" with a null handler.

Member eZCodePage::convertStringFromUTF8 (&$multi_char)

UTF8 is limited to 4 bytes only

Not important, we won'tuse that code anymore.

Class eZDebug

Code for logging should also be seperated into it's own class, again with a similar reason as above, and also because it's cleaner.

Use log interface.

Member eZDir::directoryPermission ()

Doesn't belong in a generic tool class.

Instead we make this into a configure variable for each class which requires it.

Class eZExecution

Currently this class handles fatal error and premature exits, should it also handle unhandled exceptions or is the task for another class?

set_exception_handler, and we shoul add it.

Class eZFilePasstroughHandler

This code should be changed to use the general file output code in the library (after move)

No, instead we will use *this* class and not eZFile.

Class ezforwardcompressionhandler

wrappers are evil - i think we should get rid of the shell method anyway. pear requires gzip to be enabled or atleast really wants it so we should not have to rely on external tools anymore. the shell thing is also not done yet, even more reasons to kill it. (Wrapper are not at all evil, they are common object oriented techniques (such as proxy pattern) which work quite well. However if native PHP functionality can handle the file+compression handling we should go for that).

Agreed on this.

Class eZGIFImageAnalyzer

If we could find a way to generalise this in a PHP extension (GD?) using C code it would be beneficial. e.g. a common function to return detailed information about any given image file.

We need to look into this.

Class eZi18nOperator

The hardcoded check for eng-GB must be removed, also the name of the translation file (should be determined externally of this operator).

We'll use ICU locale names.

Member eZImageAnalyzer::create ($analyzerName)

Instead of relying on the extension system to find the handlers it should have an internal array of directories to search, or even better an array that maps a handler to a PHP file directly. (Maybe both?)

We'llprobably want to send a mapping to the function and create another class/package (eZPlugin__) with helper functions to help an application to search easily.

Class eZImageGDHandler

This uses the Image extension in PHP which is a bit messy and also has had lots of problems when dealing with true-color and indexed image formats at the same time. Some effort must be done to ensure the Image extension is good enough for our use. Some things that should be done is:

Make it possible to clone one image resource but with different geometry and without copying any pixels. (basically a clone of the canvas settings). (see isImageTrueColor() and imageCreate() )

A more object oriented way of dealing with images, instead of a normal resource it could be an object with functions to call. This is PHP 5 right? (see isImageTrueColor() and imageCreate() )

Much better text handling, see Qt library for ideas. One problem has been not knowing about baselines in the text which means automatic placement of text is hard.

True color and pixel handling, now you have to allocate a true-color value and set it with setpixel, true color should be able to set directly, often they are calculated per pixel.

Doing pixel operations in PHP is quite slow so it might be a good idea to have more SIMD operations to run on a given area in the image, these operations can also be optimized for a given CPU (MMX, 3d now etc.)

Proper alpha-blending when combining images and image with text.

Taking a look at the QPainter in Qt will probably yield some ideas.

What we need to do:

Figure out if GD has a problem with 2 color PNGs seeing them as true colour or indexed.

Check out what we do with text and baselines.

Fix up setpixel.

Check alpha blending for writing text to images.

Class eZImageShellHandler

This uses the system() PHP function which are known to have problems in Windows when both the exe path is quoted and its parameters. This issue must be solved before the libs are finished.

Check out what PHP does here, seems fishy.

Class eZINI

Generalize with caching class - not every class should implement it's own way of caching. We can then also more easily implement different cache solutions (such as apc_fetch()/apc_store()).

We just remove all the extra stuff. But we do want to design something better, so that you can do overriding on this, also have global settings, per-site, and overriden settings.

Class eZLocale

This should be split into multiple classes to wrap around PHP 5.5's ICU functions for this information and PHP 5's new datetime functionality. Basically it means that this class is quite obsolete then.

We use locale in PHP, so we can get rid of quite some stuff here.

Class eZNoCompressionHandler

Doesn't do anything, so we shouldn't have it. (No need for it if we go for PHP streams, otherwise it is a perfectly valid example of the null pattern).

We'll be going for streams.

Class eZNullDB

Do we really need this class?

No, probably go with exception.

Class eZRandomTranslator, Class eZShuffleTranslator

This is kinda pointless, I suggest not to keep this class when porting

We'll keep them as examples.

Class eZSys

rename magickQuotes to magicQuotes.

Actually, we don't have to deal with magicQuotes anymore if we use the filter stuff.

Class eztararchivehandler

Rewrite from scratch, the code here is incomplete when it comes to the TAR standard (e.g. USTAR, Posix). Some useful urls:

http://en.wikipedia.org/wiki/Tar_(file_format)

http://www.gnu.org/software/tar/manual/html_chapter/tar_8.html

http://www.mkssoftware.com/docs/man4/tar.4.asp

Note: The best would be to get this in C as an extension in PHP.

We should fix this PHP code, perhaps implement with a stream.

Class eZTemplate

Make transaction support in compiler, that means it will only overwrite compiled files once all of them are finished. E.g. the template compiler will start a transaction at the start and only commit when all is done while the on-demand compiler will commit after each file.

Instead of implementing this here, we\ll make a separate package that does file based transactions.

Class eZTemplate

Add strictness levels. E.g. the lowest level should allow quite a lot of mistakes and run/compile the template even with errors, the highest level should not allow mistakes in files, e.g. wrong structure, if one is found it should generate an empty structure (internall or compiled) with only a huge warning. The template compiler script should stop on such errors.

Syntax errors should give a fatal blow up in your face error. The other semantic error should be covered by the webtesting tool, later we can probably add a compiled version without checks.

Class eZTemplate

Removal of the compiled+process mode, leave only compiled. If possible do the new opcode work now (see prototype).

Fine, as long as it doesn't create huge arrays. Interal we use opcode, and on disk compiled files. We will not execute the internal op arrays. Important is: no large arrays, easy optimization.

Some operators should be simplified . ie. not accept both arrays and strings.

Untangle the dependency mess, make sure as little code is included and executed.

We should clearly define what operators and functions are - sepearte their concepts totally.

Class eZTemplatedesignresource

This class does too much, separate the override loading/caching from the actual template file matching.

Reduce complexity by removing flexibility.

Class eZTemplateNl2BrOperator

'break' operator does the same functionality, this should be removed.

No objections.

Class eZTemplatesStatisticsReporter

Find a way to generalise the code, e.g. move out the kernel module references (can be set using methods?).

All urls in the system should be relative, why do we use full urls?

Icons are currently part of the admin design, how can this be generalised.

The Template system will get a config setting that tells it to store template statistics. After processing this information should be extractable with a method, which the eZTemplatesStatisticsReporter then can use to do whatever it wants with.

Class eZTSTranslator

Should use the new XML parser stuff and the unified caching solution

Check how memory efficient SimpleXML is.

Class eZTSTranslator

Do we really need translator handlers? It seems to be there just to be there adding additional complexity

We keep it.

Class eZWebDAVFileServer

Incomplete, doesn't work - we can either ditch it or fix it. I'd say it's an example that doesn't belong in the library

Kill it, if we have time we can make an example out of this.

Class eZWebDAVServer

Add support for propall and propname.

Check if the clients actually support them, if so, we can it it otherwise not.

Class eZWebDAVServer

Make sure the php://input bug is fixed in PHP 5.

Amos'll have a look at the php://input bug.

Having a second look at the interface and design of this class might be a good idea. Also looking at what we want to support of the DAV standard. Maybe a JAVA/.net/other component might give use some ideas.

Agreed, we need to check this.

Figure out a smarter way to debug this class, currently it is quite hard to do so to find errors. I would guess exceptions might help us quite a bit here, as well as better logging.

If things go really really really really wrong, we can perhaps have a look on

how to use exceptions here. We also need to check why our fatal error handler

didnt work here.

Better support for virtual folders/files, e.g. to have to multiple handler types at once. A way could be to map a given path to a given handler, or an object oriented way where a handler may pass on a request to another sub-handler.

Agreed

See if we can define a way to send extra properties back to the client, need to a look at DAV to figure out this is handled by servers and clients.

Check also if we can use permissions here.

Class eZWizardBaseClassLoader

The fate of this class depends on eZWizardBase, so it might not be kept in components.

We decided to keep Simon, the Wizard.

Member eZSessionRegenerate

This is a good idea, but we need to make sure it *does* do as we expect

We need to check how and if this works correctly.

File eztc.php

It should support compiling to temp files and when all files are done the original are overwritten.

That's the transaction thing again.

Components design version 0.1

This is the status of the design of the Components after the first week of the go through period. It consists only of global descriptions of the various packages and a global overview of the design based on the classes already found in the libraries. Still to do in the go through period:

Time estimates

Add functionality that we have not been thinking of yet?

Review comments on the functionality. Add any functionality that is not present yet.

Do a final decision on what goes in and what does not.

All of the above will be done around Thursday July 21 2005.

Packaging

Components will use the PEAR packaging system to store and distribute the library. This means that the various packages can be updated independently of each other.

Functionality in the first version

The following list contains a global discussion of all the packages found in the first version of the library. This list should give you a pretty good impression of what we will include in the first version. Items marked with “?” are somewhat uncertain still.

Application Framework [?]

The application framework package contains the basis of a module and view system that can be used to build many types of PHP applications. Each module should consist of a set of functionality that can be used throughout your application. The views represent the actual GUI built on top of this functionality.

Time estimate:

Archive

A set of classes that implement stream wrapper around the different archival methods, such as tar and different compression methods such as gzip and bzip2.

Cache

This package contains generic functionality for storing cache files on your system. It also contains a system to distribute messages about content changes on your site. This system can be used by your application to regenerate or remove the caches in other parts of your application.

Configuration

The configuration package provides the tools to store configuration settings for your application. Configuration options are stored on disk using INI files. The configuration package supports manipulation and storage of INI files in addition to the possibility to override settings using the override system.

Console Tools

Provides functionality for working on the console. This means the ability to parse options to scripts and output to consoles.

Database

Provides database API and SQL abstraction for SQL databases. It also contains tools for more advanced database operations such as finding specific tables and cleaning them up.

Database Schema

The database schema package provides the means to maintain database schema's for several different database implementations. Database schema stores your database in a common XML format and it is possible to create an sql file for each database, create an XML file from any database and to diff the changes between versions of your database. The changes can be provided as an upgrade SQL.

Date

A package that deals with processing dates and times, including formatting for different locales. The classes wrap around PHP's date functionality and add some extra methods that make working with date and date intervals a bit easier.

Debug

The debug package provides advanced tools for debugging of your application. Typical features are several configurable levels of debug output, application timing and nice and consistent output of your debug information. The debug package is called only through PHP which means that your application will not rely on the debug package even if you use it.

File

Provides support for file operations which are not covered by PHP or are just missing.

File stream

This package provides functionality that wraps file storage. It can be set up to store files in a database as well as on your filesystem.

File Info

Provides functionality for examining files in more detail and doing typical operations on their attributes. It can provides analysis on the file using MIME-Types and can also encapsulates information about a file or directory in objects which can easily be modified or queried.

Image Analyzer

Provides functionality for analyzing image formats and return detailed information about them, such as getting the EXIF information from a JPEG and TIFF or animation information from a GIF.

Image Creator

Provides functionality for working with images and text. It can generate images from texts as well as layer images and text together into a final image.

Image Handler

Provides functionality for doing more advanced operations on image formats. The package handles image conversion, filtering such as scaling and convenient alias management.

Locale

A package that provides functionality to format all kinds of information in a locale-dependent formats. This will most likely be an interface to ICU's locale functionality.

Logging

A set of classes that handles different kinds of logging methods. Provided methods include a file based logger that also supports log-rotations and a database based logging engine. Each logging engine is build as a handler to minimize external dependencies. We will also try to make the functionality general enough so it can be used to do event logging and create audit trails.

Mail

The mail package provides functionality for sending and receiving mail. It supports easy sending of multipart MIME and HTML mail and also provides a simple way to control and send mail using the template system.

Multi-Request [?]

This package provides functionality to make persistent requests that go over several client requests. This is useful if your application must perform long operations that would normally time out.

PDF [?]

This package provides functionality to create advanced PDF files directly from PHP. The package supports tocs, fonts, tables, headers, images, links, headers, footers and margins. The package is not based on any third party tools. You can use the template system to create PDF files through the template tie-in package.

Persistent object

Provides a functionality for dealing with database data in a unified way. The actual SQL calls are abstracted so the implementor only needs to worry about which data to retrieive.

PHP Creator

A class that let's you build a PHP file without that you have to take care about it's formatting such as indentation. Later on we might want to add tools to analyze or process PHP code too.

Request Handling

A package to handle incoming requests in a correct way. This includes managing different sets of urls for setups such as a VHOST setups (where a whole application is the only thing in a virtual host), setups where the application is installed in a directory). A class to work with URLs and access specific parts of a request (as seen in an applications view) is included too.

Search [?]

This module will provide the functionality to make your application searchable through existing search engines. It will be compatible with search engines available in the common market.

Session

A package to handle and manage sessions. This works again with tie-ins to specific session handlers to minimize dependencies and offer more flexibility. The management features include listing active sessions, disconnecting sessions and linking sessions to user(id)s. It also manages SSL/non-SSL session switches and v.v.

SRM

This module will provide functionality to keep data in memory and to have it available from PHP independent of web requests. This allows you to store common data in memory which will make access to it much faster than both file access and database queries.

System Information

Provides access to information about the underlying Operating System, such as installed Memory and CPU as well as platformed dependent items such as directory separator and EOL style. It will cover the things which are not immediately handled by PHP constants and functions, those that are handled by PHP will be properly explained.

Template

Provides functionality for separating layout and design from the PHP code. The template system supports compiling the code into PHP code to speed up the execution and allows third party add-ons to be made. The template system can be used to generate HTML pages, text files and emails.

Text tools

The text tools package contains simple text to HTML transformation tools including tools to automatically convert URLs into links and a tag based language that is transformed into more advanced HTML.

Translation

A system for translating websites' static information, such as labels, help fields, menu options etc. The system works with a definition file and special translations can be plugged in easily.

Uploaded file

The uploaded file package provides easy access to files uploaded by clients over HTTP. The uploaded file is available as a temporary file that you can choose to move to its final destination. If you ignore the file it will be deleted at the end of the request.

User Input Handler

This set of classes addresses the basic needs of filtering user originated data, such as GET, POST and COOKIE data. It builds on top of PHP's filtering extension and allows you to register your own filters too. It also provides a class that you can use to elegantly handle a set of input variables in f.e. the collection of a HTML form providing correct filtering with means of a definition structure.

Webdav

This is a component that let's you easily build a webdav server to handle file uploads and downloads. For each different mime type the webdav server can call a specially registered handler to handle storage of the file and/or do external processing on the file before processing it further in the application.

Web Tools

Provides advanced functionality for dealing with the Web or HTTP, such as advanced redirection and web client detection.

Wizard

The wizard package provides the means to create wizard like web-pages where the user has to go through a procedure over several pages. The wizard package will store temporary values in session variables.

Dependencies between the packages

The following diagram shows the various packages and their dependencies. The diagram does not (yet) contain the functionality that is new in the library.

Comments

SOAP support to persistent object. (Can be done through storage interface)

More generic message package (SMS, Jabber, ICQ, internal etc.) This would be nice to have functionality that

In general a process tool that can do any kind of process. (Wizard)

Document generation suite. Through openoffice etc.

Text tools: spell checking

If we get GL's danish project they we will get payed to research:

spell checking

document handling

Update 0.1.1

In this update we have:

Added time estimates

Updated the diagram with the new functionality and removed an extra dependency.

Added time estimates

79 / 81

2005-02-24T11:15:07