KevinM1

Yeah, I've always found that the hardest part of OOP is actually trying to define the problem I'm currently facing. There are a lot of times when a problem doesn't 100% fit a particular pattern, or is in actuality a problem that needs to be addressed by several patterns working in concert. That recognition can only come with experience.

That works thanks. What is the point of $this->? $this

It depends on the structure of the report in question. Can it contain things that are like itself or other things within it (line items?). If so, that's a Composite. Have you ever played Civilization? Armies are Composite objects. Each unit in an army may have unique stats and abilities, but they all do the same thing, and can be used the same way, regardless of whether they're alone or in a group. When a group of things can be treated - from the outside - as a singular thing of that same base type, that's a Composite. Finally, keep in mind that patterns aren't one-size-fits-all solutions. They're a starting point, a way to look and think about a problem, not necessarily an end point. Moreover, patterns have different implementations depending on the actual problem at hand. Your best bet is to get Zandstra's book. It's the best primer on OOP in PHP available.

The reason why 'global' is used there is because the specific open, close, etc. functions associated with the session_save_handler function expect a certain number of incoming parameters for each of those functions (e.g., open() anticipates only two parameters, etc.). Seems dumb that those functions don't allow optional arguments for the session path and whatnot. I'm curious as to whether or not these functions would be considered to be user defined or not, since the user is the one writing their definitions. If they are user defined, then they could have variable length argument lists, which would allow the use of func_get_args, and eliminate the 'global' problem.

Again, it all comes down to what an object is trying to do. A recipe is essentially a data type in and of itself, as it both represents data (ingredients) and the actions done to that data (the process of cooking). It naturally adheres to the single responsibility principle. Funny that you also mention a report, as it's sometimes used as an example of the Composite pattern....

Design issues aside (and, there are plenty), you need to learn when to use GET and when to use POST. GET should be used to retrieve information. POST should be used to, well, post information. Using POST for navigation is bad because it, as we've seen, denies the user from accessing a particular page if they don't have the proper information. Since POST sends data behind the scenes, then how would a user know that they broke the chain to begin with? So, rule of thumb: if it's to something a user will actually navigate to, use GET. If it's a part of your system that saves/updates data, use POST. You also need to: Do error checking. MySQL errors should not be popping up on the screen. Input filtering. Never assume that incoming values are correct, or that a user is passing in legit info. As far as the design goes.... there is no design. Everything is just thrown up on the page with no rhyme or reason. Is this a game? Why is there a stock ticker? What is the purpose of this site? Added to this misfortune is the aesthetic itself. Tables should only be used for tabular data. Not for layout. And when they are used, they shouldn't have chunky borders. The graphics are horrible. The header font is barely readable, there are round, garish buttons everywhere, and cartoony icons that do nothing to convey meaning. There's no cohesion, personality, or harmony. A bunch of loud things mushed together in a table for who knows why. I'm not trying to be overly harsh, but, really, this is the kind of aesthetic the internet moved away from years ago. It's not 1998. Geocities is dead. Let's modernize a bit. First thing's first: centered elements often look foolish. Why? Because centered elements create an hourglass figure, which is fine if you're staring at a beautiful woman, but hard to deal with when you're trying to read. Imagine reading a magazine article that had centered text. Hard to do, right? Don't center elements unless it won't break the left-to-right flow. Next: Structure. Your site needs a main structure that remains the same from page-to-page. This means not relying on the back button, whether it's the browser's or one you made, but rather having solid navigation visible on every page. What sites do you visit? Do they make you press a dedicated back button to navigate, or do they have other links visible on every page. Every page needs a header, a footer, and some clean, easy to understand/use navigation. No exceptions. To that end learn CSS and get rid of the unnecessary tables. Graphics: You need to pick a look and feel for your site. Is it fun/cartoony? Then go with the buttons and icons, and make the background interesting. Is it supposed to be a serious airline sim? Then tone it down. The site, in addition to being confusing, is bipolar at the moment. That said, standalone buttons are a bad way to go. They break the flow of a site by adding navigation to content areas. Again, having a proper navigation menu is paramount. Information: Like I asked above, what is this site about? A game? Why is there stock information if it's about airlines? What's the point? Why would I want to join?

