KevinM1

This topic has been moved to PHP Applications. http://www.phpfreaks.com/forums/index.php?topic=358814.0

This topic has been moved to PHP Applications. http://www.phpfreaks.com/forums/index.php?topic=358684.0

Hmm... I haven't seen anything in PHP like what you're asking. Generally, the various frameworks have decent documentation on how to use said frameworks, but the examples are generally simple/canned in order to highlight particular functionality. They tend to lack a meaningful, realistic project for someone to see in action. Symfony2 is pretty much a by-the-numbers MVC framework. It has great documentation, too: http://symfony.com/doc/current/book/index.html But the examples, like with others, are designed simply to showcase the framework itself.

Look at your double quotes....

Yeah, it's definitely not very readable. $k and $v make sense, but $n and $m? And using classes simply to group functions together is a waste of time. True OOP is far more than merely using classes. That said, what's stopping you from simply having the form post to itself? That's generally how sticky forms (forms that remember field values) are made.

My Mom is pretty bad, too. It's even more aggravating because she's used a computer for at least 30 years, if not longer, both at work and at home. She can learn custom, in-house software, and even make usability suggestions to the IT department, but she can't figure out how to save a bookmark in a browser. Every time I hear "Why isn't this working?!" I die a little inside.

NO. Re-read what I said. You asked about having TWO auto-incremented ids in the same row. I replied that in that case, mysql_insert_id wouldn't work because it only returns ONE id. In that kind of case you'd need to SELECT that row after INSERTING it. No, the problem is a complete lack of reading comprehension. Here's a breakdown of the process: INSERTED row only has one auto-incremented column: Use mysql_insert_id after you execute the INSERT query INSERTED row has two or more auto-incremented columns: Figure out a way to SELECT the appropriate row after you execute the INSERT query It cannot be broken down or written more clearly or explicitly.

Eh, I like it better, especially when dealing with database CRUD. All those .'s bug me.

Indeed, which is why you're having trouble. You do realize that you never actually execute your INSERT query in the code above? As far as two+ auto-increment values, you'd have to manually SELECT the row you want. The function only returns one id. You've been given the answer by three people, and have been shown the official documentation at least twice. The onus is now on you to get it to work.

Wrong. You just need to use curly braces around the array variable: echo "Look, I'm an array variable in a double-quoted string! {$arr['someKey']}";

mysql_insert_id $result = mysql_query("INSERT INTO blah blah blah...."); $id = mysql_insert_id(); It's pretty straightforward.

Amazingly, threads about application design belong in the Application Design sub-forum. This topic has been moved to Application Design. http://www.phpfreaks.com/forums/index.php?topic=358384.0

$row['pos_' . $i] is what you're looking for.

AFAIK, we don't have 'save as a favorite topic' functionality. Saving it as a browser bookmark should work.

