$code = ‘$Handle = new $Class(’;
$code .= implode(’, ‘, $ConstructionArgs);
$code .= ‘);’;

eval($code);

$code = '$Handle = new $Class('; $code .= implode(', ', $ConstructionArgs); $code .= ');'; eval($code);

sorry for the noise :) but heh, there is no way to preview the comment before posting :/

trying to solve a simple problem by adding layers and layers of code..
a) dont use PHP construtors! for objects with args. xxxxx::construct(….)
b) require before use..

Regards
Alan

wouldn’t it be better in ResolvHandle() to use an eval() for the object call ?

I guess yes but as Jeff puts it here: “I am prejudiced against eval.” which is a point of view I can understand, from my perspective because I don’t think I’d ever be able to trust it 100% and be nervous every time PHP changes version. Something like ResolveHandle is likely to get embedded in alot of code so having it break would be painful.

The three argument limit to the constructor seems like a rough edge (although it’s easy to increase). Generally though, who send more than about 5 to a constructor?

This handle mechanism is only intended to be used in a limited set of circumstances. That is when creating an object that is intended to control interaction with a user across a series of requests. The handle mechanism provides a way to compose a single assembly of objects for the interaction, and yet only instantiate the objects needed for the particular request being handled at the moment. It is an optimization adaption to PHP’s lack of ability to preserve state between requests.

If you do not wish to use this optimization, you can instead include all of the files necessary and instantiate all of the objects in the assembly on every request. This results in simpler code and is a perfectly valid way to use this mechanism in WACT. The API for doing this is the same. I took the simpler approach in [URL=http://www.sitepoint.com/forums/showpost.php?p=1208767&postcount=43]this post[/URL]. rather than try to explain the handle mechanism, it just didn’t use it.

The syntax [CODE]classfile.php|class[/CODE] is meant to be the PHP equivalent to a fully qualified java class specification: [CODE]x.y.z.class[/CODE].

The handle design replaced a template method based design and favors a composition based approach rather than an inheritance based approach for using WACT controllers. Based on the typical usage so far, this approach is better than the previous approach we used.

That said, the controller design from WACT is far from set in stone and far from finished. There may be a better design to accomplish the same thing that remains undiscovered. Also, I have not yet done benchmarking to determine if the optimization this provides is worth the extra complexity, or if it the benefit of lazy loading even outweighs the costs of the ResolveHandle function for common examples. if it turns out that it does not, I would happily consider removing this from WACT in favor of simplicity.

userupdateinitial.php#UserUpdateInitial

just to make it more like a URL, and then possibly could get ResolveHandle() creating proxies, for services/classes elsewhere.

Why was | used rather than #?

Because : is used in Windows paths…;) actually don’t think we though of # - good idea - like the remote proxy angle.