redbullmarky

y'know, as far as templating goes - i kinda agree. but that's kinda batting the responsibility away onto others. I'm probably less skilled than you. My only training has been the internet. I am 100% self-taught. as for validation, i'll restate something i said earlier in the topic: Andy's earlier post quoting something else summed it up even better: validating your code is often a case (depending on doctypes) of using <br /> instead of <br>. Or making sure you've got & instead of & as well as other html entities. And nesting the HTML correctly. and making sure IMG tags all have 'alt' attributes and are closed with " />" not just a >. Not rocket science stuff, but they are the HTML industry equivalent of spelling mistakes. As long as you've not gone down the 'echo '<tr><td>hello</td></tr>'; style of coding, getting stuck in to your site to validate it is a TINY job - even 200 errors can be dwindled right down just by fixing a few of them, as many are the result of others. I think the problem is that many people take the whole internet industry lightly, just because of how easy it is to get stuck in and write code that works even though it's wrong. Sure, everyone needs to start somewhere, and more often than not, your first sites will look like a bucket of sick. The difference is that your first sites are generally personal sites - not for selling to a client. My first mini-sites were awful. But you do need to remember that when you cross the line from hobbyist to developer, you're entering a technical arena that combines many technical and artisitic professions together. The least you can do if you're gonna work in the industry full time is to make sure your stuff is as good as it can be - not just for the "average" viewer, but also for the disabled amongst us that want to be able to use the site properly, or for those who choose different browsers altogether. *and one final point* how many of you "I don't see why validating my code is important" people are fans of Microsoft? Cos it's very funny how many other times i've seen this argument come up, most of the people who can't be arsed to tidy up their code are the first to slag off Microsoft and tell everyone else how crap a browser Internet Explorer is. So ... why IS Internet Explorer a bucket of sick? Why IS Windows full of issues constantly? Because someone didn't clean up their buggy code, and someone didn't really care whether their browser didnt follow standards. "Oh well never mind, at least we've got billions of £ for it." says Mr Gates.

haha i like that one

not much to do with PHP, but you could do worse than taking a look at mootools. it'll handle the drag/drop for you, as well as AJAX requests (also look at its manual regarding JSON which i've found tonnes simpler to use).

you'll need to do plenty of work in terms of verifying what gets uploaded, and you could do much worse than lock down the directory where the uploaded files go so that files cannot be accessed directly. one of the biggest exploits with these type of sites is the uploading of a PHP script only to then run it from where it gets placed. a custom PHP script on someone elses server = bad news.

i get an error when trying to upload:

first off the bat, it looks quite good but your top banner area is far too big, considering the logo is so small. you could shave off at least half the height which would bring the main part of the site more into view. also, for the lazy ones amongst us, make the logo a link to the homepage. I kinda expect it these days as to many others who are too lazy to motion the mouse towards the 'home' link otherwise, looks pretty good from first view.

doesnt matter whether they're "Web2.0" or not. valid code is valid code. My point bringing up that, along with ajax etc, was that so many people jump into a fairly technical arena, throw all sorts of various scripts and rubbish together to make a "site" and charge for it. On one hand I say "fair play, if you can get the work". On the other, I say you're taking away from the reputation of an industry already littered with crap and bad reputations.

Haha not completely. I just cant understand it that when you're having an argument that you're 99.999% guaranteed to win because you're totally in the right, they unleash their magic box of tricks that leaves you not only speechless, but also on the sore end of yet another losing argument. And yet still you can't live without 'em. Oh well

1) are selfish and unreasonable 2) are selfish and unreasonable 3) are selfish and unreasonable 4) are selfish and unreasonable 5) are selfish and unreasonable

