1 xangelusx Aug 04, 2006 18:01
3 xangelusx Aug 04, 2006 21:04
Me again....
Looks like it might be better to just use the value of fieldend. If we call begin_field then we wind up with an extra margin between the label and the info text because it gets wrapped in <div class=input> which has a left margin in the default CSS...
The modified info_field looks like this:
function info_field( $field_label, $field_info, $field_params = array() )
{
if( isset($field_params['format_info']) )
{
$format_info = $field_params['format_info'];
unset($field_params['format_info']); // not an HTML element
}
else
{
$format_info = 'htmlbody';
}
if( !isset($field_params['note_format']) )
{ // Default field_note for info:
$field_params['note_format'] = ' <small class="notes">%s</small>';
}
$this->handle_common_params( $field_params, NULL, $field_label );
$r = $this->fieldstart;
if( !empty($field_label) )
{
$r .= $this->labelstart
.$field_label.$this->label_suffix
.$this->labelend;
}
else
{ // Empty label:
$r .= $this->labelempty;
}
$r .= $this->infostart;
// PAYLOAD:
$r .= format_to_output( $field_info, $format_info );
$r .= $this->infoend;
$r .= $this->fieldend;
return $this->display_or_return( $r );
}
4 blueyed Aug 04, 2006 22:53
Can you provide a unified patch against CVS HEAD ("cvs -q diff -u")? I'll apply it then.
And thanks for investigating.. :)
5 xangelusx Aug 04, 2006 23:05
Erm... I'll try... Got a tut for that?
6 blueyed Aug 05, 2006 00:35
Basically, you'd do "cvs -q diff -u" in a working copy from CVS HEAD. But no problem..
I've looked at your changes and it appears that there's no problem.. in info_field() fieldstart and infostart get outputted and the call the end_field() outputs inputend (which is "infoend" in this case) and fieldend.
It's just that "inputend" gets used to end both "fieldstart" and "infostart".
So, if we do not have a special "infoend" property (is there a need?), all seems fine.
7 xangelusx Aug 05, 2006 03:43
If infostart starts a different tag then a DIV then there is no chance to close it, and since info_field only uses fieldstart, then no opening DIV will be written and now we've got T-A-G S-O-U-P!! :)
My fix above solves the problem since there is no need to write the added <div id=input> anyways.
I should test this fix with the other form layout types to make sure the defaults are OK.
8 blueyed Aug 05, 2006 21:12
I see the problem, if "infostart" is different (tag-wise) to "fieldend" - but nothing apart from this.
And the above problem only arises, if you choose to use an opening tag for "infostart" which is different from "fieldstart" and therefor does not get covered by the "general" "fieldend".
Right?
Do you want to use the Form class in such a way?
9 fplanque Aug 05, 2006 21:58
There is no infoend BY DESIGN.
Please stop trying to fix things that do not produce any visible problem for the users.
10 xangelusx Aug 07, 2006 16:08
I wanted to wrap the info text with <strong> tags. I suppose I can apply a style to the info class to achieve the same thing, but that will obviously not apply to css-less browsers. I'll try to think of a scenario where I might need to use something other than formatting tags.
But you see the problem, though, right? If infostart uses a different tag than fieldend... I won't rehash what I described earlier. Is there a reason why you wouldn't want to allow for this? Try it in one of your forms as-is:
set infostart to something like '<div class="info"><strong>' - there is currently no way to end the strong tag...
11 fplanque Aug 09, 2006 22:31
I see the problem. It has severity 1 compared to other problems which have severity 1000. We cannot waste time on this. The class is not designed to handle strong tags. No big deal.
12 blueyed Aug 10, 2006 00:22
I still have it patched locally, ready to commit it to HEAD.
After pouring over the code a bit more I discovered that I wasn't getting an extra </div> so much as missing it's beginning.
In info_field, instead of calling begin_field you just use the value of fieldstart. But at the end of the function you call end_field which uses not just the fieldend value but also the inputend value. It seems then that the solution is to either call begin_field instead of using fieldstart, or use fieldend instead of calling end_field. Is one solution preferred over the other?