General Development Considerations

Archives Yii 1.0.x Discussions
1

Hey all,

If you’ve read any of my other posts, then you know I’m a noob, so please go easy on me for this post ;)

I’ve used PHP for a while and can usually accomplish anything I need to do, but I’m a little green when it comes to full-blown web app development and the ‘right and comprehensive’ way to do things.

I know I have to take care of the following:

Security (I’ve got the basics and know what else I have to do, I think)

Error Handling (total noob)

Sanitizing Input (total noob)

What other kinds of things do I need to handle in a large app?

Also, do you know of a good resource that shows a general web app flow of when and where and how (preferably with Yii) to do these things? I can get the details of anything Yii can do from the documentation, but I’m having a hell of a time getting the Big Picture. I feel like my code is just a jumble of one-off functions with logic all over the place instead of clean and consolidated.

I’m self-taught so that probably contributes to the problem.

Even a single generic MVC flow with the above considerations in psuedo-code would be helpful.

Any suggestions?

2

Hi drech,

Good to see you put so much effort to phrase a common problem. Self-taughtness does not contribute to this problem, but makes you jump in any project you visualize without any prior planning.

If you had a large app, then Yii probably will be the last thing you’d like to touch. Grab a few sheets of paper and draw. Draw your main page’s boxes, draw your about pages, your contact pages, and many more until you covered all pages on your site without exceptions. (I did exceptions, now I feel sorry. Take your time.)

In the second step, grab even more sheets of paper and write. Write your headlines, your proposals, content, button values, everything that might occur in text.

(Of course you can do all this stuff on your computer. Paper is just better.)

Security is nothing more than following good practices. Binding parameters, applying rules, filtering user input. It is recommended to protect your application from user input in models, so you keep your controllers neat and models reusable.

Yii does error handling. You should concentrate on proper error log routes and usable error views.

I’ll definitely discuss this further, however I’d like to note this is not something Yii-related. Self-taught single developers quickstarting huge projects (or small projects that seem huge) is always a challenge.

Looking forward to hearing your opinion.

3

I thought maybe I should post this in the general PHP forum although it’s not specific to PHP either, but since I was looking for the Yii way to handle things, I posted here.

Mapping all the site pages is fantastic advice. I went to great lengths to ensure all my databases/tables were normalized before I wrote a single line of code, but failed to map out the pages themselves. So my planning was only partially done. Doh. I do have lists of functionality each page will have, written many times over as things change, of course, but it’s not the same as page planning.

I think some of my confusion comes with all the ways I’m supposed to be doing things:

Keep It Simple, Stupid,

Don’t Repeat Yourself

Skinny Controllers, Fat Models

Agile, iterative development

MVC and keeping logic out of presentation

Over-thought is Over-wrought

An example:

Assume I have three web pages; one is a login page, one is a registration form, and one is a list of registrants.

Obviously I want to sanitize any input on those first two pages, but they may be in different controllers and, more importantly, use different models. To KISS, it seems like I should have a sanitize function for each model that is specific to it’s potential input, keeping it simple and self-contained. To keep things DRY however would mean a single monolithic function that serves all sanitizing events and is available app-wide. Doing the latter would make the code hard to follow since you would need to jump between multiple files to really understand what’s going on, but there would be a minimum of repeated code.

Another example, this time with the last page (registrants):

In the controller, let’s say I query a DB for a list of existing registrants (using a fat model!). In one case, a data-filled object is returned which is then passed to a view. The view loops over it and displays the list.

In the other case, no registrants are found and an empty object is returned.

If I test for emptiness in the controller, it means I need two conditional render statements, one for the data-filled object and one that ignores the empty object.

If I test for emptiness in the view, then I have logic in the presentation where it’s not supposed to be and have violated MVC.

Which do I choose?

Even with my limited experience in writing medium or larger apps, I tend to think I should keep the views as unintelligent as possible and in this way, consolidate logic in the controllers and models. But if I do that, the code in those controllers and models becomes quite ugly; lots of conditionals to find out which render statement to execute, for this example. Well, maybe not lots, but even two seems redundant and wrong (and bloated).

