KevinM1

Don't use die for error handling. Throw exceptions and catch them gracefully.

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

This topic has been moved to Website Critique. http://www.phpfreaks.com/forums/index.php?topic=320708.0

Also, never use global. At all. Ever. Like PFMaBiSmAd says, functions are supposed to be general purpose black boxes, where data is passed in (via the parameter list), the data is processed (function body), and a result is returned (return statement at the end). Global forces your function to know about the context in which it was invoked, which just kills a function's modularity, and thus makes it a pain to debug and edit (among other things).

You're confused about inheritance. Just because you pass a layout object to a child object's constructor, that doesn't mean things will automatically be linked up. Walk through the process: 1. You create a new layout with a $site_id of 1. 2. You create a new flags object by calling layout::get_flags(); 2. a. get_flags() passes an instance of the existing layout to the new flags object, but then does nothing with it. The layout object is destroyed. 3. You create a new top_nav object by calling layout::top_nav(); 3. a. the same thing as 2. a. happens - the existing layout object is passed into the new top_nav object, and then immediately discarded. Try: class layout { protected $site_id; public function __construct($site_id) { $this->site_id = $site_id; } public function get_flags() { return new flags($this->site_id); } public function top_nav() { return new top_nav($this->site_id); } } class flags extends layout { public function __construct($site_id) { parent::__construct($site_id); } } class top_nav extends layout { public function __construct($site_id) { parent::__construct($site_id); } } $layout = new layout(1); $flags = $layout->get_flags(); $nav = $layout->top_nav();

This is EXACTLY WHY I ASKED. Can you stop posting on my threads Thorpe? Everytime you do you always have to be a jerk. Not to pile on, but these are basic metric system prefixes. The kind of stuff one learns in middle school science classes.

I don't know if there's any pre-made scripts out there for this sort of thing. I wouldn't be surprised if there were, so you should check Google if you don't feel like taking the plunge of doing it all yourself. If you do feel like getting your hands dirty, you'll need both a database and server side scripting language. Since you're here, the defaults would be PHP and MySQL. You don't necessarily need a framework. While frameworks are indeed powerful, they're at least an extra layer of learning on top of PHP and MySQL, usually two - you'd have to learn both the framework itself and most likely basic Object Oriented Programming theory and technique. The easiest ones to learn are most likely Code Igniter and Kohana. Regardless of what technology you use to build the site, the most important aspect will be your database design and domain model - how things are stored in the db, how they're retrieved, how they interact, how they should be used etc. You'll need to figure out what constitutes a lesson plan, how plans should be grouped and/or related, and the extent to which a user can interact or modify them. Start with database normalization (http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html). As a general design tip, you wouldn't be storing raw HTML pages of lesson plans in your db. Rather, you would store lesson plan data (notes, corresponding assignments, anything else relevant), and then display that data in a template, which would be mostly HTML, with just enough PHP code to echo the data in the right spots in your layout. Hope this helps.

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

Neither user nor the username need to be a folder. Most likely, YouTube is written using the MVC (Model View Controller) pattern. 'user' is the name of a controller, and 'username' is the argument passed into it's default action.

The biggest problem I see is with maintenance. With your current example, you'd have to write a valid set of metadata for every single object in your system. Further, if your design changes, you'll have to go into each affected object and edit its metadata manually. That will quickly grow tedious. See if you can refactor. @shlumph - type hinting only works with objects and arrays. It doesn't work on primitives (integers, strings, etc.). See: http://php.net/manual/en/language.oop5.typehinting.php.

IMO, you need to scrap your design and start looking into the reasoning behind OOP as a methodology and various OOP design patterns. Look into composition, abstraction, encapsulation, and polymorphism. Also, for the web, the MVC pattern is essentially the de facto architectural pattern for medium to large sites. Look at frameworks like Zend and Kohana to see how their application flow is designed. That should give you a good idea on how to proceed.

I freelance exclusively. What I do is ask potential clients what they're looking for and what their budget is. I then explain the feasible options they have available to them. My #1 concern is educating potential clients about the process and what to expect. I find that the more interested and involved a client is in the development of their site, the more likely they'll grant me leeway and the more likely they'll keep me on or hire me again in the future. Even if they don't hire me, I'll give them advice on what to look for when interviewing/looking for other developers. The last thing I want is for anyone to be swindled or taken advantage of, regardless of whether or not that person is a client of mine or not. Freelancing is all about reputation. I can afford to deny, or be denied projects that don't fit a certain level of comfort or personal integrity now if it means developing a sterling reputation to build on down the line. You may or may not have that luxury, but I think it's something to strive for. Above all else, I am honest with my clients. No BS, no promising things I can't deliver on, and no going over budget unless I get approval from them.