this is my point though. you mention the fact that they're gonna eventually write good code - that takes time - so cutting corners might save time now, but always creates more work in the long term.(edit: as Tom points out) So fair do, the problem lies with your company and not you, as you're trying to keep your job. Doesn't mean I have to agree with the morals of it. The best and worst part of PHP/HTML is the same thing - both are easy to use but both encourage people that don't entirely know what they're doing to jump in and churn out crap. LiquidFire - that's not an implication on you, but more of a general point. I do kinda feel quite strongly about this sort of thing, mainly because I've seen how the web has evolved over the past years since I got involved, and moreso since the "Introduction" of Web2.0 and AJAX to the mainsteams and since I started properly freelancing. Feedback from clients generally involves some sort of mention about how they've been shafted in the past by paying regular money for substandard results, be it from a company or a freelancer. Every man and his dog wants to use AJAX for everything without knowing why or what its implications will be. Everyone wants big text, over-the-top gradients and rounded Web2.0 logos. Just like yesterday, everyone wanted Flash. Sure, we all need to learn - I just sometimes wish the learners who have yet to appreciate the further implications of what they're doing (beyond money) ie, quality, usability, accessibility, etc - before they start taking money off people.

sorry to put the boot in dude, but that's an excuse and a half if i ever heard one. personally i would never employ someone that didn't produce top notch work, even if that meant paying more wages. Personally I am a perfectionist, but I'm also someone that likes to appreciate every potential market to a website of mine, irrespective of browser, browser settings, disability or anything else for that matter. If making a few tweaks gets me 5 extra members that are happy, that's my job done well. Sure - I'm pretty positive that there are small areas of my own work that need addressing, but the point is, I DO try my absolute best to make sure that my work is not only presentable on the main browsers (IE, FF, Opera, Safari, Camino, etc) but is also accessible enough for those that aren't as fortunate as you and I to be able to actually SEE the screen. I'm not trying to be a Mother Teresa or activist here - just pointing out the facts that so many people are naive enough to churn out sites that may look good not realising that somewhere someone isn't able to actually see it anyway. In some ways also, these coders that churn out turd without a second thought for the users are taking away jobs from those that actually want to produce quality work and not rip people off. My personal work comes from word of mouth - but delving into the freelance world and seeing how many people will churn out utter crap for stupid amounts of £££, it's no wonder clients are thinking negatively about the whole web design/development industry as a bunch of cowboys. And yeah - burn phpfreaks.com's main site all you like - but the point is, I don't live by other people's standards, be it myspace or youtube or ebay or phpfreaks or whatever - it's not a case of jumping on bandwagons or saying "well this and that site do it and they're multi-billionaires, so it's ok for me not to validate anything or show any pride" It's about pulling your finger out of your arse and saying "Right - this guy wants to pay me £2000 to do a site, which will put bread on the family table and pay the mortgage. Let's rock and roll and give him/her some quality in return." Sorry for sounding hotheaded about a seemingly trivial matter, but it really does grind me that so many people just miss the whole point - it's the little things that REALLY count when it comes down to it. I can't make everyone happy with my work - but I can bloody well try.

well. just as i thought when i first mentioned it - I turned of javascript to be stubborn (like many people still do) and guess what? I couldn't view a single page - it effectively killed every single one of your links. So i'll say it again - the site's looking much better these days - but the pointless use of AJAX just for "using AJAX" sake is not a wise move. Search engines are NOT going to index all of the content on your site, the back button on the browser gets broken, as does the refresh button. Personally I'd change them to static pages as it's just pointless. If you really are adament that the AJAX requests are staying put, then at least modify your links to provide an alternative for non-JS users. Something like: <a href="/index.htm" onclick="loadIndexPage(); return false;">Home Page</a> which, with the use of "return false", follows the link if javascript can't be run but calls your JS if it can.

