[whups] new to whups

Eric Rostetter eric.rostetter@physics.utexas.edu
Mon Oct 28 20:36:14 2002

Quoting Gary Weinreb <gweinreb@rocksolidsystems.com>:

> >Create multiple folders under /po/, one for each "function."  So we
> >might have /po/bugs/ and /po/projects/ for example.  Set a preference or
> >configuration item that says which we want (bugs or projects).  Test this
> >in common-header or whatever, and set the locale up to use the correct one.
> >This can be done very similar to themes -- no setting uses /po/, a setting
> >of "bugs" uses /po/bugs/, etc.  I'm thinking that we would want it as a
> >config item though, and not a preference, as that is more logical in most
> >cases.
> Great!  This sounds like a simple solution (usually the best kind...<g>).

Yes, if done as I said it is easy and can be applied to any horde module,
> Would this work for a situation where a user manages "Projects" and "Bugs",
> i.e. uses the Whups framework to work with different contexts of data
> structured the "whups way", say with a Module-level (in whups parlance)
> setting which tells whups that one Module is in the "Bug" context and
> displays a "Bug" interface, but another Module is a "Project" and displays
> a "Project" interface, or is this just unreasonable.

Not unreasonable, but much more difficult.  In my simple solution, you would
either have to have two seperate whups installs, two seperate user logins, 
or let the user switch between the views via preferences.  There would be
no whups per-module setting.

The big benefit of my simple solution is it can apply to any horde module
easily with the exact same code, and only one set of documentation.

Your proposal, while nice for the situation you mention, means re-coding it
for each horde module that wants the functionality, and possibly different
docs/installation/etc for each.  Much more work...

> The thing is, certainly, there are folks who manage Projects, Bugs, and
> People, and could benefit from using the whups framework across a number of
> contexts...

Yes.  But this is more difficult.  The way I'm proposing is easier from a
coding/porting point of view.

I'm not saying your way isn't good or valid.  Just saying mine is easier,
more generic, and more consitent across applications.

Or in other words, I'll volunteer to code my version, but you (or someone
else) would have to code your version :)

> -Gary

Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!