requinix

Personally, I'm still a fan of using Wireshark to inspect the request packet so you can tell what's wrong with it.

Short answer: no. Shopping carts work by using cookies and your site cannot set a cookie for a different site. Longer answer: It could be possible if a particular website had their "add item to cart" button thing programmed in a way that it really shouldn't have been. Which is by using a link to a page like "/addtocart.php?item=4252603765" that you could copy/paste into another computer and have work. So no.

Whether you use exceptions or not has nothing to do with where data comes from. It's about the architecture of the code and execution flow of the application. I strayed a bit from the exception stuff because the sun is coming up and I'm tired and I ramble when I'm tired. - I'm feeling meh about your use of exceptions here. "getValidatedData" sounds like it's doing two jobs: validation and getting data. Which is really only one job because you told it the data to begin with. Instead I would use a method to validate what's in $_POST and return a list of problems (if any). - USERException, which should really be called UserException, which should really be called something more useful than that, would go in its own file to be autoloaded. Like every other class. - WhateverItGetsCalledException would benefit from storing which field was invalid too. - Validate class, which again should be called something more useful, shouldn't be a class if all you're doing is putting one method on it like that. If you're not going to reuse the logic anywhere then it should just go alongside the rest of the input processing code. If you would reuse it then it would be better served as just a regular function - there is nothing "object oriented" about it so it doesn't make sense as a class. If you would reuse it as a sort of validator that might get passed around to other places in an arbitrary manner that isn't hard-coded into whatever processing logic is at work, then it should observe some sort of interface and you better have at least two more classes like it to do other types of validation. - Throwing an exception as a way of returning error information is... less than optimal, but IMO acceptable. It would make more sense if you skipped the validation at this point, blindly passed it along to whatever will perform the action (the //insert record), and that performs the validation and throws the exception if invalid. - Exceptions are about exceptional behavior, that is to say behavior that is unexpected or abnormal or otherwise not what typically should happen when the code executes. Validation is a normal step, getting errors is normal enough to not be considered "unexpected" or "abnormal", and so I wouldn't use exceptions for that. A simple "getValidationErrors(array $data): array" would suffice. - So then if //insert record calls the validation, what happens is the validation returns normally (validation failure is not unexpected behavior) whatever information to it, and then if there's a validation error it throws the exception itself (as the failure is "not what typically should happen"). Again, there's wiggle room there about whether exceptions could be considered appropriate or not.

He's clearly not going to be surfing porn sites or downloading torrents with it. Sitting behind a proper firewall and without my grandmother using it to download wallpapers of cats, it'll be fine.

Short of learning the packet structure, I'd fire up Wireshark (on a modern machine, of course) and run that code to see exactly how the packet is being sent. And compare with what something like nslookup or dig does. Because it seems to be parsing responses correctly, which means the problem must be in the request.

Chaining is a matter for coding style. Some people like it. Some people don't. You need to decide whether you like it or not and then write your code consistently accordingly. As for returning an object/array: It depends. Thus why abstract examples aren't very helpful for us. If getStuff() does not mutate (alter) the object and really does have multiple values to return then sure, return an object/array with the values. If setStuff() does mutate the object and a/b/c are all attributes of the object which you may want to access then it makes sense to have getter functionality, and whether that's ->a or getA() is another matter for coding style.

