Thread: [Phpslash-devel] How many page scripts do we need?
Brought to you by:
joestewart,
nhruby
Menu
▾
▴
phpslash-devel
|
From: Joe S. <joe...@us...> - 2003-04-23 16:09:56
|
With the -dev modules, you really don't need all the different scripts. GET variables can trigger the module and page to use. For instance they could be called something like: index.php?module=Story&page=admin How far should this go? All the way to only index.php? and backend.php? The entire admin/ directory can go. I'd like to eventually replace the about page with either a block or story. It's pretty bad now that it can't be modified through the admin interface. Joe |
|
From: Aric C. <php...@pe...> - 2003-04-26 00:31:36
|
Just wanted to chime in that I think this is A Good Idea.
Take it all the way to index.php.
I'd also like to see it work without the ? and &. For example:
index.php/story/admin
index.php/backend/rss
The first part ('story') could be always interpreted as the module name, the
second part the page. After that can be interpreted any way the module
chooses.
This makes search engines happier. Looks purty too.
----- Original Message -----
From: "Joe Stewart" <joe...@us...>
To: "PHPSlash Developers List" <php...@li...>
Sent: Wednesday, April 23, 2003 9:22 AM
Subject: [Phpslash-devel] How many page scripts do we need?
>
> With the -dev modules, you really don't need all the different
> scripts. GET variables can trigger the module and page to use.
>
> For instance they could be called something like:
>
> index.php?module=Story&page=admin
>
> How far should this go? All the way to only index.php? and
> backend.php?
>
> The entire admin/ directory can go.
>
> I'd like to eventually replace the about page with either a block or
> story. It's pretty bad now that it can't be modified through the admin
> interface.
>
> Joe
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpslash-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpslash-devel
>
|
|
From: Joe S. <joe...@us...> - 2003-04-28 13:40:24
|
On Fri, Apr 25, 2003 at 05:31:26PM -0700, Aric Caley wrote:
> Just wanted to chime in that I think this is A Good Idea.
>
> Take it all the way to index.php.
>
> I'd also like to see it work without the ? and &. For example:
>
> index.php/story/admin
> index.php/backend/rss
>
> The first part ('story') could be always interpreted as the module name, the
> second part the page. After that can be interpreted any way the module
> chooses.
>
In the past I have done this with mod_rewrite rules for the section
index pages, article pages and search results.
Most of the changes could be made in the templates. How true that
is now days, I don't know.
> This makes search engines happier. Looks purty too.
>
Since google spiders with ? and & fine it is less of an issue. The
other SE's are catching up. Path like arguments are definitely
better looking for email and conveying to someone else.
Joe
|
|
From: Matthew L. <lei...@ma...> - 2003-04-28 15:46:18
|
Joe Stewart wrote:
> On Fri, Apr 25, 2003 at 05:31:26PM -0700, Aric Caley wrote:
>
>>Just wanted to chime in that I think this is A Good Idea.
>>
>>Take it all the way to index.php.
>>
>>I'd also like to see it work without the ? and &. For example:
>>
>>index.php/story/admin
>>index.php/backend/rss
>>
>>The first part ('story') could be always interpreted as the module name, the
>>second part the page. After that can be interpreted any way the module
>>chooses.
>>
>
>
> In the past I have done this with mod_rewrite rules for the section
> index pages, article pages and search results.
I thought we were staying away from URL fanciness because
(theoretically) not all PSL users have access to http.conf or .htaccess
files. Maybe that's an imagined memory.
> Most of the changes could be made in the templates. How true that
> is now days, I don't know.
I've been thinking about something for a long time, and this looks like
a good time to bring it up. What about getting all URLs out of the
templates and objectifying them? A url object would be able to parse
$QUERY_STRING and/or $PATH_INFO and decode it. It would also have a
toString method which output would go into the templates.
$url = new PslUrl();
$url->setPath("/index.php");
$url->setVar("foo","bar");
$url->toString() // returns index.php?foo=bar,
but if we use a different URL scheme, $url->toString() would return
index.php/foo/bar or /foo=bar or whatever. Any URL object should be
able to understand and encode its own get variables.
Then we can provide a choice of URL encoding schemes: the basic one with
? and & and = which needs no .htaccess, or something fancier which does.
A call AddClassReplacement makes the choice
If you're going "all the way up to index.php", then the url object does
all the deciding of what page is actually being requested.
--Matt
(invigorated from PHPCon East)
--
----------------------------------------------------------------
Matthew Leingang http://www.math.rutgers.edu/~leingang
Rutgers University lei...@ma...
Department of Mathematics "This signature needs no quote."
|
|
From: nathan r. h. <na...@ds...> - 2003-04-28 16:23:22
|
On Mon, 28 Apr 2003, Matthew Leingang wrote:
> Joe Stewart wrote:
> >
> >
> > In the past I have done this with mod_rewrite rules for the section
> > index pages, article pages and search results.
>
> I thought we were staying away from URL fanciness because
> (theoretically) not all PSL users have access to http.conf or .htaccess
> files. Maybe that's an imagined memory.
>
I think that Jow was jsut saying that's how he's handled this in the past.
yes, you are correct in thinking this only works when you have confi file
access.
> > Most of the changes could be made in the templates. How true that
> > is now days, I don't know.
>
> I've been thinking about something for a long time, and this looks like
> a good time to bring it up. What about getting all URLs out of the
> templates and objectifying them? A url object would be able to parse
> $QUERY_STRING and/or $PATH_INFO and decode it. It would also have a
> toString method which output would go into the templates.
>
> $url = new PslUrl();
> $url->setPath("/index.php");
> $url->setVar("foo","bar");
> $url->toString() // returns index.php?foo=bar,
>
> but if we use a different URL scheme, $url->toString() would return
> index.php/foo/bar or /foo=bar or whatever. Any URL object should be
> able to understand and encode its own get variables.
>
> Then we can provide a choice of URL encoding schemes: the basic one with
> ? and & and = which needs no .htaccess, or something fancier which does.
> A call AddClassReplacement makes the choice
>
> If you're going "all the way up to index.php", then the url object does
> all the deciding of what page is actually being requested.
>
I don't understand why this needs to be an object. It'll get used
everywhere, it's probably best in functions.inc and let the individual
classes manage the storage of the variables.
> --Matt
> (invigorated from PHPCon East)
>
Rat bastid. I want a PHPCon South (or alternativly, I'd be nice to move
back to NYC :)
-n
--
------
nathan hruby
na...@ds...
------
|
|
From: nathan r. h. <na...@ds...> - 2003-04-28 17:07:54
|
On Mon, 28 Apr 2003, nathan r. hruby wrote:
[snip]
> >
> > I've been thinking about something for a long time, and this looks like
> > a good time to bring it up. What about getting all URLs out of the
> > templates and objectifying them? A url object would be able to parse
> > $QUERY_STRING and/or $PATH_INFO and decode it. It would also have a
> > toString method which output would go into the templates.
> >
> > $url = new PslUrl();
> > $url->setPath("/index.php");
> > $url->setVar("foo","bar");
> > $url->toString() // returns index.php?foo=bar,
> >
[snip]
>
> I don't understand why this needs to be an object. It'll get used
> everywhere, it's probably best in functions.inc and let the individual
> classes manage the storage of the variables.
>
To expand..
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.
// 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));
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.
:)
I belive that at one point we had talked about moving all URL generation
into $sess->url calls but felt that was a large undertaking for not a lot
of benifit. This may be something we want to re-evaluate now that there
are motiviations other than session propigation for rewriting url's in a
predefined manner.
-n
--
------
nathan hruby
na...@ds...
------
|
|
From: Matthew L. <lei...@ma...> - 2003-04-29 19:33:01
|
Hey,
Still thinking about this...
nathan r. hruby wrote:
>>I don't understand why this needs to be an object. It'll get used
>>everywhere, it's probably best in functions.inc and let the individual
>>classes manage the storage of the variables.
>>
>
>
> To expand..
>
> 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. 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.
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.
> 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.
--Matt
--
----------------------------------------------------------------
Matthew Leingang http://www.math.rutgers.edu/~leingang
Rutgers University lei...@ma...
Department of Mathematics "This signature needs no quote."
|
|
From: nathan r. h. <na...@ds...> - 2003-04-29 20:22:56
|
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...
------
|
|
From: Joe S. <joe...@us...> - 2003-04-30 15:44:30
|
On Wed, Apr 23, 2003 at 11:22:15AM -0500, Joe Stewart wrote: > > With the -dev modules, you really don't need all the different > scripts. GET variables can trigger the module and page to use. > A variation is to use the existing phpSlash structure and assign sections for the modules. Otherwise the modules always have the same blocks as the home page. A side note - We've been able to apply arguments to getStories like max and section. What would be the best way to pass these arguments as block options? > For instance they could be called something like: > > index.php?module=Story&page=admin > > How far should this go? All the way to only index.php? and > backend.php? > > The entire admin/ directory can go. > > I'd like to eventually replace the about page with either a block or > story. It's pretty bad now that it can't be modified through the admin > interface. > What else cannot be done through the web interface that maybe should be? Assigning pages to navbar items comes to mind for me. With module sections, there is a lot of flexibility in the page that is presented. - a different header for some sections. ( header block) - different arguments to the modules for some sections. (module block) - multiple module blocks per page. These are probably the major things I've had to do in the scripts. - different skins for different sections (page block) - You can do other weird things like make an entire section a static page using blocks. (page column) Joe |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X