| Package home | Report new bug | New search | Development Roadmap | Status: Open | Feedback | All | Closed Since Version 1.0.2 |
| Bug #3182 | _getFieldsToRender() and _reorderElements() drop fields in certain situations | ||
|---|---|---|---|
| Submitted: | 2005-01-12 21:22 UTC | ||
| From: | ate2 at cornell dot edu | Assigned: | justinpatrin |
| Status: | Closed | Package: | DB_DataObject_FormBuilder |
| PHP Version: | Irrelevant | OS: | Irrelevant |
| Roadmaps: | (Not assigned) | ||
[2005-01-12 21:22 UTC] ate2 at cornell dot edu
Description:
------------
There a some related (I think) issues here:
1. _getFieldsToRender() drops special fields when fieldsToRender property is set.
2. _reorderElements() drops any fields that are not in preDefOrder, including both special fields and fieldsToRender fields
3. even if special elements could be reordered, it would be difficult to specify the correct field name for reordering or other purposes (e.g. field labels).
4. _getFieldsToRender() always includes values returned from keys() but sometimes there are values from keys() that I don't need/want in my form.
so some requests:
1. fix problems 1 and 2 (I've got a solution that seems to be working so far for me (see reproduce code))
2. implement a method or methods like getSpecialElementName($type,$tableName) to reference the element in question
3. consider removing the feature described in 4 or making it optional through a class property
Reproduce code:
---------------
$do =& new DB_DataObject();
$fb =& new DB_DataObject_FormBuilder($do);
$fb->fieldsToRender=array("someField","someOtherField");
$fb->preDefOrder=array("someOtherField");
$fb->crossLinks=array(array("table"=>"links"));
$form =& $fb->getForm();
echo $form->toHtml();
My fix for this issue is available at:
http://environment.cornell.edu/source/DB.DataObject.FormBuilder.phps
Expected result:
----------------
Form with elements:
someOtherField
keyField (from $do->keys())
otherField
__crossLink_links
Actual result:
--------------
Form with element:
someOtherField
Comments
[2005-01-12 21:39 UTC] ate2 at cornell dot edu
Noticed another problem with my fix... the special elements that are rendered are frozen because of a glitch with _getUserEditableFields(). I added an example workaround that resolves this for me to the same place as the other fixes. It involves overriding that method.
[2005-01-12 21:46 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2005-01-12 22:35 UTC] ate2 at cornell dot edu
With point 3, I was trying to imagine a scenario down the road where the naming convention might change and refactoring might be an issue... really is just feature request.
But I still don't like 2. preDefOrder is only supposed to specify the order in which fields are arranged; why should every field have to be explicitly list twice in code if there are one or more fields I don't want displayed? I especially see this as a bug because preDefOrder is doing something that is not part of its API - preventing elements from being rendered.
As for 1, I guess it might just be my taste but it seems more intuitive to eliminate special element fields by not adding them to crossLinks, tripleLinks, etc. properties. Same sort of double-listing issue as with 2, but in this case no method actually does something the docs don't say it does.
BTW, great package, don't mean to be a nag.
[2005-01-12 22:56 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2005-01-13 00:09 UTC] ate2 at cornell dot edu
Thx. I'm not sure whether this changes anything but what I was talking about in 1 pertains only to fieldsToRender. In the workaround I'm using special elements can still be repositioned with preDefOrder. They just don't have to be included in fieldsToRender when that option is used.
[2005-01-13 00:30 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2005-01-14 17:43 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2005-02-02 02:19 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!