-
-
If we go the subclass route, it looks like the shared properties would be
- group
- id
- label
- type_hint // If necessary?
- visible
- required
- sensitive
- uidata // presumable being removed soon (tm)
- tooltip
And then it looks like the validator stuff could be moved to a virtual function.
I'm not sure we want a ton of files for this, but maybe if we put them in a subdirectory?
That said, I do think subclasses is probably the way to go long term.
Convert PurpleRequestField into a GObject
Review Request #2320 — Created March 6, 2023 and submitted
This is just a straight conversion with not much attempt to make things nice.
Also, this leaves
PurpleRequestField
as a multi-type object, but derivable, so we can change to a bunch of subclasses after.
Compiled and opened Request Fields from Demo protocol.
Summary | ID |
---|---|
82606458336e0fa9ab4132b91629089465f641b4 |
- Change Summary:
-
Make
PurpleRequestField
derivable. Also, remove thefield-type
property, as that will go away with subclasses. - Commits:
-
Summary ID 3ca778dd8e5b6c152582fe2e343a1502a939f2f2 da91326c7824c90f133a9bbfd212effb700db08d
- Change Summary:
-
Update description.
- Description:
-
This is just a straight conversion with not much attempt to make things nice.
~ Also, this leaves
PurpleRequestField
as a multi-type object, but isn't mutable, so we could perhaps change this to a bunch of subclasses, instead?~ Also, this leaves
PurpleRequestField
as a multi-type object, but derivable, so we can change to a bunch of subclasses after.