public function newPdfPedido($atividade, $id_turma, $local, $dataAula, $inicio, $fim, $fundamentacao, $observacoes, $id_professor){newPdfPedido() has 9 parameters. You need to pass 9 values to the function.

Why the heck would someone try to manually write and read DNS UDP packets by hand when there's already a perfectly good function to do it? Don't bother with that function and just use getmxrr like a sane person. As for the explanation, I don't know. There's a chr(15) in there which could represent an MX query, but my first guess would have been that the query didn't have it.

It would match fine if you didn't use the ^ and $ anchors that force the regex to test the entire string at once. And by the way, a slightly cleaner version: #/([ahi]?)\w+)#- # delimiters so you don't have to escape the /s (you can use just about anything as a delimiter and / # ! ~ are the most common)- [ahi] so you don't need | alternation - [ahi]? inside the capturing group so it always captures something (even if it is just an empty string) - \w is equivalent to [A-Za-z0-9_]

But what about a case like /search/xbox[/category/:category[/subcategory/:subcategory]]This becomes a problem of balanced brackets - simply checking for [] on either side isn't enough. Two suggestions for how to handle this: a) Don't allow optional variables and force the user to make additional routes. I've done this and it helps if you can give the user a way to configure routing in a recursive way, like <route path="/search/xbox"> route information here... <route path="/category/:category"> additional overriding information here... </route> </route>The routing system matches as much as it can, gathers all the information along the way, and decides what to do. You could also support <route path="/search"> route information... <route path="/xbox"> route information... <route path="/category/:category"> route information... </route> </route> </route>where the route information gathered for just "/search" isn't enough to serve a page and thus results in some 404-type behavior. b) Use regular expressions to turn the route pattern into another regular expression. I've done this one too. With your simple example you could have something like $route = "/search/xbox[/category/:category]"; // escape any regex metacharacters already present $regex = preg_quote($route, '#'); // if using # as the pattern delimiters // note that it will escape any of . \ + * ? [ ^ ] $ ( ) { } = ! < > | : - // or you can make this much simpler by not escaping characters and trusting the user to write mostly-regex-safe patterns // transform escaped brackets $regex = preg_replace('/\\\\\[/', '(?:', $regex); $regex = preg_replace('/\\\\\]/', ')?', $regex); // transform variables $regex = preg_replace('/\\\\\w+)/', '(?P<$1>[^/]+)', $regex); // replace [^/]+ with whatever you think matches a variable var_dump($regex); // "/search/xbox(?:/category/(?P<category>[^/]+))?"then if (preg_match('#^' . $regex . '$#', $url, $matches)) {gives you stuff like Array ( [0] => /search/xbox ) Array ( [0] => /search/xbox/category/consoles [category] => consoles [1] => consoles )The route gets [0] for the full match, and both named (useful) and numeric (useless) captures matching the assorted variables (if present). Why did I just say all that? Because at 4:30am I'm not seeing a "nice" way of solving your particular problem of dealing with the []s.

So what has changed since last time? I thought this was from a URI, but if that's true then where are these brackets coming from?

HTML 5's spec is a little better. The fun part is in the "Mutate action URL" behavior (which is what happens with method=get), but it has a flaw where the "parsed action" is undefined. However I think it's clear that the intention is to replace the parsed form action's query with the encoded form data, thus discarding whatever may be there already. So, 1. Switch to POST method? That's a matter for whether GET or POST is more appropriate for the action - the data and technical behavior of form submission are irrelevant. Given that it sounds like a "view"-type of action, GET seems more appropriate to me. 2. Keep GET? If you do then you simply put the arg1 and arg2 in the form as hidden inputs.

Speaking of doing things, For what purpose? How are you going to use it? When will this value be more useful than having just the individual components?

It's pure coincidence that you can check for numbers > 3112 - if there was a 13th month with 30 days then >3013 wouldn't work. In principle you can only do comparisons like that if you have the data arranged in decreasing order of magnitude: MMDD. Go ahead and use 3112 but you still need checkdate(). By the way, what are you going to do about 2902?

As maxxd pointed out, it sounds like regular Active Record: you have a class with properties corresponding to all the columns in the table it represents. So besides those three somePrimaryKey* fields you'd have stuff for everything else in the table. With that then, short of indexing and searching, a composite key isn't really anything special - it's just the knowledge that it takes more than one column/property to uniquely identify a record. You might not even have to do anything about it in the code.

The same (basic) way the database does it? if ($obj->somePrimaryKey1 == $primaryValue1 && $obj->somePrimaryKey2 == $primaryValue2) {But this isn't making any sense to me either. The index (composite key) in the database is all about searching - are you trying to do a search in code? Oh, and "collection" is less an OOP thing and more a term that fits the usage well. Like in the real world there's rock collections and car collections and bug collections and so on, so sometimes people use it in programming too. For example, .NET uses that word with many of its classes.

Do you already have rewriting rules for /events/page1 and so on? Because those don't look like regular files. I sure hope they aren't. If so then you should modify those to use (or at least support) your desired /events/pageN/MMDD scheme. [edit] Whatever the answer, the first part of the RewriteRule will look something like RewriteRule ^/?events/page(\d+)/(\d\d\d\d)$which would allow for dates like 9876, but it's really not worth trying to handle that here (and not just because of the complexity).

Browser? Are you using IIS to run it?

So there's that question: Does the file need to be (should it be) human-readable and editable? INIs are easier for that. And at only four values you can just use some simple scheme like ginerjm's simple text file.

Does PHP have access to that file? Can you filesize() it and such without problems? What if you put the file somewhere else?

Use forward slashes (backslashes are fine too but you have to escape them in strings) and no "file://" stuff. What's your code?

I assume a database is out of the question? JSON is easier to write out again. Associative arrays and objects are the same thing when exported so it only matters how you want to deal with them in the code.

If you use mysql_error() to get the error message then it will hopefully clue you into those trailing commas. Also, the mysql extension is really old and it's bad and you need to move to PDO or mysqli instead. Learn about them now and start using them before you write too much code and make it difficult to fix later. You also need to learn about prepared statements because any naive hacker could break that code and make Bad Things happen to your site. PDO and mysqli both support prepared statements.

May have been a hiccup on the server. Maybe the host was doing something that interrupted service. I'd ask them if they are aware of any issues at that time.

Cloning websites is copyright infringement. I'll be locking any other threads I see about this.