Me being a dummy, just to verify I understand this right

$node->extras['module_something'] = array('#type' => 'form_box, '#value' => $module->something, '#default_value' => 'lorem ipsum ferrets and mounties and bubbles and things');

<?php form_render($extras['module_something'); ?>

The key to this is the #type - if I want to provide some custom, non-form types, can I use #vlados_secret_passion ?

By default render function uses either the order specified, or the #weight property you add.

The only requirement is that you need to only have 1 parameter for the theme function (an associative array). You can re-use any theme function you want by just adding a small wrapper function, like such :

function theme_form_box($form) { return theme_box($form['#title'], $form['#value'] . $form ['#children']); } theme_vlados_secret_passion($form) - not nessesarily theming a form element, just a theme function

On Thu, 2005-12-15 at 12:50 +0200, Adrian Rossouw wrote:

Now before you guys go off an re-invent the world, please realise that the forms api already solves all these problems you guys are trying to solve. Indeed, it was built to do output, and it is already in core.

CCK _will_ be using the forms api structure to output nodes in the future (it makes absolutely no sense to use 2 separate systems, especially since there's a completely flexible system already in core.), so to future proof your code .. please think about building on the work that has already been done for the forms api.

$node->extras['module_something'] = array('#type' => 'form_box, '#value' => $module->something, '#default_value' => 'lorem ipsum ferrets and mounties and bubbles and things');

in your theme / template : <?php form_render($extras['module_something'); ?>

By default render function uses either the order specified, or the #weight property you add.

The only requirement is that you need to only have 1 parameter for the theme function (an associative array). You can re-use any theme function you want by just adding a small wrapper function, like such :

function theme_form_box($form) { return theme_box($form['#title'], $form['#value'] . $form ['#children']); }

In the future, all these wrapper functions will be removed and the original functions replaced with the new form of parameters (which makes all the phptemplate_ stub functions obsolete and allow direct loading of template for any theme function without having to explicitly overload anything ... AND it makes writing a cohesive theme editor a fsckload simpler)

You can also just use the markup property if that's what you want.

-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

I think I get it... thanks for the heads up on the fapi's extended capabilities.... here I've been thinking it was all about forms...

...

I think I get it... thanks for the heads up on the fapi's extended capabilities.... here I've been thinking it was all about forms...

Ditto.

Scott

Would it be accurate to say that in the starry-eyed future of Drupal, 'formapi' will really just be a subset of 'presentation api' or something like that? A standard way of slinging around data such that it can be edited, or rendered, or persisted, or validated, etc? --Jeff

On 15 Dec 2005, at 7:17 PM, Adrian Rossouw wrote:

On 15 Dec 2005, at 6:27 PM, Jeff Eaton wrote:

...

Would it be accurate to say that in the starry-eyed future of Drupal, 'formapi' will really just be a subset of 'presentation api' or something like that? A standard way of slinging around data such that it can be edited, or rendered, or persisted, or validated, etc? Yes.

One of the other not known things about the forms api .. (although .. i am going to refer to it by it's real name .. the view api) is that it also maps cleanly onto xml. It's a tree with properties and children. Meaning we could very simply write an import / export routine for it, that would give us the in roads into distributing CCK node types, (since you can make a package out of a node type, and a package can depend on all the modules it needs.) Now the next thing that this means, is it makes it a lot simpler to write an AJAX form designer.. since you design the element layout (the Model), and then you edit the element placement (the View .. although i think structure is more accurate.) and then it uses the theme api to render this structure. or view. The Controller is the form _submit function, but it's also optional. Also, you should note that every block in a page can now be accessed separately using the right xmlrpc call (if it's enabled of course), and you can refresh certain blocks automatically, on a timer .. or assign it to an event (which could be a link added into that block, or whenever the document changes.) It should also make it easier to expose this interface to flash or xul, since it can use xmlrpc on the back end and redraw the exact forms with the exact validation you'd have on the normal drupal sites. You could even attach ajax events to certain blocks, or just make them completely flash (think lazlo) If we do use the model/structure/view approach , it would be a fsckload simpler to just cache the models and structures, and in the case of high load sites, these things are very good candidates for being stored in shared memory. These are just some of the things possible with the forms api and only some of those more related to this discussion, but hopefully if we work together we can accomplish them. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

On 12/15/05, Chris Johnson <chris@tinpixel.com> wrote:

Adrian Rossouw wrote:

...

One of the other not known things about the forms api .. (although .. i am going to refer to it by it's real name .. the view api) is that it also maps cleanly onto xml.

It's a tree with properties and children.

...

Also, you should note that every block in a page can now be accessed separately using the right xmlrpc call (if it's enabled of course), and you can refresh certain blocks automatically, on a timer .. or assign it to an event (which could be a link added into that block, or whenever the document changes.)

It should also make it easier to expose this interface to flash or xul, since it can use xmlrpc on the back end and redraw the exact forms with the exact validation you'd have on the normal drupal sites. You could even attach ajax events to certain blocks, or just make them completely flash (think lazlo)

Adrian, you're a genius!

If we can do all this without killing ourselves with complexity, or kill our performance, Drupal will completely own the content management and web application space.

Oh, can't we die happily? Robin ..chrisxj

-- Robin Monks, CSL Web Administrator robin@civicspacelabs.org

On Dec 15 2005, at 05:50, Adrian Rossouw wrote:

Now before you guys go off an re-invent the world, please realise that the forms api already solves all these problems you guys are trying to solve. Indeed, it was built to do output, and it is already in core.

But, to bring it down to earth a bit and get back to THEMES : Why should we wait for 4.7 ? What of the many sites that will NOT be upgraded to 4.7? Is there a way to go back to what is ALREADY created and ask module developers to clean what is there based on theme parameters that y'all can agree on? Why can't we ask of developers to do something as simple as going back to their modules and setting DIV TAGS SPECIFIC TO THEIR MODULES? Not shouting, btw, just using caps to highlight. Liza Sabater, Publisher www.culturekitchen.com