Jump to content

redbullmarky

Staff Alumni
  • Posts

    2,863
  • Joined

  • Last visited

    Never

Everything posted by redbullmarky

  1. if you have your data (the Model) and your templates (the View), where the model is only concerned with fetching and handling your data and the view is only concerned with presenting it, you still need something in the middle that takes the URL request and decideds WHAT to fetch and pass it to your view - this is your Controller (in all, you'll have MVC). controllers can handle mapping what comes from your database to variables that your view can handle. That's your first point out of the way. As for "time consuming", people tend to get to fussy about milliseconds. Sure, keeping an eye on performance is all good and well, and definitely something that should be dealt with. But the fact is, using MVC, or ANY form of templating, is going to cause a bit of a performance hit compared to the old-fashioned "spaghetti code" approach of lumping everything together. However - my sites are very dynamic and I updated them alot - not just the content, but the features, etc. I like to think I can just dive in and drop in a component or whatever without breaking things, really easily. Having this seperation lets me do that - so in some respects, it's a balancing act between speed of site vs. speed of development. Now - as the speed of the site varies by unnoticable amounts, yet the speed of development and upgrades amounts to days/weeks, I'd rather have this seperation. Plus - in your examples (that you quoted just above), you use stuff like {intro} and {content} etc. On top of my suggestion and Brian's implementation, you'd need a parser within your template engine to turn those custom tags into PHP that can be processed, wheras with the method in the article, it uses PHP so no need for additional processing. You could do far worse that at least play with the article's example and/or an MVC framework (CakePHP, CodeIgniter, Zend, etc or even one in another language such as Rails (Ruby) or Django (Python)) to truly get an idea of what the benefits are. It took me a while of playing around with template engines and then, eventually, that article, to really get things to click into place.
  2. a) welcome to the forums b) please check board descriptions before posting - OOP Help is for OOP stuff only (topic moved) c) Have you tried Google? There are thousands of results, some of which (in the first page or two) give full examples of it being used. It's the EOL (end of line) character that is used on whatever server the script is running.
  3. lots. Unless you have a specific reason for using it, avoid AJAX. What I've found is that it's great for server-side lookups (such as auto suggest) or stuff like saving forms, but for serving entire pages it's a waste of time and pointless. Not to mention that accessibility goes out the window, and Google doesn't utilise Javascript when crawling your site so may not be able to index your site correctly. My list goes on, but like I say - avoid unless you really need it. When you really need it, you'll just know...
  4. sure - but he doesn't try to present an entire solution that has all the nuts and bolts of Smarty, et al - he just presents a solution. Ok, you're going to wind up with two loops - one to get the records to an array, one to display it in a list or whatever - but I'd rather that than throwing business logic inside my templates. Besides - there are further ways still, should you prefer to have only one loop - nobody said you HAD to get your data into an array before passing it in to the template: class Database { function query($sql) { ... ... returns a 'Result' object that has methods such as nextRow, etc ... } function nextRow() { } } <?php $db = new Database(); // rowset could be a class that wraps a mysql result resource $rowset = $db->query("SELECT * FROM articles"); $tpl = new Template(); $tpl->set('articles', $rowset); echo $tpl->render('index.tpl'); ?> <div class="articles"> <? while($article = $articles->nextRow()): ?> <div class="article"> <h2><?=$article['title'] ?></h2> <p><?=$article['teaser'] ?></p> </div> <? endwhile ?> </div> and to go a step further, the Result object could easily implement ArrayIterator, allowing you to treat it like an array yet only pulling records out as required - ie, one loop. His code is not the "full package" - rather a loose example to demonstrate what it can achieve. Sure, it's simplified but it IS a tutorial, not a project brief.
  5. lol trust me on this one - of all the recommendations I'd make, Smarty wouldn't be one of them (pretty much for the same reasons you outline). Take a look at my first post above, under point number 2. There's a link in there which provides details of something that has the same concept as Smarty but just using PHP syntax to achieve it - and as a result, being much much faster. Template engines are more concerned with seperating out the view from your application, where as MVC and its frameworks take things a step further by breaking up your application into two further parts - generally speaking, your data vs the business logic. Try installing CakePHP or Zend Framework, which don't concern themselves with a whole new syntax and should hopefully make things a little clearer - else, play around with the code in the link I sent you - eventually it will click.
  6. Not saying Paypal is great, but I normally hear that one when people actually don't want to donate but don't have any other excuses. As a bog-standard simple interface for taking donations in this fashion, there's nothing wrong with it at all - it works, it's secure and is established.
  7. ok cool, then here goes - they're bad and somewhat unmaintainable, based on both opinions of my own above, and also those of the article coupled with many examples of good vs poor written software. Not one of the examples would I rate over the other, as they're all fundamentally the same, just ever so slightly shuffled around. That's also fair enough. However, I've given you a nicer alternative and explained why your initial solutions are not my cup of tea. I'd be interested in why you don't particularly like the suggestion? (maybe you can teach me a thing or two, or point out something i'm missing). I'm not saying it's the holy grail of templating, or the real deal of ideas, but it's by far the most obvious and cleanest way - especially as I've built many many sites with it, some small, some huge and yet all are benefitting heavily. The initial examples you presented are a good example of how I used to put pages together and none of my old sites are maintained any more simply because they grew into a huge messy mixture of all sorts. If you open up some of the nicer frameworks and PHP packages, you'll find very similar implementations of templating "the nice way" - and if it's good enough for the big boys, then it's sure definitely good enough for me. Your examples I suppose look simple enough when you lay it out as 5 or 10 lines, but a big site will contain far far many times more code than that and hence far far many more times of complexity and mess. Not bashing you here - just answering your original question based on the fact that I've been in this position before many years ago and have learnt the long and hard way...
  8. you asked which one i would pick else propose an alternative. I told you that all methods suck for what you're trying to do and provided you with an alternative that is cleaner and achieves the same goal. from a coding point of view, all of the original ideas suck. from a designers point of view, all of them definitely suck. am i completely misunderstanding what your original question was, or are you not getting what i'm saying?
  9. i'm not sure you're completely understanding what i'm getting at. whilst i agree there are many ways to do it, and sure - some are still quite clean, the more code you can remove from your HTML, the better. that includes wrapping all your HTML inside one echo, which essentially results in you having one single big block of PHP code. my preference - fire up the template class, use setters to set the variables your template needs, and call the render method which includes the "almost" pure HTML file and replaces all your variable placeholders with values. Most of the sites I build these days have only one single echo in the entire thing - just to output whatever the 'render' method returns. If I need to do something funky to the entire layout like apply some sort of filter or add some debugging information, I only have to apply it in one place, rather than looking in loads of places. you might benefit from looking at a decent MVC framework and seeing how they approach seperation. Once you get used to it, maintaining and upgrading your site becomes a breeze.
  10. personally i reckon you should install a common PHP framework or application (CodeIgniter, CakePHP, Wordpress, SMF, etc) and see how they do it. Most of your questions would be easier understood by actually looking at the answers in practice and working things out from there. As for templating engines - my favourite tutorial should shed some light on things. They don't all have to be full of custom tags, parsers, compilers etc - the whole point is just to seperate out HOW your site looks from how it works: http://massassi.com/php/articles/template_engines/
  11. yes but there's a big difference between slipping into PHP to output a variable compared to staying in PHP and wrapping your entire HTML within one big echo statement. example: <?php // bad in my opinion echo '<div class="mydiv">hello '.$person.'</div>'; ?> vs. <!--much better--> <div class="mydiv">hello<?=$person ?></div> there isn't any real way of writing a template without some code in there (be it PHP code, or custom tags in a custom template engine) but the difference is using code where absolutely necessary and only for the way things look - not how it works or where data comes from. the whole point of using template "engines" is seperation of your view (including view logic) and the rest of your application. ok, so maybe it means you have at least 3 files to generate one page (the controller (or your main code, if you like), the "HTML" template and the template engine) but at least your HTML files look exactly like they should - HTML. Some of the benefits are more apparent when working on a project with other people. 1, If all of your code is held in one page, then only one person can really work on it at the same time. Having your template seperate to your main code means that you can work seperately on one without breaking the other. You can change te way your site LOOKS without much danger of breaking the WAY it works and vice versa. 2, Having HTML code that is encapsulated within one single PHP echo is both confusing and also problematic when it comes to single/double quotes, etc - things can get messy easily, especially if the person working with your templates isn't really familiar with PHP. Hope that clears things up a bit more Cheers
  12. all methods above, IMO, are horrible and take leaf out of the same book by mixing code and HTML together. Using 'echo' to output HTML just looks nasty and causes all sorts of issues. Read the following article for a different spin on templating as it will let you keep things far cleaner and more seperate: http://massassi.com/php/articles/template_engines/
  13. not sure. i've always known about the php tags but never used them as it sort of left coloured code out on a limb right in the middle of the post, with no wrapping or anything. haven't tried it til now.
  14. echo 'hello world'; oh yeah. nice!
  15. please read the stickies at the top of the boards before posting. this question gets asked far too often hence the sticky... http://www.phpfreaks.com/forums/index.php/topic,58799.0.html
  16. there's a few that you'll find by going straight to the developer website. I was gonna wait before upgrading because Firebug wasn't working on FF3 but it is now Just the HTML Validator one I miss now...
  17. i'm .............. let to believe............. that using hyphens instead of underscores........ is better, and the less.............. of a query string you have.................. the better........... sidenote: seriously dude, can you cut down on your ........... ? it kinda makes things very awkward and unnatural to read. It has been mentioned before.
  18. i started from Dreamweaver, using its built-in PHP/MySQL snippets for doing certain things to build simple login/registration areas, lists of results, etc. When I got more and more demanding and stuck, I spent much more time in code view, looking at the code it had generated and trying to wrap my head around what was going on. As with thorpe, I'd already programmed in other languages such as C/C++, Pascal, BASIC, etc to a half-decent level so the ability to read code was easy enough. Otherwise, it was just reading manual entries from functions, etc that were generated and doing LOTS of reading. Google is absolutely and definitely your very best friend when it comes to learning stuff like this. The better you are with Google, the quicker you will be finding out what you need.
  19. nope - but the learning curve is much much higher and, IMO, the interface in general is definitely not for everyone, especially straight out of the box. thing is with WP is that whilst you might not find a plugin you need, it's not too tricky to learn - I guess it depends on your PHP level, to be honest. WP would definitely be the easiest of the lot to get it playing ball, but by all means have a look around Joomla/Drupal's add-on repository to see if you can find what you need.
  20. *cracks nuckles* Darklink - I sort of see where you're coming from, but those that haven't got the patience to read the code and understand it probably shouldn't be doing it in the first place. Remember - whilst PHP is easy in comparison to some other web languages, it's still a serious business and a 'profession'. I get tired of people that are trying to make money from this industry, ripping off clients by providing them with poor quality, bug-ridden junk, when they really don't understand things and haven't taken the time to, either. We see tonnes of "I'm doing a project for a client, and I got this code from somewhere but it doesn't work and I don't know why." and it really gets on my tits. If you don't know what you're doing and don't understand it FULLY, you shouldn't be doing it - ESPECIALLY for clients who are paying money, no matter how little. All it does is give those trying to make a living out of doing QUALITY work a bad name. A bad name for charging more than someone trying to make a quick buck and rip people off. A bad name as an industry. How ever you look at it - a bad name. If someone wants a web presence, then there are plenty of CMS's/Blogs, etc out there to build simple sites. If someone wants to get involved in coding and making money, then the same principles apply to PHP as they do with every other job - it's not some get rich quick scheme where you get everything without putting time and effort into it, expecting to make a living. Coding PHP can be fun as well, but it's not for the lazy who can't be arsed to put some effort in to learn their tools. In addition - if an uncommented script (aside from function/class names and the odd bit here and there) cannot be understood, then one of two things is wrong: a) the programmer does not know enough, and should keep on learning. b) the script is more than likely bad bad bad and not worth using anyway. *steps of soapbox*
  21. You might get away with using something as lightweight as Wordpress along with some of its add-ons. Else something a bit more heavyweight, like Joomla, might be a good start to get something up and running out of the box. Wordpress is very simple to use and easy-ish to customise features if you can't find add-ons that do the job you need. Joomla comes with more out of the box but is much harder (IMO) to customise when you can't find add-ons and is not as user friendly.
  22. 1, getting your URL's sorted is a case of using mod_rewrite assuming you're on Apache. This will allow you to have things like mydomain.com/login instead of mydomain.com?p=login. Essentially it involves routing all your pages through the same page, as with the $_GET method, but having URL's that look like you're doing otherwise. 2, using a lightweight templating system might help you out a bit. As always, this article details some of the nuts and bolts, as well as provides fully working code - which I actually used to base my own template class on. 3, It might also be worth looking through a few simple MVC frameworks - notably CakePHP or CodeIgniter (there are loads of others, but I find these two quite simple to understand out of the box). Follow the tutorials for them and hopefully you'll see a nice way of structuring your code other than the traditional approach, and one that makes it incredibly difficult to keep on top of future development, upgrades, etc. Most frameworks use mod_rewrite (as mentioned in my first point) and some form of template engine (as mentioned in my second) so a nice decent popular framework should have you covered on all points. Cheers
  23. please do not double post - you already have an open topic here regarding this one. Cheers
  24. i've been keeping up with it a bit more this time, even though England are not taking part. As a big Liverpool fan and a big fan of Torres (though I appreciate Fabregas too), I'm following Spain in this one but - have to say - the Dutch are looking dangerous. I watched that game and it just looked far too easy - and playing against the likes of France and Italy, that's just nuts. Still - Spain or Holland to win (what a final if they both get that far!), David Villa to be top scorer and France to finish on the receiving end of the biggest whooping of the tournament. Hoping Kuyt gets on some sort of a role - that dude is one hard worker but I reckon that a decent run and some goals for Holland will do his confidence, and Liverpool next season, some good.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.