[dev] webroot paths in horde/config/registry.php

Apis Hytt php3dev@carousel.tabcat.com
Sun, 21 Jan 2001 15:51:41 -0600 (CST)



On Sun, 21 Jan 2001, Chuck Hagenbuch wrote:

> >APIS 	Some single, central path rubric would be very handy.
> 
> I'm thinking on it.
> 
Apis+
	How about a horde paths_base_repository that contains the paths
for module-root|lib|graphics|templates etc for each module?

Each separate module could access that central array and could locate
path(s) for what it wanted from horde or another module for that matter?
Registry is heading in that direction now .. maybe it becomes the
exclusive paths_base_repository for all modules, located now in the
base.php each module has in own lib.

	Currently paths are contained in each module; and, as horde
grew, this is causing shared access the modules need from each other
to be difficult to find needed path(s).

	  I would like to see horde as a sort of invisible *master* for
common libs and path configs for the other modules. With this central
paths array, an easier install could allow those who want to move
certain directories out from under the server's htdocs directory for
security protection to be easy.  Relative paths now make that hard.

	 The central paths_base in horde would also allow one to move
modules and sub-directories where one wanted them at any moment.

	 This central scheme would allow one to re-config the
central path(s) to  bring in a module customized or test sub-directory by
just changing one thing or another in the central path's repository.

	CSS scheme now appends a module's CSS to horde's CSS .. perhaps a
similar notion for appending each module's base.php to the master 
horde_paths_repository could work?

Allow each module to find the horde registry as it needs.  Allow horde
registry to append to it each module's base paths ala CSS scheme.  That
could allow each module to have their base in their own lib/base.php, but
horde registry could find and append local module base paths to make a
shared central paths repository available to all modules for subsequent
access from the completed registry at horde startup.

	This also would allow new notions needed by all modules to have
a place to be located .. in the invisible, master horde itself.
Again, this is already happening as commonality is being moved to horde.

	o *Extra*Notion*:

	It also would be handy to have a  place to configure
which modules would appear in the horde bottom module navbar.  Ideally, we
would make groups to enable combinations of different allowed
modules to appear in the navbar. Thus, in prefs, we could specify what
group of enabled modules in the defined menu grouping config a particular
user would be allowed to see and use.
  
	o Perhaps a similar scheme for each module could group and
restrict what module's topbar menu items would be available for
each group of users of a particular module, again defined in a menu
group pref for that module.

Apis-
NNNN