Ok ,so I spent about an hour on this and can see how the system hangs together, something I never really managed with the current formagick system.
Yes, I understand the fundamentals of mabs code. I'll cover the 'but' in a bit.
It isn't difficult to understand fundamentally how serevr-manager currently works. If I can work it out, anyone can!! It was just never worth investing any further time in it.
Before bandying about what may or may not be a great idea, you really need to get your head round how it DOES work now in the first place.
You can go on your server and look at this easily.
In a perfect world you just have a set of Formmagick template files in:
/etc/e-smith/web/functions
They use functions that are in the files in:
/usr/share/perl5/vendor_perl/esmith/FormMagick/Panel
If you have the wbl package it is a simple and very neat way of demonstrating this.
The file web/function/wbl is a formmagick template that calls some routines in FormMagick/Panel/wbl.pm
So in an ideal you could just rip out the FM template, add a new form of template system and call the original routines. Simples.
However, the issue is that some developers decided to use FM formatting in the pm files, which makes removing FM as a whole more bothersome, but not impossible. Even I can do some of it. It is just some time.
The old adage of separating form from content. The perl routines stay in the pm files, and templating code goes in 'function' files.
I think the general feeling is that the smeserver based on formmagick IS broken and needs a replacement.
No, it isn't that it is broken. It is because FormMagick is way old, unsupported, and not easy to learn and use. It therefore needs replacing.
My personal preference would be something NOT based on perl (ducks behind parapet), but I can see that makes no sense in the context of all the other code in smeserver which IS based on perl and could/should not be replaced on the if not broken don't fix it principle.
I am nor a perl evangelist - I can barely code quite frankly. But it is actually pointless because the whole backend relies on Perl. You would have to rip out the entire SME templating system (which is what it is after all) and rebuild it from the ground up.
HOWEVER, if you read what I have previously said, if we were really smart, I believe we can create new templates (just using Mojolicious as a templating system) which can output code as html, OR as JSON.
And if you can do that, you have the basics of an API, which can then be queried by whatever language you like. And you don't need to know anything about the perl behind it
Think:
server panel <- html -> mojo template <-> perl routine
PHP/python <- API/JSON -> mojo template <-> perl routine
The difference is in the query type.
if (type=html){
sub get_somedata()
output_somehtml
}
if (type=json){
sub (get_somedata($query)
output_somejson
}
/server-manager/wbl?type=json&query=get_dnsblist
Get the idea?
I suspect that whatever system we adopt to replace the current one will require some investment in learning and then some grunt work translating the current panels to the next format.
Yup - there will be an investment of time and effort somewhere.
The method I have suggested, assuming it is correct, will probably be easier and quicker. Especially if someone knowledgeable gave me a hand. So far I had zero assistance beyond answers to a couple of technical questions, despite requests for people to test and help.
If you look at
etc/e-smith/web/panels/manager2/cgi-bin/srvmngr/templates/starterwebsite.html.ep
And compare it with
/etc/e-smith/web/functions/starterwebsite
You might be able to see that the structure is similar although the syntax is quite different.
Well, yes and no.
If you looked at my original templates, you would be able to see exactly the same thing.
But I DIDN'T need an entire new running application to do it. And it is simple enough that *I* can do it.
The system that mab has proposed is clever, but much more complicated. It is effectively a complete application, not just some templating. And possibly overkill. I won't be able to write anything for it as it is way over my head and the point was to try and lower the bar to entry, not raise it.
You have to consider who is going to maintain it, whose is going to convert existing contribs, and who is going to be able to write new ones?
We are not swimming in developers here.........