Object Oriented Content System - the idea

[R]

Hello everybody.

I'm writing my own Content System in PHP5. I've written so far main
classes for handling DB connections, XML, XForms and Sessions.

But I've got problem with one thing - it's not even relative with
implementation - I'm looking for a smart solution

My present system works like this:

/?module=main&pa ge=intro

script includes and creates all classes instances - preprocess basic
actions - stats, privilages do some more things.
then it includes the '/main/intro.inc.php' file where I use all the
instances

but It's not and OO System when I use only 4 classes and a whole
system is procedural.

I was thinking about associating module 'main' with class 'main' and
page 'intro' with its method 'intro'.
The file 'main.inc.php' would be included and created new instance
main would be created - main inherits some properties and methods from
base class.

It would have delegate all the main classes to main eg.
$main->db->select();
$main->xml->addnode();

How do You find my solution?
Maybe You have some tips, hints?

I'd be thankful for any help

best regards
R

[NSpam]

Re: Object Oriented Content System - the idea

R wrote:[color=blue]
> Hello everybody.
>
> I'm writing my own Content System in PHP5. I've written so far main
> classes for handling DB connections, XML, XForms and Sessions.
>
> But I've got problem with one thing - it's not even relative with
> implementation - I'm looking for a smart solution
>
> My present system works like this:
>
> /?module=main&pa ge=intro
>
> script includes and creates all classes instances - preprocess basic
> actions - stats, privilages do some more things.
> then it includes the '/main/intro.inc.php' file where I use all the
> instances
>
> but It's not and OO System when I use only 4 classes and a whole
> system is procedural.
>
> I was thinking about associating module 'main' with class 'main' and
> page 'intro' with its method 'intro'.
> The file 'main.inc.php' would be included and created new instance
> main would be created - main inherits some properties and methods from
> base class.
>
> It would have delegate all the main classes to main eg.
> $main->db->select();
> $main->xml->addnode();
>
> How do You find my solution?
> Maybe You have some tips, hints?
>
> I'd be thankful for any help
>
> best regards
> R[/color]
Assuming I've read your post correctly then its a scoping problem.

You want to call an object that instantiates other objects which are
visible in the global scope.

Eg.
pseudo code

class foo {


egg = new egg;
yung = new yung;

}

foo = new fooObject();

after intantiating an instance of class foo
I think what you want to be able to do is

egg->someProperty



Maybe use sessions such as

class foo {
egg = new egg;
$_SESSION['egg'] = egg
yung = new yung;
$_SESSION['yung'] = yung
}

I haven't tried any of this - just guessing

I am humbly prepared to be shot down in flames by a more elegant
solution, or even to be told I'm just dumb

Chris

[Henk Verhoeven]

Re: Object Oriented Content System - the idea

http://www.phppeanuts.org/site/index_php/Pagina/26/principle.html

R wrote:
[color=blue]
> Hello everybody.
>
> I'm writing my own Content System in PHP5. I've written so far main
> classes for handling DB connections, XML, XForms and Sessions.
>
> But I've got problem with one thing - it's not even relative with
> implementation - I'm looking for a smart solution
>
> My present system works like this:
>
> /?module=main&pa ge=intro
>
> script includes and creates all classes instances - preprocess basic
> actions - stats, privilages do some more things.
> then it includes the '/main/intro.inc.php' file where I use all the
> instances
>
> but It's not and OO System when I use only 4 classes and a whole
> system is procedural.
>
> I was thinking about associating module 'main' with class 'main' and
> page 'intro' with its method 'intro'.
> The file 'main.inc.php' would be included and created new instance
> main would be created - main inherits some properties and methods from
> base class.
>
> It would have delegate all the main classes to main eg.
> $main->db->select();
> $main->xml->addnode();
>
> How do You find my solution?
> Maybe You have some tips, hints?
>
> I'd be thankful for any help
>
> best regards
> R[/color]

[Kenneth Downs]

Re: Object Oriented Content System - the idea

R wrote:
[color=blue]
> Hello everybody.
>
> I'm writing my own Content System in PHP5. I've written so far main
> classes for handling DB connections, XML, XForms and Sessions.
>
> But I've got problem with one thing - it's not even relative with
> implementation - I'm looking for a smart solution
>
> My present system works like this:
>
> /?module=main&pa ge=intro
>
> script includes and creates all classes instances - preprocess basic
> actions - stats, privilages do some more things.
> then it includes the '/main/intro.inc.php' file where I use all the
> instances
>
> but It's not and OO System when I use only 4 classes and a whole
> system is procedural.[/color]

