On Thu, Mar 19, 2009 at 12:36 PM, Bob McConnell <rvm@xxxxxxxxx> wrote: > From: Shawn McKenzie > > Bob McConnell 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 > >>> 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? > > > > You don't need OOP to use templates. Smarty is OOP. but there are > some > > lighter faster template solutions, as well as just creating your own > > templates that you either parse and replace vars in or just use PHP > > code. As long as you keep the PHP in your templates display oriented > > and not business/app logic based then it should be a nice solution. > > > > You might also look at a framework (codeignitor, cakephp) and go > through > > their tutorial, though these are undoubtedly MVC/OOP, it may make more > > sense once you start building something with it. > > Well, I installed CodeIgniter on one of my home servers last night, but > have not yet started through the manual. That will be an interesting > experiment. I am hoping to create a simple recipe management system > there, similar to ReciPants, but in PHP. > > At work the problem is more basic; 162 files of interleaved database > access, business logic and presentation, all written by a civil > engineering student with no software training at all. He has moved on, > but five of us working on three products are now dealing with the mess > he left behind. > > Thank you, > > Bob McConnell > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Just 162 files? I don't mean to sound condescending but if the code is that much trouble, chuck it out and start over. Build it properly by separating out the db interaction stuff ( and there are great patterns to use there as well like Active Record or work with an ORM layer like propel or doctrine ). Then separate out the presentation layer, and define a transport to that layer from the business logic layer. I like XML for this, passing it to XSLT for client side transformations into html. Then the DB passes to the business layer, which does its stuff and then passes the results to the presentation layer. And the same in reverse, the presentation layer never talks to the db layer directly. Creating that separation should make the whole maintenance issue better. Parts that need to be shared can be copied across to the other applications so that each app lives in isolation. If that is not possible, the consider breaking the shared bits into smaller pieces to limit the exposure to potential issues when you have to make changes. PCI is a pain in the ass and the rules that govern that make things very difficult, though I can see why it all needs to be there. The application I support (classic ASP) comprises 149 Mb of code in some 1500 + files scattered across some 50+ folders each with their own db access code. Nightmare isn't the word for it. It uses some 160+ DB tables as well. Rebuilding it is a task that I am looking forward to and am definitely using the MVC pattern with OOP to some extent. I am looking at codeigniter as the framework for this as its is one of the fastest and simplest of the frameworks to work on HTH -- Bastien Cat, the other other white meat
