dotSoftwaredotDevelopmentdotCustomersdotAbout us
PushOk logoblank
fast linksFast Links
news&eventsnews and events

2012-12-21 
Major update of SVNCOM version 1.7.2 are finaly released

2012-12-21 
Major update of SVN SCC plug-in - versions 1.7.2 are finaly released

Lightweight embedded Node.js database with MongoDB API.

SEMA info

Search go
PushOk Logo blank
leftSEMA inforight

At the home page of the project "Pushok SEMA" you can learn about primary goals that we tried to achieve during project development. Below we shall try to describe what actually was done.

1. Not to invent a bicycle

Our system actively employs components of the project pear.php.net. In particular, we use:
- PEAR_DB - as the database abstraction system;
- DB_DataObjects - as intermediate objects for database access;
- Translation2 - as the translation system;
- I18Nv2 - for dates and format localization.
Besides, other (general) capabilities of this package are employed.

2. UTF-8 support

All system data are in Unicode format (UTF-8). This is taken into account when formatting, string length counting and so on. Besides, translation of the client code page into internal server form is automatic. In other words, regardless of the explorer you use and character coding that is set, a text typed in Russian will always remain Russian.

3. Multi-tier implementation

The system is presently divided into server and client parts (this can be seen from the source codes): core part (lib_) and interface part (web_). The client part works only with the core and exclusively through the specified API. The client part doesn't have direct access to the database or other private parts of the core. This means that realization of clients on other platforms or integration of the system with other applications is possible.
PHP is one of the server languages without status support. On one hand this is a disadvantage, but on the other hand, it is not necessary to provide API between the client and the server at the object level. API at the functions level is sufficient. API of that kind is preferable in the sense that it can be "transparently" translated to web-services (for example, SOAP).

4. Rights sharing

This topic is a separate planet. What we have started from: first, we need small enterprise management system. Second, the enterprise can simultaneously develop several independent projects, and only some members need access to this or that project. And third, there exist external members: customers and buyers.
We have chosen something intermediate between UNIX and Windows rights.
- The rights are set for each object and are automatically extended to its descendants (object tasks, for example).
- However, the owner of an object possesses exclusive (maximal for himself) rights.
- Each object can be tagged as (I)nternal and/or (E)xternal.
- The right mask contains fields: R(right to view)W(right to modify)1-5(operation mask)I(internal)E(external).
- Each user has global (maximal) rights for particular objects.
- There can be one or several users with absolute rights (root).

Example 1: A project developer has R12I rights. I.e. he can view everything, perform operations of the first and the second levels. Only internal objects are accessible for him.
Example 2: A client of the project has R1E rights. He can view and perform operations of the first level, but only for external objects.
Example 3: A project manager has RW1234IE rights. He can do almost everything and view all objects.

5. Notifications

Notification subsystem is an integral part of the core. The functions themselves determine when and which notification to send. That is, notifying logic is rigidly threaded in the core. But delivery is a function of a separate subsystem. When a notification appears, the core indicates: object to which the notification is intended, significance of the notification and attachment level. Each user can choose significance and attachment level of notifications which he wants to get. Based on this data, the system decides to whom it would deliver notifications.

6. Speed of work

As it is known, PHP is a script language. It is obvious that for a large system, parsing of all codes, including those that may not be necessary for work, is not applicable. That is why the whole system is based on so-called messages. Each message is processed by one or several functions. And theoretically, all these functions can be located in their own file. In this way minimal parsing time is achieved. And of course other optimization schemes were and will be implemented.

7. Convenient translation

Capability of work with the system gettext (po/mo files) is provided. For that purpose we had to update the library Translation2. By the way, the updates are included into the updated version of the package.

8. Skins and layouts

Their support is provided, but without alternative variants yet.


You are 9513653 visitor since 20 Jan 2003.
3198 visitors today and 1 online right now.
blank left to top right blank

© Copyright by PushOk Software, 2003-2024, webmaster@pushok.com