piccolo_admin
piccolo_admin copied to clipboard
add enum support to custom forms
An alternative approach to #434 . It uses Piccolo choices without complex parsing definitions in the Vue frontend.
:warning: Please install the to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
:white_check_mark: All modified and coverable lines are covered by tests.
:white_check_mark: Project coverage is 94.24%. Comparing base (1157c12) to head (3cb1f9a).
:warning: Report is 47 commits behind head on master.
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@ Coverage Diff @@
## master #436 +/- ##
==========================================
+ Coverage 93.42% 94.24% +0.81%
==========================================
Files 5 6 +1
Lines 365 417 +52
==========================================
+ Hits 341 393 +52
Misses 24 24
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
@Skelmis I can't add you as a reviewer, but I'm interested in your thoughts on this approach of using Python enums in custom forms. Thanks in advance.
It looks like a much simpler implementation which I love. I'll try test it out within a week
@Skelmis Great. Thanks
@Skelmis Thank you for your time to try this out.
Do you think it'd be possible to try return Enum items as the relevant enum in this case? Or should users do the enum conversion themselves
Yes, you are right. I think the easiest way, as you say, is for users to do the enum conversion themselves. Something like this
def new_staff_endpoint(request: Request, data: NewStaffModel) -> str:
# data.permissions = Permission(int(data.permissions)) # for int enum
data.permissions = Permission(data.permissions) # for str enum
print(type(data.permissions)) # prints correct type <enum 'Permission'>
return "A new staff member has been successfully created."
Seems reasonable for me. Thoughts @dantownsend ?
Hrmm perhaps just realised we should likely add docs haha. Will see if I find time sometime to try write some up
@Skelmis Yes, you are right, but I don't see the point of writing docs because PR is not reviewed or accepted. We can add a usage example to the docs later, if PR is accepted.
Fair enough
@dantownsend what's your view on this pr? Docs before pr, or pr then docs on approved content?
Either way keen to get this moving, would love this feature
This PR has been marked as stale because it has been open for 30 days with no activity. Are there any blockers, or should this be closed?
@dantownsend what's your view on this pr? Docs before pr, or pr then docs on approved content?
Either way keen to get this moving, would love this feature
@dantownsend waiting on your response to move this PR forward
Sorry for the delay on this. I was torn about which approach to take:
- Should we make our front end understand the refs in the OpenAPI schema.
- Should we add the
extraattributes (like this in this PR).
There was also some discussion about not using OpenAPI schemas any more to drive the front end (because Litestar doesn't allow the extra attributes).
This PR might be the best approach for now though.
This PR has been marked as stale because it has been open for 30 days with no activity. Are there any blockers, or should this be closed?
This PR has been marked as stale because it has been open for 30 days with no activity. Are there any blockers, or should this be closed?
@dantownsend do you have any updates regarding this PR? Is it blocked as a result of technical basis or more so just personal time constraints
This PR has been marked as stale because it has been open for 30 days with no activity. Are there any blockers, or should this be closed?