John Crisp
2018-01-24 13:31:48 UTC
Well, I have had a reasonable play with stuff and can see some ways
forward but would like some input.
I have also had a look at the fundamentals of what Stefano was doing and
generally understand that.
Both Stefano and I went at the problem from different angles but we both
found one problem in common, and that is how data is queried and
returned to the calling application.
The roadblock I have hit, which Stefano also found, was a lack of a
generic API.
Yes, we have the underlying esmith libraries eg configDB, accountsDB,
networkDB but if you want to query them you need some perl to do so.
Ideally we should be able to query the server and get back either some
html or say JSON to be able to display the manager. More separation
between the visual front end and the server backend.
Having had a good look through it struck me that the answer was kind of
in front of me.
Currently we have this kind of approach:
Directories - I'll refer to them as functions and vendor_perl:
/etc/e-smith/web/functions (this should really be called 'templates IMHO)
/usr/share/perl5/vendor_perl/esmith/FormMagick/Panel
So we get:
web browser <-> functions <-> vendor_perl
For example:
functions/useraccounts queries vendor_perl....useraccounts
Now useraccounts holds lots of nice little routines - create_user,
modify_user etc etc. Cool. Except.......
Rather than just being a set of functions, it also has a pile of
embedded FormMagick template stuff. So the routines are unusable as they
are.
It returns an answer, with some FormMagick back to the 'function' file,
which also has a load more FM stuff. There is no separation of code and
content.
However, as a way forward we have a much better example in the WBL contrib.
The vendor_perl file is pretty well JUST code, and the 'function' file
is pretty well JUST a FM template. It would probably be fairly easy to
remove the FM from the vendor_perl file and create a new Mojo based
'function' file.
Still with me ?
So what can we do ?
My suggestion would be to do the following:
1. Put all the current SM related files in one rpm - currently it is in
at least 2. It can then be removed if required without breaking anything.
2. A new directory structure for a new SM run from a new virtual host so
we can build and test
3. Copy the vendor_perl files into a new dir and strip the FM code from
them to make them pure code/function files. Some will be easier than
others but the core stuff has about 20 odd files to rework. With a
separate SM system we can run the two together if needs be (at least on
a test box)
4. Create some new 'function' files using Mojo - to be really clever we
can probably set some form of switch so they can output either html to
be rendered by say bootstrap/jquery as per my demo OR JSON that can be
read my any other type of system/frontend
Now, this is all very simplistic as I don't do complicated.
Here's another question. We can use either Mojolicious or Mojolicious::Lite
The difference as far as I can see is that Mojo full fat uses an entire
directory structure with separated code and templates whereas Mojo Lite
embeds the template in to the perl file.
You can check this for yourself like this:
Make a temp dir someplace. Then:
mojo generate lite_app LiteManager
mojo generate app FullManager
See the difference.
To date I have been using the Lite version. I'd suggest the full fat
version is better with separated templates.
If we are smart I think then you should be able to do something like
https://your.server/servermanager/useraccounts
(called from the SM panel) Displays useraccount page as normal
https://your.server/servermanager/useraccounts?get_user&username=joe
Returns a JSON encoded string of the information
Your API basically becomes all the functions that are in the vendor_perl
files. No knowledge of perl required at that point unless you want to
add a new API function.
If you want to shift platform them someone rewrites
events/actions/libraries but the API calls stay the same.
Now, I can do a bit of this, but anything related to security is way out
of my depth, be that configuring a virtual host, login panels etc
I might be able to rework some of the panels, but certainly not all - my
coding skills are nowhere near good enough.
I may try and hack the WBL files to see if what I am proposing actually
works, but I am pretty sure it would.
I'm quite happy to do some of the lifting on this, but will need some
help in the first instance.
If I am completely wrong or barking up the wrong tree then put me out of
my misery immediately. If the approach seems reasonable then is anyone
going to help or am I just wasting my time?
Tin Hat at the ready.....
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/
forward but would like some input.
I have also had a look at the fundamentals of what Stefano was doing and
generally understand that.
Both Stefano and I went at the problem from different angles but we both
found one problem in common, and that is how data is queried and
returned to the calling application.
The roadblock I have hit, which Stefano also found, was a lack of a
generic API.
Yes, we have the underlying esmith libraries eg configDB, accountsDB,
networkDB but if you want to query them you need some perl to do so.
Ideally we should be able to query the server and get back either some
html or say JSON to be able to display the manager. More separation
between the visual front end and the server backend.
Having had a good look through it struck me that the answer was kind of
in front of me.
Currently we have this kind of approach:
Directories - I'll refer to them as functions and vendor_perl:
/etc/e-smith/web/functions (this should really be called 'templates IMHO)
/usr/share/perl5/vendor_perl/esmith/FormMagick/Panel
So we get:
web browser <-> functions <-> vendor_perl
For example:
functions/useraccounts queries vendor_perl....useraccounts
Now useraccounts holds lots of nice little routines - create_user,
modify_user etc etc. Cool. Except.......
Rather than just being a set of functions, it also has a pile of
embedded FormMagick template stuff. So the routines are unusable as they
are.
It returns an answer, with some FormMagick back to the 'function' file,
which also has a load more FM stuff. There is no separation of code and
content.
However, as a way forward we have a much better example in the WBL contrib.
The vendor_perl file is pretty well JUST code, and the 'function' file
is pretty well JUST a FM template. It would probably be fairly easy to
remove the FM from the vendor_perl file and create a new Mojo based
'function' file.
Still with me ?
So what can we do ?
My suggestion would be to do the following:
1. Put all the current SM related files in one rpm - currently it is in
at least 2. It can then be removed if required without breaking anything.
2. A new directory structure for a new SM run from a new virtual host so
we can build and test
3. Copy the vendor_perl files into a new dir and strip the FM code from
them to make them pure code/function files. Some will be easier than
others but the core stuff has about 20 odd files to rework. With a
separate SM system we can run the two together if needs be (at least on
a test box)
4. Create some new 'function' files using Mojo - to be really clever we
can probably set some form of switch so they can output either html to
be rendered by say bootstrap/jquery as per my demo OR JSON that can be
read my any other type of system/frontend
Now, this is all very simplistic as I don't do complicated.
Here's another question. We can use either Mojolicious or Mojolicious::Lite
The difference as far as I can see is that Mojo full fat uses an entire
directory structure with separated code and templates whereas Mojo Lite
embeds the template in to the perl file.
You can check this for yourself like this:
Make a temp dir someplace. Then:
mojo generate lite_app LiteManager
mojo generate app FullManager
See the difference.
To date I have been using the Lite version. I'd suggest the full fat
version is better with separated templates.
If we are smart I think then you should be able to do something like
https://your.server/servermanager/useraccounts
(called from the SM panel) Displays useraccount page as normal
https://your.server/servermanager/useraccounts?get_user&username=joe
Returns a JSON encoded string of the information
Your API basically becomes all the functions that are in the vendor_perl
files. No knowledge of perl required at that point unless you want to
add a new API function.
If you want to shift platform them someone rewrites
events/actions/libraries but the API calls stay the same.
Now, I can do a bit of this, but anything related to security is way out
of my depth, be that configuring a virtual host, login panels etc
I might be able to rework some of the panels, but certainly not all - my
coding skills are nowhere near good enough.
I may try and hack the WBL files to see if what I am proposing actually
works, but I am pretty sure it would.
I'm quite happy to do some of the lifting on this, but will need some
help in the first instance.
If I am completely wrong or barking up the wrong tree then put me out of
my misery immediately. If the approach seems reasonable then is anyone
going to help or am I just wasting my time?
Tin Hat at the ready.....
_______________________________________________
Server Development Discussion
To unsubscribe, e-mail devinfo-***@lists.contribs.org
Searchable archive at https://lists.contribs.org/mailman/public/devinfo/