Discussion Stefan Cronje · Dec 15, 2023

CSP Pages versus Classes extending from %CSP.Page

Hi all,

The last time I used CSP was back in 2008, so I am very rusty on it.
This question might have been asked many times, and the answer probably is that it is a matter of preference.

Are there scenarios to which CSP pages is easier/better to use than classes extending from %CSP.Page?
I want to build a little thing and don't want to start at the wrong end.
Doing an API-based, heavy client-side framework is not a requirement, and I would prefer not to do it that way.

Some of the criteria

  • Users need to do a login.
  • RBAC per page using the instance's Users, Roles and Resources
  • Call some server-side methods, natively or with javascript (open to any of the two)
  • Mostly server-side rendered.
  • Most readable code.

I know this is a subjectively opinion based question, but would like some input.

Thank you

Comments

David Hockenbroch · Dec 15, 2023

In my opinion, if you have a page that doesn't necessarily need to have any user interface elements - %CSP.StreamServer is a good example - that's the primary case for extending %CSP.Page. If you need a UI, then a csp page is easier to deal with.

0
Iryna Mykhailova · Dec 26, 2023

I'd agree with @David Hockenbroch - if you have a UI, you will most likely find it easier to work with a csp page like a usual html and all that. But if you don't have a UI (or it's super simple), then you would create a cls file and extend the %CSP.Page.

0
Pierre LaFay · Dec 26, 2023

I am currently developing a REST API backend and I have chosen to systematically use classes, because mixing csp files and classes seems to me to harm the maintainability of the code.
Furthermore in this case, a database backup contains everything, I don't have to worry about separate files.
This is just my opinion :)

0
Stefan Cronje · Jan 11, 2024

I want the class route.

I did a lot of abstraction for the UI, like the page header, sidebar (menu) and footer. Re-usable classes for each of these page sections, as well as being able to create a "template" page to extend from, then let each specific page add its content into it. I also needed security on menu items and resource access control across pages, so abstraction made sense.

I did it a bit like you would with Django templates.

I might post an example of how I did this at some point. I used the Material Dashboard Pro UI framework, so I can't share that specific content due to copyright issues on the CSS and JS included.

0