Programmer epiphany

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Programmer epiphany

Post by alex.barylski »

back when I first started web development, coming from a desktop development background I was accustomed to using seperate files for most parts of an application, etc...

So naturally when I switched over to web development every page was a script and every action was a script.

As years progressed and I started using templating techniques, etc...I slowly made the transition into index.php (front controller type scripts) where index.php was the single applicaiton entry point...

Then I started appreciating seperate scripts to carry out actions, but keeping everything else inside a index.php (using classes/function API as a model) templates to seperate view from logic...

Using multiple switch statements, I had a IMHO clear applicaiton entry point and easy to follow code...

Each CASE would pull on model objects or push out templates based on certain page selector criteria, etc...

Then I started a personal project and my aim was to enhance my understanding of accessability thanks in part to an argument turned educational experience I had with iamsure

So I start thinking everything accessable, simple, intuitive designs, quick loading...think like Google...use CSS...slim HTML, etc...with the help of our own Oren, I was able to seriously chop my HTML files down in size...and made it pass transitional designs...something until now, I've always ignored in favour of fancy designs...

I spend most of my time thinking of application design, algorithm optimization, etc than I do about end user experiene, especially those with disabilities...

But it's nice to know I'm making some moral progress...

Anyways, on this project I've dropped any javascript which was essential to the application funcitonality (client side FORM checking) I've scrapped in favour for server side checking, validation, etc...I've always sanitized INPUT on the server, but never checked it...left that to javascript...

Today, I enounter a problem and it confuses me like mad...makes me realize my understanding of HTTP isn't quite what I thought it was...despite having read many articles on how their actually implemented...never mind used...thats life I guess :P

It forces me into re thinking my application design...as accessability is now an important issue...so instead of using a single application entry point...I will now use seperate files for most of the static entry points (about, faq, etc)

I moved away from this approach a good number of years back...because I found prototyping an applicaiton much faster using a single index.php...which it is...

But now, I'm thinking I'll use this approach all the time...single index.php to generate the prototype, hammer out some issues, then start to refactor into a more modular MVC design...I mean...it's even more efficient...

I know I've asked this quesiton in the past...but now I want more indepth answers...

Try and actually justify your answers...explain to me some caveats, positives and nagatives of both...

What design technique do you use...???

Cheers :)
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

I think that's the first time one of your paragraphs has actually wrapped on my screen. :D

Oh, nice.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

lol

You mean...I never use enough spacing? I like spacing...I can't help it...even when I read books....tight paragraphs drive me nutts...small print too...despite having better than 20/20 vision...I like easy readability :P

Anyway feyd, I'd like to hear your reasons for using one approach over the other...outside of the obvious like using seperate pages is more efficient...etc...

Spill the beans...
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

No, I mean your paragraphs are never long enough to wrap on my display, so it just looks like line, blank line, line, blank line, etc.. I would have included a screenshot but unfortunately, my machine doesn't want to cooperate right now.

I have no major preference in terms of what you've talked about. I like to keep the entry points fairly minimal simply to keep the places where I have to adjust things minimal too.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Ok so you have no opinion or choose to remain agnostic... :P

But you could still comment on both...listing positives and negatives...caveats, etc...no???

I'd like a other perspective to the positives and negatives to using both...

What are the up and downs of each...and so on :)
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

The screenshot I meant to get earlier.
http://tatzu.net/examples/ScreenCap.png

Honestly, I can't give pluses or minuses to either as I really don't study these things. Frankly, I just don't care enough.

I'll say this: designed right, both are perfectly fine and valid with little differences. Designed bad, and they'll stink like week old rotting fish.
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Post by alvinphp »

You can have your front controller (single access point via index.php) and still use MVC. This is one of many ways...

1. Client -----sends request---> FrontController (index.php?control=about)
2. FrontController ----delegates---> PageController (aboutControl.php)
3. PageController ----invokes---> Objects (your Model)
4. PageController ----loads---> TemplatePage (aboutTemplate.php)
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post by RobertGonzalez »

