Re: [PHP] functions/methods and what they should return
You want to break off things into as many functions and components as possible. The idea is that if you want to change the way tables are displayed with the data, for instance, you can't break the way data is queried. I usually have a bunch of different files like inc.function.something.php and use lots of require_once() statements. -Dan On Wed, 2003-08-20 at 21:59, Chris W. Parker wrote: Hi people. I'm working on a large application right now (complete ecom store) and I'd like to get some feedback on something. Each product that is in the database can have at least one attribute to it (i.e. color, size, etc.). Right now I've got a method in my Products class called ShowAttributes($id). This method, based on the ID passed to it, will query the db and ultimately return a string that makes up the drop down box for a form. Am I better off doing this sort of thing in a function or having the function only return the records I need and let the calling page handle the display of the records? What do you think about this? Thanks, Chris. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] functions/methods and what they should return
Each product that is in the database can have at least one attribute to it (i.e. color, size, etc.). Right now I've got a method in my Products class called ShowAttributes($id). This method, based on the ID passed to it, will query the db and ultimately return a string that makes up the drop down box for a form. Am I better off doing this sort of thing in a function or having the function only return the records I need and let the calling page handle the display of the records? I usually allow the function get only what i need, thus making it as simple as i possibly can. If you are using it as a drop down function for a form then i would get the data form a generic source and populate it with that information (i.e. i use arrays that hold data for forms, and query the database to find out which item in the dropdown should be selected. So in short: 1. Have a function return only what you need (meaning that it should be in the right format for you.) 2. Have the display page handle all the dropdown logic. -- BigDog -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] functions/methods and what they should return
Dan Anderson mailto:[EMAIL PROTECTED]
on Wednesday, August 20, 2003 3:04 PM said:
You want to break off things into as many functions and components as
possible.
Hmm.. Ok. So right now I've got this (psuedo code):
function displayAttributes($id)
{
// query db
// store results in array
// perform logic that builds HTML string
// return HTML string
}
But instead you think I should do this:
function GetAttributes($id)
{
// query db
// get records
// return record array
}
function BuildAttributes($id)
{
$attributes = GetAttributes($id);
// format $attributes
// return HTML string
}
Is that what you're suggesting?
The idea is that if you want to change the way tables are
displayed with the data, for instance, you can't break the way data is
queried.
I don't understand this exactly. What do you mean by can't break the
way data is queried?
I usually have a bunch of different files like
inc.function.something.php and use lots of require_once()
statements.
Hmm.. Although this sounds like a good idea at first, it seems like it
would get pretty complicated really fast. Am I missing something?
Thanks.
Chris.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] functions/methods and what they should return
Hmm.. Although this sounds like a good idea at first, it seems like it would get pretty complicated really fast. Am I missing something? Well the idea is that on very large programs you create a number of different components that can be used and changed independently. To give you an example, if you don't split up those two functions, and you decide you want to modify the way the results are displayed, it is possible you could accidentally break the database query when updating the way tables are updated. (i.e. debugging is easier because you can test functions in seperate programs. The other thing is (again, on very large programs. for small programs the quick and dirty solution is almost always faster) that if, for instance, you decided you wanted to create a second way to display results you could either cut and paste the original big function and modify it or create two functions that call GetAttributes. But if you cut and paste, when you go to change the way GetAttributes gets attributes you will need to update /two/ functions and not just one. This is one of the reasons why breaking things up into components makes creating and maintaining very large scripts easier. -Dan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] functions/methods and what they should return
function GetAttributes($id)
{
// query db
// get records
// return record array
}
function BuildAttributes($id)
{
$attributes = GetAttributes($id);
// format $attributes
// return HTML string
}
That is a good way...you have the functions only doing what they need to
do. Thus splitting up some of the logic and presentation. In the
GetAttributes function you could do any filtering...but mainly you dont
want to do any presentation because u can now reuse that function other
places.
--
BigDog
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] functions/methods and what they should return
Dan and Ray, Thanks for your help. This helps clear some things up for me! Chris. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] functions/methods and what they should return
While I'm still on my soapbox... There are a number of great books out there on object oriented programming. Basically the idea is to take a top down approach -- decide what components makes up what you want to do, what components make up those components, and so on until you can program common components together instead of having that much more code to modify. And this is a /great/ way to tackle large projects. I have some scripts where I use a 400 line function a dozen times. Much easier to modify 400 lines when needed instead of 4800! But at the same time, for quick and dirty projects it's not efficient. If all you need is a quick 100 line script you'd be bloating your code to use the OOP approach. The simple fact is that when you try to write a function you have to create variables and other things to make it much more general -- and that can be a lot harder then just /doing it/. Plus, on a quick script it may become silly to break down things into components unless you plan on expanding on the script at some point in the future... -Dan On Wed, 2003-08-20 at 22:31, Chris W. Parker wrote: Dan and Ray, Thanks for your help. This helps clear some things up for me! Chris. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