If I understand you correctly, the system is well defined and works, but you
think that perhaps it is "wrong" because it is not OOpy enough? Perhaps I
am overstating the case, but it seems that is what you are saying.

It also sounds like your system is similar to my own. All calls go through a
single page which always does basically the same stuff in the same order,
being sanitize the inputs, check for session status (possibly route out to
login form), connect to database, perform writes, perform reads, close db,
generate HTML, say goodnight. Various hooks at the middle stages give the
system its life.

Now, if this is basically a procedure, meaning a series of steps, why not
code it procedurally? In my case this is all in one big file, why break it
up? Its easier to edit one file.

Not sure if this is where you were going, but thought I'd chime in.

--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec )ure(Dat)a(.com )

[nospam@geniegate.com]

Re: Object Oriented Content System - the idea

In: <12e35601.05030 20817.368700c6@ posting.google. com>, ruthless@poczta .onet.pl (R) wrote:[color=blue]
>I'm writing my own Content System in PHP5. I've written so far main
>classes for handling DB connections, XML, XForms and Sessions.
>
>But I've got problem with one thing - it's not even relative with
>implementati on - I'm looking for a smart solution
>
>My present system works like this:
>
>/?module=main&pa ge=intro
>
>script includes and creates all classes instances - preprocess basic
>actions - stats, privilages do some more things.
>then it includes the '/main/intro.inc.php' file where I use all the
>instances
>
>but It's not and OO System when I use only 4 classes and a whole
>system is procedural.
>
>I was thinking about associating module 'main' with class 'main' and
>page 'intro' with its method 'intro'.
>The file 'main.inc.php' would be included and created new instance
>main would be created - main inherits some properties and methods from
>base class.[/color]


This is not new, it's based on the Model-View-Controller design pattern,
and has probably been around since programmers learned to use dispatch
tables, it isn't OOP centric, PHP centric or even web centric. I've
actually seen variations of it in assembler. Also pretty common in those
"pick a number" menu systems of yesterday. It's really good if you want
to avoid tangled if(..) else .. or select ... case blocks. It really
mirrors the web server itself: Apache is the controller, the
file system is the "model" and the browser is the "view".

What I do (simplified):

script.php
<?php
$ctl = new Controller();
try {
$view = $ctl->run(); // Run a do_ method, Your intro() would be do_intro()
$view->display(); // display the output of do_intro()
$ctl->finish(); // Any cleanup? (Won't be called on exception)
}catch(Viewable _Exception $ex){
$ex->display(); //PHP5 has exceptions YAY! we can override it with something
//supporting a display() to show critical errors.
}
?>

// Does the delegation.
class Controller {
public function run() {
//Do stuff, figure out what method to run, setup common objects, etc..
$meth = $this->figure_out_do_ method(); // What page are we showing?
$view = $this->$meth(); //Run the page, (do logic stuff, but no output)
return($view); // This returns an object with a display() method.
}
public function finish(){
// Do stuff AFTER page displayed, you might pass the $view
// object as a parameter if you wanted some context.
}
// This is a "model".
protected function do_intro() {
// Some-what important: don't display anything here,
// somewhere (such as the View) may need to send headers.
// These do_* methods exist to setup views for later display.
return($view_ob ject_containing _intro_page)
}
protected function do_something_el se() { }
}

// This is the cheese.
class View {
public function display(){
// you include() a PHP script here, or perhaps
// do an XSLT transformation, etc.. *this* is where output
// is generated.
}
public function param($key,$val ue = FALSE) {
// this is how we communicate with the do_action method.
}
}

Then, I just override Controller with the appropriate do_ methods. Everything is run
from a dispatch table, I don't base any filenames/methods directly on user input,
for instance: $DISPATCH[DO_INTRO] = 'do_intro', there is no way outside input
can run any method not in the table. I sort of cheat by combining the Controller
and the Model. (But overall it's more convenient so far)

The view object would (in theory) allow you to embed it into a larger PHP
program, or run a method without displaying any output.

Overall, I'm pretty happy with it, it seems to work good and it's fairly clean.
It's a carry-over from some PHP4 stuff, which as pointed out, is a carry over
from the ancient geeks. :-)

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) but
that had some downsides if you want to share private utility methods across
"action" boundaries, so, I went with a method-is-model approach. Have a look at
the jakarta/Struts project to see what I mean. Their controller wears only 1
hat. It is considered by many to be the correct approach.

