Replies: 3 comments 3 replies
-
Let me know what you think. The tldr is-- I want to have all the parsing be handled by something like a |
Beta Was this translation helpful? Give feedback.
-
Hey @dwreeves , thanks for taking the time and thinking about these. You touched on a few points, here are my quick thoughts:
Yes, that's correct. I've sometimes mixed and matched columns, attributes and properties, and I've tried to improve on that, but it's still not very clear. Some part of that is from the SQLAlchemy I think which doesn't make this clear. Definitely worth improving. But about prefixing form fields and attributes, honestly I think that's an overkill right now, because in the context of this libraries field is always part of the form and SQLAlchemy won't use that, and column/attribute/property is part of the SQLAlchemy model. What do you think?
Actually this part in both SQLAdmin and Flask-Admin is heavily forked from WTForms-SQLAlchemy and I haven't really got a chance to improve on that. It's not really readable or even modern python because they have to support a wider range of Python. Definitely this can be improved.
This one is the most serious one and I'm really hesitant because it's a much larger effort. I'd suggest we can start by baby steps and revise this along the way. We can maybe create separate issues for whatever we agree to improve and work on them separately. Does that make sense? Again, thanks a lot for taking the time and contributing to the project. It's very much appreciated. |
Beta Was this translation helpful? Give feedback.
-
Hey @aminalaee, do you have any intentions on looking into #116? I want to continue working on sqladmin while I have time (I won't be unemployed forever!), and #116 is blocking other steps. |
Beta Was this translation helpful? Give feedback.
-
I've been playing around with the idea that it would be much easier to rework the internals to achieve a few objectives:
Define terms clearly
SQLAlchemy seems to be inconsistent, or at least confusing, on what it refers to as "properties" versus "attributes". Simple example below:
The output of the above code is:
Even though the mapping
sqla_inspect(Boathouse).attrs
seems to imply the mapped objects are "attributes," it ends up returning "properties" instead, and theis_attribute
/is_property
attributes make that clear.I propose that
Union[str, InstrumentedAttribute]
should always refer to an "attr
", and thatUnion[ColumnProperty, RelationshipProperty]
should always refer to a "prop
".Right now this is not entirely the case. The most clear example is that
ModelAdmin.get_model_attr()
returns a property, so it should be renamed toget_model_prop()
.Additionally, this library uses a lot of powerful OOP libraries that have potentially overlapping concepts. We can improve readability (most notably in contexts where things are being mixed and matched) by prefixing SQLAlchemy variables with
sqla_*
, and prefixing WTForms variables withwtf_*
. So instead of "model", it's asqla_model
; instead of a field, it's awtf_field
.Clear converter function signatures
I pulled the design pattern from Flask-Admin, and added my own typing:
Again on naming consistency: the "converter" should be the object typed as
ModelConverterBase
. The methods are not converters, they are converter callbacks.This also means, by the way, that the method
ModelConverterBase.get_converter()
should be renamed toModelConverterBase.get_converter_callback()
."The function signature is more limited-- How do I do X?" Here is an example of why, for example, the
column: Column
input is not needed. Here is a refactor of the converter callback forEnum
types:In this case, access to the column is done through
prop.columns[0]
.ModelConverterBase.convert()
does too much.This method not only converts the type, it also adds kwargs that can be processed upstream.
The convert method should be simple, and kwargs should be handled upstream of convert. The only code below that wasn't implemented is
get_callback()
. Everything else is unabridged.Handle all parsing by iterating over
List
s ofAdminAttribute
s.I think instead of working directly with SQLA objects and WTF objects, these should be given an extra layer of abstraction that relates them to the admin panel object. These should be called
AdminAttribute
s. This class addresses a lot of the aforementioned problems by creating a common interface to do various tasks:dict
s by the Flask-Admin API, but they should be all placed in a single object).wtforms.Field
kwargs can be handled inAdminAttribute
.AdminAttribute
In this context, the main parsing challenge just becomes turning a SQLAlchemy model's fields into
AdminAttribute
s as defined by theModelAdmin
's classvars. (But that is easy.)Here is the code I have so far for
AdminAttribute
s:And here is the code I have for parsing
ModelAdmin
classvars intoList[AdminAttribute]
s:Beta Was this translation helpful? Give feedback.
All reactions