[buddypress-trac] [BuddyPress Trac] #5500: Date xprofile field enhancement

[buddypress-trac]

#5500: Date xprofile field enhancement
-------------------------------------+------------------
 Reporter:  sooskriszta              |       Owner:
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  2.7
Component:  Extended Profile         |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |
-------------------------------------+------------------

Comment (by boonebgorges):

 > Field Type is intended to represent a generic type of profile field,
 rather than a specific instance of a field. A Field Type object has no
 value (the value each member inputs) -- its methods that output HTML use
 the templating loop -- so it having a mechanism to store data doesn't seem
 appropriate.

 Right. But fields might have settings or various manners of being
 customized that are specific to the field type. It makes sense that any
 field of the Date type would have "range" properties, but that doesn't
 make sense for any other field type. The Field Type should not be aware of
 any specific field, but this is why I've written
 `BP_XProfile_Field_Type::admin_save_settings()` to require a `$field_id`
 parameter. So the logic is:

 * The field save controller is `xprofile_admin_manage_field()`, which
 assembles a `$field` object from the values in `$_POST` and saves it
 * Once it's set up, I call `$field->admin_save_settings()` (this is on the
 *field* object)
 * `BP_XProfile_Field::admin_save_settings()` does nothing but call
 `$this->type_obj->admin_save_settings( $this->id );`
 * `$_POST` information is extracted as required in
 `BP_XProfile_Field_Type_Datebox::admin_save_settings()`

 So I think the separation of concerns is pretty good - the Type object
 only knows about fields __in general__. The icky part is accessing the
 `$_POST` global inside of the Type object. An alternative would be to put
 all the type-specific settings inside a single `$_POST` key, so that you
 `xprofile_admin_manage_field()` could pass the `$_POST['type_settings']`
 array to the field object. But we already access `$_POST` in the datebox
 field type, when processing `edit_field_options()`.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5500#comment:53>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac