On Tue, Jun 15, 2010 at 2:50 PM, Mossman, Paul (Paul)
<[email protected]> wrote:
> Does that make sense?
i think so.  settings will be organized by how they should be
displayed to the user, not how they are stored in the configuration
files and be injected with generalized settings.  velocity will own
the burden of navigating the settings hierarchy and
ignoring/translating generalized  settings that may or may not apply
to the configuration file.

Couple points

1.) if you'd like to make improvements to how settings are displayed,
you'll have to maintain db patches to translate one setting path to
another.  For example if you move  /phone/audio/handset/volume to
/phone/audio/volume/handset so it displays in a "better" spot, all
existing values will need to change their path stored in the database.
 The good thing about the organizing settings based on configuration
files was that it was a canonical path.

2.) I still think that generalized settings and therefore generalized
UI should handled through generalized tapestry pages and each vendor
supplies an interface/class to support that UI.  How Intercom works
with PolycomIntercomDefaults.java and Lines work with
PolycomLineDefaults.java and Phonebooks work with
DirectoryConfiguration.java.  Then phones can not only translate from
it's settings to generalized settings, but can also implement java
code for specialized handling.  For example, determining the default
value based on live system settings.

3.) Improvements to overall settings can be achieved with an interface
where an admin can search settings by their label, description and/or
current value.  Exactly how eclipse let's you find settings, you
almost don't care how eclipse organizes them.

i know we're beating this to death, but i think it's important and so
i appreciate you filling me in.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to