I split of my 0.9 thoughts because there seem to be a lot of them...
On Thu, 16 Sep 2004 12:41:57 -0500
Joe Stewart <joestewart-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx>
wrote:
> For psl 0.9:
>
> Not an exhaustive list or even looking at the current Roadmap.
>
> bring as much that BE has developed into psl as needed.
> - subsections
Yes!!
> - sitemap
> - subsites
How often would this be needed? Back-End might be more suitable solution
for sites that are big enough to need subsites.
> - block caches
> - trackback
> - multi language
> - what else?
A thought: Allow for switching CSS while keeping the same skin without
using a dummy template directory + skin.ini
> Move old stuff like glossary, etc. out of the core?
Makes sense. Having said that, space is probably not an issue. So maybe
just have glossary etc turned off by default.
> How much should be released with the core?
>
> Move the templates to a subdirectory of the module. This is supported
> now. But I'd like to get 0.8 out first.
Makes sense
> module install, register, update, remove method - including db setup,
> other required modules and version(s) required.
Definitely.
> Navbar administration? - This shouldn't be too bad. We can generate the
> navbars once per session/authentication cycle couldn't we?
Definitely too. The current menu-config setup is not end-user friendly at
all...
> Oh, enough for now.
Here's my initial thoughts:
PSL does a lot, but in a lot of places it's really ugly, and there's a lot
of legacy code lurking around. I think a lot of the work in the 0.9 cycle
should be focussed not on adding new features (PSL has already got a lot),
but making existing features more accessible/ understandable.
Areas could include:
A. Improvements to interface/interaction
Interface cleanup and/or redesign, particularly around block and section
administration (it should be possible to position blocks from the section
admin screen).
Seagull (http://seagull.phpkitchen.com/) seems to have put a lot of thought
into their UI - with the result that a less functional application-
framework looks like it can do more than PSL.
We may have to find some design type person to take some of this on.
B. Updated user documentation
Back-End's wiki manual has worked well (http://manual.back-end.org/) -
maybe we could do the same with phpSlash?
Good, clear instructions on troubleshooting the installation of a new
module should be a high priority!
C. Cleaning up code
It would be nice to separate the data access, presentation and business
logic more consistently. From my experience with Back-End, it would be good
to do this *before* adding in new features like subsites and
multi-lingualness.
(Moving to a compiling/caching template system like smarty or Flexy might
be worth thinking about).
There's a fair bit of duplicated code lurking around too (eg compare
Story::getStory() and Story::getStories()). Other stuff that comes to mind
are adding common datetime handling throughout the code (could be lifted
from Back-End)
While we're at it, we could add consistent phpDoc comments, and make the
output available online somewhere.
And finally, there's XHTML compliant templates (and documentation of the
classes that are used - I've made a start on this but there's nowhere to
put that right now - see below)
D. Move to PEAR (controversial?)
phplib provides a stable codebase, but development has pretty well stopped.
I have a feeling that it will make sense (at some point in the future -
possibly before PHP5 becomes the standard) to move to using PEAR db,
template and security handling at some point. On the other hand, if it
ain't broke...
> Maybe we can discuss this on irc as well.
Good idea. I'd like to participate, timezones permitting.
Peter
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
|
