yes, you can't take a template out, that is in sqlCVS. Reason is: The exporter looks for the psc_mod date. If it is 0 it does not get exported.

The reason behind the exporter is, that you can save your own av device templates, and don't have to relearn your remotes due to a needed reinstall of lmce. Also, it allows for people to exchange the av device profiles with each other.

I also tried template exporter (thanks for effort), but for me it doesn't work cause my templates were contributed through sqlcvs. Was it meant to do so ?

In my case I have several templates I've contributed to older Mantis system and since it's unclear what will happen with those contributions, I would like now to backup them into sql files but it seems that Exporter as it is won't do this?

posde,Thanks for making this available. This script seems like an excellent stopgap solution to sharing device templates until the sqlCVS method is working better.

There seems to be a bug in the script. If you export, then import a device template, all words in the ruby code beginning with $ are deleted. Unfortunately ruby uses lots of $ characters so this causes a lot of corruption.

I took a closer look at DeviceTemplate2php.php. PHP evaluates variables ($words) and escape characters (i.e. \r \n) in strings automatically whenever it sees them in "double quotes". In single quotes on the other hand, PHP does not evaluate them.

How $words and /n, /r, etc are interpreted in nested mixed single and double quotes are interpreted by PHP is extremely hard to figure out. I'm not even sure that interpretation of nested quotes in PHP is clearly defined. In any case, when you have PHP code, sql statements, and ruby code all supposedly delimited by the same quotes that are included in the PHP code, sql statements, and ruby code it quickly turns into madness.

Maybe someone who is expert at PHP, sql, and ruby could unravel this script to make it work. I think, however, the simplest solution is to rewrite the same script using a different language. A language that has good sql support and string interpretation rules that lend themself to this sort of thing is key.

I also think that if it is rewritten, the usage ought to be more like this:

If I can find the time I might undertake this myself. I think it is important to be able to share device templates. I think there might also be a role for import/export of device templates even when sqlCVS is working well -- device templates ought to be tested on a variety of installations before they are permanently committed to the code base.

I was asked to hack away at this script and this is what I came up with.It now has a web user interface and prompts to save/load template files to the user's local drive. Encapsulation of the data is now done using php's serialize function which should prevent it from attempting to resolve any php tokens in the data.I do not have a system to test out the import on so the best I have done for testing on that part is look over the generated sql queries. I would appreciate it if those with test systems could install it and test out a few different templates, particularly the ones giving problems above.The file is in the trac ticket at http://svn.linuxmce.org/trac.cgi/ticket/208

I was asked to hack away at this script and this is what I came up with.It now has a web user interface and prompts to save/load template files to the user's local drive. Encapsulation of the data is now done using php's serialize function which should prevent it from attempting to resolve any php tokens in the data.

merkur2k,That sounds great.

Quote

I do not have a system to test out the import on so the best I have done for testing on that part is look over the generated sql queries. I would appreciate it if those with test systems could install it and test out a few different templates, particularly the ones giving problems above.

When I ran the output of the original script, it would generate a new copy (with the aforementioned problems of course) of the output device template. The point is that you should be able to test the import by running the script on the same machine where the export took place -- it should generate an identical device template with a different device template id.

I just used it to import some stuff into my new setup that I had before reinstalling the core and ran into some problems. Yeah the idea is to have it recreate the old device as a new one, but I see now that its going to need a bit more logic so that it knows to duplicate related data as well (if they havent changed then it doesnt export them, hence they dont get created in the import). Also screwed up the query generation, the field names shouldnt be quoted. Ill get an updated version out tomorrow probably.