Download the PHP package lekoala/kaly-forms without Composer

On this page you can find all versions of the php package lekoala/kaly-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?

Informations about the package kaly-forms

kaly-forms

A deliberately small library for framework-independent, server-first form presentation + interaction.

Documentation

It is not a replacement for request mapping or application/business validation. The intended split is:

The core idea is that the form can render itself while rendering remains replaceable:

Form delegates to RendererInterface; HTML is not hard-coded into the form definition.

Intended use cases

1. Simple login form

Named arguments, built-in fields, structural browser/server rules, server errors:

2. Rich server-first form

examples/rich-registration.php demonstrates:

3. Custom field type

A custom field is just a semantic PHP type plus a registered renderer:

No reflection or service discovery is needed.

4. Custom elements

CustomElementField renders a custom element and can keep a hidden native input as the canonical submitted value:

This lets JavaScript own the rich UI while the normal HTML form still owns submission semantics.

Core design choices

Form definition, state and rendering are separate

The form may render itself, without owning HTML policy

Form::__toString() delegates to its RendererInterface. This gives the ergonomic template API:

while allowing a Kaly application, Slim application or a package to inject a different renderer/theme.

For auto-escaping engines (Twig/Latte), optional bridges convert HtmlRenderable::toHtml() to the engine's native safe-markup type, so the template only receives form. kaly-tpl and plain PHP do not auto-escape, so <?= $form ?> already works. See docs/integrations/templates.md.

Server validation remains authoritative

The library ships only structural rules that can also project to native HTML attributes (required, minlength, ...). Business rules stay in the application and are merged into FormState as FormError values.

StructuralValidator is an optional standalone validator: convenient for a light application, but when the application already owns validation (Kaly, Symfony Validator, a domain service, ...) that layer stays the server authority. Do not run both for the same submission unless intentional. See docs/architecture.md.

Interaction metadata, not a JS framework

Conditions and remote option sources are represented as metadata. assets/enhance.js is a tiny, untested reference example, not a supported API: the contract is the data-kf-* attributes and Condition, tested on the PHP side. An application may use sco-pe, custom elements, Alpine, Stimulus, vanilla JS, etc.

Wizard/multi-step is outside the form core

A wizard should own workflow/state and expose one Form per step:

The form library should not become a workflow engine.

Included

Explicit non-goals

Kaly integration

Kaly already owns request input mapping, validation, CSRF and rendering adapters. The integration can stay thin:

A Kaly renderer adapter can recognize HtmlRenderable and turn it into native safe markup, so the template remains:

or the Twig equivalent without a form_* DSL in the template.

Slim integration

No Kaly dependency is required.


All versions of kaly-forms with dependencies

PHP Build Version
Package Version
Requires php Version ^8.3
ext-mbstring Version *
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 lekoala/kaly-forms contains the following files

Loading the files please wait ...