Re: [Phpslash-devel] How many page scripts do we need?

[nathan r. h. <na...@ds...>]

On Tue, 29 Apr 2003, Matthew Leingang wrote:

> Hey,
>
> Still thinking about this...
>

Good!

> nathan r. hruby wrote:
> > if it's an object that's needed, much of this framework lays already in
> > phplib session object, which we can expand from, if an object is *truly*
> > desired.  Again, I htink that having this in the globall scope would
> > probably be easier and faster in the long run.
>
> I don't think URLs should stay in the templates because then changing
> GET variable names means having to change the templates and that seems
> like a breach of the design/logic barrier.

We left 'em there to make it easier for people who don;t want to chnage
code to futz with stuff.  I've also found it hand to not have to deal with
the URL or any of the presets in code.  This may just be me, and I might
be willing to give up that ease for the benifit of having path-ified URL's
and the ability to move away from & as an argument seperator.

> I still think a class is the
> best way to allow different implementations of the URL, or just to have
> all in one place the functions which put it together.
>

I disagree.  If the functionality is simple and/or needed by *everything*
it belongs in a global function.  In this instance both of those
requirments are fulfilled.  There's no need to spend time creation an
destroyiog ab object 50 times a page load just to process some variables.

> Perhaps global wrapper functions could be used for the most common url
> creation methods for coding ease.
>
> > // Set the inital URL we want
> > $url = '/foo.php';
> >
> > // thake this and bring back an array of everything we need to develop a
> > // URI for what we want to ppoint at
> > $url = urlAddQuery($url, array('foo' => 'bar', 'session' => $sessid));
> >
> > // it should look somehting like this.
> > print_r($url);
> > // Array(
> > //	[method] =>	$_PSL['protocol']
> > //	[base] =>	$_PSL['rooturl']
> > //	[file] =>	/foo.php
> > //	[args] =>	Array(
> > //		[foo] =>	bar
> > //		[session] =>	fjiweqcn ujnjrinu290vncu034vn u390vntu13
> > //	)
> > //)
> >
> > // take that array and push it though a function to turn it into a URI
> > $tpl->add_var('URL', urlFinish($url));
>
> But if you want to add other GET variables conditionally, you'll have to
>    manipulate $url['args'].  What about removing a GET variable?  Even
> uglier.  It just naturally looks like members and methods to me.
>

Well, my my world urlAddQuery() pops things onto the end of the array, so
you can call it multiple times, conditionally or no :)  And you can very
easily make a urlRemoveQuery('varname') that removes the the array entry
for the named index.

Members and methods and variables and functions are the same thing, one's
in it's own namespace, the other isn't, but that namespace has a cost.  I
also think that a whole class and object dedicated to a fairly trivial
task is just over-engineering without any inherit benifit.

> > Easier to grok, less creation/teardown costs, etc.. (I've been working on
> > another project that's wacked out but all procudural using jsut
> > include_once() to seperate code.  It's a mess to navigate and use, but
> > it's freakin' *fast* so my new thing is to look for places where we can
> > reduce/reuse existing structures or at least avoid introduccing new stuff.
> > :)
>
> Is the procedural model definitely faster than OO?  We already use lots
> of classes.  If we're reorganizing the whole project architecture then I
> think introducing new stuff is not a bad idea after all.
>

Yes, the procedural method is a bit faster, this probably will not be the
case after php5.  I'm not suggesting a re-org of the entire codebase,
though there are a few places where I'd like to reduce and optimize things
for better performance and easier grokability.  My pet peeve is The fact
that $_PSL is in every class, including db so print_r()'ing a object is
worthless - I'm tempted to write a quick sed script to change every
$this->psl into $GLOBALS['_PSL'] jsut to get rid of them.

-n
-- 
------
nathan hruby
na...@ds...
------