Adapting to an "app" level environment
Created 7 years ago by failcookieI have a client that is looking to transform their intranet from a custom ASP.NET build to a proper CMS build. They have a few pages on their site, but most of their content is just basic stuff like an Employee Directory, list of current projects, company news, etc. Pyro would be a good fit for all of this, but I was exploring two different areas in particular.
1.) They are wanting to push information from their intranet to a mobile app that we will be releasing at a later date. It will mostly be grabbing stuff from the CMS database and showing it on a mobile-spefic setup. I have worked with API development in Laravel, but I haven't explored doing that with Pyro. Is it really difficult to grab the information I need stored in the CMS and send it out in an organized REST GET? An example would be the app querying a URL for All Projects and returning all of the projects with their title, project description and location of the project. In Laravel, I would just query the fields in the model and display it. I would assume I would probably need to setup the model for each module to handle this?
2.) I will have to create a frontend form for handling a lot of content based on business requirements. Is it difficult to push information to the CMS database in that nature? I would assume not - I am just not familiar enough with the form process in Pyro yet.
Ultimately - it will be a pretty big deal that content can be managed easily and efficiently, which will be a UI challenge over a platform challenge. The rest is just hoping for the best!
Perfect! Always good to have that comfort of "oh crap forgot to consider that".
@failcookie ya the API module basically exposes all streams data / field type / field type presenter layers via a RESTful API based on Laravel's Passport package. Super solid solution I would say.
For the other stuff - I personally would do a couple custom addons. Which are EXTREMELY easy to do if you haven't checked it out there are some videos on the subject. Then you can customize the backend UI super fast to their needs and you're still using Streams so it'll integrate with API module automatically.
Already built a solid Addon - way easier to build than I actually thought it was going to be. I have played around with permissions in the backend a little bit, but not down the custom module level. If I create a Projects module, we will want to make sure only project managers are able to see and edit the content. Is it difficult to add granular permissions across custom modules? I would assume it's mostly just using Authorization from Laravel and feeding that information back to Pyro.
It's insanely easy @failcookie - most of it is automatically guessed for you! For example forms guess the {module}::{stream}.write permission. Tables guess read. Delete table action guesses delete. And you can use the Authorizer utility for everything else you need custom (and sections, buttons, and other UI components accept permission definitions that they will use).
Check this out: https://github.com/anomalylabs/posts-module/blob/master/resources/config/permissions.php Those are automatically tied into UI since they 1.) exist and 2.) match stream slugs / guessed actions.
Custom permissions can be checked with the authorizer: https://github.com/anomalylabs/streams-platform/blob/1.2/src/Support/Authorizer.php
Just a note if your authorizer or a core authorization hook (like the guessed ones I mentioned) check a permission that is not defined then it's automatically true. That's why custom module forms / tables work by default. You've not defined any permissions.
Oooooooh this is so awesome! Man I really appreciate your work and effort on all of this. Even more so for taking the time to lay it out like that. I'll setup some test examples and revisit if I have some more questions!
My pleasure! Let us know if you need any guidance or anything 😊
I don't see any issues with anything you mentioned.
Ryan has an API module you can use https://store.pyrocms.com/api-module.html
You can create any form basically instantly as long as the table is a stream, which, saying you want to use PYRO, they will be.