No reason to do anything crazy like that. Forget SOCKETS, use HTTP or HTTPS.
Clientside/mobileside/webside build in HTML+CSS+JS. #win On Tue, May 15, 2012 at 9:18 AM, Eugène Ngontang <sympav...@gmail.com> wrote: > Hi Jani! > > I haven't seen the last statements of your post, whre you say I'm not really > clear and that i'm building a non-http GUI using Django. > > > OK let's stay on the rendering issue only, and specify things simply. This > is a simple description of the architecture I want to set up : > > - A Client (not a user interface). Client here means a module which is > installed in a remote computer and communicate with the server via socket. > > - A server listening from several remote client (Here i'm not talking yet > about http request), and receive informatons from them. In fact client must > be doing actions and send informations about their actions to the server. In > the oder hand data to be processed by each client is pushed/dispatched by > the server. > > - And admin (not Django Admin, but admin in the sens of my app), destined to > be the module allowing use of the application. Then the Admin module is part > of the server and will proviede a GUI for manipulating data in the data > base. It's in this GUI that users of the application will enter their > request, by filling a form or clicking a link for exemple. And data from the > GUI could be stored in the data base, while being send to the remote clients > (not to be displayed by the client, but to be processed). In the same way, > informations comming from those clients to the server have to be diplayed in > the GUI. > > With a graphical GUI, The server could have a reference to an object > representing my GUI, and it will be done. > But I choose a web GUI for view and administration. It's where Django comes. > > And my problem is to make my server being running a network thread, > receiving data from the GUI(web browser) and sending informations update to > the GUI (for web page content). > > This is really my issue. If all the actions of my server depended on my GUI > request (http request), I could do what I like behind when handling a http > request, but while managing http:8080 connexions, the application is running > another process/thread on another TCP/UDP port. > > And yes I want a web GUI. > > Is why I'm looking the best way to achieve that. We can exclude Django web > server, as it will not be used in production for the application deployment. > > Hope now it's clear for you, and more for the other users. > > Thanks! > > > 2012/5/13 Jani Tiainen <rede...@gmail.com> >> >> Hi, >> >> There is several ways to achieve what you maybe want to do. One of the >> simplest way is separate frontend (your userinterface) and server backend. >> You can build your Django application as a service (xml-rpc, json-rpc, >> restful). That would give you advantage to choose whatever frontend you >> like. Of course it would add some overhead. >> >> On Sun, May 13, 2012 at 1:14 PM, Eugene NGONTANG <sympav...@gmail.com> >> wrote: >>> >>> Hi! >>> >>> I'm a python developper, but new in django. >>> >>> I'm devolopping a multi clients-server application. >>> >>> The server and the clients are communicating via sockets, The server >>> receive somme states from clients, and display them in the User >>> interface. >>> In the other hand, the server has to send a message(packet) to the >>> client when an event occurs in the GUI, and data are stored in a >>> database. >>> >> >> Note that Django is mainly built for web (HTTP protocol based) >> applications. In such an environment you run two different things: your GUI >> (usually browser) that is totally ignorant of server side (Django). Then you >> send request to some URL, Django routes it to some view and view produces >> again next output to be displayed in GUI (browser again). One of the common >> functions in the view is database manipulation. >> >>> >>> Then I choose to make a web interface where data could be viewed and >>> manipulated. And I discovered Django, which fit all my needs. I tested >>> and liked the framework. >>> >>> My questions are: >>> - Can I override the djando admin methods so that i can not only >>> customized my views and html page, but also manipulate objects in >>> database, so that i can do another action when catching an event in >>> the GUi. >>> For example, taking the django admin tutorial, I would like to do and >>> action like sending a message the user choose "add a poll". How can I >>> do those things? Cause I noticed that method that alter data in data >>> base are part of django admin module and cannot be overriden >>> >> >> You shouldn't "fight against admin". If something cannot be done in the >> admin you usually get a way with writing your own stuff. >> >>> >>> - To achieve what I want, i would like to run my server engine and my >>> django admin in two separated threads. How do i run my admin module in >>> a thread? Cause till now i'm using the command line "python manage.py >>> runserver >> >> >> Again your GUI would run "somewhere" (it's not relevant) and it's not >> concern of Django. It's architecture is designed to be share nothing - which >> means that you can run several threads/processes of your applications - And >> those threads/processes are not aware of other existence. And it doesn't >> matter. >> >>> >>> - I also tried to overide tables name, and foreign keys names. Could >>> you guys provide me a true life example? >>> >> >> Err.. Override what and where? And how you tried to do that? >> >>> >>> - And now in the production step, I would like you guys to tell me >>> what to choose for serving files. I would like to with your experience >>> what's better between running a unicorn server or apache with mod_wsgi >>> >>> I don't know if i'm clear, but i hope. In brief I'd like to use the >>> django framework features to design my Gui like i want, customize >>> interactions between the gui and the backend, and choose a good web >>> server for the production. >>> >> >> No you're definitely not clear. My interpretation is that you want to >> build (non-http based) GUI using Django as backend server. Even Django isn't >> exactly designed for such a work it still can do it. >> >> If it was something else try to split your questions in smaller fragments, >> perferably with more clearly specified use cases, workflows and samples of >> the code. >> >>> >>> Thank you for advance >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Django users" group. >>> To post to this group, send email to django-users@googlegroups.com. >>> To unsubscribe from this group, send email to >>> django-users+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/django-users?hl=en. >>> >> >> >> >> -- >> Jani Tiainen >> >> - Well planned is half done, and a half done has been sufficient before... >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To post to this group, send email to django-users@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. > > > > > -- > ngont...@epitech.net > sympav...@gmail.com > ------------------------------------------------------------ > Aux hommes il faut un chef, et au chef il faut des hommes! > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > 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 django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