It’s these kinds of questions that drive me nuts. Am I looking for best practices or is this stuff related more to design patterns? I don’t know what to look for to see ‘how it’s done’ in professional apps. I realize I’m not professional caliber yet, but that’s my goal and want to get on the right track.

Thanks for helping me understand, I really appreciate any advice or pointers to information :)

4

Please note that I will share my own experience (since I don’t have others :)).

The first thing I totally disagree with:

This is wrong. There is a myth that views are not connected with models. The MVC architecture is a triangle, not V-shaped. There is nothing wrong with logic in views either.

Of course you don’t want to manipulate global app states in views, but that’s a completely different scenario. Checking for emptiness is a very important part of presentation (since this influences your final output), and has nothing to do with application flow (controllers), or with top database layer (models).

In many cases where request is asking for a single object (like, say, a blog entry) it’s more semantical to throw CHttpException(404) in the controller and not in views.

Having said you’d like to follow KISS, DRY and other theories, you also say you want to stick to design patterns; however, it’d be the same as blindly following some self-appointed experts’ advice. Applying design patterns where they are inappropriate equals over-thinking. :)

As you also implied, there is a bit conflict between design patterns - KISS would mean less functions, less classes, less lines of code, etc.; while DRY would centralized components, more files to keep everything separated and reusable, etc.

You need to consider many factors to decide which practice to apply where. Do you expect high configurability? Do you need maximum performance? Is reusability really important to you?

Centrally sanitized input seems like a bad idea to me. Models (both AR and forms) do have the tools to apply rules to data in different scenarios. They are responsible for storing and returning correct and safe data.

Furthermore, let’s say I store datetime as UNIX timestamp. I mostly use this in united formats, so I have set up a method for this in the model.

But I have to print the time in a different format at one single point in the whole application. After making sure this format won’t be needed anywhere else, what should I do? Is it worth to add parameters to the model method? Is it good practice to generate it in the controller, so I’ll hardly configure it again? I’d make the manipulation in the view.

In conclusion I have to admit: my belief is that views are the most reusable components in my applications, so I use their power freely and wisely.

Always follow practices that make sense. Doing all this stuff in semantical way is way more helpful in the long run.

5

Mindmapping could be a good tool to start. And clear out points.

Something like this:

Mainpage - mailbox "block" - Only for registered users

                        - Only for users logged in - Use sql to get data - Modify for output


     


     - see friend feeds - Same as above

Or for page "flow"

Register - Email - Must have six signs

             - Must be valid


             - Must be none existent/ used


             - Must be repeated - email2 - Same as email

And so on :)

How you "use" your mindmap tool, is not a "standard" thats the fine thing about mindmaps. They represent your "brain". No uml standard, or how you have to order you bubbles. Just a few "special" signs for bubbles are used.

I would recommend freemind. As a free mindmap tool :)

If you write ( or have to ) a big app, try to break it down in small useful pieces. I would then recommend to work on around three "small" pieces of it. So you could switch to another part of the app. When you run in trouble. And comeback later. This helps allot.

I also would recommend to read someting about time management. In German there is a book called: Time management in 5 minutes. Not quite sure if it is called like this.

For the rest ask other users. Or use the mighty search engines out there.

Oh and use a cvs like svn, git or whatever you like.

6

I’ve reread both of your replies several times. There’s a lot of insight there.

I can see now that trying to apply all those theories forced me to over-simplify in order to resolve the conflicts between them. It’s freeing to know views don’t have to be unintelligent templates. I was being too literal with MVC.

It’s also freeing to know that, while structure is of course important, I should not be so rigid in applying theories. I need to code in a more fluid way and ‘slide’ between those patterns as requirements and common sense dictate.

As far as mind-mapping, I was surprised to see I had already installed freemind but never used it, so I’ll give that a shot :)

For the clearing out points, I went over the functional sheets I have been working on and realized a shocking thing: all of the info there is from the user’s perspective and has no bearing on how it will be implemented :blink:

So I’m going to draw out all the pages for the user/design perspective to see specifically what needs to be coded, use freemind to generate implementation details from the developers perspective, break the app into modules, and code it up using whatever practice/pattern is best suited to the task at hand.

It sounds obvious to me now, but with so much stuff going around in my head about all the ways I’m supposed to be doing things, I couldn’t see it.

This is exactly what I needed.

Thank you!