I think there is a lot to be gained from using a framework. I have an
extremely large web app in asp ( over 1500 pages ) and maintenance is
a frigging nightmare as it's so imtertwined.
Using the code ignitor framework reduces that dramatically and I now
have 5 rules based classes that control the majority of the app with
the rest of the code being mainly basic crud and validation.
The code is much cleaner, way simpler to maintain and the mvc pattern
makes changes and additions a breeze.
Sorry for top posting, ipod seems to prefer that for it's mail setup
My 2 cents, though it's worth looking at other frameworks like qcodo,
cake, or send to pick the flavor that fits you best
Bastien
Sent from my iPod
On Dec 27, 2008, at 7:57 PM, Murray <planetthoughtful@xxxxxxxxx> wrote:
I'm interested in this topic as well. I'm starting out on a
reasonably large
web application, and I'm wondering at the best approach in PHP,
particularly
since it's been some years since I worked with PHP on a daily basis
(the
last 5 years have been purely C#).
There's some dev community bias against using frameworks, isn't
there? On
one hand I'd love to take an approach that would make my end goal
easier
(thanks for pointing out Code Igniter, I'll look into it further),
but on
the other hand I'd rather avoid choices that 'tainted' (perhaps not
the
right word, but the best I could think of) the overall acceptance of
the
application once it's ready for release.
So, currently I'm wondering about things like, 'Do I make an app
that is a
distinct page-per-function, or do I make an app that uses a monolithic
index.php (similar to Wordpress?) and dynamically presents
*everything*based on querystring values.'
M is for Murray
On Sun, Dec 28, 2008 at 10:05 AM, Nathan Nobbe
<quickshiftin@xxxxxxxxx>wrote:
Hey,
How do you structure your web applications? I am thinking in terms
of
separating presentation and logic. How is that done in PHP?
mvc is pretty popular, but php is so flexible you often don't need
it for
smaller applications.
For example, if you take a page-controller approach, a php app is
dead
simple. You have a seperate entery point for evrything; login.php,
register.php, etc could be considered controllers, then all your
common
logic comes in via some includes, hopefully files outside the
webroot. then
you have some template directory w/ files that are a mixture of php
and
html(for example). your 'controller' files include the library
code, hit
the db (if necc.) and then stuff data into the templates for output.
if you want to see an exmple if a more traditional mvc there are
scads of
open source frameworks out there which use a front controller
approach. Code
igniter is really straight forward, you can probly learn quickly
from it.
And how many architecture patterns are there?
please do try to avoid pandoras box on the list ;) It can result
in 100+
post threads, heh. that being said patterns are pretty general
things,
that's why they're called patterns. most of the time various
languages will
result in slightly different concrete realizations of a pattern,
but you'll
find most of them rather simple to realize in php. One that really
isn't
well suited to phps build-up / tear-down paradigm is the state
pattern.
much easier in java or cpp, imo.
-nathan
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