I have been using a FrontController that fetches content from a database, then feeds the content to the template parser (in my case, TemplateLite). Inside the template, I throw whatever static content I want (minimal, if any) into the template using conditionals based on the currently selected page. So in essence, I have an index.php that includes a pageController class that uses the querystring to determine what page I am on and serves that page.

In all, I am looking at three template pages (header, footer and content), one viewable PHP page (index.php) and several classes (DB Abstraction, PageControl, Templating) in addition to some general settings and constants.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Programmer epiphany

Post by Christopher »

Hockey wrote:It forces me into re thinking my application design...as accessability is now an important issue...so instead of using a single application entry point...I will now use seperate files for most of the static entry points (about, faq, etc)
Ok ... so you have decided to move from a Front Controller to Page Controllers or static HTML pages.
Hockey wrote:But now, I'm thinking I'll use this approach all the time...single index.php to generate the prototype, hammer out some issues, then start to refactor into a more modular MVC design...I mean...it's even more efficient...
Ok ... so you plan to use a Front Controller during design and then ... this is where I lose you ... "refactor into a more modular MVC design...I mean...it's even more efficient". I can't think of a more modular MVC implementation than using a Front Controller ... going to Page Controllers would be less modular ... not that more or less modular is better or worse. And I have never heard of MVC being efficient. And why are you not using MVC with the "single index.php"? So I guess I am a little confused.
Hockey wrote:What design technique do you use...???
I think maybe you mean implementation techniques here ... not clear what you are asking for ... do you have an example?
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Everah wrote:I have been using a FrontController that fetches content from a database, then feeds the content to the template parser (in my case, TemplateLite). Inside the template, I throw whatever static content I want (minimal, if any) into the template using conditionals based on the currently selected page. So in essence, I have an index.php that includes a pageController class that uses the querystring to determine what page I am on and serves that page.

In all, I am looking at three template pages (header, footer and content), one viewable PHP page (index.php) and several classes (DB Abstraction, PageControl, Templating) in addition to some general settings and constants.
That's how i've done it hitherto :p

at least last couple years...as I didn't do that in the begining...
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Programmer epiphany

Post by alex.barylski »

arborint wrote:
Hockey wrote:It forces me into re thinking my application design...as accessability is now an important issue...so instead of using a single application entry point...I will now use seperate files for most of the static entry points (about, faq, etc)
Ok ... so you have decided to move from a Front Controller to Page Controllers or static HTML pages.
Hockey wrote:But now, I'm thinking I'll use this approach all the time...single index.php to generate the prototype, hammer out some issues, then start to refactor into a more modular MVC design...I mean...it's even more efficient...
Ok ... so you plan to use a Front Controller during design and then ... this is where I lose you ... "refactor into a more modular MVC design...I mean...it's even more efficient". I can't think of a more modular MVC implementation than using a Front Controller ... going to Page Controllers would be less modular ... not that more or less modular is better or worse. And I have never heard of MVC being efficient. And why are you not using MVC with the "single index.php"? So I guess I am a little confused.
Hockey wrote:What design technique do you use...???
I think maybe you mean implementation techniques here ... not clear what you are asking for ... do you have an example?
I have alwasy modeled most software I have written after MVC or at least that what I learned through osmosis in using existing frameworks in other languages...I used static HTML pages for maybe the first 4 weeks of learning HTML before I got into Perl :P

I am unsure of the differences between a front controller and a page controller...as they both (from what I understand) intercept commands by parsing a URI and execute appropriate model/views...?

A front controller might dispatch commands to component specific controllers...where as a page controller could maybe be implemented using a single switch statement anin which case the CASE handler would emulate the component specific controller???

When I said modular, I didn't mean so much in design as I did runtime execution performance...

by using seperate scripts for everything, the script itself begins to act like the controller so an explicit controller is not needed...as event handling is done intrinsically by HTML FORM action attributes...am I correct in making the analogy there???