SEO = search engine optimisation. One of the weird things with many of these frameworks is that you'll probably never use $_GET ever again - but more of a segment approach. It's weird at first, but when you get used to it, you realise how much crap you throw in the URL. example? would become: which from what i've both read and experienced, REALLY helps getting those pages indexed. Google is not really a fan of pages that have lots of URL parameters - so simplifying it into a more readable fashion does wonders. A look at the URL's of blogs and many "Web 2.0" sites will show you how it's not all about the ? and the & as for your last point(s), dont just see the examples (RSS/validation/AJAX) as all there is - those were (personal) examples of those tasks that when I used to sit facing another project, I thought "*sigh* not another bloody contact form/Rss feed, etc" - now I can just get on with app/site specific stuff. In my opinion, Rails (and Ruby) itself is sideways comparable to Cake (and PHP). If you know PHP, stick with it as Ruby doesnt REALLY offer any additional benefits (due to my old argument about the languages being more powerful than their results). As a beginner, maybe one might go either way and both ways would be fine - however, when the ultimate gain is to earn money and put bread on the table, best to stick with what you know rather than tackling "that" learning curve again. And in my other opinion - if Cake doesn't do something that Rails can - write some code to make it! That's much easier than learning a whole new language and starting from the bottom of the ladder again. Cheers

