George wrote: > --- On Wed, 6/9/10, Douglas Hubler <[email protected]> wrote: > > I have a simple question to help me > > understand this a little more > > > > If I have a phone object called "p" that represents a polycom 430 > > model, and I call > > > > Setting s = p.getSettings(); > > > > Will s (and it's children) contain any settings that are > not found in > > > > sipXconfig/plugins/polycom/etc/polycom/phone.xml > > > > under your new scheme? > > Per my understanding: no, s will retrieve all setting from > phone.xml file (which is composed at build time by merging > general.xml and phone-model.xml).
I see the concern behind Douglas' question. A number of existing plug-ins have a direct UI layout to config file mapping. Their velocity templates contain for loops to iterate over screens and sections when generating the config files. My thought was that plug-ins who cannot make use of a "general" setting would simply layer a "hidden" directive over it, thereby suppressing it from the UI. But a velocity template looping through a section would see the "hidden" setting, and generate a corrupt configuration file... > > Does the same go with the lines of said phone object, and > > corresponding /etc/polycom/line.xml file? > > > > Instead, I may find settings that are in a general.xml > file. i will > > also likely find a polycom.xslt file for custom setting > mashing rules > > of the general.xml settings file into the various polycom > files. If i > > don't find a polycom.xslt I may find a general.xslt that does the > > default mashing for me? > > Yes, IMO this should be the case: specific phone xslt file > (polycom.xslt) for generating specific phone settings - if > case (as in Paul's example - a soft client with common SIP > phone functionality, but without Network Settings such as > VLAD ID.), otherwise a general.xslt file that will just merge > general settings with phone model settings in phone.xml. This could alleviate the above concern? General settings that do not apply would simply not appear in phone.xml, as per the directives in polycom.xslt? So will the specific phone xslt file explicitly list the settings to be included, or those to be excluded? Still I have the feeling that the direct UI layout to config file mapping approach for velocity templates aren't going to work well with the new generalized settings. The generalized setting patch will simply not match the specific configuration file directives. I think that's expected though. We are trying to improve the UI layout by freeing it from the config file structure. It makes sense then that re-structured plug-in velocity files won't be able to for loop over the UI layout. (Not to mention the fact that some settings will be hard-coded in the velocity templates.) My suggestion is this. Let's not put any effort into build building framework capabilities and/or specific phone xslt files in order to have velocity files iterate over the elements of the UI layout. -Paul [email protected] _______________________________________________ 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/
