On 16 October 2010 00:21, Damir Dezeljin <[email protected]> wrote: > Hi. > I'm working on an application tat communicates with embedded devices > connected to the LAN. The devices are controlled by a central server written > in C++. Django is used for the front-end or better to say the GUI for the > server. > Part of the data the user needs access too are stored in the database, hence > the Django DB API to access this data; however, there are certain data and > actions that requires direct communication with the C++ server. The > communication is implemented using CORBA (OmniORBpy). E.g. of a situation > where the CORBA interface between the GUI and the server is needed is the > flush of devices configuration or update of the following and this should be > real time and not implemented polling the DB. > Currenly I'm instantiating the CORBA interface to my server in the views.py. > I'm wondering if there is a better way to do it as I just don't see how > could I put the CORBA interface in the Model part of the GUI? << I'm still > confused by MVC approaches certain frameworks like CakePHP use. I think > Django is not such a framework; however, I still think I should somehow > separate the data layer from the business logic (bottomline: Django is still > kind of a MVC framework). How can I do this? > Of course I would also like to solve the problem I'm currently facing: > Let's suppose both the C++ server and Django web site are up and running. If > the C++ server is restarted the web page doesn't work any more until when I > restart the web server too. I instantiate the CORBA object in a global > scope; however, I thought there is no persistence for the Django code > between the web browser calls. Am I right? Why the connection to CORBA > ceases working in such a case? << with e.g. C++ or Python stand-alone > clients the connection is reestablished each time the script / program / ... > is executed.
That is an implementation detail left up to the web server. If you are using mod-wsgi, then instances are reused for future requests (by default), hence your problem. There may also be some thread-safety issues with instantiating the CORBA object in the global scope you may want to think about. I'd probably instantiate the CORBA object once per request by doing so inside the view (or by instantiating another class that does that, as well as provide methods to access properties). > Thanks for any hint you may have, > Damir > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