GetContents was a one-method class. Something like that is often better represented as a trait (available only in PHP 5.4 - see: traits). In lieu of that, make it a static method, and don't inherit from it. Inheritance creates is-a relationships. Does it make sense for a Geo object to also be treated as a GetContents object? I also had an issue with the class name - GetContents - itself. Class names should be nouns as they are used to represent things: a database connection, a MVC controller, a data transfer container, etc. Even in environments that are more OO oriented and have events baked in, events are represented by an Event class, not a DoSomething class. Generally speaking, yes. Abstract base classes provide the foundation of functionality which can then be layered upon by concrete child classes. Interfaces, while on the surface appear to do the same job, are actually used when you want to keep an object's public interface (its public method signatures) the same, but vary the implementation behind the scenes. The best example I can think of is Dependency Injection, which is what really opened my eyes to the way interfaces are supposed to be used. Let's say you're working in a MVC environment. In your controller, you need to be able to access the database for basic CRUD functionality. Instead of directly accessing the db, you use a repository. So, you have a setup like this: class BlogController extends Controller { private $repo; public function __construct($repo) { $this->repo = $repo; } public function saveBlogPost() { $this->repo->update(); } } public class BlogRepository { private $dbc; // PDO or MySQLi public function __construct($dbc) { $this->dbc = $dbc; } public function update() { // grab $_POST data and update the db through the $dbc } } That works great, but what if you need to test the repository and don't want to access the database with the tests, so as to not fill the database with crap test data? Instead of commenting out code, you put the repository method signatures in an interface, and have both the 'real' and test repositories implement them: interface IRepository { public function get($id); public function update(); // etc. } class BlogController extends Controller { private $repo; public function __construct(IRepository $repo) { $this->repo = $repo; } public function saveBlogPost() { $this->repo->update(); } } class BlogRepository implements IRepository { /* code that accesses the db */ } class TestRepository implements IRepository { /* code that does NOT access the db */ } The controller doesn't care about which repository it gets, as both are of the type IRepository. This is one way that OO code becomes modular. There's the adage "Code to an interface (meaning an object's public method signatures), not an implementation." The language construct interface allows us to do that by specifying an object's public method signatures, leaving the implementation up to individual classes to define. Admittedly, something like the above isn't all that necessary in PHP since it's dynamically typed. $repo could be anything, and PHP wouldn't care. In statically typed languages (C++, Java, C#), proper use of interfaces is vital. So, after all that, rules of thumb: Use an abstract base class when: You need to share particular implementations across objects, but don't need to instantiate the base class itself. Use an interface when: You need to keep the method signatures the same for a group of objects, but also need to change how they work under the hood. Think plug-ins/modules. --- One thing, in your code, I'd just put the method declaration of _request_formatted in your Geocoding class definition, like so: abstract class Geocoding { protected $_url, $_content_type; public function __construct($url, $content_type) { $this->_url = $url; $this->_content_type = $content_type; } public function get($formatted = false) { return ($formatted) ? $this->_request_formatted($this->_url) : $this->_request($this->_url); } protected function _request($url) { if(ini_get('allow_url_fopen') != 1) { $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_FAILONERROR, 1); curl_setopt($ch, CURLOPT_RETURNTRANSFER,1); curl_setopt($ch, CURLOPT_TIMEOUT, 3); $contents = curl_exec($ch); curl_close($ch); } else { $contents = file_get_contents($url); } return $contents; } protected function _request_formatted($url); } With the way you have it now, Geocoding can't 'see' it as it's defined in the child classes.

You're not using interfaces correctly. For one, it's highly irregular to specify a constructor in an interface. You may also get into trouble considering where you implement the request method. Finally, nothing you're doing really requires an interface. Interfaces are best used when you're relying on polymorphism. In this case, that would mean when the request method must be implemented, but the implementation can vary. Since your request method is really set in the GetContents class (which is a horrible name, BTW - class names should be nouns, not verbs), you don't gain anything. Rather, you merely add a layer of unneeded complexity. IMO, you should simply use an abstract base class and derive from it.

If you're using PHP 5, be wary of the '&' as well. It's generally unnecessary in assignment statements as objects are passed/returned by reference.

It's often easier to keep it to one class/file due to __autoload, or its SPL counterpart. Unless you like manually referencing include files.

Click 'Profile' at the top of the screen. Click 'Show Posts'.

In PHP, strings are denoted with quotes. Unquoted entries are treated as constants.

$_SESSION['forum'] Note the quotes.

The posts still exist (they weren't deleted). They were likely moved due to being originally posted in the wrong subforum.

Also, a nitpick: don't use the 'var' keyword. PHP 5 has three official access modifiers - public, protected, and private.

I edited the title of the topic to better reflect what you want. Usually, when referring to a database, 'inject' relates to SQL injection attacks. Do you have an integer id column in your table? If so, instead of setting it to auto-increment upon data insertion, have your PHP script generate a random number for the id (look at mt_rand), and insert that with the rest of the data. When you print out a report, simply ORDER BY id ASC. The emails will be effectively shuffled.