Re: Thoughts (Was: Re: [Phpslash-commit] CVS: phpslash-dev CHANGES,1.76,1.77)

Peter Cruickshank <list-UnZd7gj/[email protected]> Thu, 8 Jul 2004 10:52:59 +0100
Newsgroups gmane.comp.cms.phpslash.devel
Organization CNGN
Message-ID <[email protected]>
On Wed, 7 Jul 2004 14:17:25 -0500
Joe Stewart <[email protected]> wrote:

> On Wed, Jul 07, 2004 at 11:26:25AM -0700, Peter Cruickshank wrote:
> 
> > + [E]  debug() now uses backtrace if available to show details of
> > file/class and+      line
> 
> This looks to be very cool.  Thanks.

:-)

> Have you had a need for the delayed viewing option for debug now?  It's
> handy for viewing variables used before cookies being set.

I have in Back-End and it's definitely cool. phpSlash doesnt have much left
in the way of debug statements at the moment.

I've not used the debug mail option - but it occurs to me that it might be
good to automatically defer all debugs til the page has been closed -->
only one email per page

> Now that you've pretty much gone through the code again.  Any new
> suggestions to make?

I like phpSlash's general approach (still seems cleaner than most other
CMSish systems even after all these years). 

Probably sections are the area that I'd want to work on next:

- allowing selection and positioning of blocks from the section admin
screen (hiding the complexities of block admin from those who don't need to
know).

- allowing hierarchical sections


Other stuff (brain dump, in random order):

- there's a lot of repeated code in the story classes (eg getStories vs
getStory) which could be simplified

- we could bring back from Back-End the common date/time input function.
psl is currently pretty inconsistent

- search still needs to be turned into a class. It's use of global
variables needs looked at too.

- infolog doesnt use the proper page generation methods and is now broken
(I will fix this soon)

- I'm not sure how relevant block/story level caching is now that we have
jpcache. It would be good to keep the cached content away from
structural settings stuff in the database. (This might be too fundamental
to be worth looking at)

- We need to create a new bare-bones database. After a while, the
description of the features section begins to grate...

- We need to define and document the stylesheet classes and ids that are
used and then make sure that all the skins use them consistently (eg
ShankZen uses class="psl-desc" whereas basic uses class="desc" or even
id="desc" which is bad html)

- The whole user interface/interaction thing needs cleaned up (nice error
messages, cancel button on form screens etc). Introducing htmlArea has made
a big difference to story input - it would be nice to make it the default
method.

- split out the menu definition stuff from the rest of config.php (keeps
the designers away from the scary stuff). Probably as something like
config_menu.php - it's too complex to be turned into a .ini file?

Think that'll do for now... :-)


Peter
-- 
Peter Cruickshank
peter cruickshank biz



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com