That tends to be the way most people do it, although you can use the __get and __set magic methods to reduce boilerplate at the cost of efficiency (take a look at some of my initial thoughts/playing with the idea: http://stackoverflow.com/questions/6550550/dumb-experiement-creating-c-esque-properties-in-php). That said, a common mistake many burgeoning OOP devs make is using setters and getters as a step in a larger operation. If you're calling getProperty() only to do more work on that property, then you need to ask yourself if it makes sense for your object to have a performComplexActionWithProperty() method instead. If you're merely treating an object as a property bag, then you're not doing OOP. Also, if your object has 20+ fields, you're likely doing it wrong. Objects should adhere to the single responsibility principle. If, when describing what your object does, you have to use the words and or or more than once, you're trying to do too much. Refactor the other functionality into their own classes.

Things to look at/search for: Query strings $_GET[] PHP Page Controller Google should provide you with all you need.

This topic has been moved to JavaScript Help. http://www.phpfreaks.com/forums/index.php?topic=345904.0

Do NOT use 'global'. EVER. It's entirely unnecessary and is the path down which horrible code is written.

You could do either one. Hell, you could simply have a textbox for users to write an entire infix expression and parse it with PHP on the back end. It all depends on what you want and what you think is the best design. Like Pikachu said, we're not in the business of doing homework for students. That includes giving the kind of advice which would minimize what individual assignments are trying to teach.

I use camel case as well. I'm not a fan of underscores in general. Looks ugly, IMO, and requires extra key presses. The exception is as a prefix to private members. I'm torn on using them, so I often simply leave the first letter of my private members lowercase: private function somePrivateFunction(){} I capitalize public members, like so: public function SomePublicFunction(){} Class names themselves always have capitalized first letters. Interfaces have the 'I' prefix: class Example implements ISomeInterface{}

Since PHP is executed on the server, there's no way to get a direct look at the PHP code without access to the server the code is running on. Regarding the rules, take a look at them: http://www.phpfreaks.com/page/rules-and-terms-of-service Since you're focused on adult content, be sure to adhere to rule 8. We're a PG-13 outfit (with occasional lapses into R territory), so behave accordingly.

@djl1990 Whenever you're curious about a built-in PHP function, you should take a look at it in the manual: http://www.php.net/quickref.php Chances are, you'll see a use case example in the documentation that will help your overall picture come into focus.

Why not use a session variable? Set the session variable in your contact form page, and then when the user is redirected, check for it.

And, just to clarify how that happens: Gurus are selected on merit. For us, it means being active and helpful. Posting merely to increase post count is frowned on. So, if you (or anyone) wants to be a Guru, simply do your best to help others. If you're consistent, we'll notice.

Bingo, although you transposed A and B (A is the parent, denying B access to its private member). Private means private, a.k.a., "Hands off my cookies (even you, Junior)!" Protected means family, but no outsiders. It's a useful distinction to have because, even if you want a class to be extended, there are rare occasions when you don't want certain data members to be accessible down the hierarchy chain.

IMO, you really need to stop and take your time to grasp the basics of OOP. There are a lot of problems with what you have, and, honestly, you'd be better served trying to start over from scratch than hammer away at what you currently have. Start here: http://php.net/manual/en/language.oop5.php Then go here (a MUST HAVE step if you want to start thinking like an OOP in PHP programmer): http://www.amazon.com/Objects-Patterns-Practice-Experts-Source/dp/143022925X/ref=sr_1_1?ie=UTF8&qid=1318537549&sr=8-1 Finally, go here: http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_2?s=books&ie=UTF8&qid=1318537603&sr=1-2 Those three sources are definitely not all inclusive re: OOP, but they will teach you the correct way to approach common programming problems and to 'see' things in an OOP manner. It's certainly a more efficient way of doing it than trying to learn fundamental design methodology entirely from an online forum. Besides, a lot of what we give as advice stems from those resources (and others) in addition to our collective experience. You might as well have access to those resources yourself if you're serious about pursuing OOP.

Private hides whatever it's attached to from everything except the class in which the private member was defined. Protected hides whatever it's attached to from everything except the class in which the protected member was defined and any child classes. In other words, it's working properly.

Or, you could use htmlentities to replace tags with their entity counterparts. The script text (i.e., <script>blahblahblah</script>) would appear on your screen as text, rather than execute.

In your JavaScript, echo $row['quantity']. In your HTML, attach your onsubmit event to the form tag itself, not the input. Remember, you're submitting an entire form, thus the submit event fires on the form.

Have you tried echoing $senderEmail to see if it actually contains a value?

How much does aesthetics play in the competition? A jaunt over to Smashing Magazine for inspiration may help as well.

If you want to wow them, try to make your site mobile friendly. CSS media queries and the like. Also, don't be afraid to see how the big boys do it. Download existing CMS solutions and take a look at how they handle templates, themes, and plugins. EDIT: It just dawned on me... I'm a US citizen. What am I doing giving advice to a Canadian entrant?

You need to repeat your variable for each test, e.g.: elseif ($Sub >= 26.00 || $Sub <= 50.99 ){