When using a single index.php application entry point, using MVC, the design is still modular, but runtime execution is a monolithic beast. Parsing alot of possibly unessecary code, etc...

Even if designed well and you didn't include alot of excess non-required code...by using individual scripts you remove the need for a front controller at least don't you? Dispatching is done by action attributes...

In that sense I meant it's more modular and thus efficient...less parsing, less execution, etc...

index.php - Single application entry point - needs some mechanism to dispatch commands to appropriate handlers, etc...likely using GET variables...as most do...

Some benefits:
1) Single application entry point...
2) Emulate postback functionality is made easier

But it has the down fall of requring extra wiring (i'm a poet :P )

Code: Select all

include('somefile1.php');
include('somefile2.php');
include('somefile3.php');

$obj1 = new MyObject();
$obj2 = new MyObject();

$pageid = (int)$_GET['pageid'];
switch($pageid){ // Page controller???
  case 1: // Module/component controller???
    include('lang.thismodule.php');
    $obj1->assign('body', $GLOBAL['LANG001']);
    break;
  case 2: // Module/component controller???
    include('lang.thismodule.php');
    $obj1->assign('body', $GLOBAL['LANG001']);
    break;
}
index2.php - Multiple application entry point, HTML by nature of it's FORM action attribute handles the routing of actions to command handlers, aka the script itself.

No runtime mechanism is required now to map the command to event handler as the script is invoked whenever someone clicks submit via the browser. No runtime performance hit!!!

Code can be made equally modular and both can follow MVC, but this doesn't require front controller???

Code: Select all

include('somefile1.php');
include('somefile2.php');
include('somefile3.php');

$obj1 = new MyObject();
$obj2 = new MyObject();

// Observe the lack of switch statements or other wiring mechanism???
// Less parsing, less execution...but multiple entry point is required...
include('lang.thismodule.php');
$obj1->assign('body', $GLOBAL['LANG001']);
In this regard, at a higher level or end user level...it's more modular...not in design...but as far as runtime performance is concerned...it's better and partly why I'm considering it for this particular project as they are both modular and can be well designed, but doesn't require as much controller mechanism's???

What I was looking for was opinions, not so much in what is better or worse, because both depend on many factors...but I wanted people to point out highlights of each and negatives of each as well...

The latter is search engine friendly and doesn't incur a performance penalty for extra wiring...the first is slightly more managable, or at least it has been in the past...but I think that can be corrected...

The first is also awesome for cracking out prototypes...in that you can quickly begin to "hack" out a solution and later convert to a more end user modular design...

I was simply curious why one was used over the other...in your own projects...what di you like, dislike...what were some problems you enctounered, etc...

Cheers :)
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Post by alvinphp »

---
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

I don't see how index.php and index2.php are different.
(#10850)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

I use front controllers and page controllers, with minimal entry points.

However, I do use multiple front controllers. I define different areas of an application needing different front controllers.

Example: forums - I have a front controller for the actual forum, and a seperate front controller for the admin area. In effect, they are two seperate applications - the only link between the two is the database. So I have, for example, directory structure of "/www/docroot/forums/" and "/www/docroot/admin"

I have a convenience index.php which redirects to forums/index.php in the docroot.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

arborint wrote:I don't see how index.php and index2.php are different.
They are different only in event handling, otherwise I want them to be identical...

There is *no* switch statement or additional wiring in index2.php as the dispatching of events is handled by HTML vie FORM action attributes...

index2.php is just a placeholder, it could be any number of files, aboutus.php, faq.php, contactus.php, addlisting.php, etc...

Whereas index.php would use a page controller, etc via a switch statement...

so instead of static URL's is would use GET like:

Code: Select all

index.php?page=aboutus
Because static URI (index2.php) doesn't require additional "wiring" to delegate event handling to a controller, etc...it's more efficient in that matter...
Post Reply