[Phpslash-devel] Re: RFC: more modular "modules"

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

On Fri, Mar 07, 2003 at 03:15:49PM +0000, Peter Cruickshank wrote:

<snip>
> 
> What I like about phpSlash, and what makes it stand out from the crowd, is that it is flexible and easy for a developer to extend or customise. I think it would be a shame to try to idiot-proof the code at the expense of performance or flexibility (might as well use a *Nuke then with its huge range of modules).
> 
> So I dont think there's much need for any auto-install code or other hand-holding (not that it's been discussed here).
> 

There may be room for some command-line installation scripts without 
sacrificing the configuration flexibility.  Last summer I had a commitment from the debian maintainer of postnuke to help 
with a debian package:

http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=81947


> Having said that, it is good to be rethinking things - the code's grown up a lot since 0.6.2. 
> 
> It would also be good to have criteria for acceptance of new modules. Just have to make sure the existing code is up to scratch!
> 

I think an published API would help in this regard too.

> Some other random thoughts:
> 
> Config/installation issues I can think of (no answers though, sorry):
> - adding menu items

Maybe a web based menu admin.

> - adding classRequirements

In my proposal the classRequirements would move to the module's scripts.  
JIT class registration.

> - module customisation (passwords etc)
> - database changes (new tables, updating permissions and groups etc)
> 
> Currently, it's a case of editing config.ini and manually running SQL. Possibly painful, but runs efficiently once done.
> 
> I dont think it would be good if we end up with a chain of config files having to be read and processed every time a page is loaded.
>

Good question about module configuration needs.
 
> The database has got to the stage though that modules might need an install.php script to create the apprpriate tables, work out record ids and update db_sequences where new block-types or permissions are added.
> 
> 
<snip>

> >
> >I've given this a little more thought.  I think templates will have to 
> >reside with the module by default.  But support being moved to skins and 
> >language directories.
> 
> Templates dont have to be with the module code once installed. Modules could come packages as a zipped up tree. There's the risk of overwriting existing stuff, but that can be got round by naming convenions (eg all must start with module name).
> 

no, but where to put them?  Just choose the "basic" skin?

If they stayed with the module by default, a site designer could setup 
skin specific ones under the skin's directory optionally.

> As far as skins are concerned, I think that stylesheets and images should be closer to the tpl files. I also think that skins should consist of base sets (in en_US I guess!), with language-specific variations. So for skin sssss:
>         /public_html/skins/ssss/*.tpl
>         /public_html/skins/ssss/de/*.tpl (i think the number of language-specific templates will be relatively small)
>         /public_html/skins/ssss/images
>         /public_html/skins/ssss/images/de/ (allow for different title and button graphics, for instance)
>         /public_html/skins/ssss/scripts
>         /public_html/skins/ssss/styles/ssss.css (to allow for locale-specific stylesheets, if ever needed)
>

The kicker to this is the templates themselves actually have nothing to do 
with the public_html stuff and are more similar to the other included 
files.  They don't need to be in web-root at all.
 
> - it'll make maintenance/extension of skins easier by having all the skin stuff under one tree
> 

agreed.  This was bantered some as to how to setup the styles.  Lars Hueur 
suggested the styles directory with skin-name.css.  This allows for actual 
stylesheet files to be cached by the browser.

thanks for your input,

Joe

> - it leaves the .tpl files exposed within the URL, no serious risk though.
> 
> - adding module names into the directory structure could make things very convoluted, I see Joe's point about it being good to include skins within modules - but we'd have to deal with image or script files (must be within the URL) and *.class files (should be away from URL root). I think a naming convention would be enough to prevent confusion.
> 
> 
> A separate internationalisation point is that much of the code assumes that the 'submit' button has english values (eg save, update). We really should be able to deal with the german, french, norwegian words... maybe it's just a case of changing
>         switch ($submit) {
>         case 'save':
>                 :
>         }
> to 
>         switch ($submit) {
>         case pslGetText('save'):
>                 :
>         }
> And also change the buttons to be
>         <input type="submit" name="submit" value="{LANG_SAVE}">
> throughout? (saves having extra variations on the templates).
> 
> 
> - is it worth trying to deal with variations within a language for spelling/timeformats (en_UK, en_CA, en_AU, de_DE, de_CH)? - I can't see that it would be an issue in practise. 'english', 'deutsch' etc would be whatever the language of the main users. Though I am impressed when I see an international site produce UK english, I can still make sense of the word 'internationalize' even if it is spelt wrong, and dates even if the month is in the wrong place. Possibly a controversial thought though.
> 
> >> I think it's important to remember the goal:  A phpslash contributor 
> >> should be able to add functionality without changing files.  So either you 
> >> add a new directory with standard subdirectory/filename structure or each 
> >> new module can add files in certain directories, or a mix of the two.  
> 
> Has to be a mix IMO cos of the need to keep *.class files away from the URL
> 
> >> 
> >> [snip]
> >> 
> >> > I probably won't get too much more time to look at this till Monday.
> >> 
> >> I'm out for a few days as well.
> 
> No wonder!
> 
> Anyway, I hope my thoughts were useful, even if they ended up being more about skins...
> 
> Peter 
>