Download the PHP package italix/forms without Composer

On this page you can find all versions of the php package italix/forms. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of italix/forms

Informations about the package forms

Italix Forms

PHP Version

Form metadata over a table schema, and HTML rendering for it. You describe the form — labels, sections, widgets, rules — and the fields come from whatever already knows your columns.

Rendering:

Why the fields are not declared here

Because they are already declared somewhere. A form built from a hand-written field list drifts from the table the moment a column is added, and the drift is silent — the form keeps rendering, just without the new field. FormMeta wraps a TableMeta and describes only what the form adds on top: what a column should be called on screen, which section it belongs to, which widget renders it, what must be true before it saves.

The adapters in Adapters/ build a TableMeta from a schema object, an array, or a relation, so the source can be an ORM table, a config array, or something you wrote this morning.

sensitive() is tested adversarially, not asserted

A field marked sensitive() is redacted everywhere the object can be serialised. The suite does not ask the object whether it redacted anything — it plants a recognisable secret in a placeholder, a help string and a custom attribute, then searches the serialised output for the secret. That is the difference between testing the flag and testing the guarantee.

Exclusion is total and separate: excluded fields disappear from each(), all(), by_section(), count() and to_array(). Hidden and excluded are different things and the suite pins both.

Escaping: four implementations, on purpose

FormHtml::esc(), AbstractWidget::esc() and two closures in TemplateWidget each call htmlspecialchars separately. That is duplication and it is deliberate: the house rule that makes a library a leaf means Italix\Forms may not depend on Italix\Encode. The guarantee therefore cannot be centralised, so it is covered instead — the suite breaks when any of the three files loses ENT_QUOTES.

If you are reading this because the duplication looked like a defect: it is the trade, written down. The cost of the alternative is a dependency edge between two packages that are otherwise independent.

TemplateWidget was found uncovered by mutation, not by reading — the first version of the XSS corpus never routed through it, and breaking it changed nothing.

The corpus itself is five payloads pushed through eleven entry points each: 55 renderings, asserting that the raw payload is absent rather than that some entity is present. Plus one assertion that escaping does not strip — that is a data-loss bug a passing XSS test hides.

Rules live elsewhere

Since 2.0.0 the rule vocabulary is italix/rules: Italix\Forms\Validation\Rule → Italix\Rules\Rule. MIGRATION.md, next to this file, has the one-line sed that performs the move and advice on rolling it out in report-only mode first.

Widgets

Rendering/Widgets ships the usual set; WidgetRegistry is how you replace one or add your own. WidgetInterface is the whole contract — a widget receives a FieldMeta and returns markup.

Requirements

php >= 7.4, italix/contracts. italix/rules is suggested: without it, rules() still stores whatever you hand it, but there is no vocabulary to hand it.

All versions of forms with dependencies

PHP Build Version
Package Version
Requires php Version >=7.4
italix/contracts Version ^2.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package italix/forms contains the following files

Loading the files please wait ...