Recent Topics

1 Aug 04, 2006 18:01    

I noticed that the Forms class was missing an infoend parameter. Being a go-getter, I plopped a value in:

	function switch_layout( $layout )
	{
		
		...

		switch( $this->layout )
		{
			...

			case 'fieldset':
				
				...

				$this->inputstart = '<div class="input">';
				$this->inputend = "</div>\n<!-- END: div class=input -->\n";
				$this->infostart = '<div class="info">';
				$this->infoend = "</div>\n<!-- END: div class=info -->\n";
				
				...

Seemed logic. Most likely just an oversight, I figured. Then made one other quick hack to get it to show up:

	function info_field( $field_label, $field_info, $field_params = array() )
	{
		...

		if( !empty($field_label) )
		{
			$r .= $this->labelstart
						.$field_label.$this->label_suffix
						.$this->labelend;
		}
		else
		{ // Empty label:
			$r .= $this->labelempty;
		}

		$r .= $this->infostart;

		...

Then things got screwy. My fieldset-based forms started looking funky. I got jiggy with it and started troubleshooting (hence the <!-- END div class=info --> comments).

EDIT: see next reply

[strike]---------
Somewhere an extra DIV was getting dropped. I tracked it down to the end_field function which always adds the inputend value. Is there a reason for doing this, or does it make more sense to have each function add the inputend value if appropriate? Was end_field just a time-saving, repetition-avoiding function?

In summary - it would be useful to have an infoend value, but it would require a lot of rewritting to get it to work properly. Is it worth it? (My goal being to fix it in trunk, not just patch it on my copy and keep merging it into future releases)

PS: OK, maybe not A LOT of rewritting, but more than 10 lines for sure. I just want to know that I'm not ruining some well thought out solution that you've already addressed.
---------[/strike]

2 Aug 04, 2006 20:51

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?

3 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 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 Aug 04, 2006 23:05

Erm... I'll try... Got a tut for that?

6 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 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 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 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 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 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 Aug 10, 2006 00:22

I still have it patched locally, ready to commit it to HEAD.


Form is loading...