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

[Matthew L. <lei...@ma...>]

On Fri, 7 Mar 2003, Peter Cruickshank wrote:

<snip>
> No more sleep for a while then, Matt :-)  Congratulations anyway.

<plug style="shameless" href="http://www.leingang.net/baby"/>

> Here are my thoughts...
> 
> 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).

Hear that.  I've downloaded and played a little with *Nuke and it also 
seems that its autoloading is at the expense of performance.  

> So I dont think there's much need for any auto-install code or other
> hand-holding (not that it's been discussed here).
> 
> 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!

Good point, although nobody's beating down the door with patches. :-)

> Some other random thoughts:
> 
> Config/installation issues I can think of (no answers though, sorry):
> - adding menu items
> - adding classRequirements
> - module customisation (passwords etc)
> - database changes (new tables, updating permissions and groups etc)

Sounds like the module developer should provide:
- a patch to config.ini
- content script, admin script
- an SQL script incrmental from last major release? 

> Currently, it's a case of editing config.ini and manually running SQL. Possibly painful, but runs efficiently once done.
Did somebody say README?

> 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 point.  Would you feel differently if each module had a config file 
that was loaded once per session?

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

Wherever possible, I think this should be done with class methods.  If 
you want to add a permission, there should be a slashPerm::addPerm() 
method (or something).  

> Would save a fair bit of unnecessary array processing for sure.
> 
> I think en_US is overkill at least at the moment (see below)

<snip>
> >> Silly question:  Why do we have language divisions in the template
> >> directory?  Isn't all i18n destined for the locale directory?
> 
> I think it's good that language-specific stuff (for static info) can
> be dealt with within .tpl files if wanted. Some stuff it just too
> complicated/big to include in $pslstrings. See my thoughts on
> structuring skins below...

OK, I understand this now.  Joe pointed out that you might have banner
images with text in different languages, so that's one reason to localize 
skins.

> >> Another idea, which I think PHPGW uses, is that within each module 
> >> directory you have template and l10n subdirectories.  

I wanted to double check their directory structure, but it seems they shot 
themselves in the foot.  All of their site's content got deleted!  By 
downloading a release, I confirmed:  
phpgroupware/MODULE/templates/SKIN/*.tpl is how they do it.  

Something that's bothering me:  It seems that programmers should develop 
new modules, but graphic designers should develop new skins.  I suspect
that most of us do both, but is there a way to keep them totally separate?  
Maybe that's not such a big deal.  The skin designer could add templates 
to any module.  

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

> - it'll make maintenance/extension of skins easier by having all the
> skin stuff under one tree

And the contributor of a new module has to traipse into the skin dir...

> - it leaves the .tpl files exposed within the URL, no serious risk though.

No risk, but unappealing to me

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

Aye, there's the rub.  If we want module contributions to be in a single
part of the psl tree, then we have to put stuff that should be
world-visible (images, admin scripts), and stuff that shouldn't (include
scripts, and to a lesser extent, templates) into the same level of the
tree.  Maybe that's the reason for the admin.php?module=foo style...

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

Very good point.  Could be done right away.

> 
> - 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 we should, because we can.  And I don't think its that hard if we
write a good pslGetText and psl_getLocalInfo.  I agree it would be
bothersome to provide separate language files for every single locale, so
why not do it like we're doing the skins?  You can have a full language
file en_US/foo.php; then en_UK/foo.php could indicate that whatever
strings weren't localized (um, localised) there should be taken from the
language default.

That's all for now.

Later,
Matt

-- 
----------------------------------------------------------------
Matthew Leingang                http://www.math.rutgers.edu/
Rutgers University              lei...@ma...
Department of Mathematics       "This signature needs no quote."