Xibo Design & Architecture

1

Coming from a mostly ASP.NET MVC background and done some Go, Node.js and Python web, more than sometimes I get lost in Xibo code base. I see that [X].class.php, [X]_view.php and [X].js files. But it would provide a faster going through things in development if a 10`000 feet view were available with a guide on how to plumbing things.

I’ve found some links referring to a developers part in manual but they are dead now. This project is based on 1.3.1 :expressionless: but 1.7.x would be fine too.

Best;

2

The problem is that writing that stuff takes a whole bunch of time - which is why our development documentation is bad (and probably why contributions are low :smiley:)

We are also undergoing a massive switch in architecture for 1.8 series. 1.8 will be PSR compliant and use the Slim Framework.

In any case, the basics are:

  • /lib/pages/xxx - classes responsible for displaying pages, showing forms and responding the form posts. index.php?p=display will get to /lib/pages/display.class.php displayPage method.
  • /lib/data/xxx - sort of models responsible for CRUD
  • /theme/default/html/ - templates
  • /theme/default/js/xibo-cms.js - the main JS file that hooks up all the AJAX forms.
1 Like
3

Thanks!

(IMHO)
Glad to hear you are about to use a framework. Not that using frameworks is a good thing by itself, but using a well designed/well established framework is essential to any greater than average project; and micro-frameworks with a sane design for middle-ware are good to have as company in the tool-belt.

Any estimation about time for first appearance of 1.8 series? (Struggling with current mess in this project is consuming me in a fast-sucking-vampire fashion!).

Thanks Again!

4

It’s a very large body of work. When we get closer to having a pre-release available there will be some timescale.

As it stands, it’s “when it’s ready”

1 Like
5

“When it’s ready” is the best! I look forward to see 1.8.x series.

6

You can see the labours here: https://github.com/dasgarner/xibo-cms/tree/feature/playlists

I avoided using a full framework as I didn’t want to have to rewrite everything; a microframe work provided the flexibility to leave quite a bit of stuff in place.

Basically, anything in lib/data/ will be converted to proper Models, anything in lib/pages/ will become Controllers and for now the View layer will remain slightly messed up with the Controllers calling the Theme engine we already have.

There will be two applications (web and api) which both call the same routes - the controller will be responsible for providing the correct output to the correct application.

Middleware will be used for auth, csrf, storage, state, oauth, etc - the appropriate combination will be included with each app (api gets oauth, web gets sessions, etc).

It also uses a PSR logging wrapper - logging to DB and chrome at present.

Please feel free to make any suggestions :smiley:

1 Like
7

Thanks for this enlightening answer. I’m not the best one to suggest anything on Xibo for certain. But things that had hurt me before comes to mind: It’s nicer to have “any service” injected as a middle-ware. We have a default chain of middle-wares which will be used in absence of route-specific middle-ware. This way one can (for example) exclude the session middle-ware or removes a specific logging middle-ware crafted for being used just in development; if it’s not needed and that can be a huge performance boost - of-course you have mentioned ‘state’ as a middle-ware. That way it would be far easier to convert a middle-ware to a global (infrastructural) service (which preferably would still be injectable) that the other way around.

The second thing is versioning the web api (at least)! A ‘v1/something/val1/val2’ and a ‘v2/something/val1/val2’ helps far greater than occasionally not just in term of effort but also maintenance and handling a pluggable architecture - a versioning scheme should be considered here, a convention.

I’ll try to halt any further development on our current app and put it just in maintenance mode and start a new branch in parallel - I hope I can succeed in that!

Thank you very much!

8

I’ve thought about how to achieve that and honestly, i’m not sure at present. I will give it some more thought though.

Once we have everyt transaction mapped to an API, what i’d really like to do is have an automated test runner for each API call (therefore testing the entire application). The UI wouldn’t be tested, but the core app would.

1 Like
9

Thanks!

Just for the record by ‘v1/something/v1/v2’ I meant ‘ver1/something/val1/val2’.

10

Haha, yeah I got that :smiley:

1 Like