Alberto wrote: > Damian Krzeminski ha scritto: >> What do you think about following the way it used to work for older >> versions of the plugin? As far as I remember the profileName for SNOM >> settings can have (optional) suffix that you write about. No matter what >> method you chose to generate new profiles (velocity, jdom, something >> else) >> it should not be that complicated to strip the suffix (if present) >> and use >> its value to add desired SNOM XML attribute. >> > Ok now I have the right picture. The v6 Snom plugin was writing all > fields as read only except those with a sub element profileName that > appended the $ char to the name attribute. An example: > <setting name="contrast"> > <profileName>contrast$</profileName> > > $ mean read write. This is not ideal in my opinion. The trouble is > sipxconfig is writing may empty parameters that will be read-only in the > user interface. Examples: I configure with sipxconfig one sip identity > and all 11/12 empty lines are read only from the web interface.
You can use this convention or come with some other convention. > > The best solution I imagine is to have a configurable drop down list for > each snom parameter setting the parameter as Read only and Read/write in > the user interface. I'm not sure but I bet this mean duplicate all > parameters in the plug-in. I do not really think that asking admin to decide which parameters should be configurable by the user is the best way to go. You as a plug-in author should be able to make this decision. If there are couple of for which you think it's important to let admin decide it you can add some extra settings that would flip it. Most phones actually do not sipXconfig to express which parameters should be user configurable on the phone. That's why we do not really have a framework support for that. But it's not difficult to add it at some point if people think it's really needed. As I said: I remain sceptical - it looks to me like pushing one more problem to administrator. If it was up to me I would actually hide 80% of parameters that each phone provides. I cannot believe that they are all needed. Maybe we just need "minimal"/"normal"/"advanced" switch in UI with minimal displaying only a small subset of parameters that are really useful. > > Another possible solution is to have a single parameter setting the > permission for each group. I would say: add it only for the groups for which it makes sense... > > Last I imagine is to leave the the read/write exceptions in phone.xml. > In this case is there any better way to characterize the permission > field of a parameter? Doing something like the following is legal? > <setting name="contrast"> > <permission>RW</permission> > </setting> You can store whatever you want in profileName. That value is used only by profile generation and its content is entirely up to you as a plug-in developer. I do not think that there is a need to add permission to settings until we have some framework support for it. As long as it's just one plug-in you need to stay in <profileName/>. > > I tried to have a look in the phone.xml dtd but seems to be a broken link: > http://www.sipfoundry.org/sipXconfig/dtd/setting_2_0.dtd It used to work... Scott: is there any safer place to host DTDs - I am pretty much giving up on www.sipfoundry.org at this point. Alberto: configure your XML editor to get DTD from you local disk. I know you can do this for Eclipse in XML Catalog properties. The DTD is in neoconf/etc. >> I you are unsure on how to do that, I or some other sipXconfig >> contibutor >> can help you once we see some code. >> D. >> >> > Very unsure ... but I'm sure I will work it out. I'd love to have some > references of Velocity syntax and how to handle objects in phone.xml and > line.xml. Attached a patch with the work done so far. Did not have a > look at junit test yet. > Actually my major trouble is I yum upgraded my test system and > sipxconfig is not working anymore. I'll send another specific message soon. > Thanks for the patch. If no-one else gets to it I'll review it once my 4.0 queue gets shorter :-) Velocity syntax reference is here: http://velocity.apache.org/engine/devel/vtl-reference-guide.html _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