'=' is the assignment operator. '==' is the equality operator. For if-statements, always use the second one. Why? It's always possible to assign a value to a variable. Further, the statement will actually execute. In your case, this means you're overwriting $row['password'] with $_POST['password'] and $row['name'] with $_POST['name'].

This isn't the place to air dirty laundry about, or issue ultimatums to another community.

Currently I'm a design usability consultant, and mmmm this doesn't sit well with me. As a disabled developer, I concur. There's no real good reason not to make your sites as accessible as possible. Those considerations should be included in the estimates/allotted time for the project.

You don't need a form at all to do this. That would be overkill, not to mention that forms are used to submit data, not handle UI changes. All you need to do is attach an onclick event to each square. Inside that click event's handler function, have it grab a hold of the current page background color and change it to whatever you want. It's a couple of lines of code, depending on exactly how you have it set up. The particular details rely on how exactly you want this to be structured in your HTML. So, if you can supply some sample code, I can point you in the right direction.

$604, for what you're asking, is very, very unrealistic. You really need to educate yourself on what things cost, what various CMS systems and frameworks can do, and how much time and effort would go into making your system. I live in the US and charge $30/hr, which is pretty damn cheap. Your bid would be 20 hours of work for me. So do you really think you could get your entire system finished in that amount of time? Keep in mind that the time would not only include writing the system, but testing and debugging it. A development studio would charge at least twice what I do, if not 3x-5x, depending on their size and reputation. Also, a CMS is not a framework. A CMS is an application in and of itself. And, remember, the C in CMS stands for Content. Most of these systems aren't designed to handle e-commerce out of the gate. Instead, they're designed to make it easy for people to create articles and news items - traditional content. A framework is PHP code that eliminates the low-level grunt work, such as connecting to a database and retrieving results. Using a framework does not mean that code written with one is somehow inferior or 'not custom'. Virtually all professional developers use a framework of some sort, as it speeds up development. You really need to do research before attempting to throw money around. What are the prices in India, generally speaking? Do they change if the costs are payed with American/European money as opposed to their own currency? What sites has that particular company created? Do you like their portfolio of work? How did they deal with clients? Do you have an idea about how much they charged for the sites you've seen? Or how much something like your site would cost in general as opposed to their estimate? You're a business man. You need to do your due diligence before committing to anything. Otherwise you'll continue to get into these awkward situations.

What do you get for the generated hyperlink? In other words, when you hover your mouse over 'prev', are the expected values there when you look at the URL in your browser's status bar?

Just put critical files above your web root directory.

Not in the slightest. At least, not if you're trying to write legit OOP code. Each class defines a data type (think int or string). They denote both a kind of data and the actions that can be performed on that data. An object is an instance of that newly created custom data type. Objects are supposed to represent things - a product in an online store, a user, a login handler, etc. Objects are also supposed to be as independent as possible. All your system should know of an object is its public interface - the public data members and methods it contains (not to be confused with the interface keyword, which is both similar and different). This allows one to change the implementation of an object without changing how it's used by other parts of the system. This is what the terms abstraction, encapsulation, and polymorphism describe. Think LEGOs. Objects are the blocks. They all have their unique characteristics (this one is blue, the other is a 1x4, etc.), and they can all be put together in different ways to make new meta shapes, but they can only connect together in one way - by matching pegs with holes. This is how objects work. The peg->hole relationship is facilitated by an object's public interface. That's the only proper way to stick the blocks together.

You need: if(isset($_POST['submitBtn'])) Also, you've got your logic backwards. With PHP, you always attempt to handle incoming POST data first, then show the form. Your form should still send the data with the way you have it now, but you're coding yourself into a corner with your current script structure.

No, it's a way to decouple one's app from having to rely on a particular type of db (MySQL, SQLite, PostgreSQL, etc.). Essentially, it separates the database interface/API from the actual underlying store, making it easy to port one's app from platform to platform with minimal fuss.

Is your safe() function in the same file or include-ed in the email code you're using? Your main script needs to be able to 'see' the function.

You mean $row['rsTown']....

It's not uncommon to have HTML helper objects like this. Just remember to keep them as abstract as possible. A Form object should really only display the starting and ending <form></form> tags, with its action being determined by parameters passed in. The other inputs would then be their own objects. A Textbox object, Password object, SelectList object, etc. This allows you to create a form with an arbitrary number of inputs, and gives you a hook for validation. It's hard to describe in more detail if you don't know the MVC pattern.