Re: [PHP] Design question
On Sat, 2011-02-05 at 11:11 -0500, li...@pruimphotography.com wrote: Morning everyone! I have a design question... No it's not about the interior of my house... although I could use some help with that as well... I am working on a framework for my own use (And maybe one day will beat out the popular frameworks! Hey I can dream right? :)) and to increase my knowledge. Here's my current index page: DJ_doctype(HTML4S); DJ_head(Double J FrameWork, $cfgCss, $cfgMeta); DJ_modules(navigation, option); DJ_page(main_content.html, mainContent); DJ_dbconnect($cfgDatabase); DJ_footer(copywrite, Double J Web Design); It all works perfectly but I'm starting to question having a bunch of function calls like that or should I simply have a big master DJ_displayPage() call? or should I have my framework create the html files? Has anyone gone down this road before? any pitfalls I should watch out for that aren't in google yet? :) Thanks everyone! Jason Pruim I guess it all depends on what you need. A little while back there was a discussion on the list about whether or not to leave all content dynamic or have the PHP CMS create the various .html pages required. There are pros and cons to each method. As for the various calls vs a single call to display the page, that depends on how you will be using it. Personally, I'd prefer using one call to something like your call to DJ_displayPage() which itself can accept various parameters or an array of parameters that then makes the more individual calls to the other functions. Anything to reduce typing while still being maintainable is never a bad thing in my book, unless it becomes a crazy long list of chained calls! Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Design question
On Sat, Feb 05, 2011 at 11:11:57AM -0500, li...@pruimphotography.com wrote: Morning everyone! I have a design question... No it's not about the interior of my house... although I could use some help with that as well... I am working on a framework for my own use (And maybe one day will beat out the popular frameworks! Hey I can dream right? :)) and to increase my knowledge. Here's my current index page: DJ_doctype(HTML4S); DJ_head(Double J FrameWork, $cfgCss, $cfgMeta); DJ_modules(navigation, option); DJ_page(main_content.html, mainContent); DJ_dbconnect($cfgDatabase); DJ_footer(copywrite, Double J Web Design); Copywrite should be copyright in this context. It all works perfectly but I'm starting to question having a bunch of function calls like that or should I simply have a big master DJ_displayPage() call? Is this index page a front controller, or are there separate page controllers? If the calls are all *identical*, then you can stuff them into a single function call. The biggest problem with this is variable visibility. You'll have to monitor that and decide if it's worth it. In my case, I use page controllers where all the important variables are declared. If I put a render() function at the bottom, I'd have to pass in all those variables (on the stack) rather than simply have them visible to the template page that I include() at the bottom of the page controller. or should I have my framework create the html files? Has anyone gone down this road before? any pitfalls I should watch out for that aren't in google yet? :) Some of this depends on your overall application architecture, which is where the front contoller/page controller question above comes from. Paul -- Paul M. Foster http://noferblatz.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design question
On Feb 5, 2011, at 11:19 AM, Ashley Sheridan wrote: On Sat, 2011-02-05 at 11:11 -0500, li...@pruimphotography.com wrote: Morning everyone! I have a design question... No it's not about the interior of my house... although I could use some help with that as well... I am working on a framework for my own use (And maybe one day will beat out the popular frameworks! Hey I can dream right? :)) and to increase my knowledge. Here's my current index page: DJ_doctype(HTML4S); DJ_head(Double J FrameWork, $cfgCss, $cfgMeta); DJ_modules(navigation, option); DJ_page(main_content.html, mainContent); DJ_dbconnect($cfgDatabase); DJ_footer(copywrite, Double J Web Design); It all works perfectly but I'm starting to question having a bunch of function calls like that or should I simply have a big master DJ_displayPage() call? or should I have my framework create the html files? Has anyone gone down this road before? any pitfalls I should watch out for that aren't in google yet? :) Thanks everyone! Jason Pruim I guess it all depends on what you need. A little while back there was a discussion on the list about whether or not to leave all content dynamic or have the PHP CMS create the various .html pages required. There are pros and cons to each method. I'll definitely be looking that thread up! I got a little behind in my reading and must have missed it. As for the various calls vs a single call to display the page, that depends on how you will be using it. Personally, I'd prefer using one call to something like your call to DJ_displayPage() which itself can accept various parameters or an array of parameters that then makes the more individual calls to the other functions. Anything to reduce typing while still being maintainable is never a bad thing in my book, unless it becomes a crazy long list of chained calls! That last sentence is the kicker... That's where it gets hard hehe. When is too much too much? And I am guessing that is a decision that only I as the programmer can make... At least until someone uses my framework and complains about it! :) Thanks Ash! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design question
On Feb 5, 2011, at 6:46 PM, Paul M Foster wrote: On Sat, Feb 05, 2011 at 11:11:57AM -0500, li...@pruimphotography.com wrote: Morning everyone! I have a design question... No it's not about the interior of my house... although I could use some help with that as well... I am working on a framework for my own use (And maybe one day will beat out the popular frameworks! Hey I can dream right? :)) and to increase my knowledge. Here's my current index page: DJ_doctype(HTML4S); DJ_head(Double J FrameWork, $cfgCss, $cfgMeta); DJ_modules(navigation, option); DJ_page(main_content.html, mainContent); DJ_dbconnect($cfgDatabase); DJ_footer(copywrite, Double J Web Design); Copywrite should be copyright in this context. It all works perfectly but I'm starting to question having a bunch of function calls like that or should I simply have a big master DJ_displayPage() call? Is this index page a front controller, or are there separate page controllers? If the calls are all *identical*, then you can stuff them into a single function call. The biggest problem with this is variable visibility. You'll have to monitor that and decide if it's worth it. In my case, I use page controllers where all the important variables are declared. If I put a render() function at the bottom, I'd have to pass in all those variables (on the stack) rather than simply have them visible to the template page that I include() at the bottom of the page controller. Right now in my simple test pages the variables are very standard but I will keep an eye on it to see if I need to change to a different system. I'm leaning more towards doing a page controller. I've always liked the way that I can simplify the display of pages especially with regards to updates in the layout by just having a index page that controls the entire site. or should I have my framework create the html files? Has anyone gone down this road before? any pitfalls I should watch out for that aren't in google yet? :) Some of this depends on your overall application architecture, which is where the front contoller/page controller question above comes from. Thanks for the insight! I'll be keeping these points in mind in my work! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] design pattern
On Thu, Aug 13, 2009 at 4:45 PM, Ralph Deffkeralph_def...@yahoo.de wrote: Hi Martin, thanks for ur efforts, this is a lot of good work. for my opinion the start is a bit too much theoretical and valid for all type of application. In simple words, u are too close to the book. I would love to have something closer to the purpose of PHP and its applications. if u have a look at the SMARTY documentation u have good explanation (and a bad example by the way concerned oop) what are the real world problem. When it comes to the final u find the most spagetti code in putting the page grafic designer toghether with the business logic. It would be great if this could be put in good oop patterns. As I can not see that with the little amount of time I have got, p l e a s e tell me what will come up on this edge? ralph_def...@yahoo.de Martin Scotta martinsco...@gmail.com wrote in message news:6445d94e0908131322w722a37bbi24983ae143c5d...@mail.gmail.com... On Thu, Aug 13, 2009 at 4:04 PM, Ralph Deffke ralph_def...@yahoo.de wrote: so guys why u don't discuss Martins outcome? is there no advice, idears? isn't there a need for it? nobody want to use it? I WANT TO LEARN ralph_def...@yahoo.de -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php I was following the entirely conversation, I must admit I wasn't expecting such thread. It is not common to see design patterns applied to PHP applications and, is more common to don't see PHP applications. They are just scripts. Many scripts in a simple folder puts together to do the dirty work. Of course there are many kicking-ass PHP Applications, but they are a minimum portion compared to old-fashioned scripts. So, how do we start writing good quality PHP Applications? That's a very good question, and I don't know the answer, but I think by talking about design patterns we are in a good way. It's true that using design patterns the code will run slower, but it'll be flexible, maintable, and the most important: simple. After all that's what we are looking for, something really simple that make our life as developers happier every day. How do you explain the crescent number of php frameworks for rapid development? PHP core team has taken OOP seriously. Do you note the new SPL objects? The core team creates those objects using many designs patterns. By example the RecursiveDirectoryIterator and it's family use the decorator pattern. Also features such as late static binding were added because a design pattern. I think there will be some separation in the community, those who will stay using scripts and those who will use heavily OOP. I do not know who the dark side will be, xD -- Martin Scotta -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php L - O - L. Little time you've got? I just glanced at the list and you seem to have a lot of time typing up incoherent messages. I would suggest reading some books on programming architecture instead of typing out all sorts of silly emails that don't make any sense. As it turns out, if you know how to program in theory, the language itself becomes moot. Bai! -- http://www.ericbutera.us/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] design pattern
Ralph Deffke wrote: so guys why u don't discuss Martins outcome? is there no advice, idears? isn't there a need for it? nobody want to use it? I WANT TO LEARN Maybe it's your grasp of the English language, maybe not. But I detect an air of aggression to your posts. ARE YOU JUST TROLLING? Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] design pattern
On Thu, Aug 13, 2009 at 4:04 PM, Ralph Deffke ralph_def...@yahoo.de wrote: so guys why u don't discuss Martins outcome? is there no advice, idears? isn't there a need for it? nobody want to use it? I WANT TO LEARN ralph_def...@yahoo.de -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php I was following the entirely conversation, I must admit I wasn't expecting such thread. It is not common to see design patterns applied to PHP applications and, is more common to don't see PHP applications. They are just scripts. Many scripts in a simple folder puts together to do the dirty work. Of course there are many kicking-ass PHP Applications, but they are a minimum portion compared to old-fashioned scripts. So, how do we start writing good quality PHP Applications? That's a very good question, and I don't know the answer, but I think by talking about design patterns we are in a good way. It's true that using design patterns the code will run slower, but it'll be flexible, maintable, and the most important: simple. After all that's what we are looking for, something really simple that make our life as developers happier every day. How do you explain the crescent number of php frameworks for rapid development? PHP core team has taken OOP seriously. Do you note the new SPL objects? The core team creates those objects using many designs patterns. By example the RecursiveDirectoryIterator and it's family use the decorator pattern. Also features such as late static binding were added because a design pattern. I think there will be some separation in the community, those who will stay using scripts and those who will use heavily OOP. I do not know who the dark side will be, xD -- Martin Scotta
Re: [PHP] design pattern
well u got to know me personal, however may be u mix it with sarcasm? may be I can't express that as good as I want in english. if u follow the posts didn't some put me in the stupid corner? I think its legal to ask why the question of Martin are not discussed. and I still think, my question what he want to accomplish still is legal and reasonable. Many posts said, code done with design pattern framework are easy to maintain and understand. I ask u; is Martins work easy to understand? he put a lot of effort, but with even design pattern it comes to the point of a good presentation. not all people are the top smartest. as u may have realised, he changed the presentation already and is coming up with a more overview like documentation. he is realy working hard, and I can't wait to see what benefit I could have from his work what size of project it is worth for. he deserves that design pattern experts comment his work. ralph_def...@yahoo.de Robert Cummings rob...@interjinn.com wrote in message news:4a846ea7.5010...@interjinn.com... Ralph Deffke wrote: so guys why u don't discuss Martins outcome? is there no advice, idears? isn't there a need for it? nobody want to use it? I WANT TO LEARN Maybe it's your grasp of the English language, maybe not. But I detect an air of aggression to your posts. ARE YOU JUST TROLLING? Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] design pattern
Hi Martin, thanks for ur efforts, this is a lot of good work. for my opinion the start is a bit too much theoretical and valid for all type of application. In simple words, u are too close to the book. I would love to have something closer to the purpose of PHP and its applications. if u have a look at the SMARTY documentation u have good explanation (and a bad example by the way concerned oop) what are the real world problem. When it comes to the final u find the most spagetti code in putting the page grafic designer toghether with the business logic. It would be great if this could be put in good oop patterns. As I can not see that with the little amount of time I have got, p l e a s e tell me what will come up on this edge? ralph_def...@yahoo.de Martin Scotta martinsco...@gmail.com wrote in message news:6445d94e0908131322w722a37bbi24983ae143c5d...@mail.gmail.com... On Thu, Aug 13, 2009 at 4:04 PM, Ralph Deffke ralph_def...@yahoo.de wrote: so guys why u don't discuss Martins outcome? is there no advice, idears? isn't there a need for it? nobody want to use it? I WANT TO LEARN ralph_def...@yahoo.de -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php I was following the entirely conversation, I must admit I wasn't expecting such thread. It is not common to see design patterns applied to PHP applications and, is more common to don't see PHP applications. They are just scripts. Many scripts in a simple folder puts together to do the dirty work. Of course there are many kicking-ass PHP Applications, but they are a minimum portion compared to old-fashioned scripts. So, how do we start writing good quality PHP Applications? That's a very good question, and I don't know the answer, but I think by talking about design patterns we are in a good way. It's true that using design patterns the code will run slower, but it'll be flexible, maintable, and the most important: simple. After all that's what we are looking for, something really simple that make our life as developers happier every day. How do you explain the crescent number of php frameworks for rapid development? PHP core team has taken OOP seriously. Do you note the new SPL objects? The core team creates those objects using many designs patterns. By example the RecursiveDirectoryIterator and it's family use the decorator pattern. Also features such as late static binding were added because a design pattern. I think there will be some separation in the community, those who will stay using scripts and those who will use heavily OOP. I do not know who the dark side will be, xD -- Martin Scotta -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design Dilemma - Database Data Abstraction
2007/4/10, Richard Lynch [EMAIL PROTECTED]: On Sat, April 7, 2007 11:49 am, Martin Alterisio wrote: The solution I presented is to access, and act upon, a database as if they were PHP arrays, meaning that a table is presented as an array of records. I don't quite get why you think this is any more fool-proof than using a database in the first place, but okay, I guess... It's not intended to be fool-proof, and I never said so. I said those-who-never-RTFM-proof, maybe some of those are fools, but many of those have not received the proper preparation in computer sciences, and maybe it's not their fault they can't read a manual meant for us coders to read. Anyway, if there is already an API that allows us to create objects that look and act like PHP arrays, why don't just use that API for something like an ORM? My dilemma is as follows: a PHP array is a construct more restricted than a DB table. In a PHP array the index is either an int or a string, in a table de index can be any combination of fields. Then, my problem is how to design coherently the indexing of the arrays that represent the DB tables. I could index by the order as they are presented by the DB: You have not specified any ORDER BY for the DB so far. Why should I impose an order if the implementation may want to decide this order. By definition, then, the order is UNDEFINED and the DB is free to return the result set in ANY order it finds convenient. And that's okay, and I shall use the order the DB finds convenient. $DB['users'][0] is the first user from the query SELECT * FROM users $DB['users'][1] is the second user from the query SELECT * FROM users etc.. But this have many cons. First, without a deterministic order, the array can change its logic order on the whim of the DB, nobody assures that the order will be kept after a modification is made to the data, and this can be confusing and error prone: Until you define an ORDER BY in the DB, there is no order, period. If the DB presents the result sequentially there is an order, even if it follows an undefined criteria. If you *DO* define an ORDER BY in the DB, you'll have to be able to write a PHP function which can duplicate that ORDER BY and http://php.net/usort the array, or dis-allow changes to the array that introduce new keys, and disallow using integer keys. Why? I just let the DB manage the order. To use usort I'll have to actually put the results in a real array, wasting memory, cpu time, and db access. $name1 = $DB['users'][3]['name']; $name2 = $DB['users'][5]['name']; $DB['users'][3]['name'] = $name2; $DB['users'][5]['name'] = $name1; The last sentence may not be writing to the adequate record. What's wrong here? For example, if the current order for the 'users' table is by the 'name' field, after the first write this order may have changed, then the record we'll be trying to write next won't be the one we intended to. If 5 isn't 5, then you are screwed from the get-go... That's why I don't like this indexing criteria. Another possible indexation could be by the value of the PK, but this also have some problems. First, it can be confusing if the PK is an autonumeric int, as this might be seen as a numeric indexation. Second, not all tables have only one field as PK (I can ask that all tables have at least a PK, but I can't ask that the PK is made of only one field). Exposing an auto_increment field to anything above the DB layer is almost always a Bad Idea (tm). Why? Or, what do you mean by exposing the auto_increment field? Show me one site that doesn't expose the value of this field (when needed) in the url. $user = $DB['users'][$userid]; // get $DB['users'][$userid] = $user; // update or insert $DB['users'][] = $userid; // insert unset($DB['users'][$userid]); // delete I think you will find that detecting the array changes and pushing them back down to the DB will be much more difficult than just providing an API to a database in some kind of normalized functions... That's the easy part, I'll just use the SPL interfaces. Sorry, I forgot to mention this in my first email as I explained in the following emails. There is also the problem with many-to-many relationships. If there was only one table that related two tables in this way, I could do the following: Well, yeah... You are going to have to have at least 2 if not 3 arrays to do that with any efficiency at all... Hey. Would you think I'll even propose this here if I didn't think I could guarantee at least the same efficiency as other ORMs? $DB['users'][$userid]['groups'] - groups where the user belongs $DB['groups'][$groupid]['users'] - the users of a group There would be a third table other than users and groups which doesn't show up. But, what to do when there is more than one relationship table for the same two tables? And if the relationship table also had some extra fields? You can't just call everything
Re: [PHP] Design Dilemma - Database Data Abstraction
On Sat, April 7, 2007 11:49 am, Martin Alterisio wrote: The solution I presented is to access, and act upon, a database as if they were PHP arrays, meaning that a table is presented as an array of records. I don't quite get why you think this is any more fool-proof than using a database in the first place, but okay, I guess... My dilemma is as follows: a PHP array is a construct more restricted than a DB table. In a PHP array the index is either an int or a string, in a table de index can be any combination of fields. Then, my problem is how to design coherently the indexing of the arrays that represent the DB tables. I could index by the order as they are presented by the DB: You have not specified any ORDER BY for the DB so far. By definition, then, the order is UNDEFINED and the DB is free to return the result set in ANY order it finds convenient. $DB['users'][0] is the first user from the query SELECT * FROM users $DB['users'][1] is the second user from the query SELECT * FROM users etc.. But this have many cons. First, without a deterministic order, the array can change its logic order on the whim of the DB, nobody assures that the order will be kept after a modification is made to the data, and this can be confusing and error prone: Until you define an ORDER BY in the DB, there is no order, period. If you *DO* define an ORDER BY in the DB, you'll have to be able to write a PHP function which can duplicate that ORDER BY and http://php.net/usort the array, or dis-allow changes to the array that introduce new keys, and disallow using integer keys. $name1 = $DB['users'][3]['name']; $name2 = $DB['users'][5]['name']; $DB['users'][3]['name'] = $name2; $DB['users'][5]['name'] = $name1; The last sentence may not be writing to the adequate record. What's wrong here? If 5 isn't 5, then you are screwed from the get-go... Another possible indexation could be by the value of the PK, but this also have some problems. First, it can be confusing if the PK is an autonumeric int, as this might be seen as a numeric indexation. Second, not all tables have only one field as PK (I can ask that all tables have at least a PK, but I can't ask that the PK is made of only one field). Exposing an auto_increment field to anything above the DB layer is almost always a Bad Idea (tm). $user = $DB['users'][$userid]; // get $DB['users'][$userid] = $user; // update or insert $DB['users'][] = $userid; // insert unset($DB['users'][$userid]); // delete I think you will find that detecting the array changes and pushing them back down to the DB will be much more difficult than just providing an API to a database in some kind of normalized functions... There is also the problem with many-to-many relationships. If there was only one table that related two tables in this way, I could do the following: Well, yeah... You are going to have to have at least 2 if not 3 arrays to do that with any efficiency at all... $DB['users'][$userid]['groups'] - groups where the user belongs $DB['groups'][$groupid]['users'] - the users of a group There would be a third table other than users and groups which doesn't show up. But, what to do when there is more than one relationship table for the same two tables? And if the relationship table also had some extra fields? You can't just call everything $DB then, can you? You'll need to name the tables as part of the key system. At which point you might as well go back to DB and tables, really... Also the delete action presents some problems: unset($DB['users'][$userid]['groups'][$groupid]); Am I deleting the group or the relationship between that user and group? I believe the last is more coherent, but still it can be prone to confusion. [shudder] Your first problem was in cramming an N-to-N relationship into a single array... I could make $DB['users'][$userid]['groups'][$groupid] represent the relationship rather than a record of groups table, where both the group data and the relationship data are stored (I would have to ask that there are no field names duplicated between these tables). This way I solve the problem with the extra data, and the problem with the delete. About the possibility that there may be two relationship tables for the same pair of tables, using explicitly the name of the relationship table instead of the name of the other table would solve the ambiguety (but I think it would be unusual, and I rather keep the access through the name of the other table). Ugh! If my field names can't match up between tables for fields that have the FK relationship, I would categorically refuse to work with your arrays. I'm sure there are more things I'm not considering, that's why I ask your help to find them, and your opinion about what I've said up to now. Abasndon this idea quickly, before you waste any more time on it, is my opinion. :-) -- Some people have a gift link here. Know what I want?
Re: [PHP] Design Dilemma - Database Data Abstraction
Martin Alterisio wrote: I have a dilemma on a design where I humbly ask your help. I'm working on the model part of a web application (not to be understood in the web2.0 way, but in a more general way, where anything mounted on HTTP is a web application) done in PHP5 following the MVC design pattern. But the strong point is that the result must be those-who-never-RTFM-proof. But that's not my dilemma, I only mention this so that no RoR concept or similar is thrown into the table, that is, NO ActiveRecord. The solution I presented is to access, and act upon, a database as if they were PHP arrays, meaning that a table is presented as an array of records. Here comes my dilemma. But first let me explain a bit about the scenario so far: I snip there - too much detail without defining the problem ;) Database Data Abstraction normally refers to using a common internal structure which can be loaded from a range of database engines. It sounds as if you have no requirement to 'Abstract' the database, only to come up with a persistent object layer under a single database engine? You have indicated that you are looking for a multi-user system, and so the raw data must be in the database, but as you have seen, the flexibility afforded by any database engine is difficult to duplicate. The thing to remember is that you should ONLY be reading the data you need for the current user, and so your persistent objects do not need to be as complex as you seem to be looking for. It is always faster to ask the database for an answer than to copy everything to PHP in order to work with it. With any decent database you can provide views of the data in a suitable format for the arrays you need display on the user interface. I tried to find something suitable to point you at, but it's difficult http://www.appelsiini.net/~tuupola/php/DB_DataContainer/ Is probably in line with your current outline? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design Dilemma - Database Data Abstraction
2007/4/9, Lester Caine [EMAIL PROTECTED]: Martin Alterisio wrote: I have a dilemma on a design where I humbly ask your help. I'm working on the model part of a web application (not to be understood in the web2.0 way, but in a more general way, where anything mounted on HTTP is a web application) done in PHP5 following the MVC design pattern. But the strong point is that the result must be those-who-never-RTFM-proof. But that's not my dilemma, I only mention this so that no RoR concept or similar is thrown into the table, that is, NO ActiveRecord. The solution I presented is to access, and act upon, a database as if they were PHP arrays, meaning that a table is presented as an array of records. Here comes my dilemma. But first let me explain a bit about the scenario so far: I snip there - too much detail without defining the problem ;) Yeah, sorry about that, the concept seems a bit difficult to explain. I didn't found anything similar to point as reference. Database Data Abstraction normally refers to using a common internal structure which can be loaded from a range of database engines. It sounds as if you have no requirement to 'Abstract' the database, only to come up with a persistent object layer under a single database engine? Nope. It's an abstraction layer where the API is the common array operations, implemented through the SPL interfaces for that purpose. No explicit database is involved, except that some constrains to the structure of the data shall be involved. You have indicated that you are looking for a multi-user system, and so the raw data must be in the database, but as you have seen, the flexibility afforded by any database engine is difficult to duplicate. The thing to remember is that you should ONLY be reading the data you need for the current user, and so your persistent objects do not need to be as complex as you seem to be looking for. It is always faster to ask the database for an answer than to copy everything to PHP in order to work with it. With any decent database you can provide views of the data in a suitable format for the arrays you need display on the user interface. I completely understand, that's why from the beginning I decided that no precaching nor caching would be done, and lazy evaluation would be the way to go. The array operations would be transparently mapped to their counterpart db action when needed. I tried to find something suitable to point you at, but it's difficult http://www.appelsiini.net/~tuupola/php/DB_DataContainer/ Is probably in line with your current outline? Thanks but that's exactly what I don't want to do. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php Thanks for answering but my problem isn't how the abstraction will be actually implemented, but that the API (the array interface) stays as coherent as possible. If you have the time, please read what was snipped, those are my thoughts about how to make the array API coherent and what problems I encountered. Thanks again.
Re: [PHP] Design Dilemma - Database Data Abstraction
2007/4/8, Paul Novitski [EMAIL PROTECTED]: At 4/7/2007 09:49 AM, Martin Alterisio wrote: The solution I presented is to access, and act upon, a database as if they were PHP arrays, meaning that a table is presented as an array of records. This implies to me that you'll read a series of tables into arrays, modify the arrays, then update or recreate the database tables from the arrays. I can't really see how this can work for multiple users because as soon as a second user reads and starts modifying the data there will be obvious discontinuities between the two data snapshots, and updating the tables from one user will erradicate changes made by others. Is this a single-user application you're working on? First of all, thanks for replying, I really appreaciate it. Second, I'm sorry, in my wild search for help I made the mistake of making assumptions that would only lead to problems of communication. I forgot to mention the base idea for the implementation. Actually no real arrays are made, just objects that look and function like normal arrays through the SPL interfaces ArrayAccess, Countable, Iterator and IteratorAggregate. Answering your question: no, this will be used in a multi-user enviroment. Basically all array operations will be traslated to the corresponding DB operation. No caching. No postponing operations. Except for the record object, which I think I will implement it so that field updates are done on object destruction, but I'm still thinking about this. I could index by the order as they are presented by the DB: $DB['users'][0] is the first user from the query SELECT * FROM users $DB['users'][1] is the second user from the query SELECT * FROM users etc.. But this have many cons. First, without a deterministic order, the array can change its logic order on the whim of the DB, nobody assures that the order will be kept after a modification is made to the data, and this can be confusing and error prone: $name1 = $DB['users'][3]['name']; $name2 = $DB['users'][5]['name']; $DB['users'][3]['name'] = $name2; $DB['users'][5]['name'] = $name1; The last sentence may not be writing to the adequate record. Hmm. I don't see why this wouldn't work -- you're not changing the keys (3 5) required to point to those unique records. I can see a problem if $name1 and $name2 were themselves the keys, but you're not doing that in this example. Well, it could not work if those operations are translated on the spot to the corresponding DB action. If that were the problem, though, you could simply mandate a rule that you can never change the key of an array element that represents a data record, so that the record sequence remains what it was originally. However, making your program logic depend on the record sequence as it was read from the database seems quite iffy anyway [especially in a multi-user system]; I'd just use the data table's primary key as the array key and leave it at that. Random access rocks! From what you write, it almost seems as though you're assuming that these statements: $DB['users'][3]['name'] = $name2; $DB['users'][5]['name'] = $name1; actually modify the database records they represent. If so, what system are you using? I just don't see this happening using simple PHP and MySQL. When you read a data record into a PHP array [with, for example, mysql_fetch_array()] that array is just a static copy of the data and doesn't possess any dynamic updating power over the database. Or are you using an I/O class that you're not showing in your example code that executes a modifying query each time an array element is changed? That's actually what will happen. Using the SPL is actually posible. Sorry, mi mistake for not explaining it throughly. Another possible indexation could be by the value of the PK, but this also have some problems. First, it can be confusing if the PK is an autonumeric int, as this might be seen as a numeric indexation. You can prefix an autonumber field with alphabetic characters to force it away from numeric indexing: $sKey = str_pad($aDataRecord['recno'], $iPadLength, 'pk_00', STR_PAD_LEFT); $aArray[$sKey] = $aDataRecord; e.g., recno 12345 becomes array key 'pk_012345' Using str_pad(...LEFT) ensures that the array keys will be in the same sequence as the data records even though the autonumber values will be composed of differing numbers of digits. You just have to choose a pad length that equals the longest series of digits your database will generate for an autonumber field. But suppose $user holds the info of an user record: $DB['users'][$user['id']] I would like that to point to the same user. Still, I'll think this thoughly. Thanks Second, not all tables have only one field as PK (I can ask that all tables have at least a PK, but I can't ask that the PK is made of only one field). You can construct a single array key from multiple database fields: $aArray['pk_'
Re: [PHP] Design Dilemma - Database Data Abstraction
At 4/7/2007 09:49 AM, Martin Alterisio wrote: The solution I presented is to access, and act upon, a database as if they were PHP arrays, meaning that a table is presented as an array of records. This implies to me that you'll read a series of tables into arrays, modify the arrays, then update or recreate the database tables from the arrays. I can't really see how this can work for multiple users because as soon as a second user reads and starts modifying the data there will be obvious discontinuities between the two data snapshots, and updating the tables from one user will erradicate changes made by others. Is this a single-user application you're working on? I could index by the order as they are presented by the DB: $DB['users'][0] is the first user from the query SELECT * FROM users $DB['users'][1] is the second user from the query SELECT * FROM users etc.. But this have many cons. First, without a deterministic order, the array can change its logic order on the whim of the DB, nobody assures that the order will be kept after a modification is made to the data, and this can be confusing and error prone: $name1 = $DB['users'][3]['name']; $name2 = $DB['users'][5]['name']; $DB['users'][3]['name'] = $name2; $DB['users'][5]['name'] = $name1; The last sentence may not be writing to the adequate record. Hmm. I don't see why this wouldn't work -- you're not changing the keys (3 5) required to point to those unique records. I can see a problem if $name1 and $name2 were themselves the keys, but you're not doing that in this example. If that were the problem, though, you could simply mandate a rule that you can never change the key of an array element that represents a data record, so that the record sequence remains what it was originally. However, making your program logic depend on the record sequence as it was read from the database seems quite iffy anyway [especially in a multi-user system]; I'd just use the data table's primary key as the array key and leave it at that. Random access rocks! From what you write, it almost seems as though you're assuming that these statements: $DB['users'][3]['name'] = $name2; $DB['users'][5]['name'] = $name1; actually modify the database records they represent. If so, what system are you using? I just don't see this happening using simple PHP and MySQL. When you read a data record into a PHP array [with, for example, mysql_fetch_array()] that array is just a static copy of the data and doesn't possess any dynamic updating power over the database. Or are you using an I/O class that you're not showing in your example code that executes a modifying query each time an array element is changed? Another possible indexation could be by the value of the PK, but this also have some problems. First, it can be confusing if the PK is an autonumeric int, as this might be seen as a numeric indexation. You can prefix an autonumber field with alphabetic characters to force it away from numeric indexing: $sKey = str_pad($aDataRecord['recno'], $iPadLength, 'pk_00', STR_PAD_LEFT); $aArray[$sKey] = $aDataRecord; e.g., recno 12345 becomes array key 'pk_012345' Using str_pad(...LEFT) ensures that the array keys will be in the same sequence as the data records even though the autonumber values will be composed of differing numbers of digits. You just have to choose a pad length that equals the longest series of digits your database will generate for an autonumber field. Second, not all tables have only one field as PK (I can ask that all tables have at least a PK, but I can't ask that the PK is made of only one field). You can construct a single array key from multiple database fields: $aArray['pk_' . $aDataRecord['fieldA'] . '_' . $aDataRecord['fieldB']] = $aDataRecord; unset($DB['users'][$userid]); // delete Unsetting the array element, rather than retaining it with a deletion marker, implies that you're intending to recreate the database tables rather than update them atomically. Is this correct? Regards, Paul __ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] design?
Thanks, John. It's probably also a matter of how you name the classes. It needs to be a clear name that describes what it 'is'. Hence, the depot name. Anyway, indeed I have finished the concept of the app. Sjef John Wells [EMAIL PROTECTED] schreef in bericht news:[EMAIL PROTECTED] On 6/30/06, Sjef [EMAIL PROTECTED] wrote: Thanks, John, I'm not sure I completely get the idea of a pair class. As an question and answer are in the same database tabel I now created a questionDepot class that gets the array from the db, does save and update operations, and for example, sets a flag in the db tabel when a question is accepted for the list. Hi Sjef, It sounds as if you've got the idea, even if I didn't explain myself well. My point was to *not* create a Question class that maintained an array of questions, which was only _implicitly_ related to a similarly-structured but disparate Answers class. An array of questions sitting beside an array of answers is, in my opinion, not a proper abstraction of the objects you're dealing with. Perhaps it is out of experience that I'm harping on this point, because I've been burned by a similar design before. One of my first OO projects was a weblog, and I had built a Post class, and then for posts with galleries, a separate Gallery class that contained *only* image information for it's parent Post. On it's own, this wasn't all bad, but the big mistake I made was how I handled multiple posts and multiple galleries (like for building out the homepage where I showed 5 recent posts and a thumbnail from each, if they were galleries). Within each Post and Gallery class, I turned the properties into _arrays_. So what originally was a string for the post's title, now became an array of strings for many posts. Likewise for the Gallery class. Arrays of thumbnails became arrays of arrays of thumbnails. I'm sure The List will shudder at this design, but hey, I've learned my lesson. Be-lieve-me. Anyway, the point is, your initial approach was the same (if I read it correctly). You suggested an array of questions, and an array of answers, which would only be implicitly related. Your design started with the concept of many questions, and many answers, but my argument is that, abstractly, you should begin with one question, and one answer. Then think in terms of a question-answer pair that *belong to each other*. And then think of many question-answer pairs. Anyway, I'm sure that by the time you've finished reading this hair-splitting rambling, you've already finished your app and moved on to something else entirely. :) -John W -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] design?
On 6/30/06, Sjef [EMAIL PROTECTED] wrote: Thanks, John, I'm not sure I completely get the idea of a pair class. As an question and answer are in the same database tabel I now created a questionDepot class that gets the array from the db, does save and update operations, and for example, sets a flag in the db tabel when a question is accepted for the list. Hi Sjef, It sounds as if you've got the idea, even if I didn't explain myself well. My point was to *not* create a Question class that maintained an array of questions, which was only _implicitly_ related to a similarly-structured but disparate Answers class. An array of questions sitting beside an array of answers is, in my opinion, not a proper abstraction of the objects you're dealing with. Perhaps it is out of experience that I'm harping on this point, because I've been burned by a similar design before. One of my first OO projects was a weblog, and I had built a Post class, and then for posts with galleries, a separate Gallery class that contained *only* image information for it's parent Post. On it's own, this wasn't all bad, but the big mistake I made was how I handled multiple posts and multiple galleries (like for building out the homepage where I showed 5 recent posts and a thumbnail from each, if they were galleries). Within each Post and Gallery class, I turned the properties into _arrays_. So what originally was a string for the post's title, now became an array of strings for many posts. Likewise for the Gallery class. Arrays of thumbnails became arrays of arrays of thumbnails. I'm sure The List will shudder at this design, but hey, I've learned my lesson. Be-lieve-me. Anyway, the point is, your initial approach was the same (if I read it correctly). You suggested an array of questions, and an array of answers, which would only be implicitly related. Your design started with the concept of many questions, and many answers, but my argument is that, abstractly, you should begin with one question, and one answer. Then think in terms of a question-answer pair that *belong to each other*. And then think of many question-answer pairs. Anyway, I'm sure that by the time you've finished reading this hair-splitting rambling, you've already finished your app and moved on to something else entirely. :) -John W -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] design?
On 6/29/06, Sjef [EMAIL PROTECTED] wrote: Hi there, Hi Sjef, First off, I think David has a good point with regards to the OO vs Procedural approach. If you're looking to do this quick and easy, it might not be worth your time fussing with OO. Unless you'd like to just for the exercise, which I wholly support, so go for it! I want to create a class Question for dealing wiht the questions and a class answer for the answers. Each could contain an array with the their part of the content of the database table. As far as how to design it OO-style, I'd first urge you *not* to have separate classes managing lists of questions and answers. Say for example you query your db for questions, build up your array inside your questions class, and then while doing the same for your answers class, you inadvertently introduce a looping bug that drops one of the answers from the array, or possibly changes the order that you create your array, or any other number of possible mistakes (human or otherwise). Point is, in the end you'd have two out-of-synch classes that really should've been built separately to begin with. A single question and it's answer(s) are tied together, so keep it that way in your class abstraction. That said, I'd suggest building a question-answer *pair* as a class, and then you'd have an array of these question-answer pairs representing your entire list (which could be encapsulated into a container class if you wished). You could, to be even more abstract, create base question and answer classes to represent the most basic type of question or answer, and then hold individual, **related** instances of these within your question-answer pair class. Do you see the difference? You could even take it a step further and build derivatives of your base answer class to represent different types (string, multiple choice with one answer, multiple choice with many answers, etc)...But I'm sure I'm already getting far ahead of your original design. But David started it! :) HTH, John W -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] design?
How about answer extends question? -Original Message- From: David Tulloh [mailto:[EMAIL PROTECTED] Sent: Friday, June 30, 2006 9:36 AM To: Sjef Cc: php-general@lists.php.net Subject: Re: [PHP] design? Sjef wrote: Hi there, I am starting a new, very small project. A simple question and answering form. In one screen, question and answer can be typed, the strings will be saved in a database table questions which holds question and answer (as there is only one answer to a question). There will be a webpage displaying all the questions, clickable to the webpage of the answer to the question clicked. I want to create a class Question for dealing wiht the questions and a class answer for the answers. Each could contain an array with the their part of the content of the database table. The class Question manages the class Answer, so when instantiating the Question, the Answer will follow. Beside of this I want to create a 'visual' component class that creates the lists as displayed on the webpage. Is this a good idea? Or should I not bother, and just create one class Question that also deals with the Answers. You have essentially three pages: one that displays a form and inputs the entered data to a database; one that gets a list of questions from the database; one that displays a specific question/answer pair. As a ballpark estimate, I'd say that the above should be possible in under 100 lines of PHP code. You are looking at creating a Question class, an Answer class and a Visual/List class. The net result being that you double the number of PHP files and considerably increase the amount of code, there isn't much opportunity for code reuse here. Now, if the objective is to play with php OOP then go ahead. I would even suggest a DB class, a TableRow class, the Question and Answer then inherit from the TableRow, a TableRows class from which your List class would inherit. Maybe throw a few in to control the templates etc. as well. If the objective is just to get the job done and the site out, I don't see why you should bother with OOP at all. David -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] design?
Thanks, John, I'm not sure I completely get the idea of a pair class. As an question and answer are in the same database tabel I now created a questionDepot class that gets the array from the db, does save and update operations, and for example, sets a flag in the db tabel when a question is accepted for the list. My question was asked with the experience that a complete procedural approach often turns out to become messy, you have to use certain visual objects more often in teh app, therefore why not create a visual class to use more than once. So, it was just an urge to write cleaner code By the way: as always, I already exceded the 3 or 4 pages David mentioned, if only for the idea to add a 'placed' tag in the db. Sjef John Wells [EMAIL PROTECTED] schreef in bericht news:[EMAIL PROTECTED] On 6/29/06, Sjef [EMAIL PROTECTED] wrote: Hi there, Hi Sjef, First off, I think David has a good point with regards to the OO vs Procedural approach. If you're looking to do this quick and easy, it might not be worth your time fussing with OO. Unless you'd like to just for the exercise, which I wholly support, so go for it! I want to create a class Question for dealing wiht the questions and a class answer for the answers. Each could contain an array with the their part of the content of the database table. As far as how to design it OO-style, I'd first urge you *not* to have separate classes managing lists of questions and answers. Say for example you query your db for questions, build up your array inside your questions class, and then while doing the same for your answers class, you inadvertently introduce a looping bug that drops one of the answers from the array, or possibly changes the order that you create your array, or any other number of possible mistakes (human or otherwise). Point is, in the end you'd have two out-of-synch classes that really should've been built separately to begin with. A single question and it's answer(s) are tied together, so keep it that way in your class abstraction. That said, I'd suggest building a question-answer *pair* as a class, and then you'd have an array of these question-answer pairs representing your entire list (which could be encapsulated into a container class if you wished). You could, to be even more abstract, create base question and answer classes to represent the most basic type of question or answer, and then hold individual, **related** instances of these within your question-answer pair class. Do you see the difference? You could even take it a step further and build derivatives of your base answer class to represent different types (string, multiple choice with one answer, multiple choice with many answers, etc)...But I'm sure I'm already getting far ahead of your original design. But David started it! :) HTH, John W -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] design?
Sjef wrote: Hi there, I am starting a new, very small project. A simple question and answering form. In one screen, question and answer can be typed, the strings will be saved in a database table questions which holds question and answer (as there is only one answer to a question). There will be a webpage displaying all the questions, clickable to the webpage of the answer to the question clicked. I want to create a class Question for dealing wiht the questions and a class answer for the answers. Each could contain an array with the their part of the content of the database table. The class Question manages the class Answer, so when instantiating the Question, the Answer will follow. Beside of this I want to create a 'visual' component class that creates the lists as displayed on the webpage. Is this a good idea? Or should I not bother, and just create one class Question that also deals with the Answers. You have essentially three pages: one that displays a form and inputs the entered data to a database; one that gets a list of questions from the database; one that displays a specific question/answer pair. As a ballpark estimate, I'd say that the above should be possible in under 100 lines of PHP code. You are looking at creating a Question class, an Answer class and a Visual/List class. The net result being that you double the number of PHP files and considerably increase the amount of code, there isn't much opportunity for code reuse here. Now, if the objective is to play with php OOP then go ahead. I would even suggest a DB class, a TableRow class, the Question and Answer then inherit from the TableRow, a TableRows class from which your List class would inherit. Maybe throw a few in to control the templates etc. as well. If the objective is just to get the job done and the site out, I don't see why you should bother with OOP at all. David -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] design pattern/code generators
robert mena wrote:
Hi All,
I am looking for advice regarding design patterns/code generation in PHP5.
I have a simple code generation tool (written in PHP) to interface with
database. It works fine for simple situations but seems a little
strange for more complex ones.
Suppose I have a table user (id, name, age) and a table
account(idAccount, idUser, name). My generator creates a class for each
table and a standard db class. Each class basically has a set/get
method for each property and some standard insert, delete, update,
search methods
ex.
class user
{
var $db
function setName(..)
function getName()
function insert()
{
$this-db-query(insert into user values...)
}
...
}
I've omited the other methods/constructor but you can get the picture.
The problem comes when I have to access information the comes from 2+
tables. Suppose I have to show all users accounts. Now I end up with
something like this.
$u = new User() ;
$a = new Account() ;
if($u-search())
{
for($i=0;$i...)
{
$idUser = $u-getId() ; $u-next() ;
$a-setIdUser($idUser) ;
if($a-search())
{
// print
}
}
While this works I feel there must be an easier/cleaner way. If I was just
querying the database a join would give me the result in one pass.
the join is based on a foreign key constraint - An idea might be to
generate a method based on the FK details (in either or both relevant classes),
if you are using an older version of mysql, or don't actually define the
constraint in the DB, then this maybe impossible - unless you use a
config file to generate each class.
so that you can do:
$user = new User();
$ac = $user-getAccount(); // returns the correct Account object.
In my case what should I do ? create a new method showAccounts ?
Where should I put it, in User or Account class ?
on the User class, Account would probably want a method like showUser().
I am interested in advices regarding how to design it better so I can
make the proper adjustments in my generator.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design Languages for site design
UML is a universal language that can be used for PHP, a factory, Java, Legos, etc. I had entertained reading up on and learning UML last year, but was convinced, by friends, it wasn't worth it unless you would be using it all the time (meaning working at a large company). I think they are actually working on a new version of UML that is supposed to simplify it. That doesn't mean you shouldn't have good planning. An entity relationship diagram is still crucial for your database. But UML may be overkill, especially for a single developer. Personally, I started reading up on design patterns instead. You may actually already be using the most popular design pattern, MVC (Model, View Controller). You should be able to find a bunch of articles on the net on the MVC technique, including a few specific to PHP. I still tend to make it up as I go along more than I should, but my mistakes are a lot easier to fix if I design around MVC. UML is still on my list of things to learn, but it's just lower than other things. On Jan 27, 2004, at 10:50 AM, Daniel Brown wrote: Not sure if this is off topic or not, apologises in advance if it is. Does anyone here use any software design languages (is that the right term?) like UML when they are designing Php driven web sites? As I am looking to start a new site/project and I want to design it properly instead of making it up as I go along like I usually do. And I was wondering if any of the software design languages like UML were any use for this? Does anyone here use UML or something similar when they are designing their next site/php project? -- Brent Baisley Systems Architect Landover Associates, Inc. Search Advisory Services for Advanced Technology Environments p: 212.759.6400/800.759.0577 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design Patterns PHP5
On Thu, 2004-01-22 at 14:31, Thomas Svenson wrote: Got the book Core PHP Programming 3rd Edition, which covers PHP5. One thing that it talks about is that with, specially, the new oop model it will now be much easier to develop in PHP using Design Patterns (DP). check out http://www.phppatterns.com That should give you tons of great information. -- Ray -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Design Patterns PHP5
Ray Hunter wrote: On Thu, 2004-01-22 at 14:31, Thomas Svenson wrote: Got the book Core PHP Programming 3rd Edition, which covers PHP5. One thing that it talks about is that with, specially, the new oop model it will now be much easier to develop in PHP using Design Patterns (DP). check out http://www.phppatterns.com That should give you tons of great information. Seems to be exactly what I was looking for. I quickly found one pattern on the site that is very irritating though - the line patterns they are using in the tables. Makes it hard to focus on the content somehow... Many thanks, /Thomas -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Design Patterns PHP5
Design Patterns is a big category that can cover any area of design. In general the idea is that there are Best practices ways of solving particular design problems. Java is the area (particularly J2EE) where I've seen the biggest promotion of the idea coming out of a company (in this case Sun) through their publishing arm. Even before that things like libraries and in C++ the Standard Template Library provided a lot of Design Pattern support. One particular application of Design Pattern engineering is in the area of application frameworks. Two in particular Fusebox and Model-View-Controller (MVC) are very popular for providing structure to large online system projects. The best known MVC library is Struts which came out of the Jakarta project. Fusebox, which has a PHP implementation going, came out of the ColdFusion language. There is probably MVC libs to help you get going with MVC, but I haven't used them myself. I'm sure there are probably many other frameworks I'm not familiar with. You might try googling on some of the words and phrases I mentioned, and in particular application framework if you find that the most appealing aspect of this topic. -Original Message- From: Thomas Svenson [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 1:32 PM To: PHP General Subject: [PHP] Design Patterns PHP5 Got the book Core PHP Programming 3rd Edition, which covers PHP5. One thing that it talks about is that with, specially, the new oop model it will now be much easier to develop in PHP using Design Patterns (DP). Since that is new to me I have been searching for some easy reading to understand how it works and if it is easy to learn. The book states that using a DP will be beneficial, specially for larger projects and to create reusable code. I have found some info, such as the Patterns Library at http://hillside.net/patterns/, but the information there isn't very easy read for me. What I would be grateful to know is which DP is best for web projects based on PHP(5). Preferable if someone could give a short description on how the common DP's could be applied for web projects. I would also like to get a few tips on books, or preferable free resources on internet, that helps me understand this. Thanks, /Thomas -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design - Database, Hard File, Combination?
Mike wrote: Hi, So I'm working on a CMS that has the ability to move pages from one category to another, and whole sub-categories (and all their pages) to a different categories. I have a file that defines the hierarchy of the menu: .|Something ..|sub-something ..|sub-something else .|something -else ..|sub-something-else ...|etc. .|else-something ..|it's children [ snip ] I think if you were to change you menu definition file to XML, it would make this a lot easier. Then you can use the domxml functions to grab your parent/child relationships. -- Burhan Khalid phplist[at]meidomus[dot]com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design question.
Hi, I place name all my included files *.inc... I place them all in a folder /inc/ and place a .htaccess file in that directory to restrict the files being served of HTTP: Files ~ \.inc$ Order Allow,Deny Deny from all /Files Another option would be to place them in a folder ABOVE your web root, so that Apache can't serve them -- if you have that option. This does a few things for me: 1. I know that all *.php files are intended to be served direct to the user through a web browser, and I know that all .inc files are code fragments, not intended to be run out of context. 2. As long as Apache is configured properly, no one will see any passwords n stuff. Cheers, Justin on 22/09/02 11:55 AM, Chuck PUP Payne ([EMAIL PROTECTED]) wrote: Hi, I have a question. I been working a personal project that I am want to make a like simpler. I have several pages have in which I have place the information to connect to my database, whick is getting old. What I am wanting to do is create file like most do, a config, but I want to know which is better, config.php or config.inc. I know there not much different from what I have read but I am wanting to know which gives more protection. And what recommendation would you give on set it up? I am only asking because I am at some point wanting to release my project to public. Chuck Payne Magi Design and Support -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design question.
This explanation from Justin is worth saving. I also like to call all of my included modules *.inc, and I prefer to store them outside of document root. However, if you want to keep all of your files together, the .htaccess file shown below is the best way to restrict direct access to modules. Some people make the mistake of simply making *.inc files considered PHP by Apache (claiming it is better to execute them than to have their source code displayed), but this gives attackers the opportunity to execute your modules out of context - a very dangerous approach. One extra note worth adding is that you should add this configuration to your httpd.conf if you are the Web server administrator. This will keep you from having to remember the .htaccess file everywhere. Justin's method is best for when you do not have this option. Chris Justin French wrote: I place name all my included files *.inc... I place them all in a folder /inc/ and place a .htaccess file in that directory to restrict the files being served of HTTP: Files ~ \.inc$ Order Allow,Deny Deny from all /Files Another option would be to place them in a folder ABOVE your web root, so that Apache can't serve them -- if you have that option. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design question.
Thanks guys. That really helpful. Chuck Payne On 9/21/02 10:16 PM, Chris Shiflett [EMAIL PROTECTED] wrote: This explanation from Justin is worth saving. I also like to call all of my included modules *.inc, and I prefer to store them outside of document root. However, if you want to keep all of your files together, the .htaccess file shown below is the best way to restrict direct access to modules. Some people make the mistake of simply making *.inc files considered PHP by Apache (claiming it is better to execute them than to have their source code displayed), but this gives attackers the opportunity to execute your modules out of context - a very dangerous approach. One extra note worth adding is that you should add this configuration to your httpd.conf if you are the Web server administrator. This will keep you from having to remember the .htaccess file everywhere. Justin's method is best for when you do not have this option. Chris Justin French wrote: I place name all my included files *.inc... I place them all in a folder /inc/ and place a .htaccess file in that directory to restrict the files being served of HTTP: Files ~ \.inc$ Order Allow,Deny Deny from all /Files Another option would be to place them in a folder ABOVE your web root, so that Apache can't serve them -- if you have that option. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design question.
(Sorry if I've already sent this.) I agree. But, I don't really see any problem having *.inc files as *.inc.php (so that they'll be executed by Apache) esp. IF the config file have only this: (Even if this is executed nothing shows up...) ?php $my_super_user = 'blahblah'; $my_super_password = 'blahblahblah'; ? I just thought this is worth knowing esp. if there's no way you can use .htaccess. (Of course, if you can't use .htaccess, you might want to change ISPs or set up your own server but that is for a different topic :) - E This explanation from Justin is worth saving. I also like to call all of my included modules *.inc, and I prefer to store them outside of document root. However, if you want to keep all of your files together, the .htaccess file shown below is the best way to restrict direct access to modules. Some people make the mistake of simply making *.inc files considered PHP by Apache (claiming it is better to execute them than to have their source code displayed), but this gives attackers the opportunity to execute your modules out of context - a very dangerous approach. One extra note worth adding is that you should add this configuration to your httpd.conf if you are the Web server administrator. This will keep you from having to remember the .htaccess file everywhere. Justin's method is best for when you do not have this option. Chris Justin French wrote: I place name all my included files *.inc... I place them all in a folder /inc/ and place a .htaccess file in that directory to restrict the files being served of HTTP: Files ~ \.inc$ Order Allow,Deny Deny from all /Files Another option would be to place them in a folder ABOVE your web root, so that Apache can't serve them -- if you have that option. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design Tips
Not so long ago (well last week), I wrote a PHP proxy script which worked in the form: www.myserver.com/proxy/www.whatever.com/blah and it would request the page www.whatever.com/blah and then display it changing all the links on the page to point to my proxy script... The whole script took a hour to write, and I eventually got it to do posts and get, and to send all headers So using PHP is totally possible for what job you want Andrew - Original Message - From: David Redmond [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 27, 2002 2:13 AM Subject: [PHP] Design Tips Hi All, I'm about to put myself in the deep end by attempting to create an PHP app that will perform the role of a proxy server. The application has to perform the following based on the URL that the web client will be requesting. URL Requested: https://servername/id0001/ 'id0001' is a unique for each of my clients and they have a matching record which points to their content. Each client will have a different server that their content is hosted on. I want the PHP app to read in that id number , perform a SQL query to obtain where their real server is, retrieve the content then display it back to the client. The app would have to deal with GET POST as it would be working with dynamic content at the remote end. Is this even possible using PHP? If anyone has had any experience developing this type of App before, please let me know how you went and/or provide any tips that you can :) Cheers -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Design Problem
Does it matter? The search engine doesnt know your producing dynamic content, its just requesting a page to scan, regardless of the way your producing it. - James -- W: www.londontown.com @: [EMAIL PROTECTED] -- -Original Message- From: Dani [mailto:[EMAIL PROTECTED]] Sent: 30 May 2002 14:40 To: [EMAIL PROTECTED] Subject: [PHP] Design Problem Importance: High Hi everyone, I'm new to this... What is the best way to make Search Engine Crawler still index us although we are using a script (PHP) to detect the IP of the crawler to provide the keywords for a certain crawler? Any advise is welcome.. Dani -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design Problem
Thanks very much for the advice! Was that actually the way to do it? If it is,where can I get list of the IPs, please... thanks again... Dani James Holden wrote: Does it matter? The search engine doesnt know your producing dynamic content, its just requesting a page to scan, regardless of the way your producing it. - James -- W: www.londontown.com @: [EMAIL PROTECTED] -- -Original Message- From: Dani [mailto:[EMAIL PROTECTED]] Sent: 30 May 2002 14:40 To: [EMAIL PROTECTED] Subject: [PHP] Design Problem Importance: High Hi everyone, I'm new to this... What is the best way to make Search Engine Crawler still index us although we are using a script (PHP) to detect the IP of the crawler to provide the keywords for a certain crawler? Any advise is welcome.. Dani -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Design Problem
I do it a different way - using IP's can be a bit of a bummer since they might change but often as not the hostnames dont. I detect spiders using the HTTP_USER_AGENT which identifies them either as say kitty once hourly, GoogleBot or Lycos or some such - most of the decent spiders use the user_agent var to identify themselves and you can display alternate info dependent on which spider it is. For the majority of the content stuff we do we steer clear of using long and difficult query strings since some (not all) search engines dont like them - We use the Apache Directive (Location or .htaccess Files) to run our stuff through what looks like a directory but is in fact just a script. - James -- W: www.londontown.com @: [EMAIL PROTECTED] -- -Original Message- From: Dani [mailto:[EMAIL PROTECTED]] Sent: 30 May 2002 15:18 To: James Holden Cc: [EMAIL PROTECTED] Subject: Re: [PHP] Design Problem Importance: High Thanks very much for the advice! Was that actually the way to do it? If it is,where can I get list of the IPs, please... thanks again... Dani James Holden wrote: Does it matter? The search engine doesnt know your producing dynamic content, its just requesting a page to scan, regardless of the way your producing it. - James -- W: www.londontown.com @: [EMAIL PROTECTED] -- -Original Message- From: Dani [mailto:[EMAIL PROTECTED]] Sent: 30 May 2002 14:40 To: [EMAIL PROTECTED] Subject: [PHP] Design Problem Importance: High Hi everyone, I'm new to this... What is the best way to make Search Engine Crawler still index us although we are using a script (PHP) to detect the IP of the crawler to provide the keywords for a certain crawler? Any advise is welcome.. Dani -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design Problem
James Holden wrote: Does it matter? The search engine doesnt know your producing dynamic content, its just requesting a page to scan, regardless of the way your producing it. search engine spiders will usually disregard the search string of a URL, i.e. everything after and including the ? character. to overcome this, you should use url rewrite mechanisms which can turn http://www.example.com/page.php?key1=val1key2=val2 to http://www.example.com/page/val1/val2 hth, Jakob. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design Problem
On Thursday 30 May 2002 19:42, James Holden wrote: I do it a different way - using IP's can be a bit of a bummer since they might change but often as not the hostnames dont. I detect spiders using the HTTP_USER_AGENT which identifies them either as say kitty once hourly, GoogleBot or Lycos or some such - most of the decent spiders use the user_agent var to identify themselves and you can display alternate info dependent on which spider it is. Do note that some (most?) crawlers don't take kindly to this practice of delivering content based on the HTTP_USER_AGENT. If you're found out you'll most likely be removed from the search engine in question. -- Jason Wong - Gremlins Associates - www.gremlins.com.hk Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * /* On the whole, I'd rather be in Philadelphia. -- W.C. Fields' epitaph */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Design Problem
I dont deliver alternate content, I track when they visit which is a different thing all together. - James -- W: www.londontown.com @: [EMAIL PROTECTED] -- -Original Message- From: Jason Wong [mailto:[EMAIL PROTECTED]] Sent: 30 May 2002 13:05 To: [EMAIL PROTECTED] Subject: Re: [PHP] Design Problem On Thursday 30 May 2002 19:42, James Holden wrote: I do it a different way - using IP's can be a bit of a bummer since they might change but often as not the hostnames dont. I detect spiders using the HTTP_USER_AGENT which identifies them either as say kitty once hourly, GoogleBot or Lycos or some such - most of the decent spiders use the user_agent var to identify themselves and you can display alternate info dependent on which spider it is. Do note that some (most?) crawlers don't take kindly to this practice of delivering content based on the HTTP_USER_AGENT. If you're found out you'll most likely be removed from the search engine in question. -- Jason Wong - Gremlins Associates - www.gremlins.com.hk Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * /* On the whole, I'd rather be in Philadelphia. -- W.C. Fields' epitaph */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design Problem
On Thursday 30 May 2002 20:09, James Holden wrote: I dont deliver alternate content, I track when they visit which is a different thing all together. No, but the OP was asking (if I understand correctly) how to identify search engines and deliver keywords (META I suppose) accordingly. -- Jason Wong - Gremlins Associates - www.gremlins.com.hk Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * /* My cup hath runneth'd over with love. */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Design Problem
On Thu, 30 May 2002 [EMAIL PROTECTED] wrote: search engine spiders will usually disregard the search string of a URL, i.e. everything after and including the ? character. Not sure about the others, but Google does follow GET args. miguel -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
