Dynamically subclass schema
Closed this issue · 3 comments
Currently we are mangling the hash references used by DBIx::Class directly, e.g.
__PACKAGE__->columns_info->{description}->{field_type} = 'html';
This is not very clean and also forces us to change the schema itself. It would be better
to subclass the schema and add our methods / components.
Idea for solution:
http://stackoverflow.com/questions/2701049/injecting-relationships-in-dbixclass
Where do you think it should go? It makes most sense to me that this info is in class itself, since it's about it.
Also i think that no one should be afraid to change class file, opposite, i think there should be all logic that is tightly (natural logically) bond to class.
Subclassing is fine, but unnecessary for a simple class. That can be left for developer to decide.
Registering and unregistering looks even less pretty to me. It's possible to set this parameters somewhere else by something like this:
schema->resultset('User')->result_source->columns_info->{username}->{label} = 'User name';
I agree that this hash structure isn't clean and could be improved. Do you have any suggestions on that?
On 07/28/2014 01:19 PM, Grega Pompe wrote:
Where do you think it should go? It makes most sense to me that this info is in class itself, since it's about it.
Also i think that no one should be afraid to change class file, opposite, i think there should be all logic that is tightly (natural logically) bond to class.
That's true for the usecase when you have the chance to put the adjustments into the class itself.
But for the general purpose (e.g. using TE as replacement for phpmyadmin) this doesn't work.
Configuration file or SQlite database are places where we could add this extra information.
Subclassing is fine, but unnecessary for a simple class. That can be left for developer to decide.
We would do it in a transparent way, so usually the developer doesn't need to worry about.
Registering and unregistering looks even less pretty to me. It's possible to set this parameters somewhere else by something like this:
schema->resultset('User')->result_source->columns_info->{username}->{label} = 'User name';
I agree that this hash structure isn't clean and could be improved. Do you have any suggestions on that?
This is definitely not clean and not guaranteed to work in the future.
Regards
Racke
Perl and Dancer Development
Visit our Perl::Dancer conference 2014:
You're right. I'll move these setting into YAML config file.