Documentation

Here you can find documentation of core, functions, classes, and modules
For code snippets and usage see guides

About

Setrill is a php framework (extended to Javascript an android applications, as a client-server layout) that has been developed for several years. Current version manager first commit is from September 2017, but first commits are coming from November 2011.

Documentation is the key for anything, specially for high levels softwares. This is the main reason why this site is created.

It all started with two separate projects; a project manager inspired on dotproject.net at first, and a website called YoteConozco.com (co-developed with CGodia, and MPampols ) which is now closed. Both shared core parts, and was later on when we decided to name it ;) Setrill is a catalan word for a recipient that contains oil for cooking.

The project manager has been growing and has been deployed on companies. It's intended to be the core of the company, and includes anything, from clients/suppliers, opportunities, projects, accounting, and whatever you can imagine

The project is being developed using multiple private subversions repositories. Sources can be browsed and downloaded from this site. But there is no official repository available on github or any other site.

As a philosophy I have always considered that a company (and also individuals) may own the software it is using (and the data they are generating with). And that's is because i believe in opensource, because it usually (not always) allows you to improve it, and you are usually not stick to a system.

I completely disagree with current deployments of SaaS (Software as a Service), because nor only you can install the software (because usually web based), you are having credentials to use it. What could happens if the company providing the service denies your access (maybe without notifications?), or maybe it's closing it. What would you do with that data you have entered or generated using the application ? If you don't use the service, and close the relationship, what would happen if later on you need the data? Some cases, making a backup or exporting it's easy and doable, but on some applications, this is not as easy and you could lost some data in the process. This is the main reason because always I recomend having your data always accessible on something you own.

I also consider that you have always own and be accessible to your data, and not rely on 3rd parties. Nowadays we usually rely on documents that are available on multiple platforms, witch also includes invoices from companies and banking. But what could happen if sometime later you need it and they are not accessible? (maybe they have considered it's to old data.. who knows). Also if you need to share things with 3rd parties, i'll recommend you always to get the control over the share, for the same reason.

You may have been notice (or not) that there has been no questions on this site about cookies. It's not using them. No need to use them to get it working, and less need to give data to giants and 3rd parties. Only you must accept data treatment related to data processing if you create your login, because we are storing you email and some needed, to get you granted in the site. You can download the full source from here. (developed over Setrill, of course!)

If you like your work and find it useful, or you are using it, collaborate to get it bigger! ;)

Requirements

Setrill needs php Version 7.

Altough it can run as standalone application from console, it's mainly intended to be run on a web server. It has been developed on Apache2 web server running on Debian.

For web applications, requires Apache2 mod_rewrite module to be enabled.

Structure

Folders

Setrill main folders are

  • /classes

    main php classes

  • /include

    common php procedures

  • /modules

    each module can have a submodule, called section.

    • module folder
      • module.class.php
      • config
      • module section
        • section.class.php
        • config
      • ...
    • ...
  • /application

    applicattion overrides. File Structure is the same as root folder.

  • /deploy

    deploy overrides. File Structure is the same as root folder.

  • /cache
  • /log
  • /addons
    • disabled

Each folder under modules is considered a module

Application can define custom folders so they are considered part of a module. By default, modules can haves this folders

  • action

    contains action request files.

  • data data request files
  • cron console request files
  • print

    contrains printing request files

  • dms
  • config
  • images
  • css
  • lang folder, stores translations
  • js javascript code

This information is stored on CApp::module_structure , and it's comoon for all modules and sections.

Scopes

When loading a file, the file loaded will be firstly search on Deploy, Secondly on Application, and finally on Main.

So any file could be overriden.

Main Scope

This is the core part, on modules will be installed

Application Scope

This is a customization for a certain application

Deploy Scope

This is a customization for a final client/location, intended for changing the appearance or specific things.

Classes can be extended to modify, alter, add behaviours on each escope. They must be named as

  • MyClass.class.php
  • MyClass.application.class.php
  • MyClass.deploy.class.php

Css files can be served concatened when accessed as static file if named in this way. This ensures styles are correctly overrided

  • style.css
  • syle.application.css
  • style.deploy.css

In the same way, js files can also be served concatened.

  • code.js
  • code.application.js
  • code.deploy.js

Js files, could be also concated reversely

  • code.js
  • code.prev.application.js
  • code.prev.deploy.js

Installation

At this moment, installation must be perfomed from terminal. Installation is performed using the install entry point.

Entry Points

Start of the application is always on files defined. Project files should never be accessed directly or bypassing the entry points.

Application type is stored on CApp:type

Console Request

The aplication is run from terminal. It is the entry point for installation, and maintenance procedure. It's also been used on automatted runs, or long time exections.

Files are located on cron folder, and entry point file is cron.php

can also be started from application, using CApp:cron_file_exec

Html Request

This is the typical entry points for a site. Files are located on root of module or section folder, and entry point file is index.php

Url file extension is .html

Content can be served as a data request. see getting content from a data call.

Data Request

This is a request to get data from server, to be processed by client.

Url file extension is .xml parameters are usually set by get data

Files are located on data folder, and entry point file is xml.php

Action Request

This is a request to modify data on server. Url file extension is .html and parameters are usually set by post data

Files are located on action folder, and entry point file is action.php

Static Data Request (images, css, js files)

The file is accessed on a location dependending on file extension. In case of css and js files on diferent scopes can be concatenated

The entry point file is static_server.php

Files

The files are accessed on dms folder, and entry point file is file.php

Alternatives

Alternatives are a way to avoid the creation lots of small very similar files. They are defined always on set_alternatives function using set_alternative function.

When using alternatives we will not find the file on the file structure.

Configs

There is main config.php file on /config

Each module has it's own config.php file. Modules can have a predefined config file, called config.new. On first install the file es copied to config.php

Logs

As usual, logs should not be accessible and readable. They are placed on log folder.

PHP Logs

error.log

Store logs outputs from php.

Database Logs

mysql.log

Store mysql queries.

Project Documentation

Setrill and it's module documentation are based on this site.

PHP

Classes

CObject

Flags

_flags
set_flags
check_flags
check_flags

Triggers

Triggers are stored on internal var _triggers

Triggers can be added on app event OBJECT_SET_TRIGGERS or object defined events as 'cobject_set_triggers'

For triggers objects check object triggers

add_trigger
set_triggers
removeTriggers
restoreTriggers

Errors

_error
has_error

Events

_events

Unused vars

_unused_vars

Debugging

print_data
print_data_get_value

CApp

type

module_structure

GetModuleFile

see scopes

getListObjects

store_object

Console

console_output
read_optional

CModule

set_alternatives

set_alternative

CDataObject

set_value

get_value

copy

CDBObject

getDefinition

reset_id

str_id

insert

valid

load

loadFromKey

get_key_value

load

loadAll

update

delete

set_table

optimizeTable

install

upgrade

alter

Quering

Queries are automatically build from data stored in an array

Static funcions available, to get code more cleaner

data_query_field
data_query_multiple

CExtendedObject

addObj

expand_object_on_query

CUnionObject

Addons

Triggers

Object Triggers

CDeleteTrigger

allow_load_deleted
delete_trigger_enable_real
is_deleted

CRleatedObjectTrigger

insert_related_object
assing_related_object
get_from_related_object

CPeriodTrigger

between_start_end_query
load_all_between_start_end

App Triggers

Modules

Setrill

Console Entry points

install

Database

Mysql

Config

Web

Javascript

Layout

Jade

CLayoutJadeFile

CJadeLayoutTrigger
addJadeFile

Javascript

Css