Symfony

[dmcglone]

I just took a look at Symfony It was such a pain trying to even get it working over my network that I gave up on it. What a shame. :-/

[jazzman1]

Symfony is an enterprise level framework for me and it's not easy to learn.

 

Don't be embarrassed  

[Jessica]

Ok...

Did you have a question? Or shall I move this to misc?

[dmcglone]

Haha. I couldn't believe in order to get it to run you had to be working on the machine it's installed on (which has no GUI) or add the WAN IP in the config file. Adding the WAN IP would require opening my firewall. All this made me cringe and I just gave up on it.

[dmcglone]

Ok...

Did you have a question? Or shall I move this to misc?

Oops, my bad. Yes please could you move it? :-)

[Jessica]

Cool story bro.

[gizmola]

Symfony2 has a lot of thinking that went into how professional developers typically work. It represents best practices. Yes, almost all professional developers use one of 3 methods these days:

 

- Working locally in a MAMP or WAMP

- Working locally in a VM (Vagrant, Virtualbox etc)

- Working remotely on a server that has shell access

 

So, first of all, yes symfony2 requires command line access, but this is primarily in order to give you essential productivity and testing tools you run from the command line. They also create these things you might have heard of called "unit tests" which help insure that you have well tested framework, and encourage their users to do the same.

 

Secondly, every modern library and framework in the php world is moving to support PSR-0 and the composer tool. Composer requires a shell.

 

I know about the issue you encountered, which is that symfony starts with intrinsic "environment" configuration. There are 2 main environments they support -- 'dev' and 'prod'. These are enforced through the "Front controllers" that are the bootstrap for the framework. The actual scripts are in the /web directory and are named app.php (prod) and app_dev.php (dev).

 

The problem you had is that in app_dev.php, there is a small rule that you need to comment out:

 

// This check prevents access to debug front controllers that are deployed by accident to production servers.
// Feel free to remove this, extend it, or make something more sophisticated.
/*
if (isset($_SERVER['HTTP_CLIENT_IP'])
    || isset($_SERVER['HTTP_X_FORWARDED_FOR'])
    || !in_array(@$_SERVER['REMOTE_ADDR'], array(
        '127.0.0.1',
        '::1',
    ))
) {
    header('HTTP/1.0 403 Forbidden');
    exit('You are not allowed to access this file. Check '.basename(__FILE__).' for more information.');
}
*/

Do that and you can call the app_dev.php controller on your remote server and develop away.

[448191]

IMO S2 is by far the best PHP framework right now. Granted it has a learning curve, especially for less experienced developers, but it's well designed (or well "borrowed" from other frameworks like Spring) and much more mature / complete than the alternatives. I didn't like S1 and opted for ZF1, but I like S2 a lot better than ZF2.

 

The standard distribution just contains some stuff to get a sandbox setup quickly: the contents of app_dev.php are just illustrative. As gizmola suggests, just tweak it to your needs. Same goes for the config files that come with it. There's a distinction between an example sandbox setup and library code.

 

Anyway, I highly recommend S2 and you might not want to give up on it before you understand why things are the way they are.

[dmcglone]

Nice Gizmola. Thank you.   

I was going to add my IP to this file, until I found out I was going to have to use the WAN IP and open my firewall. Well at least according to my google searches and didn't know if commenting it out was a good idea or not.
 

I'm going to go give it another look now.

Thanks again

[448191]

Nitpicking perhaps but I feel strongly about it: it's not. Don't *ever* comment out code, just remove it. I truly despite when devs comment out code. Version control allows you to look at historical versions, clean up your mess behind you and use comments for what they're for: commenting.

 

Bit off-topic but one of my mayor annoyances in reviewing work of others on my codebase. You flush the toilet after taking a dump too, right?

[dmcglone]

I do, but you never know at this point I may want to keep that turd.

[448191]

Should you want to look at it after it becomes obsolete, look in the repo history. If you're not using a VCS that's an even bigger issue (even the smallest projects should), but if you are, there's no reason to keep code not being used and plenty in favor of removing it. If you need to temporary disable something (a situation to be avoided like the plague btw), remove it and restore the file afterwards using your VCS or IDE. There is no valid reason for commenting out code, seriously. You'll end up committing/pushing that crap at some point, even if you're vigilant. And then your crap it not just your problem anymore. Instead of flushing, you picked up your feces and spread it all over your teammates' faces, to keep with the metaphor

 

Not on topic so I am going to leave it at this, but it annoys the hell out of me especially because it's such a widespread bad habit. 

[dmcglone]

I wish I was good enough to be developing on a large scale. Most of my work is only for myself. I haven't even really gotten to a VCS point yet, but I had just inquired about it the other day on here, and signed up on Github because I am starting to feel the need. Also, I inquired about the Smarty templeting system and today I decided to look at some frameworks. So I am definately moving on up I just need to find what works best for me and how to implement it into my skill set and enviroment.

[KevinM1]

I wish I was good enough to be developing on a large scale. Most of my work is only for myself. I haven't even really gotten to a VCS point yet, but I had just inquired about it the other day on here, and signed up on Github because I am starting to feel the need. Also, I inquired about the Smarty templeting system and today I decided to look at some frameworks. So I am definately moving on up I just need to find what works best for me and how to implement it into my skill set and enviroment.

 

Symfony2 comes with the Twig templating system by default, so you'd probably be better off learning that.  I agree with the others in that S2 is the best PHP framework available right now.  There definitely is a bit of a learning curve, especially as you go deeper down the rabbit hole, but it's worth learning, IMO. 

 

