customer A needs an extension to the base auth app to store a SRID chip UID for a door access control.
customer B needs an extension to store a number from a bar code scanner at the same place for, dont know single sign on, or whatever.
customer C needs both.
whats the way in django? making a app features everything and has options for deactivating some or all features?
in open object i can make an app extension for a single purpose and can simply combine them afterwards which is more clean and changes on one dont affect the other (normally).
but the complete odoo is a heavy thing for only having a ORM layer and a webinterface.
It depends upon whether these customers are all on the same site, or if you’re talking about building different sites for each of these customers.
But basically, yes, the Profile method of model extension is probably the way to go here.
That raises the question regarding odoo that I haven’t found a definitive answer for - in your example where you make an app extension - is that creating a new database table or is it altering the existing table? If you combine both those options for customer C, how many tables get created?
instanciating the base class, creating the view and menus
instanciating child class belonging to app 1 (SRID) applying the new and overriding functions and fields on the already existing model object, its views and menus
instanciating child class belonging to app 2 (barcode) applying the new and overriding functions and fields on the already existing model object, its views and menus
Customer A: 1. + 2. occur
Customer B: 1. + 3.
Customer C: 1. + 2. + 3.
belonging on what addons are installed for the customers.
so it does’n matter if they are on the same site or not. everyone gets what he want, and only what he want
data for A and B ist stored in 2 tables and data for C in 3
mixins!!!
mixins is the word i wasnt able to find last week.
and in open object there special mixins, which can inject themselves from outside into models of existing apps.
in place.
and these apps and models dont need to know the mixins.
but the original app which introduced the Person model will still use Person to fill its views with data and not MyPerson.
so if i need a new field in Person i need to create a new app which inherits Person and introduces its own views and controllers instead of just injecting the field into Person of the original app.
Admittedly, that does depend upon how “Person” is constructed. While it’s possible in Django to build an object that works like that, it’s not a common practice.
On the other hand, I fail to see how an app that uses a Person object can take advantage of a method that doesn’t exist until it is applied by an inherited model. If I create a MyPerson with a method “reverse_name”, how exactly is Person going to use that method without me changing something to tell it to use that method?
As far as the “need to create a new app” - you need to have an app, yes. That’s a fundamental design of Django - more an issue of code organization than anything else. But that doesn’t prevent you from importing classes and methods from other locations, overriding that which is needed to be changed.
The best demonstration of that are the Generic Class Based Views. I can build a view taking any object, and have it build a form for that object - after all, that’s essentially what the Django admin does, and there’s nothing special about it.
While I can see how Odoo may be designed to facilitate those types of designs, I think you’re overstating the difficulty or degree of work to provide the same benefits within Django.
But that just brings me back to my original point from where we started on this discussion. From everything I’ve seen / read, Odoo and Django are fundamentally different products addressing two different audiences. You wouldn’t try to use Django as a replacement for Odoo, but you could use Django to build a clone / replacement for Odoo. See the FAQ on where Django fits within a web stack.
Odoo and Django are fundamentally different products addressing two different audiences
your absolutely right. but the ORM framework on which odoo is based has exactly the same purpose as django. sadly im not able to seperate odoo from its framework. thats why im searching for a new ORM framework, if possible including all the features i can find in openobject and well supported and stable
On the other hand, I fail to see how an app that uses a Person object can take advantage of a method that doesn’t exist until it is applied by an inherited model. If I create a MyPerson with a method “reverse_name”, how exactly is Person going to use that method without me changing something to tell it to use that method?
the templates, used by the view of the Person object can be changed in almost the same way as the model is inherited. the templates are strict XML, so using xpath you can pull out, push in ore move what you want. also from outside. without the developer of Person has intended it.
this makes it possible to seperate features into different addons and combine them afterwards by simply installing them or not.
That’s cool, I can see that. If I were ever in a situation where I would find that helpful, that would be reason enough to install an XML-based template engine in Django. (Or, possibly, build a database-based version of the engine rather than file-based - or both.)
However, across 7 years now of working with Django professionally, I have never run into a situation where I’d want / need to do something like that. (Acknowledging that my uses of Django aren’t exactly “mainstream”. So I’m not saying it’s not useful or a “killer feature” - I can see circumstances where it would be. I’ve just never worked in any environment where those circumstances would apply.)
