I know ActiveAdmin looks at your models to pull in information into its dashboard. I'm wondering if ActiveAdmin can be configured to pull in API Endpoints? For instance I'd like to have one instance of ActiveAdmin running and I'd like to feed it multiple Project endpoints that have different schemas.
This is to prevent having to have an ActiveAdmin instance running for every Rails app we build.
Thoughts? Do I need to provide more information?
ActiveAdmin relies heavily on information ActiveRecord and the database provide, which is how it's able to dynamically build your tables and forms. It isn't designed to plug into APIs like you're talking about. Best bet is to just include the gem and build the panels for the stuff you need within your Rails app.
Related
We are looking to use KeystoneJS in a large project and we want to be able to customise the Admin panel. There's a nice example of how to do it here, and I've been reviewing this PR to the project. Although the example looks as if it would work for us, I don't understand the logic behind it, that is, what we would need to implement to make it work, what the possibilities and constraints are.
Is it the case that when you use the Keystone NextJS app (which is good for us), if you add a folder /admin/pages the Keystone app will look there and use those custom admin pages instead of the regular ones? I'm assuming we have full access to the rest of the app, the controllers, the DB from these pages as well....
I also noticed that JedWatson notes in https://github.com/keystonejs/keystone/pull/1019 that
Note this lacks SSR support, and I didn't put as much effort into the examples, but it's otherwise (I think) identical in functionality.
Does it lack SSR support just for the admin part, or does adding custom admin pages somehow affect SSR support in the rest of the app? (SSR is the reason we're using next)
Thanks for any info.
There are two api for custom pages, one is pages option in the admin-ui app constructor and 2nd is part of hooks api in keystone constructor.
pages: this one is legacy and only adds custom pages, it does not overwrite the existing list pages in admin-ui it only hides them if not properly configured. usually the Dashboard is visible and all lists are listed there.
hooks: this is new and expected to add more customization options, unfortunately my PRs are stale and they are not the spec keystone core team would want to add. this also does not removes any pages.
admin ui runs as react app built or loaded using webpack config. that is why there is no ssr support. even though the example use a custom admin directory but that not loaded by nextjs component, it is loaded dynamically using webpack server mounting the admin-ui react app
if you really want to have ssr, you can use some learning from closed PRs which were used as POC long ago. but that would be overkill as the admin-ui has many more updates after that.
hooks/pages have access to core limited set of access, there are some access based on React context, provider and consumer hooks. You can use react-apollo hooks as there is already provider wrapped at root of react context. you can also make use of react router hooks, they are upgraded to latest version. it has no access to server side context or controller. (not sure what you meant by controller)
i want to make Content Management System that can run on nodejs code.help me out in this project .I know that cms is written in php but i want to add the functionalities with the help of nodejs or expressjs.help me in connecting the cms application with nodejs .
CMS is a type of application, and is not uniquely written in PHP. Developing the entire content management system is a large project with many moving parts. To get a sense for how involving it is, you can take a look at this example project where somebody walks you through one particular way of implementing a content management system in NodeJS. However, your implementation will vary depending on your goals of the CMS you are looking to develop.
I created a simple web site using WIX platform. (https://www.wix.com/). I have some simple forms. Like customer registration and package management. All the UI part is done. And I have a Node.JS server to manage customers and packages. API is 100% done.
Now I need to connect WIX template with my NOde.JS REST API. Is there any possible ways to do this ?
My Node Server is deployed on a Ubuntu server and I can access it anywhere.
Please help me on this.
Yes, now Wix has this thing called Wix Code platform, which enables you to dynamically control your UI components and bind it to data coming from the outside.
To answer your question, they have this fetch API which you can use to write code to fetch your own server and get the data from it. Here is a link Wix Code API - fetch
Anyway, this is their site, Wix Code, you may learn a lot more there. Also they have those tutorials and examples of many "how to..." and examples Wix Code Tutorials and Videos
Cheers!
I want to build a website using the MEAN stack and my database schema will be defined using Mongoose. This website will have an admin site, in which I will have all the CRUD operations for the data displayed by the frontend website. As the object model will be the same, if I'm using Java or C# I would compile this classes in a Jar or Dll and use it in my frontend site, along with the DB definitions and repositories (say hibernate)
What will be a recommended approach for reuse this object model in this MEAN scenario? Is it common to have another "folder" in my express setup? What if I want to run the admin site on another port?
I see you have no response yet, one example; Here is a nice scaffold that im working with which uses also JS, not C or Java and is a fairly good example of what your looking for i think. This will help you expedite, expand and go in which direction you want from there, by being a very adjustable MEAN stack scaffold using MOngoose, having CRUD examples, and even Bootstrap Jade SASS front end to help facilitate if you want to use it.
You would separate out your admin site as one of the MVC sections, and so forth, just like you would on any other MVC site pretty much, you can just follow the code standards in the documentation there.
Is it be possible to customize/extend JHipster for an organization ?
By that, I mean having a local version that creates some projects with features that are specific to an organization ? For example, using a custom authentication scheme (that still relies on Spring security), using custom styles (colors, fonts), adding certain Maven dependencies and so on.
If this is possible, can it be done while retaining the possibility to update JHipster in such a way that an update of JHipster would not overwrite these extensions ?
Thanks.
Here's the approach in general:
First, we created a blank project with all standard JHipster
stack. DBMS used is Postgres. We outlined the basic data structure
with jhipster entity generation tool, creating the most important
relations etc. We also defined the basic user roles and permissions
within standard JHipster options. At this phase we didn't pay very
much attention to the details such as complex unique constraints,
business restrictions, user management, JPA errors handling and
presentation etc. Just created a sort of backbone to start with.
CRUD pages are all standart.
We introduced some domain-specific business logic. Basic frontend customization was performed: branding,
styles, some custom views (still used bootstrap classes extensively) etc. Jhipster-generated frame was kept in place but extended. We changed authorization logic a little bit on both backend
and frontend, it's token-based with certain token validation
rules. User-friendly error handling was introduced, allowing user to
understand what business restrictions show up in various conditions. We started to write more complex unit tests to meet the business logic implemented recently. Entities are mostly (~80%) crafted manually at this stage, because we got used to the data structure offered by JHipster, and we had too much customization in CRUD REST controllers, pages and tests covering all that. Liquibase changelogs were generated with liquibase:diff and edited manually. We don't add such entities to .jhipster folder.
Because of demands for interface design growing high and strict, it was decided to introduce separate frontend layer for end-user interaction. It partially shares REST interfaces with jhipster-generated frontend, but is absolutely independent in terms of project structure. We decided to use Angular for new frontend layer as well. In fact, it is a subfolder with separate index.html, bower.json, Gruntfile.js etc. At the same time we continued to improve business logic, refine db structure, increase code coverage, introduce new user roles etc.
...
So we have slightly customized "old" JHipster frontend for administration and data mangement purposes. And an independent "new" frontend with custom design to deal with end users. Please note: it IS possible to keep an original interface, customize it to some limit and preserve the possibility to generate entities, and it worked well in our project as far as it was justified.
Some notes:
Component versions in pom.xml were constantly updated by hand;
Maven dependencies were manually added to pom.xml;
JS dependencies were manually added to index.html/bower.json/app.js;
If you have complex frontend scripting, dealing with JS uglification for production profile may be tricky;
Another difficult thing is to keep liquibase scripts working for both DBMS used by spring-boot and H2 which is used for tests;
You'll probably face some problems with configuration tuning depending on domain logic specific for your project.
I hope it helps.
Another approach that has been introduced in release 2.26.0 (mid december 2015) is to build your own modules, see documentation.
Later on in release 5.0.0 (mid 2018), JHipster has introduced a more powerful tool: blueprints, although it requires more effort than creating a module. With a blueprint, you can even replace the language/framework of the generated project, it has been successfully used for Kotlin, NodeJS and VueJS.