Regardless, you should also learn how to use the following:

 

1. Composer - essential for real development.  Learn it, love it, use it.

2. Git, or some other form of VCS.  Git's popular because the basics are easy enough to learn, the way it tracks versions is lightweight, and it's distributed

3. Unit testing (PHPUnit)

 

Unit testing is probably the hardest to get used to, because it means programming in a different way.

[448191]

Everyone working in a large-scale professional environment was where you're at now at some point. Assuming you've mastered the syntax and features of at least one language with OO support, you'd do well to explore OO principles. Start with reading about the concepts of coupling and cohesion. This allows you to understand SOLID principles and design patterns. Also get comfortable with the de-facto standard deployment platform: Linux. I always say a good programmer is half a system admin. 

[448191]

Unit testing is probably the hardest to get used to, because it means programming in a different way.

 

Actually, TDD is a paradigm, Unit Testing by itself is not. I'm not trying to undervalue it but strictly it just refers to testing a small subcomponent, and doesn't dictate a development process like TDD does. Unit Tests are written to ensure predictable behavior of existing code as well, despite Kent Beck's explicitly advice worded "don't bother". Symfony also provides facilities for headless functional testing (or Integration Testing), very useful to ensure your components don't just work but work together.

[dmcglone]

Symfony2 comes with the Twig templating system by default, so you'd probably be better off learning that.  I agree with the others in that S2 is the best PHP framework available right now.  There definitely is a bit of a learning curve, especially as you go deeper down the rabbit hole, but it's worth learning, IMO. 

 

Regardless, you should also learn how to use the following:

 

1. Composer - essential for real development.  Learn it, love it, use it.

2. Git, or some other form of VCS.  Git's popular because the basics are easy enough to learn, the way it tracks versions is lightweight, and it's distributed

3. Unit testing (PHPUnit)

 

Unit testing is probably the hardest to get used to, because it means programming in a different way.

 

Thanks for the info, this type of info is exactly what I'm in need of and I've got my work cut out for me. I've been writing PHP for a few years and I'm starting to wonder where I was all these years?

 

And I thought I felt small earlier, Huh, I think I've been reduced to a speck of dust now. LOL

[dmcglone]

Everyone working in a large-scale professional environment was where you're at now at some point. Assuming you've mastered the syntax and features of at least one language with OO support, you'd do well to explore OO principles. Start with reading about the concepts of coupling and cohesion. This allows you to understand SOLID principles and design patterns. Also get comfortable with the de-facto standard deployment platform: Linux. I always say a good programmer is half a system admin. 

 

I'll probably never do a large scale type app, probably something more medium scale like wordpress, but I'd still like to have the knowledge to go large-scale if I ever needed or wanted to. As far as a language, I've used PHP for a few years and feel comfortable with it, but not where I want to be though.

 

As far as Linux goes..... Been a  Linux user since RH 6.2 (I believe) Currently using Ubuntu

[448191]

Even if you never go "big", understanding OO principles is a smart move. It's the quality that I find lacking in developers most often: they stop after learning syntax and language features, perhaps they'll keep in touch with with a public community but the PHP community is catching up too slowly and cling to practices that don't scale. Although, and I speak from experience, you might be tempted to overdo things once you do have a solid understanding of OO: bringing a sledgehammer to a game of midget-golf. But likely you'll start building stuff that justify the size of your hammer

 

PHP has a bad rep as a platform for Enterprise development, you should see the faces when I tell people it's all written in PHP after I tell them what we do.    In any case, a better understanding of OO will benefit you using pretty much every common language. You can learn the syntax and facilities of 10 languages and that conceptual knowledge will be useful in all 10 cases.

[dmcglone]

I think I already do build stuff according to the size of my hammer. I been having a battle with myself for at least the last 2 years about my code organization, project organization and just tidiness in general. More often than not, I start working on a project and I find myself spending way more time trying to organize and tidy up code than I actually do developing. This is what led me to come here the other day and ask about Smarty, a VCS and now a framework.

Also I try to mimic my own three tiered architecture, but I find it's not really working for me. That's where I was hoping to implement either a template system or a framework and not only because of the the things I mentioned above, but also because I hate the sight of echo statements everywhere. Don't know if it's just me or I'm crazy, but an echo statement makes me cringe.

On a side note, I've been playing with symfony since earlier today, and I like what I've seen so far. The sight of my PHP code and HTML is promising to me, but I'm having a small problem getting an example from their website to run, but I'll figure it out in a bit when I join their forum.

I appreciate all the feedback everyone has given me thus far. It has proven to be invaluable to me.

[gizmola]

Good start with Github. If you don't mind your source code being public you already have access to the most successful vcs in a saas environment. Of course you can also pay them to allow you to have private repos.

 

However, even before you get this all hooked up, just install git on your server, git init your directory, and you will have made a great start and begun to address 448191's original point.

 

This is because git is fundamentally different from older spoke-hub systems like subversion.

 

Git was designed to be decentralized, so you in essence have a full repository on your local system. Of course people want to collaborate with others that requires github or some other server, but aside from pushing code to another server, there is nothing you don't already have available in your local git. You can make branches, commit code, and merge branches together -- all on your existing server. And of course you get the immmediate benefit of being able to get back prior commits, diff between them, and all the goodness you expect from a vcs.

 

As soon as you get that going, and configure your server and github with the appropriate keys, you can push your code up to github, but it's not something you have to have going before you can start to benefit from git.