Being able to add the do_ methods dynamically would really be nice to improve
performance, as PHP5 wouldn't need to parse so much code on each page load.
Perl has $AUTOLOAD for this, (Endless fun when mixed with @ISA..) but PHP
doesn't appear to have that. You can "kind of" cheat by having do_ methods
require files only when run, that is what I do for some methods.

Also, I tend to use DO_ variables for the dispatch lookup, some people perfer
to use the URL path. (The reason I use DO_ is so a form can trigger different
do_actions based on multiple SUBMIT buttons) consider using paths instead,
search engines seem to like that better. (But it sucks if you need multiple
submit buttons.. you have to create a do_interpret_di spatch() type of method to
figure out the button and run correct method - ick.)


Jamie
--
http://www.geniegate.com Custom web programming
guhzo_42@lnubb. pbz (rot13) User Management Solutions

[Henk Verhoeven]

Re: Object Oriented Content System - the idea


Hi Jamie,

nospam@geniegat e.com wrote:[color=blue]
>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)[/color]

Apart for the use of the word 'action', this could have been a partial
description of the phpPeanuts request dispatch.
[color=blue]
> but that had some downsides if you want to share
> private utility methods across "action" boundaries[/color]

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?

Greetings,

Henk Verhoeven,
MetaClass,
www.phpPeanuts.org.

(BTW, i do not really have a C++/Java background, i never underderstood
how the advantage of making methods 'private' can outweight the
advantages of the (possible*) use of patterns like visitor, lazy
initialization (but overridable from subclasses) and double dispatch)

* 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...

[nospam@geniegate.com]

Re: Object Oriented Content System - the idea

