Re: [Phpslash-devel] phpSlash Roadmap discussuon - 0.9

[Joe S. <joe...@us...>]

On Sat, Sep 18, 2004 at 10:45:50AM +0100, Peter Cruickshank wrote:
> 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 <joe...@us...> 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!!
>

I'm not sure about implementing exactly the same, but this feature is sorely 
needed.
 
> > - sitemap
> 
> > - subsites
> How often would this be needed? Back-End might be more suitable solution
> for sites that are big enough to need subsites. 
> 

good point. Just throwing stuff out.


> 
> > - what else?
> 

- pagination - I can't believe I forgot this one.

- user page redesign - I like the author list in BE.

> A thought: Allow for switching CSS while keeping the same skin without
> using a dummy template directory + skin.ini
>

That is the current method.

A css switcher block would be nice.
 
> > 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.  
> 

Will do that for now.  I don't think many people actually put it to good use.

With all the skins we are at about 2 meg.  Adding phplist makes it about 3meg.

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

I've been looking at tiki's menu admin - pretty nice.
> 
> > 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.
> 

I get surprised sometimes seeing some of the legacy code.

> 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?
>

ah.  I didn't see this before my other response.  I installed a wiki already on 
php-slash.org but don't have much experience.
 
> Good, clear instructions on troubleshooting the installation of a new
> module should be a high priority!
> 

I guess that might be me (:

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

Thanks for bringing this up.  eGroupware has this architecture.

They use ui, bo, and db as there separation.

dcl uses almost the same nomenclature.  

I'll probably add this to sf.net RFE pronto.

> (Moving to a compiling/caching template system like smarty or Flexy might
> be worth thinking about).
>

maybe so.  Anyone seen any recent benchmarks?  The last I saw still showed phplib 
templates faster.  Curious if the phplib templates in PEAR bear this out as well.
 
> 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.
> 

I used to generate this and make it available.  Here is the link for -ft:

http://www.php-slash.org/phpdoc/phpslash-ft/

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

I'm torn on this.  I've found some versioning issues with PEAR.  It's nice for us 
including phplib now.

There has been talk of rewriting parts of phplib for php5 support.

> 
> > Maybe we can discuss this on irc as well.
> 
> Good idea. I'd like to participate, timezones permitting. 
> 

You don't seem to sleep anyway.

Joe

> Peter
>