gizmola

If it's a variable you need the $. $id.

The main blocks of your layout should all be id's. Put whatever styles you'll use across different tags into classes. You do not need to make a choice between the two: a tag can have an id, name and class. Typically the positional aspects of the blocks would be styled in the id. Things like fonts, colors etc, would go into classes, because you want those to be consistent. Doing a good .css takes some planning.

Yes it's definately a design question. One thing to consider is what sort of interface or api are you trying to achieve for yourself. Whether or not something should be passed as a parameter in the constructor is up to you. Also it's important to keep in mind that you can call methods from other methods. So if you had a method like: myForm->loadPost($post); You can always optionally call this from inside your constructor using: $this->loadPost($post); From my point of view, if I was frequently going to want to create a form object and in doing so needed access to the post data (to redisplay with error messages and previously entered data, for example) then I'd probably build that option into the constructor, just so I could avoid having to explicitly make the method call, but there's no major difference other than convenience in the api. Years ago I wrote a tutorial and the example I used was a timer class. The class let you create timer objects and they had a timer->start() and timer->stop() param. In the constructor i provided an option to call $this->start() when the timer was created, because a lot of times that's what you would want to do --- make the timer and have it start timing immediately.

The main thing about oop is that the methods (public and private interface) to the internal data is bound together with the actual data. That can be beneficial in organizing your data. There are also common design patterns that have proven to be good ways to solve common problems. This is one of the reasons so many web application frameworks include an implementation of the MVC pattern. In php oop is not as often used for its inheritance properties, other than in the case of well known libraries that have been written in oop. Often the oop is hiding complexity and again the importance is that the public methods are providing an api for use of that class. I wouldn't underestimate the value of private or protected variables (or even just leaving them public) in a class defination. When you consider users, it's nice to be able to have a let's say, an array of "users" which might represent "friends", or an array of permissions. The functions might be very similar, but it certainly helps organize your data and keep things clean, when you can have a method that for example, reads in the permissions for a new user and stores them in the user object.

We don't know what your class structure is so there's no great way to give you advice. With that said, a common technique is to pass in optional input using an optional parameter: So then you can do: $frm = new myForm; or $frm = new myForm($_POST); class myForm { function __construct($post = NULL) { if ($post === NULL) { // No post data } else { // post data was passed. } } }

This very much depends on how badly you want to suppress cheaters. You can set the cookie expiration to be whatever you want it to be, so there's no issue setting a 24 hour cookie. If suppression of cheating is important, then I would make sure to store the IP address in the vote row, and you can then do some queries that group by IP, and use that to remove blocks of multi-votes based on whatever threshold you decide to be gaming the vote system.

Yes, I understand what you meant. You should not use die. You can perform your error checking at the top of the script based on whatever conditions represent errors. If there are errors, you can either redirect or you can simply display the errors in a box and re-emit the form. This is a pretty standard problem and easy enough to code for. Your first problem is that you are using die(). What many people will do is create an array called $errors. If your error checking code finds an error you add to the $errors array. // .... some error occurred $errors[] = 'The user was not found or the password did not match. Please check your input and try again."; Then you can check to see if there were any errors: if (count($errors) > 0) { // Login form needs to be shown again // Show error box now foreach($errors as $msg) { echo $msg; } } These are very simple examples that leave off obvious condition checking. Your code didn't have any setting of state to indicate that a person was successfully logged in. This is something that shoudl be checked, because people shouldn't be seeing a login form if they have already logged in. How are you going to handle that if you don't use sessions?

Well you are echoing values of a variable that has no value, so you're getting NOTICE warnings. You can turn down the errorlevel so that notices are not shown, but that won't fix problems you'll still encounter.

Don't use die. The use of sessions can solve your issues.

A constructor is simply a function that gets called when an object is instantiated with new. You don't call a constructor -- it gets called automatically.

Take a look at mysql_info(). Perhaps that will solve your issue.

The basic rule of thumb is that if you are identifying a block, you should use an id. All id's should be unique -- that is, in your page you should not see more than one element that has the same id. In your case, almost all of your divs (header, main, footer, footerright, footerleft) should be ids. Use class definitions to generically style one or more elements.

Mysql isn't case sensitive, regardless of whether you use = or LIKE. You actually have to use WHERE 'BINARY' to get it to look at case. Huh, sure enough - for some reason I have always thought that. It's certainly true for most RDBMS, so maybe you just confused it with Oracle or SQL Server or Postgresql. MySQL is full of these little quirks.

I can't explain your results. The name of the variable should not be relevant. You should of course always check the input values when debugging. If I understand you correctly,the implication is that $search = $_POST['search'] would have been empty. I can't explain why that would be true unless the search form element had a typo. You could have hunted this down by doing a var_dump($_POST) at the top of the script.

Mysql isn't case sensitive, regardless of whether you use = or LIKE. You actually have to use WHERE 'BINARY' to get it to look at case.

While I agree that your script lacks sophistication in terms of sanitized input,etc. at the same time I don't see anything wrong with it. Based on the information you provided, I would check that your mysql table (I'm assuming myisam format) using myisamchk). I would also suggest you use mysql command line client or phpMyAdmin and just do a SELECT Fullname from Accounts query and take a look at the format of the data. Make sure there aren't leading or ending spaces or any other characters in there that would account for why an exact match wouldn't work.

A "pro" php tip is to always omit the ending php tag from any script that only includes PHP code. A line or 2 of whitespace can inadvertantly cause output to be triggered in scripts where you never intended that to happen -- like your functions.php include script. Whenever a script is included, you have to realize that it is injected as is, into the including script. Since PHP allows for the intermixing of PHP and HTML. Leaving off the end tag will eliminate that problem.

Yes, you have the right syntax. Should work fine as long as name is actually the primary key of the table.

I went ahead and looked at the document you provided. Your structure is correct. subject_level is a classic Many to Many relationship resolver table, resolving the many to many relationship between subject and level. What I would recommend for your queries supporting the forms you're generating, is that you join the tables together using a standard inner join. You can then order result by level. As you loop through the result set, you simply set an outer variable on level. Anytime the level in the result set changes, you would emit a new section with the level heading and a new set of checkboxes. I would go so far as to say that you should take the same approach in your prior code, where you are instead doing 2 queries. That is not necessary, as joining the tables together will get you everything you need in one. If you need the results for only one level, you can always include that in the WHERE clause for the query. If you have any specific questions in regards to your coding, feel free to post them in a followup.

Looks to me like this rule is rewriting everything to www.....

Here's my thoughts: 1. Menu needs to be MUCH bigger. You have a giant logo, it needs to at least compete with that. Also menu colors should match the logo in some way. In general you should have a color pallete and be working from it. 2. Don't like the background tile behind the site. Whatever you do with that, you at least need some sort of border treatment so it doesn't look so plain. 3. Considering that the site is doing so little for the business, I'd suggest at least adding a facebook wall area of their fans.

I don't know how to say this any clearer than I already did. What is preventing you from implementing the query that was already provided you, using the table structure you have?

Right away, if you actually knew the box model, you would know that the margin sits outside the border. Did you examine any of your assumptions? For example... what is the "body?" Is it a box? What is it's model? If you don't specify properties specifically, what are the default parameters for things like the margin? Is the body contained by anything? What about the DOM? How about this? http://dbaron.org/css/test/rootbox

Take a look at this: http://www.w3.org/TR/CSS2/box.html