Antonio Conte

Actually, PHP is rumored to have bad recursion support. I can't prove that in a scientifically correct manner, but it holds true from personal experience and some unconfirmed sources on google. Generally, if you have ever done recursion in Java, C or anything like that, PHP will not perform comparably to them. I generally stay away from recursion in PHP because of this, although I would not generally recommend anyone from using it neither. Maybe Larry knows more about the recursion support? Recursion is a function that calls itself btw. Generally, recursion has a lot of overhead. You should almost always replace recursion with iterative calls if possible, but that is sometimes not convenient. All kinds of programming tricks has it usage. Btw. This is more of an informative/non-sense post than actual help. I'm speaking in general terms here...

I believe you need to write a more advanced query then. It's a little bit tricky to understand the problem without some example results, but I believe you need to add a where clause here. It could be something along the lines of : WHERE page_id = $page_id OR parent_id = $page_id That might not even be close to a solution for you, but it will help with your thought process. Think about what kind of records you need, check that all variables have correct values, and check number of recursions to make sure you get everything. Use a combination of print_r(), echo and similar to get this info.

Right on. You got the idea there. With a solution like that, you can make it exactly as advanced or simple you want it.

One easy miss here. PHP arrays start the count on zero, (0) while MySQL starts at 1. Try printing out the number inside the loop, and see if the first is repeated or the last is missing. Adjust accordingly. This might not be your problem, but it's at least a very easy check.

I don't fully agree, but I don't complete disagree neither, Jon. When it comes to functionality, data integrity or clarity for users, I would not rank speed the highest. You don't need that extra information anyway in a product list/overview on second thought, so it would functionally be the same. (I guess) I think my idea might be a good solution, but I'm sure I missed some pitfalls. Do you need to use stored procedures, though, 1cookie? This seems very limiting and rigid to me. What if you want to incorporate some new clauses? What might be a better idea is a standard GET-based search where search query alters by the param. As an example, how about: domain.com/search.php?brand=nudie jeans domain.com/search.php?category=new I'm not sure if this is really a better idea, but that is what my sleep deprived brain would have done. Btw. It would be easy to include searches on all clauses, add filters and that kind of stuff with such a solution. If I'm not very good at explaining my thoughts, I can write a short demo tomorrow.

