Re: Object Oriented Content System - the idea
nospam_at_geniegate.com
Date: 03/15/05
- Next message: nospam_at_geniegate.com: "Re: Php not free anymore"
- Previous message: Annoying: "MAthML"
- In reply to: Henk Verhoeven: "Re: Object Oriented Content System - the idea"
- Next in thread: Henk Verhoeven: "Re: Object Oriented Content System - the idea"
- Reply: Henk Verhoeven: "Re: Object Oriented Content System - the idea"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 15 Mar 2005 09:33:36 GMT
In: <d155b4$beb$1@news6.zwoll1.ov.home.nl>, Henk Verhoeven <news1@phppeanutsREMOVE-THIS.org> wrote:
>
>Hi Jamie,
>
>nospam@geniegate.com wrote:
> >The downside of this is that when I want to add new pages,
> > I need to modify my script.php to use another class
> > and/or modify an existing class. It might have
> > been better if run() returned an Action type of object
> > that supports a display() or getView() method,
> > so that one could easily add new do_ (or "actions")
> > dynamically, (Thus keeping the Controller and Model separate)
>
>Apart for the use of the word 'action', this could have been a partial
>description of the phpPeanuts request dispatch.
It's a description of a LOT of software, real common technique used long before
the web, long before OOP. It was probably in use before the advent of
compilers. Perhaps without a "view" though.
Objects make the whole thing a lot easier, but it's essentially the same
old thing done over again.
I'll bet there are dozens of PHP projects that use the same pattern in one form
or another. The "view" part is the easiest thing to mess up, since it's so
tempting to display output straight from the action, I *believe* Jakarta Struts
is designed so you simply _can't_ do that without jumping through major
hurdles. Would probably be difficult to enforce this militant style in PHP. (I'm
kind of glad for this, since 'print_r()' is my best friend. :-) )
The thing that really turned me away from Struts was what I percieved as
complex bloated stuff (like "view config files") Now I find myself essentially
doing a "view.xml" to overcome flexibility problems.. guess there was a good
reason they did it like that. :-/ Kind of sucked having a whole separate
"view", with 1 string difference, a view.xml (or view.cfg) can overcome this
with parameters. Haven't dabbled in WAP yet, but I imagine it could be instrumental
there too.
As HUGE as it is, Jakarta Struts is a good place to look for ideas about this
stuff. (It's java, but you probably don't have to know java to see what's going
on) Theirs is kind of a "1 size fits all" so it has to be more complex.
They even have stuff to populate javabeans directly from a request, real handy
stuff. Problem (as I percieve it..) is it's just too much. Best to have
a smaller scale, custom MVC if it'll work out and you don't need the whole
package. (my opinion anyway.. I'd probably use Struts if I went back to java
though)
> > but that had some downsides if you want to share
> > private utility methods across "action" boundaries
>
>Can you explain what you mean by private utility methods? What kind of
>things do they do? Did you consider to refactor them to a delegate?
I just found it convenient to share common utility stuff, such as maybe loading
an object from $_POST or checking session data, etc.. whatever "actions" are
using it. Things that aren't really part of "business logic" (buzzword logic
:-) ). Jakarta does a lot of this stuff in a generic sort of way with
populating javabeans and friends. Beans in PHP aren't usually (in my opinion) a
good idea, since each file needs to be parsed each time and anyhow maps are a
native datatype.
To do the same with separate Actions, you'd have to create a separate "util"
class that is shared between objects. (One more thing to keep track of :-( )
In a language that parses it's script on each request, the overhead opening
yet another file didn't seem worth it. (I already had a lot of files for
the business logic, I guess you'd call it delegation.)
It probably is better to have separate Action objects in the long run:
$controller = Factory::createController($CONFIG);
$action = $controller->getAction();
if($action){
$view = $action->process($request);
$view->display($response);
$action->finish($view);
}
In particular, the "finish()" method would have been a lot cleaner. (Not a huge
problem for me, I don't use it a lot, 1 finish method shared among several
action "methods", but it I can see it getting messy in generic settings.
In my case, I just have a some events that may need to be run after the page
had been shown, no biggie. (notify "listeners" that may send email, etc..)
There may be a hundred or more "Actions", on paper it seemed like seperate
classes would be a real mess. Also seemed like the temptation would exist to
have an action perform way more than it should. Maybe I was wrong..
One nice thing about having a n-number of Action/Foo/Bar.php files is that
they could have been loaded only when needed. That would have been slick,
perhaps faster too. (Assuming the overhead of another abstract class was
worth it) Something like:
abstract class Action {
/**
* Process request, return a view.
*/
public function process(&$request);
/**
* Do stuff after the view has been shown.
*/
public function finish(&$view);
// .. methods the crystal ball didn't warn us about, but turns
// out we needed in actions. isError() maybe?? only the
// future knows..
}
>* blocking possible ways of extension esssentially means making the
>decision on what is good design on beforehand instead of in a conctete
>situation where reuse and extension occurs - this seems contradictory to
>the principles of simplicty and fit for purpose that i believe to appy
>to good design...
The advantage of keeping them private or protected has been to prevent using
them in other places. Makes debugging easier, if something is private, you know
it can't be used outside a given scope and therefore it's safe to change w/out
worries of botching up the big picture. Another reason is to have accessor
methods, should your private data change.
A lot of it depends on who has the code, you can always go back and bump access
level up should it be required, can't do that in reverse very easy though. (As
you point out, making things private or protected does create problems when
crossing package boundaries :-( )
Yea, deciding access levels in advance has always been quite a challenge, very
easy to screw up. My rule seems to be: "If I control the source, it's private
till I need it". I used to be the opposite, but ended up trying to figure out
what was used where, what happens if I modify it. Taking the defensive has helped
me in this area.
Fewer methods improves re-use in terms of inheritance. In "java land" you can
always implement more interfaces should you need more methods, keeping each
interface small and tight. (Or have a method that returns an implementation by
way of private inner class and interface) In PHP this typically means another
file to load.
I really wish PHP had "inner classes" that could go a long way in creating
better design.
I suppose a downside with "frameworks" is that parsing thousands of lines of
PHP code each time a page is loaded would be impractical. (Something that would
have to be done if you had dozens of interface definitions, this is why I haven't
used Interfaces in PHP very much.) Some day, when I make my next million... I'll
buy a zend compiler. :-)
Jamie
-- http://www.geniegate.com Custom web programming guhzo_42@lnubb.pbz (rot13) User Management Solutions
- Next message: nospam_at_geniegate.com: "Re: Php not free anymore"
- Previous message: Annoying: "MAthML"
- In reply to: Henk Verhoeven: "Re: Object Oriented Content System - the idea"
- Next in thread: Henk Verhoeven: "Re: Object Oriented Content System - the idea"
- Reply: Henk Verhoeven: "Re: Object Oriented Content System - the idea"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
