On Thu, 2009-03-19 at 12:14 -0400, Bob McConnell wrote: > From: Bastien Koert > > On Thu, Mar 19, 2009 at 11:06 AM, Bob McConnell <rvm@xxxxxxxxx> wrote: > > > > From: Virgilio Quilario > > >> That looks nice, but how do I get to the point where I can > understand > > >> how to use it? > > >> > > >> I have also looked at the Smarty site > <http://www.smarty.net/>, but > > >> their documents assume significant experience in building and > using > > >> templates. > > >> > > >> Where can I find guidance or tutorials on how to do all of > this, > > >> starting with only a rudimentary knowledge of HTML and PHP. > It would > > be > > >> best if they also focused on procedural rather than object > oriented > > >> code. > > > > > > > > > When I started learning smarty, I spent most of my time doing > research > > > and that's really tiresome and it is so hard to find examples. > > > Experimented a lot and listed those what's possible, then > applied them > > > to my projects. > > > > > > Now to make them handy I posted them to my site so i can have > a look > > > whenever and wherever. > > > > > > http://www.jampmark.com/php-programming/16-very-useful-smarty-scripting- > > tips-and-techniques-to-make-templates-smarter.html > <http://www.jampmark.com/php-programming/16-very-useful-smarty-scripting > -tips-and-techniques-to-make-templates-smarter.html> > > > > > > As a first step, maybe you should see the crash course at > smarty > > > http://www.smarty.net/crashcourse.php > > > > Hi Virgil, > > > > After your last post here, I looked at your site, then the > Smarty site. > > That was what triggered this question. Templates are a black art > to me. > > I don't even know where to begin to understand them. Every > reference I > > have looked at so far assumes that I already understand the MVC > pattern, > > which is also one of the dark arts. > > > > Let me put it simply. I can't grok OO. I tried to do OOP for > several > > years, but it simply does not make any sense to me. As a direct > result, > > I don't understand the concept nor application of patterns. So > how do I > > figure out how to use templates without having to absorb those > first? > > Can I learn enough this way to determine if a site can be > converted from > > the current state (PHP and XHTML spaghetti) into templates and > begin > > that transformation? > > > > Bob, > > > > You really would need to learn those concepts first OOP / MVC. There > is > > a learning curve, but you really don't need OOP to be able to do an > MVC > > style application, but it does make the code neater. > > > > One of the books that really helped me grok OOP is Head First > OOP...another > > is Martin Fowlers Patterns of Enterprise Architecture. > > > > The MVC pattern is explained well in a number of places, but worth > > checking out are both the cakephp framework site and the codeingniter > site. > > > > You'll find that there are people from both camps here, pure OOP and > other > > just as happy with procedural coding styles. Many use both, using > objects > > to handle common tasks like DB interaction or filesystem processes. > > Yes, I have to deal with both camps here as well. Of five developers > doing PHP at the moment, two are primarily using OOP. But I spent 3.5 > years as part of a team developing MS-Windows services in C++. After all > that time, I was only able to write basic functions for others to > convert into methods or classes. I could eventually find my way around > in some of those classes, but it seemed that every time I figured out > what was where, somebody "refactored" a major component and I had to > start all over again. All I saw was a lot of unnecessary overhead and > obfuscation which made little sense in the long run and slowed down both > the development and the application. The result was a handful of DLLs > that are shared between several products, and each time anything is > changed in one of them, every product needs to be retested to make sure > nothing got broke and some have to be recertified for PCI-DSS as well. > > So you are telling me that I can forget about trying to use templates. > Since I can not understand OOP, there is no chance I will be able to use > them. > > Just knowing that will probably save me several weeks of frustration. OOP for those having trouble: <?php // Procedural: function person_get_from_db( $personId ) { // Load person data based on $personId } function person_get_name( $personData ) { return $personData['name']; } function person_set_name( &$personData, $name ) { $personData['name'] = $name; } $person = person_get_from_db( 1234 ); person_set_name( $person, 'Bob' ); echo person_get_name( $person ); ?> <?php // OOP class DbPerson { private $name; private $otherPersonData; // ... function DbPerson( $id ) { // Load person data based on $id } function getName() { return $this->name; } function setName( $name ) { $this->name = $name; } } $person = new DbPerson( 1234 ); $person->setName( 'Bob' ); echo $person->getName(); ?> So from the above you can see that the two translate quite cleanly between one another. We merely change passing the structure to function to a case of calling the functions on the structure itself. Now, where does OOP make more sense? <?php // Procedural. function fireman_get_from_db( $firemanId ) { $data = person_load_from_db( $firemanId ); $data['fireman'] = load_stuff_for_fireman_from_db(); } function fireman_set_name( $firemanData, $name ) { person_set_name( $firemanData, $name ); } function fireman_get_name( $firemanData ) { return person_get_name( $firemanData ); } function fireman_set_station_id( $firemanData, $stationId ) { $firemanData['stationId'] = $stationId; } function fireman_get_station_id( $firemanData ) { return $firemanData['stationId']; } $fireman = fireman_get_from_db( 1234 ); fireman_set_station_id( $fireman, 57 ); echo fireman_get_station_id( $fireman ); ?> <?php // OOP class DbFireman extends DbPerson { private $fireman; function DbPerson( $id ) { parent::__constructor( $id ); $this->fireman = load_stuff_for_fireman_from_db(); } function getStationId() { return $this->fireman['stationId']; } function setName( $name ) { $this->fireman['stationId'] = $stationId; } } $fireman = new DbFireman( 1234 ); $fireman->setStationId( 'Bob' ); echo $fireman->getStationId(); ?> So as you can see they're almost identical except that the OOP version of fireman didn't need to redeclare functions. True you could have skipped doing that if you just used the person functions, but then you may introduce onconsistencies. Additionally, the class version ensures that the methods applied are those bleong to the concept of "fireman" whereas passing data structures around can easily get confusing, especially if you choose to allow the person functions to be applied to the fireman. Going futher, using OOP let's you do all sorts of generic application functionality. Instead of passing a data structure around for which I need to know what specific functions can be applied, instead i can pass around an object and the correct method will be chosen for that data type when I call the method. For instance, many data structure have an "id" field, in yours you'd need to apply the right kind of id function to retrieve it (or know the exact array key to grab it directly). In OOP, you just call the id() method and don't care about what data type you have since the data type and method association is managed internally. At any rate, you can do anything in procedural code that can be done in OOP code, you just end up doing the management of the data yourself... data management that OOP developers get to take for granted. The example I provided is trivial and does properly represent real world usage... of which there are many. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
