Form API

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
This group should probably have more organizers. See documentation on this recommendation.

This group will talk about how to enhance form API. And also, we will realize that we talk of so please subscribe only if you are ready to code.

dvessel's picture

Request for review on RendElements

Hello theme developers, I created a PHP class for working with Drupal Render Arrays (sub-set of Form API).

The code behind it is fairly complicated and this is the first piece of OO code I focused on so I can't guarantee the quality of it. I'm posting here to let everyone know about it and to get some feedback on the approach and suggestions on possible improvements.

The details on it are in my sandbox. http://drupal.org/sandbox/dvessel/1122312

Read more
mlncn's picture

AJAX Form Messages, an API to provide an enhanced user interface for forms– catching errors before the submit button is hit

This module will provide an API and a UI for immediate inline validation or other checking and responding of form elements. (Contrast this with AJAX module, which validates the entire form via AJAX when the submit or preview button is pressed.)

The ideal will be to automate using (or make it very simple to use) existing form element validation functions as the back-end of inline validators.

The initial motivation was to extend (and make an honest module out of) Unique Fields AJAX checking, but the number of nice-to-haves and ought-to-bes make point the way to a new API for setting message conditions and messages. This will be developed API-first.

Notes from my due diligence are here: http://data.agaric.com/raw/ajax-form-messages-proposed-module

Read more
Xano's picture

Form API: the next generation (FAPI TNG)

I'll just keep this short and simple. Longer stories can be found in my blog. See the links below.

I started working on a new form API because I hate the way the current API works sometimes and there are a lot of others who feel similarly. Key features so far:
- OOP
- More flexible validation
- No more hook_forms()
- No more base form bullshit

Biggest roadblock: elements are now classes. How do we make extending those as flexible and as clean as possible?

Resources:

Read more
markus_petrux's picture

Name for a numeric form element?

Sometime ago I wrote Format Number API and Formatter Number CCK modules. The former implements options at site/user level to define thousands separator and decimal point, also provides APIs to display numbers. The later implements CCK fields for different types of numbers. These CCK fields implement their own numeric form element based on textfield. Too bad! I should have implemented in Format Number API a form element for numbers at FAPI level.

Read more
chx's picture

A better notation?

I have a wild idea, but this is the place to post them.

Let's say you have

$form['level1']['level2']['#options'] = array(....);

instead, let's close the leveling with a ['_'] and omit the #.

So.

$form['level1'][''] = array('type' => 'checkboxes', 'options' => array('this', that'));
$form['level1']'level2']['
'] = another form API element here.

This would save a lot of #.

Some code:

Read more
chx's picture

Dynamic forms

One of the biggest problems with form API is that we need the form API array as it was when the form was created so that we can set values for it. And also we need a current form array to be rendered. This will solve upload problems, multipage forms, poll etc etc.

Let's discuss how to handle this problem.

Read more
Subscribe with RSS Syndicate content

Form API

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: