Please login or register.

Login with username, password and session length
Advanced search  

News:

You need/want an older version of sNews ? Download an older/unsupported version here.

Pages: 1 [2]

Author Topic: php coding - why the *really* wide lines?  (Read 13245 times)

funlw65

  • Hero Member
  • *****
  • Karma: 96
  • Posts: 771
    • Country Lab
Re: php coding - why the *really* wide lines?
« Reply #15 on: April 16, 2008, 03:25:22 pm »

 :) I`m watching this thread with MAXIMUM interest... please, continue :D. For first time, as a very newbie, html_input scared me... Now, I consider it handy... but I am for improvements...
Logged

Joost

  • Guest
Re: php coding - why the *really* wide lines?
« Reply #16 on: April 16, 2008, 03:31:35 pm »

My suggestion about using commas instead of dots, was based on 4 articles and one test run by myself, which (I thought) showed remarkable results. However, after running some more tests yesterday, I was not able to replicate these results.
So either, we are looking at a myth, or later versions, like php5 which I am using now, are optimized to take care of that.

Logged

Keyrocks

  • Doug
  • ULTIMATE member
  • ******
  • Karma: 449
  • Posts: 6020
  • Semantically Challenged
    • snews.ca
Re: php coding - why the *really* wide lines?
« Reply #17 on: April 16, 2008, 05:43:49 pm »

Doug, did you look at the 300x numbers?  echo takes 1.73 seconds to complete, now think about echoing html_input....

Actually, why was html_input put in place of the html blocks back in 1.4?

Help me out with a little more background EQ...
1)  What are "the 300x numbers"... and... 2)  expand on your point - echo takes 1.73 seconds to complete, now think about echoing html_input....
(answered below by the "Baker")

EDIT - REVISED
As noted earlier... I still have a copy of Mika's snews1531DE.php file. It's been some time (pre-1.6) since I've looked in it.
Taking a look at the notes Mika provides for the // FORM GENERATOR function... This function essentially determines how the echo  html_input strings work. They do have purpose. They all have the same format. Where each is used... it is customized using the 15 values-options. I'll bet there are very few of us who have really come to understand how the // FORM GENERATOR function works and how useful it is. Here's that section from Mika's 1531DE.php file... with his comment notes...

Code: [Select]
<?php

// FORM GENERATOR
function html_input($type$name$id$value$label$css$script1$script2$script3$checked$rows$cols$method$action$legend) {
# Form generator builds XHTML form tags based on inserted parameters.
# label for input tags (required: $id, $label; optional: $css, $js1-3)
$lbl = !empty($label) ? '<label for="'.$id.'">'.$label.'</label>' '';
# id used in most of the tags (id="$id")
$ID = !empty($id) ? ' id="'.$id.'"' '';
# class is optional for most of the tags (class="$css")
$style = !empty($css) ? ' class="'.$css.'"' '';
/* ----------------------------------------------------------------------------
   JavaScript behaviour attribute is optional for most of the tags.
   (usage example: onclick="javascript: DoSomething();")
   - You could add up to three JavaScript behaviours at the same time: $js1, $js2, $js3
-----------------------------------------------------------------------------------------*/
$js1 = !empty($script1) ? ' '.$script1 '';
$js2 = !empty($script2) ? ' '.$script2 '';
$js3 = !empty($script3) ? ' '.$script3 '';
# $attribs is a set of usual or optional input attributes (id, style, JavaScript) merged into one variable for easier maintenance.
$attribs $ID.$style.$js1.$js2.$js3;
# value is required in some of the tags (value="$value")
$val ' value="'.$value.'"';
# input is starting attribute of some form tags (required: $type, $name; optional: $attribs)
$input '<input type="'.$type.'" name="'.$name.'"'.$attribs;
switch($type) {
/* -------------------------------------------------------------
- This switch is based on the input TYPE attribute.
- Some types require several attributes, and the others just one or two.
  (examine each type and try to recognize it's pattern)

<form> requires action and method (attributes are optional)
- formatted as:
  <form method="some-method" action="some-action" (attribs are optional)...>
- if all the parameters are ommited and the $method parameter has value "end",
  it will display end tag </form> (not used in basic sNews engine).
----------------------------------------------------------------*/
case 'form'$output = (!empty($method) && $method != 'end') ? '<form method="'.$method.'" action="'.$action.'"'.$attribs.'>' '</form>'; break;
/*--------------------------------------------------------------------
  - <fieldset> has <legend> tag already built-in (attribs are optional)
  - formatted as:
    <fieldset><legend (attribs are optional)...>legend-text</legend>
  - if all the parameters are ommited and the $legend parameter has value "end",
    it will display end tag </fieldset> (not used in basic sNews engine).
----------------------------------------------------------------------*/
case 'fieldset'$output = (!empty($legend) && $legend != 'end') ? '<fieldset><legend'.$attribs.'>'.$legend.'</legend>' '</fieldset>'; break;
/*-------------------------------------------------------------------
  - text and password <input> types share the same attributes
  - <label> tag is already built-in
  - formatted as:
    <p><label for="some-id">label-text</label> :<br />
    <input type="text-or-password" name="some-name" id="(the same as in label)" value="some-value" />
    </p>
----------------------------------------------------------------------*/
case 'text':
case 'password'$output '<p>'.$lbl.':<br />'.$input.$val.' /></p>'; break;
/*-------------------------------------------------------------------
  - checkbox and radio <input> types share the same attributes
  - formatted similar to text and password <input> types
    except they require $checked parameter to be "ok" (checked) or empty (unchecked)
----------------------------------------------------------------------*/
case 'checkbox':
case 'radio'$check $checked == 'ok' ' checked="checked"' ''$output '<p>'.$input.$check.' /> '.$lbl.'</p>'; break;
/*-------------------------------------------------------------------
  - hidden, submit, reset and button <input> types comes without paragraph formatting
  (that should be done manually while building form code)
----------------------------------------------------------------------*/
case 'hidden':
case 'submit':
case 'reset':
case 'button'$output $input.$val.' />'; break;
/*-------------------------------------------------------
- <textarea> formatting is quite obvious (I hope :))
- and the result is:
  <p><label for="">label-text</label> :<br />
<textarea....>default-value</textarea></p>
---------------------------------------------------------*/
case 'textarea'$output '<p>'.$lbl.':<br /><textarea name="'.$name.'" rows="'.$rows.'" cols="'.$cols.'"'.$attribs.'>'.$value.'</textarea></p>'; break;
}
# display form tag
echo $output;
}

?>

« Last Edit: April 16, 2008, 06:32:48 pm by Keyrocks »
Logged
Do it now... later may not come.
-------------------------------------------------------------------------------------------------
sNews 1.6 MESU | sNews 1.6 MEMU

Keyrocks

  • Doug
  • ULTIMATE member
  • ******
  • Karma: 449
  • Posts: 6020
  • Semantically Challenged
    • snews.ca
Re: php coding - why the *really* wide lines?
« Reply #18 on: April 16, 2008, 06:34:47 pm »

Doug....EQ is referring to jlhaslip's post

Thanks Bob... I wondered what all those numbers in there were...  :P
It DOES help when someone explains something clearly for folks who have no experience with the subject at-hand.

To summarize jhaslip's results in "layman's terms (for me and anyone who comes across it and wonders what it is), the purpose of this test was to test-run a block of script in three different formats to see which one performed best:
- with each string as a separate echo statement,
- with all strings joined (concatenated) together to parse as one echo statement,
- and as plain HTML script.

Tests were run at five "load" levels:  1, 3, 30, 300 and 3,000 iterations.
The following values are recorded in seconds, rounded off to 6 decimal points.
               
echo format:
1    .000082
3    .000079
30    .000214
300    .002917
3M   1.731710
               
concatenated format:
1   .000073
3   .000080
30   .000176
300   .003134
3M   .8445778
               
html format:
1   .0000830
3   .0000748
30   .0002119
300   .0030589
3M   .7549360
« Last Edit: April 16, 2008, 07:10:47 pm by Keyrocks »
Logged
Do it now... later may not come.
-------------------------------------------------------------------------------------------------
sNews 1.6 MESU | sNews 1.6 MEMU

jlhaslip

  • Sr. Member
  • ****
  • Karma: 16
  • Posts: 374
    • My snews with AEF Forum site
Re: php coding - why the *really* wide lines?
« Reply #19 on: April 16, 2008, 06:38:41 pm »

that value in red (and the two values under it) are for 3,000 iterations of the code.

the really small values on the left are duplicates for a second running of the single iterations.

it didn't cut and paste worth *schmidt*
Logged
Yes! I have no siggy.

centered

  • Guest
Re: php coding - why the *really* wide lines?
« Reply #20 on: April 16, 2008, 07:19:17 pm »

Thanks for clairfying Bob!

I would liek to see a test similar to my inital post in this thread, and if possible, taking the same script and conentating(sp?) it, then testing it.

Why?  Because straight HTML will always be faster because it doesn't have to be parsed (by php), also html_input code is real code being used, and it is code we use everyday (well maybe not EVERYDAY, but you get the picture).  Otherwise the testing is fine, but moot in point, because it is not a real test comparing the function in question.
« Last Edit: April 16, 2008, 09:05:37 pm by equilni »
Logged

codetwist

  • Hero Member
  • *****
  • Karma: 50
  • Posts: 940
Re: php coding - why the *really* wide lines?
« Reply #21 on: April 16, 2008, 08:45:04 pm »

Optimization of html_input ... just curious, what are profiling data for this one. Don't recall numbers but I assume that should be really significant portion of total page building time. Right?
Logged

centered

  • Guest
Re: php coding - why the *really* wide lines?
« Reply #22 on: April 18, 2008, 12:59:14 pm »

Yes it is...
Logged

Joost

  • Guest
Re: php coding - why the *really* wide lines?
« Reply #23 on: April 19, 2008, 08:15:06 pm »

I am beginning to dislike html_input and sometimes just for that one reason another reason is I have disliked not knowing what each 15 parameters are...

I ran a little test: I swapped function settings with a index.php-like piece of code. Memory usage dropped by 100 kb.
Using function html_input leads to:
- a bigger file size.
- More memory usage.
- More complexity
Logged

funlw65

  • Hero Member
  • *****
  • Karma: 96
  • Posts: 771
    • Country Lab
Re: php coding - why the *really* wide lines?
« Reply #24 on: April 19, 2008, 09:27:52 pm »

I am beginning to dislike html_input and sometimes just for that one reason another reason is I have disliked not knowing what each 15 parameters are...

I ran a little test: I swapped function settings with a index.php-like piece of code. Memory usage dropped by 100 kb.
Using function html_input leads to:
- a bigger file size.
- More memory usage.
- More complexity


I hear the wind of change? :D
Logged

Joost

  • Guest
Re: php coding - why the *really* wide lines?
« Reply #25 on: April 19, 2008, 11:59:53 pm »

I am beginning to dislike html_input and sometimes just for that one reason another reason is I have disliked not knowing what each 15 parameters are...

I ran a little test: I swapped function settings with a index.php-like piece of code. Memory usage dropped by 100 kb.
Using function html_input leads to:
- a bigger file size.
- More memory usage.
- More complexity


I hear the wind of change? :D

For me personally, no. :)
I never understood that function and  at first I blamed it on my own lack of insight, acknowledging there might be good reasons for having it coded this way. There might have been good reasons when the code was introduced. Probably there was a plan back then. However, at this point, I see no benefit for sNews at all.
For the same reasons, I kicked out function tags in one of my sNews versions that is living on my desktop. It needs almost 2 kb (looped) code to render a simple html line.
Now, almost one year after writing my first line of php, I code by the following rule:

If I don't understand its purpose, I don't need it. If I don't need it, I don't want... Then I toss it out.

It makes coding easier that way.  ;)
Logged

lessismore

  • Jr. Member
  • **
  • Karma: 0
  • Posts: 67
Re: php coding - why the *really* wide lines?
« Reply #26 on: April 20, 2008, 04:37:24 am »

Interesting info, but I didn't mean to "drag" html_input() performance into scrutiny - only as an example of format.

I used html_input() as an example of how PHP programming seems to want to win an obfuscation award at every opportunity by cramming as much as possible into a single line of code.

In PHP, there is an abundance of tabs (the most inconsistent key on the keyboard) for control structure, but no love for the simple carriage return - the line widths are huge? I don't get it ...

Perhaps I've done too much ASM and C code and just haven't kept up with the times ... ever see the SNL "grumpy old man" skits? There was a skit about programming - "In my day, we didn't program in ones & zeros like you.  We couldn't afford the ones, so we had to program in zeros - and that's the way it was - and WE LIKED IT!".  PHP formatting makes me feel like the grumpy old man.  :)

Thanks - and I know this is only slightly related to PHP as applied to snews (per forum guidelines) - but I respect this community for both technical prowess & courtesy so I don't mind asking marginally relevant stupid questions.
« Last Edit: April 20, 2008, 04:49:41 am by lessismore »
Logged

codetwist

  • Hero Member
  • *****
  • Karma: 50
  • Posts: 940
Re: php coding - why the *really* wide lines?
« Reply #27 on: April 20, 2008, 10:50:49 am »

@ lessismore : Well, it's not 'php programming' because there is no real entity 'php programming' that is writing code on its own. It's programmer who is doing poor implementation job even if initial idea is ok. And there is nothing inherently wrong with idea to provide function or whatever to build formatted output statements. Usually it helps, usually it makes code shorter and usually it reduces maintenance hurdles. Presence of usual benefits is directly related to quality of implementation. As for tabs ... well, actually, a lot of editors and IDE will reformat code; for instance, at least they will replace tabs with spaces if You request that.
Logged
Pages: 1 [2]