Open dariocravero opened 10 years ago
Moved away to 1.0.0.
Look at https://github.com/ianwhite/orm_adapter We could steal the base and move our ORMs syntax from generators to adapters. Thoughts?
@ujifgc In my opinion the orm_adapter project, solve very well the problem, however padrino handle some ORMs that this project don't know how to handle.
We can try to improve the orm_adapter project, or create a abstraction ourselves.
What do you guys prefer?
/cc @dariocravero
@ianwhite from orm_adapter stated earlier that they will not accept PRs with new adapters https://github.com/ianwhite/orm_adapter/pull/30 https://github.com/ianwhite/orm_adapter/pull/12
So, we could fork as separate gem or just mimic the API.
I forked the gem and renemed to padrino-orm_adapter
.
https://github.com/namusyaka/padrino-orm_adapter
Maybe we could treat padrino-orm_adapter as a padrino official gem. I'm going to put this to our repositories place if you hope.
Marvelous!
Requested couch potato in #849 Requested rom-rb in #1312
Brain dump. /cc @skade
Instead of dumping all the ORM bits directly into the admin, we could interface them through a set of helpers (the API) that would inject the required methods based on the ORM of choice.
The helpers could look like
get_one(Model, id)
.This could allow for a pretty much static and mountable admin application, i.e, you only need to switch the adaptor for it.
Pushed even further it could allow for one liners that define manageable objects and it's associations.