In: <d155b4$beb$1@n ews6.zwoll1.ov. home.nl>, Henk Verhoeven <news1@phppeanu tsREMOVE-THIS.org> wrote:[color=blue]
>
>Hi Jamie,
>
>nospam@geniega te.com wrote:[color=green]
> >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)[/color]
>
>Apart for the use of the word 'action', this could have been a partial
>description of the phpPeanuts request dispatch.[/color]

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)
[color=blue][color=green]
> > but that had some downsides if you want to share
> > private utility methods across "action" boundaries[/color]
>
>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?[/color]

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::create Controller($CON FIG);
$action = $controller->getAction();
if($action){
$view = $action->process($reque st);
$view->display($respo nse);
$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(&$reque st);
/**
* 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..
}

[color=blue]
>* 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...[/color]

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

[Henk Verhoeven]

Re: Object Oriented Content System - the idea

Jami,

Some reactions in random order:
[color=blue]
> I suppose a downside with "frameworks " is that parsing thousands
> of lines of PHP code each time a page is loaded would be impractical.[/color]

I expected php to be smarter then that. The standard php may not have a
JIT compiler, but that does not say it can not keep some intermediate
form like bytecode in memory for the next request. Of course it has to
check the files' timestamps to make sure they are not modified, but
that's not very time consuming with a proper OS like Linux.

I always use a framework. It's now 572 KB of class code but it only
includes class files of classes it needs. I have had some problems with
performance, but could always track them down to frequent database
access and could solve them with caching instead of retrieving objects,
or a little bit custom retrieval code. I guess it's not fast enough for
hundreds of simultanious users, but i did not yet stumble upon a
customer who has such needs, so i just do proper coding for
[color=blue]
> They even have stuff to populate javabeans directly from a request,
> real handy stuff.[/color]
I guess peanuts has that too. Actually when i looked at struts it was
nearly undocumented and very messy code. That was when i was writing my
second generation of framework in Java, maybe 1998 or so. Then SUN came
with EJB and such, making everything unecessarily complex. In time this
drove me away from Java, so with php i tried to make the simpelest thing
that could possibly work for the same amount of framework power as i had
in the first generation (Smalltalk).
[color=blue]
> 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.[/color]

I can't follow you here. Imho Beans are essentially objects with meta
data. If you need the objects, why not have the meta data as well? Ok,
it has to be initialized for every request, but it helps to take a lot
of repetitive code away, so there is less to parse in the end. I don't
see what it has to do with maps/associative arrays, except of course you
need those for caching.
[color=blue]
> 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" (..)
> To do the same with separate Actions, you'd have to create a separate
> "util" class that is shared between objects.[/color]

I must admit i have a lot of this kind of funcion inherited by different
kinds of "actions". Furthermore when i decompose one action into several
children (parts) to compose a page from, the children get a reference to
the parent action (whole) so that they can 'ask the parent' or delegate
back. But that does not mean i do not make a utility class if i have
clear semantics for it. For example i have a utility for tracking all
requests so that i can return the user to the context from where he went
editing an object, a utility for keeping statistics of a website, and i
am planning to make a utility for checking if a user is authorized for
an action.
[color=blue]
> It probably is better to have separate Action objects in the long run:
> (..)[/color]
Interesting, in my hunt for simplicity i have tried to see the
controller as just the first 'action' in the hierarchy. But it does do a
specific kind of dispatch so maybe i should rename it 'controller' anyway.

With respect to having a separate view to display a response, that is no
different from a part that gets some parameters set by its 'whole',
usually to refer one or more business objects to be displayed. But i
agree, the naming may sometimes be helpfull in itself.
[color=blue]
> Kind of sucked having a whole separate "view", with 1 string
> difference, a view.xml (or view.cfg) can overcome this
> with parameters.[/color]

I thought XML is quite slow becuase it has to be parsed for every
request ;-)

Are those parameters dynamic? Or do they have to be set beforehand?
Dynamic tends to keep things simpler...
[color=blue]
> In "java land" you can always implement more interfaces should
> you need more methods,[/color]
This whole business of keeping track of interfaces does add considerable
overhead. In extremo it leads to the irratic situation that an old class
won't compile on a new version of Java because they have extended the
interface while the same class already compiled on an older version of
Java runs perfecltly with the rest of the old application.

In Smalltalk we simply did not formalize interfaces on beforehand but
instead, made a description of them (called protocols) after a while.
Having no formal interfaces certainly never stopped us to implement one
or more methods. Actually, what i still miss is the ability to add one
or more methods to an existing class without having to change the
original class' source. That way you can simply add the implementation
of an interface to an existing class. This makes code maintenance in
packages a lot simpeler and the resulting code more elegant. Yet another
example of a different meaning of 'private', i guess.

Thanks for your enlightening reaction,

Henk Verhoeven,
www.phpPeanuts.org.

[nospam@geniegate.com]

Re: Object Oriented Content System - the idea

In: <d17r72$14t$1@n ews4.zwoll1.ov. home.nl>, Henk Verhoeven <news1@phppeanu tsREMOVE-THIS.org> wrote:[color=blue]
>I expected php to be smarter then that. The standard php may not have a
>JIT compiler, but that does not say it can not keep some intermediate
>form like bytecode in memory for the next request. Of course it has to
>check the files' timestamps to make sure they are not modified, but
>that's not very time consuming with a proper OS like Linux.[/color]

I'm not 100% sure, but if the fact that there is no way to store a variable to
be shared among subsequent requests is any indication I assumed PHP re-parsed
each time.

If you know a way around this, something like a "global map" that is loaded
once and available until the file changes, the web server terminates, or the
cache is rolled over, I'd really like knowing about it.

I realize this isn't proof that it doesn't do the same with byte code, I suppose
one could use the zend compiler or go with commercial products.
[color=blue][color=green]
> > They even have stuff to populate javabeans directly from a request,
> > real handy stuff.[/color]
>I guess peanuts has that too. Actually when i looked at struts it was
>nearly undocumented and very messy code. That was when i was writing my
>second generation of framework in Java, maybe 1998 or so. Then SUN came
>with EJB and such, making everything unecessarily complex.[/color]

Ah yes, EJB... I liked the ideas I read about it, but yea, too complex
in my opinion. (I've only played with it to see how suitable it was, never
deployed in a production environment)

The book "Bitter EJB" sort of turned me away from it.
[color=blue]
>Imho Beans are essentially objects with meta
>data. If you need the objects, why not have the meta data as well? Ok,[/color]

Thats the problem and the nice thing about Maps. If all you have is
getXXX and setXXX, it's tempting to just use a map, afterall no more code
to load in etc..

Then, when you need to supply defaults or in some other way cook it, you're
toast.
[color=blue]
>kinds of "actions". Furthermore when i decompose one action into several
>children (parts) to compose a page from, the children get a reference to
>the parent action (whole)[/color]

I'm having a hard time following this. Do you have multiple Actions
pr. request? Each action potentially adding something to the View?

I understand the parent part, (actually keeping a "Context" of some sort
around is always a good idea, should you ever find yourself in the spot
of "I can't share this data with that method")

So you have:

Action
View --> Child Action 1 >- [View] -> Child Action 2
View <--

Where both Action 1 and Action 2 are run when the top level Action is run? (and
a common View passed between them)

I think I can see some logic to this, did something like it once for a middle
tier, each Request (based on an XML document) could invoke multiple actions,
each action added some stuff to a "response" XML document.

This was MVC (I thought of it as batched-rpc) in a different way, the Actions
were more like listeners and could react to any request they wanted. Had the
advantage that you could do multiple things with 1 request. (For instance, add
multiple records)

Disadvantage: every action had to be notified for each request. (Not really a
problem if you had < 40 actions though, the "XML tree" was a custom design,
small & optimized for read-only access with perl regular expressions) The
actions were setup to run in the order you wanted them to. I suppose if you had
many more actions, you'd probably map them to XML paths to avoid notifying a
lot of actions that weren't interested.

Never thought of applying it to urlencoded data though. hmm... interesting
idea! :-)

Am I understanding you correctly? Several actions pr. view?
[color=blue]
>am planning to make a utility for checking if a user is authorized for
>an action.[/color]

I'm glad you brought this part up, it is one nice thing about having the
"actions as methods" model. If you have multiple controllers (each one
inherits from a base controller):

class Controller {
// .. common controller methods ..
public function run() { return($view); }
}

Then you have something like this:

class AdminController extends Controller {
public function run {
$this->checkAuth(); // ALL methods need authentication.
...
return(parent:: run())
}
}

It's easy to test for authorization of all the actions, convenient with
related actions. Inconvenient because you need a different "kicker script"
for different areas. (In my case nice, because I can have smaller view.xml
files see below..)
[color=blue]
>I thought XML is quite slow becuase it has to be parsed for every
>request ;-)[/color]

I agree! thats why I really, really did not want to do it. grrr...

I kept the XML simple, using attributes because they parse faster.
Tried at first to use an .ini, but it just didn't work out on paper. (Ended
up with either a zillion .ini files or really convoluted names)
[color=blue]
>Are those parameters dynamic? Or do they have to be set beforehand?
>Dynamic tends to keep things simpler...[/color]

Parameters can be set either way. In the XML doc, they are static but
the Actions set them dynamic. Actions are never supposed to send anything
to the client, the only way they should display anything is with a view.

Typically, they set an object or a variable as a parameter and the view takes
that map/object/data and formats it for HTML display using an includeed PHP
file. The PHP view shouldn't try to do anything besides display.

If it weren't for the parse-each-time problem, this would allow you
to embed 1 action into another action or, even a completely different
web application with a different system as you could have it's "view"
display markup for an HTML container in a larger page, basically you
have more control over when/where it is displayed.

If you were to embed it into something using the same system, you'd set the
view as a parameter to a parent view and the parent view would call it's
display() within the HTML container. (Or perhaps one day... XML container)

Jamie
--
http://www.geniegate.com Custom web programming
guhzo_42@lnubb. pbz (rot13) User Management Solutions

[Henk Verhoeven]

Re: Object Oriented Content System - the idea

nospam@geniegat e.com wrote:[color=blue]
> I'm not 100% sure, but if the fact that there is no way to store a variable to
> be shared among subsequent requests is any indication I assumed PHP re-parsed
> each time.
>[/color]
In the beginning i was worried about this too, but nowadays i think this
not sharing variables is really a design issue: allowing no
multithreading makes life a lot easier, not only for php programmers,
but also for the developers of the engine.[color=blue]
>
> If you know a way around this, something like a "global map" that is loaded
> once and available until the file changes, the web server terminates, or the
> cache is rolled over, I'd really like knowing about it.
>[/color]
Bytecode can be cached quite easily on a file to file basis in such a
global map: It only needs to be checked to be in sinc with the file at
the moment the file is included. It does not contian any variables that
can cause race conditions (the temporary variables are on the stack, not
in the bytecode). Of course on top of the cache you need to keep track
for each process of the bytecode as it is currently in used by the
process, but if you do not cache you have to do that anyway to implement
the include_once function.

There is no reason why php programmers would need to know about this
caching mechanism: is can be made 100 % transparent. So if there is such
a global map, why would they tell us? But it can be checked quite
easily: put two really large but identical scripts into two different
files, reload apache, then run the first one to initialize everything
the script needs from php, then run the second one the first time and
see how long that takes, then run the second one the second time and see
if that takes considerably less time.
[color=blue]
>
> I realize this isn't proof that it doesn't do the same with byte code, I suppose
> one could use the zend compiler or go with commercial products.
>
>[color=green][color=darkred]
>>>They even have stuff to populate javabeans directly from a request,
>>>real handy stuff.[/color]
>>
>>I guess peanuts has that too. Actually when i looked at struts it was
>>nearly undocumented and very messy code. That was when i was writing my
>>second generation of framework in Java, maybe 1998 or so. Then SUN came
>>with EJB and such, making everything unecessarily complex.[/color]
>
>
> Ah yes, EJB... I liked the ideas I read about it, but yea, too complex
> in my opinion. (I've only played with it to see how suitable it was, never
> deployed in a production environment)
>
> The book "Bitter EJB" sort of turned me away from it.
>
>[color=green]
>>Imho Beans are essentially objects with meta
>>data. If you need the objects, why not have the meta data as well? Ok,[/color]
>
>
> Thats the problem and the nice thing about Maps. If all you have is
> getXXX and setXXX, it's tempting to just use a map, afterall no more code
> to load in etc..
>[/color]
Ok, i see, and php objects essentially ARE maps.
[color=blue]
> Then, when you need to supply defaults or in some other way cook it, you're
> toast.[/color]

Exactly! But you do not need to write all accessor methods to have
encapsulation. You only need to have a mechanism that uses the accessor
method if it is there and uses the members directly if no method is
present. PHP5 has two ways to do this: you can either use member
overloading or method overloading, see

http://nl2.php.net/manual/en/language.oop5.overloading.php

member overloading seems the logical choice but it has two problems:
- it leaves you with the problem to call the getter or setter if it exists,
- it denies you direct access to the members (if i understand it
correctly - please correct me if i am wrong or incomplete).
The former can be solved with a variable call like $this->$methodName( ),
the latter i think will sooner or later turn out to be so problematic
that you will have to make workarounds like using a different member
name or using an array instead of mebers. So i prefer the latter: agree
on a getter and setter naming convention (the one from java beans will
do nicely) and allways call those methods. If they don't exist, let your
__call function get or set the right member :-).

PhpPeanuts also offers a component model that implements encapsulation
without allways having to write accesor methods. It also works in php4
through generic get($propertyNa me) and set($propertyNa me, $value)
methods, but it adds more abstraction by using meta object code that
defaults to the persistency framework for derived and multi value
properties. So if you have $myOrder which holds an instance of class
Order with a multi value propety 'orderLines' of type 'OrderLine',
$myOrder->get('orderline s') will require_once the class OrderLine,
retrieve the orderline records which belong to the order from the
database, populate one instance of OrderLine for each record and return
a reference to (a variable with) the array with references to (varibles
with) the instances.
[color=blue]
>
>[color=green]
>>kinds of "actions". Furthermore when i decompose one action into several
>>children (parts) to compose a page from, the children get a reference to
>>the parent action (whole)[/color]
>
>
> I'm having a hard time following this. Do you have multiple Actions
> pr. request? Each action potentially adding something to the View?
>
> I understand the parent part, (actually keeping a "Context" of some sort
> around is always a good idea, should you ever find yourself in the spot
> of "I can't share this data with that method")
>
> So you have:
>
> Action
> View --> Child Action 1 >- [View] -> Child Action 2
> View <--
>
> Where both Action 1 and Action 2 are run when the top level Action is run? (and
> a common View passed between them)
>[/color]

It's more like
Controller->ActionOrPage->children->Array(
'Child1' => Child1->childeren-> (etc)
'Child2' => Child2->childeren-> (etc)
)

Creating and running the children can be done from the main method:

function handleRequest() {
$this->printHeader( );
$this->printPart('Chi ld1');
$this->printPart('Chi ld2', 'parameter1');
$this->printFooter( );
}

Or you could use the default implementation of handleRequest inherited
from PntPage, wich is to include the skin<PageName>. php, with is a php
script like:

<H1>Heading above the output of Child1</H1>
<?php $this->printPart('Chi ld1') ?>
<H1>Heading above the output of Child2</H1>
<?php $this->printPart('Chi ld2', 'parameter1') ?>

printPart() loads the part class, instantiates it passing the parameters
to the constructor, and runs it. The part may include another skin or
implement a printBody method, both may have children of their own who
again etc. etc. Or course this is not the entire story, there are more
low level ways to explicitly load the part class, name it, intsantiate
it, configure it explicitly and then 'run' it, but in most cases the
above methods will do. There is a diagram of the request handling and
page composition on:

http://www.phppeanuts.org/site/index_php/Pagina/26/principle.html

But your XML aproach seems appropriate too. It seems worthwile to check
if php really does all that parsing you mention, if it doesn't there is
nothing to withhold you from embedding one action into another action.
If it does, it must have a pritty fast parser given the performance i
get with phpPeanuts ;-)

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.

[salmo.bytes@montana-riverboats.com]

Re: Object Oriented Content System - the idea

RE> "I guess it's not fast enough for
hundreds of simultanious users, but i did not yet stumble upon a
customer who has such needs....."

There are lots of advantages to machine generated HTML:
it becomes possible to make hundreds of pages based on
a relatively small number of pre-loaded database inserts.
And machine generated pages tend to follow a consistent,
well-organized look and feel.

But that doesn't mean you have to serve those pages
at runtime. Why not have the program spit out static
HTML, written out to the server side file system?
When you want to change the way the pages looks, tweak
a stylesheet or load a few new parameters into the database
and then rewrite the static pages.
Then everything runs quickly and you don't have to
worry about cpu cycles.

Those *few* pages that really do need to be generated dynamically,
say as a response to interactive form input, can still
be generated on the fly. But the great bulk of pages
on most sites don't need to be generated dynamically.
Yet they can still benefit from machine generation...as static
html.

[Kenneth Downs]

Re: Object Oriented Content System - the idea

salmo.bytes@mon tana-riverboats.com wrote:

[color=blue]
>
> But that doesn't mean you have to serve those pages
> at runtime. Why not have the program spit out static
> HTML, written out to the server side file system?
> When you want to change the way the pages looks, tweak
> a stylesheet or load a few new parameters into the database
> and then rewrite the static pages.
> Then everything runs quickly and you don't have to
> worry about cpu cycles.
>[/color]

You can even do both. Put a "dynamic" directory ahead of the static
directory in the include path. If it cannot find the page, it generates it
and saves it. Subsequent attempts will find the cached page.

When the system is upgraded you clear the dynamic directory.

We chose this route because it keeps HTML generation in the PHP layer
instead of working it into the install. The install simply builds pages
that contain associative arrays with the necessary dictionary data.

We have yet to give this any rigorous speed testing, and may drop it if it
turns out to be a Bad Thing.

--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec )ure(Dat)a(.com )

[Henk Verhoeven]

Re: Object Oriented Content System - the idea

Hi Salmo,

Sure, one way to boost performance could be chaching the html. However,
this has downsides too: a database with 10.000 records that firs in 10
Mb of database space can take hundreds of megabytes html cache. And
keeping track of how changes to the the data affect the page cache can
be hard. Of course this depends on the application, i guess caching is
attrictive for relatively simpel applications like a CMS. But in our
case processor time is simply not expensive enough to take the trouble
of integrating a chaching mechanism.

Greetings,

Henk Verhoeven,
MetaClass


salmo.bytes@mon tana-riverboats.com wrote:[color=blue]
> RE> "I guess it's not fast enough for
> hundreds of simultanious users, but i did not yet stumble upon a
> customer who has such needs....."
>
> There are lots of advantages to machine generated HTML:
> it becomes possible to make hundreds of pages based on
> a relatively small number of pre-loaded database inserts.
> And machine generated pages tend to follow a consistent,
> well-organized look and feel.
>
> But that doesn't mean you have to serve those pages
> at runtime. Why not have the program spit out static
> HTML, written out to the server side file system?
> When you want to change the way the pages looks, tweak
> a stylesheet or load a few new parameters into the database
> and then rewrite the static pages.
> Then everything runs quickly and you don't have to
> worry about cpu cycles.
>
> Those *few* pages that really do need to be generated dynamically,
> say as a response to interactive form input, can still
> be generated on the fly. But the great bulk of pages
> on most sites don't need to be generated dynamically.
> Yet they can still benefit from machine generation...as static
> html.
>[/color]