fapi

CCK, Fapilicious and Validation API cooperation

Xano's picture
public
Xano - Mon, 2008-08-18 17:32

This afternoon TapocoL, cYu and I (Kaaskop @ IRC) discussed the possibilities of CCK, Validation API and Fapilicious to work together on form processing. Currently, CCK features built-in validation for specific fields, like addresses. Fapilicious is a library which (though still under development) features built-in field validation for any form field. Validation API mainly is a UI for creating custom validators and using them for CCK fields.

A few of the ideas:

<

ul>


Embed process should be like forms api?

sime's picture
public
sime - Thu, 2007-06-14 12:10

In writing SWF Tools I attempted to follow some design patterns that would make the embedding aspect of it generic. The embedding logic is there, but it's surrounded by a lot of unreleted code. So with the benefit of hindsight, here is a run-through of an "Embed API". Much of this is simply cloned Forms API.


Ahah Forms v1.5 - Secure Dynamic Subforms

starbow's picture
public
group: Javascript
starbow - Sat, 2007-04-07 06:45

At the Drupal Summit, chx & eaton let me know that avoiding the FormAPI security by directly accessing $_POST was a bad idea. So I dropped the slide out of my presentation that talked about how to create dynamic subforms, and spend the last two weeks hacking like mad. I now have an approach that I believe combines convience and security. It is packaged up in Ahah Forms v1.5 as the dynamic_subform.module. It uses the same basic algorithm as drupal_get_form when #multistep is true (but is incompatible with #multistep, so don't try to use both of them).

I have a full write up at: Secure Dynamic Forms and Subforms, but here is an example of the functions in use:


CCK and FAPI 2.0 as Relationship API

adrian's picture
public
adrian - Tue, 2006-05-02 11:57

One of the things I came away with from the Vancouver DrupalCon, is that we already have our relationship API, in the form of CCK and what I want to do with forms 2.0.

Firstly, in forms 2.0, there will be 2 discrete steps.

Step 1: Defining Fields for form. (or node type, or whatever)
Step 2: Placing these fields within their final form structure (add tables, fieldsets etc).

Now I am basing this functionality off of the cck field definitions, so that all the validations and field type
code will be built using cck, and one of these field types is 'nodereference'

CCK already handles all the 'has, can have and single / multiple' bits of the relationship api, and with


Syndicate content