Closed mohaphez closed 2 months ago
Thank you @mohaphez.
I aim to keep Bolt as simple as possible and avoid adding business logic that could complicate the use of such simple forms!
also that is why I added many ways to provide your own custom structures for the form or sections or fields.
for the machine_name
you can depend on the html id filed
, which is how I use it when sending the form responses to an API.
by: table lists
you mean the responses report, right?
so I don't think the enduser should control what to show on the table or not, maybe in your case you're (the developer) is the end user :) , but some time users make mistakes and complain about why they don't see the field in the report :)
check the class: ManageResponses:79
we can disable some fields that doesn't makes sense to display them like the file upload since you can't filter or search in this fields response. (its just a URL)
the other option available is that all table column have: toggleable
, so the user can control what to see and what to hide.
one of the form I see on a client app is only one filed which is a textarea
to collect feedbacks from their users, so a table view will be very helpful in this case!
let me know, if this sounds good and what else I can provide for more customizations. thank you.
Thank you @atmonshi for your detailed explanations.
Yes, you can use htmlId
as the machine_name
, but since it's stored inside JSON, it's not ideal for querying, which was the primary purpose I mentioned earlier.
To give a brief example, the machine_name
is typically used for building APIs or something like this. However, I agree that not everyone may need this feature.
Regarding the column display option, you're right. But when the number of fields increases beyond 5 or 6, the table's width expands, making it messy—especially for fields like textarea
and richeditor
. Relying on toggleable options to filter this can be inconvenient, as many panel users tend to overlook them.
Overall, thank you again for your attention. These are just suggestions, and if you feel they add unnecessary complexity, we can certainly pass on them. I brought this up because I thought these features might be useful to others as they have been for our systems.
Thanks (^_^)
thank you for understanding.
I may look into making the column display option configurable from the config file or via BoltPlugin
on the panels.
base on experience trust me you can truest the users and let them decide :) so its up to the devs to decide if a field type will be hidden on the table or not.
will play around soon, and try to find a good API for it.
there is also an idea I had to let devs customize the built in fields and make any needed changes, but planing to do that after v4.
as for the machine_name
I think Custom Schema for fields is the best to do it.
closing for now, feel free to reopen if you needed anything :)
Could we introduce a
machine_name
field alongside the existingName
field? This would be particularly useful for custom queries in services. UnlikeName
, themachine_name
wouldn’t depend on languages and could follow a specific format, such as snake_case without spaces. This makes it easier to work with in code and when writing queries.Additionally, I suggest adding another field to control whether a field's value should be displayed in table lists. This would help keep the table view clean by showing only important fields while skipping fields like text areas, which can have long text that clutters the table.
In my custom schema design (as shown in the attached image), I’ve implemented this feature. We could add a similar option to the package. If you agree, would you prefer adding this as a field directly (like in the example), or would it be better placed in a settings section?
In my implementation, I added a
list_visibility
column to the fields, which is a boolean type to toggle visibility.Let me know your thoughts on this suggestion.