Open jbroadway opened 11 years ago
Playing with a sample conf/fields.php
for a minute...
; <?php /*
[mysocialapp/groups]
name = Groups
type = select
callback = "mysocialapp\Group::fetch_list"
[mysocialapp/geolocator]
name = Geolocator
type = handler
handler = myapp/fields/geolocator
; */ ?>
The first is a hypothetical dynamic drop down that would be populated by the mysocialapp\Group::fetch_list()
method call. The second is a hypothetical custom field type that requires its own handler to render, perhaps for loading additional scripts or render something other than just a simple text or drop down field.
In the extended_fields database table, these would have a type value of mysocialapp/groups
or mysocialapp/geolocator
respectively.
I think these being read from a config file is also more secure than a parameter to enter any arbitrary values for the callback or handler name.
The format for an app's conf/fields.php
works like this so far:
; <?php /*
[mysocialapp_groups]
name = MySocialApp - Groups
type = select
callback = "mysocialapp\Group::fetch_list"
; */ ?>
This will add a "MySocialApp - Groups" to the Custom Fields form, which will render as a drop down field in the Custom Fields section of an ExtendedModel's add/edit forms, with a list of values fetched from the following method call:
<?php // apps/mysocialapp/models/Group.php
namespace mysocialapp;
class Group {
public static function fetch_list () {
return array (
/* replace with db call */
'yes' => __ ('Indubitably'),
'no' => __ ('I should think not!')
);
}
}
?>
To finish up, I'd like to add the handler
custom field type that moves all of the rendering over to a custom handler.
Added docs on this to the updated Elefant 2 docs. Haven't implemented the handler custom field type yet however.
The drop-down custom field type only accepts a static list of options. An alternate 'Dynamic drop down' type could accept a function or method name (e.g.,
myapp/MyModel::get_option_list
) that would be used to retrieve the list of options. This would make custom fields much more powerful.Further, there are still a very limited number of types. A
Dynamic custom
type could accept a handler name (e.g.,myapp/options
) that would be used to render the field itself. This would make any field type possible.Taking this a step further, if an app could define custom fields in a
conf/fields.php
file, similar to how an app can specify embeddable handlers for use in the Dynamic Objects menu, then instead of the user having to know and manually type the method or handler name in the above, they could instead be presented as a list with user-friendly names.