On Thu, Mar 19, 2009 at 12:36 PM, Bob McConnell <r...@cbord.com> 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




Cat, the other other white meat

Reply via email to