you kinda need to remember though that the examples given in this topic are just that - and that is REALLY skimming on the surface of what a framework can do in one small area of your site. But consider stuff like validation, RSS, AJAX, Emailing, nice URL's for SEO, amongst many many many other things - all areas that time after time get asked about in terms of "how do I do this?" - though whilst its still advisable to find out, a framework will do much of this sort of stuff for you. your example is pretty much there, although like 448191 says, it's better to delegate responsibility elsewhere rather than doing any crunching within. so you might have a model class called 'User' that extends the 'Model' class (and any class extending 'Model' will also have the same methods available which is where the usefulness really comes in): <?php class Model { public $tableName = null; function get($conditions) { $query = "SELECT * FROM {$this->tableName} WHERE $conditions"; // rest of code here return $result; } private function __call($name, $param) { if(substr($name, 0, 5) == "GetBy") { $field = strtolower(substr($name, 5)); $conditions = "$field = '{$param[0]}'"; $result = $this->get($conditions); } return $result; } } class User extends Model { public $tableName = 'users'; } $myuserinstance = new User(); $user = $myuserinstance ->GetByUsername('redbullmarky'); ?> but yeah - ultimately you've got the gist. useful, huh? Cheers Mark

overloading to me is a little sketchy to talk from a technical POV since I guess I use it the best way I know how - how C++ do it is beyond my scope but yeah you got it in one. it's very handy for setting up "pseudo-methods" like this. PHP 5 natively allows use of the __call method. PHP4 does support it to an extent with just the attition of the overload function. One that Steve mentioned, Symfony, also uses the __call method in this fashion to handle table columns - and now I use it myself, I honestly think it's very useful to have. For further reference, you could do worse than checking out CakePHP's impementation of models - which does bring much of the Rails-type functionality to PHP. My own framework is heavily based on Cake, but differs in some ways - but here's a basic outline of my login method in my Users class that I now use for EVERY site I do. function login() { if ($this->input->post) { if ($user = $this->User->findByUsername($this->input->post['username'])) { if ($user['User']['password'] == md5($this->input->post['password'])) { // login succesful } } } } compared to the huge amounts of validation, etc I used to use, it really cuts things down. Also, my registration - all I do is specify what fields need validating and what they should contain (which doesnt differ much from project to project so I can generally get away with minor tweaks). As a result, my entire registration script (method) is a bit like: <?php function register() { if ($this->input->post) { $this->User->create(); // start with a blank // try and save the user. the model will do my validation for me. if I do need // additional validation, I'll do it before doing the following. if (!$newuser = $this->User->save($this->input->post)) { $this->view->set('errors', $this->User->errors); } else { // success! redirect to "thanks" page and prompt user to login or something. // i COULD also automatically log the user in or prompt for activation $this->redirect('/users/welcome/'); } } } so you see that my entire registration script page is tiny (obviously there's a template involved, but that's just HTML and another story) - all the validation is done for me, all the cleaning up of "attacking" code is done also, and I can pretty much knock up the PHP code for a login page in 2 minutes.

i'm not sure what you mean... you'll find most of the info here: http://uk3.php.net/overload the way i use __call in this way is pretty much like: <?php class test { function __call($funcname, $params = null) { if (substr($funcname, 0, 9) == 'findAllBy')) { echo 'you wish to find all user records by ' . substr($funcname, 9); echo '<br />the parameters you want to send also are:<pre>'; print_r($params); echo '</pre>'; } } } $mytest = new Test(); $mytest->findAllByUsername('redbullmarky'); $mytest->findAllByOccupation('Freelancer'); ?> does that help or did i miss the point of your question totally?

they DO cut down the work. Consider a real life example. Imagine you have a forum. Now imagine how many SQL queries you'll be making throughout the entire lot - for dealing with logging in, retrieving usernames, etc, etc - the list goes on. Now - consider an example from something like Cake or Rails (both of which work in a similar way) UserModel.php <?php class UserModel extends Model { // no code here needed! // all methods are inherited, but this model will // automatically attach itself to a table called // 'users' due to the classes name. } $user = new UserModel(); // load all users $all_users = $user->findAll("active = 'y'"); // load just record based on username // uses method overloading - specifically the __call method. $just_me = $user->findByUsername('redbullmarky'); // create/update a user based on $_POST array // validation is done by the Model class itself and returns errors // how many lines of code would this NORMALLY take? $user->create(); if (!$user_id = $user->save($_POST)) die('error saving'); ?> think how many times you create login/validation/cleaning/saving code in each project, time after time, and how mundane it is. at the end of the day though, whilst they DO cut down the amount of code, don't just expect them to do everything for you - you still need to put the graft in, and if you're not prepared to, then maybe a CMS like Drupal, etc would be much better for the task at hand than a framework. My main reason for picking Cake and CodeIgniter was just the fact that both seemed logical to me. Not that the others aren't, but these two just seemed comfortable and straightforward. Symfony just seemed a bit too complex for me. Also I liked the fact that Cake enforced a structure on me for my application files - the sort of kick up the arse I need to make sure I don't produce a mess, but also in a way makes it easier to learn as no confusion as to where everything should go etc. Cheers

ok, well you've posted the HTML - how about posting the relevent PHP code what you have right now? that'll be the problem, rather than the HTML.

Cake is closer to Rails than CodeIgniter but CodeIgniter is initially easier to use and is packed with tonnes more stuff out of the box. Personally I like CodeIgniter too but used it as a stepping stone to learning Cake quickly - both are somewhat similar. CakePHP is released under a MIT licence so selling code won't be a problem. CodeIgniter have their own here: http://codeigniter.com/user_guide/license.html

What do you mean by this? well - at least with our teachers - we soon realise the difference between "being able to teach" and "being able to do". They do talk about them lots - it's just that PHP is more popular than any of its frameworks, but Rails is more popular than its language. I've been doing PHP for a good couple or 3 years now I guess, and yet only came across Cake/CodeIgniter/Zend Framework/Symfony, etc when I started digging around for stuff about MVC and OOP. Most topics about PHP vs RoR also tend to try and point why comparing a framework to a language isn't fair. read my other comment - PHP, ASP, Ruby, you name it - they're all far superior and more powerful than their resultant HTML, so it really doesnt matter. If you're using to PHP, stick with it. If you like Ruby because of Rails, then stick to PHP and get a framework like one that I've mentioned above. Cheers

1, what does the Creative Commons badge refer to? the Cheesecake or the template? I'm just kinda confused by its inclusion 2, Comic Sans. It doesnt actually look too bad, due to the fact that the template is fairly quirky in itself, but if you can find a better font - do it. there's even an entire website dedicated to it: http://www.bancomicsans.com 3, The top banner text ("Just Say Cheesecake") is very pixellated (FF2 on a PC). Consider a graphical representation instead, and left-aligned. 4, lose the underlines of the navigation tabs. if you can, also try and "blend" the tabs with the page itself - ie, like making that active tab "white" and blend it in with the white content area. 5, Some "panels" need some padding. Like the grey box on the homepage and the Reviews on the About page. overall, it's not too bad. It's quite quirky and "fun" I guess - just needs some refinement in terms of styling.

umm - trying to use CodeIgniters classes without fully understanding them/OOP, etc? Dude - save yourself the trouble. CodeIgniter is strong enough on its own: a) it'll let you build client sites b) it'll teach you a good deal about OOP and MVC c) it's structured well enough that, when you're ready, you can build your own framework so that porting your existing sites to your f/w from CodeIgniter shouldnt be too difficult. I did this with CakePHP and now have a framework where there'd be minimal fuss porting my sites to Cake and vice versa. Run before you can walk and just get on with using a tool that's good enough to do the trick. At the moment it seems like you're trying to write a framework at 2000 miles per hour without understanding ANY of the principles or reasons behind doing so - resulting in rewrite after restructure after rewrite after restructure after .... blah - like I keep telling you - slow the hell down!

there's a contradiction in terms if I ever heard one anyway. you seem to have missed the point. and if it's your IT teacher, then so is he and should be fired. Ruby = language. PHP = language. Ruby on Rails = framework built USING the language. therefore, Rails and PHP ARE NOT COMPARABLE to eachother. Ruby is also NOT an easy language to learn, contrary to what people say. Sure - there's a "how to build a blog in 3 seconds" video tutorial, which to be honest makes Rails seem easier than scoring in a brothel, but that's Rails - not Ruby alone. CakePHP/Zend/CodeIgniter are frameworks modelled around the same MVC pattern as Rails. CakePHP is (was?) significantly based on Rails and therefore allows you to write the same 'Hello World' and 'Blog apps' in 10 lines of code or whatever. The whole point of frameworks is to cut down the amount of code written for each and every project - helping to minimize effort on common tasks. Stuff like parsing input, validation, database access, etc - most of it's done by the frameworks. Don't get me wrong at all - Ruby looks like a nice solid language and Rails is a nice framework that to be honest is probably the only reason Ruby is what it is today - but yeah, it's a buzzword to go next to "Web 2.0" in the buzzword dictionary. I keep saying this also, but what you need to remember is that both PHP and Ruby (irrespective of frameworks) are far more superior/powerful than their output (HTML) - so the choice between the two often generally boils down to what you already know. Cheers Mark

designed to do that? it DOES look like the page has been ungracefully killed, so you can argue that in designing it to stop it looking bad on one hand, it looks bad on the other. surely though - if you have the script in place to recognise "bad" input and handle it by just killing the script, surely you could just not kill the script and handle it more gracefully? even if just a message saying "Sorry, there was a problem" and/or a redirect back to the forum main page?

it depends on the nature of the industry using the application. i've actually started doing a lot of work on an app of my own for PDA use (ie, a handset with a proper browser not just WAP) as the recruitment industry can mean time on the road away from computer. The app itself doesnt actually differ in any way, apart from a few $_SERVER checks to determine the type of handset/screen res, etc (differs slightly with each device as to what info is available other than just USER_AGENT). The biggest difference is your CSS/templates. If you site is predominantly table-based, then you'll have a more difficult job (because some browsers are landscape, some portrait so sometimes you need to really cap the width), but if it relys much on CSS for the layout, you shouldnt actually find it too bad. It's just a case for me of including a different layout stylesheet based on the device. A site that has pretty good use of this is http://www.bbc.co.uk - it provides most of the content with alot of the unnecessary bells and whistles taken out, in a stripped down portrait format. Worth a look for some ideas, as the site has LOTS of content when viewing on a "normal" browser. Hope that helps a bit...