restarone / violet_rails

an app engine for your business. Seamlessly implement business logic with a powerful API. Out of the box CMS, blog, forum and email functionality. Developer friendly & easily extendable for your next SaaS/XaaS project. Built with Rails 6, Devise, Sidekiq & PostgreSQL
https://violet.restarone.solutions
MIT License
96 stars 43 forks source link

ability to define form placements for API Namespace #1512

Open donrestarone opened 1 year ago

donrestarone commented 1 year ago

Is your feature request related to a problem? Please describe.

Violet Rails allows you to define your app's Domain Entities through API Namespace. For example, if you were building an app to track songs, you would have an API Namespace to store song data. In the example below we have an API Namespace for Songs that allow us to store songs along with their title and artist (song attributes)

Screen Shot 2023-04-04 at 12 18 12 PM

Continuing the example of the song app, Violet will let you manage your data model via API Resources:

Screen Shot 2023-04-04 at 12 18 22 PM

If you want to create songs (using Web Forms), you have the ability to customize the form representation for the API Namespace (in this case, Songs):

Screen Shot 2023-04-04 at 12 19 14 PM

Each of the attributes in the API Namespace, you are able to customize the form field type and control if its shown to the user or not

Screen Shot 2023-04-04 at 12 19 54 PM

The problem

Currently the only way to customize different form placements (eg: a placement for Admins, Users and Visitors that show a different form for each demographic) is to do it via Javascript.

Describe the solution you'd like

We want to be able to define multiple form placements (like we have for multiple renderer snippets: https://github.com/restarone/violet_rails/releases/tag/0.9.65). For example, one such placements for the song app example above, would be to only show title as an option for when asking for song suggestions by website visitors.

The implementation should allow for Form placements:

  1. to enforce current_user authentication
  2. to be defined in any number and be associated to an API Namespace
  3. to be customizable on a per placement basis (defined order of form field attributes)
  4. that does not break existing forms on sites (backwards compatible with the snippet API)

UI spec

The Rendering Tab needs to be re-arranged. Numerically, there are only 2 types of entities in this pane (API Renderer or API Form). So there needs to be a sub-view defined here with tabs for API Renderer and API Form that then expand on the details.

Screen Shot 2023-04-04 at 12 34 24 PM
donrestarone commented 1 year ago

this feature gap affects https://nikean.org forms