We fully agree, Jon. The question is how this can be modeled effectively. If you take a look at the current scheme, you would need to add 12 products no matter size, color, etc. My thinking is data a more generalized product, with extended information about the actuall products size, color and availability could be defined on top of that. That would allow you to add a single general product (Like "Nudie Jeans Slim-legged bootcut Nr. 10", but control how many "blue, medium" or "red small" are available in stock.

Ok, I thought you were struggling with something here. If you want a general discussion on your ER-diagram, sure we can do that. From the looks of it, your models look pretty good. However, there are some things that bother me a little bit here, or that I want to ask you about. 1. The table Prices. I don't get that entity. You should store the prices as floating point numbers. Your current solution is a one-to-one relationship that does not make sense to normalize. If you need the price table in another setting, do that, but remove the relationship to products. 2. Categories in products. Could some jeans fit in several categories? Might be worth thinking about. 3. Stock. This one is a bit tricky, so discard me if it's the wrong approach. A single pair of Jeans might come in 10 colors and 5 sizes. Currently, you would need to add 50 products. This is too complex to figure out while on the train, but you should think about this one. Is there a way to add a generalized jeans product and then add size, color and numbers of jeans? I don't know if that would work for you, but it would make many things easier. Hope that was closer to what your after.

The examples should be perfectly trasferable to other type of products too. Read the parts you did not fully get another time, then try out some of the code. After that, it should click in place for you.

You should really check out this thing called Personal Messages. Cool read anyway.

What's the purpose here? It's important, as absolutely validating an URL may be tricky. Is it enough to be reasonably sure that the URL is correct and make sure the URL is safe to display? Then a mix of the FILTER_VALIDATE_URL filter and htmlentities() might be enough for you. Remember to fit your solution to your needs. After all, security and usability might be the most important here. Once a URL is safe, and you can reasonably assume it has the correct structure, you might have done enough.

Elementary, my dear Watson. Good job, Edward.

@lrzins: The reason it works is because YII will look for model attributes and by convention require you to have a get-method for it. You can argue both ways if this is a good solution, but currently you just need to know that's how it works. The reason different versions of caps/similar also works, must be because YII applies some String operations there.

I got to admit I really love Twitter Bootstrap. You can create really beautiful design with a very small stylesheet overriding Bootstrap's defaults. I've been waiting for such a thing for a long time. While other frameworks might be good, no-one has ever collection everything from button design to different form layouts in a framework (and succeed). Twitter Bootstrap understands what you generally need in a framework. I started out as a web designer, and have tried several of these framework. Bootstrap is the first one I've liked.

XHTML is alright, but don't use XHTML 1.1 Strict. Other than that, you are currently free to use whatever you like, even HTML 4.1. If you are planning on writing new HTML, I would recommend going for HTML5.

Short answer; Yes. Frameworks are very generalized for obvious reasons, and you would not code everything the same way yourself. The important thing is finding the balance between an abstract and case-specific solution. Taking your FedEx-example, I would code just that. However, if the FedEx class uses very general functionality in some cases, you may want to generalize that part alone. Very good, modular procedural code can be pretty similar to object oriented classes. You are right on that. I think you should read a little bit about class design. Like with databases, there are ways to plan your class hierarchies before you implement them. Learning a little about UML design will take you a long way

Sure this can't be fixed by database normalization instead? I don't understand why a separate table is needed for every campaign. I might be missing something crucial here, but generally I would suggest you to take another look at your database structure. While this may be working fine now, how about half a year from now? The reason why this do not exist is because such problems are usually solved by well known normalization rules.

Actually, I gave you way more to go on than Larry. While his recommendation about rendering views might seem what you are after, you really need to be able to apply the right kind of logic to the rendering of those views to achieve what you want. While his answer is completely correct, you completely fail to understand the requirements along the way to achieve what you want... I'm a pretty nice guy, so I'll just tell you to read more on the basic principles of the MVC pattern. With basic logic and that theory under your belt, this problem should be very solvable for you.

Ziggi. Not to get personal about this, but read my suggestion one more time. They are along the exact same line as Larry's, and I have to tell you that rendering views partially is nothing special. My suggestion actually tell you have such a task can be performed, but you don't really seem interested in accepting that.

I think a large part of your problem is that you ask for "YII based examples". What you want to achieve here is a simple step by step system based on logic and some clauses. The only difference on how to achieve this in YII and a simple procedurally coded website is where to place the blocks of logic. The question is this: are you sure my "general opinion" is not only a lack of understanding for the things possible to deploy within YII? I can't really see any problems implementing something along your description with DOJO. The only problem I have is that I can't really give you a step by step explanation on how to achieve the wanted result... Concluded. Are you sure you attacking the problem from the right angle? It looks like a simple "achievement system" to me. Once an achievement is unlocked, a new tab is opened. This feels very much like your static pages problem to me. I'm not sure you try to solve the problems the easiest way possible.

Some of the beauty of views is that you may introduce such things easily. Add the Javascript file reference to the header and apply the code needed in the bottom of the view file. Very simple, and very affective. No need to make this more complex by wrappers or that sort of things. I can be benefitial, but it's not really required. Doing this in YII is no different than with standard HTML. The only thing is that you can't take advantage of YII's event system (which seem awesome) but you should be able to get most tasks done with standard JS/Dojo code. A little drawback admittedly, but sometimes the best solution is the simplest one. If this does not work, I'm sure jQuery can perform all of the same tasks. Hope that's a good enough of an opinion. I know you don't always like these opinion based posts, so ignore it if the shoe does not fit.

That is not linked to MySQL or even PHP, but to Apache - the web hosting software. There's no difference functionally between "htdocs", "public_html" or "www". Remember that there is not link between MySQL to PHP, but the other way around. The only thing you need to worry about is finding the PHP files through Apache (by a normal URL, no magic there) with your browser. When the files are executed, you just make sure you are connected to the new MySQL database. Don't overthink this. As an example, create a file called "test.php". Place code for connecting to MySQL in there. Upload to "public_html" with FTP software. Run it with *your-domain.com/test.php" and it works like on localhost. No magic there.

One reasoning is the ability to actually define 'English' in your call logically.. I like the approach as it's very clear what the default is. I think it's good practice as you might need the explicit case later on.

It's called procedure, and is stored as a table. It's callable, and can be parameterized. It can therefor be great for calculations or similar tasks. You just got to look it up in the manual for syntax, but now you know when you can utilize it. As a side note, I've never used stored procedures myself, as tasks can often be solved other ways. It is a good trick to add to the toolbox non the less.

I would say that's an acceptable "workaround". I haven't read the documentation for this, but if that solution is stated clearly, I find it both pretty and logical. I tend to think example usage of code lacks from the YII documentation, but maybe that's just me. Glad you solved it. If it's possible, you should add a guide on virtual attributes in the manual.

Remember that a String can also be used as a key. "NY" can be used a primary key in the city table, and a foreign key in the table above. (General clarification not tied to normalization) I would suggest you to learn the normalization rules, as it will help you to understand when you can break them.