data sharing with multiple clients by server simultaneously
Hi guys. I have a doubt regrading communication b\w client and server. consider an example there are 20 clients continuously connected and share data with server and server response to there request. my requirements are What are all the concepts needed inorder to make it? and some alternatives. thank u -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMsYeuHUAtE0TaoOpbLrha%3DQ8NsOqrsji65eu04Md6QS8bHQfA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: What do you think about unify templates feature?
Could you please explain about it. I hadn't understood ur idea.
On Thu 17 Jan, 2019 2:32 pm J. Pablo Martín Cobos Hi,
>
> From one year ago, I am using an own command for Django templates that
> unify them. With an example it is easy to see. If I am to render for
> example a template call news.html like it:
>
> 1. news.html
>
> {% extends "base.html" %}
>
> {% block title %}
> {% include "inc.news.title.html" %}
> {% endblock %}
>
> {% block content %}
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> {% endblock %}
>
> 2. base.html
>
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> http://www.w3.org/1999/xhtml"; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
>
> {% block title %}{% endblock %}
>
>
> {% block content %}{% endblock %}
>
>
>
> 3. inc.news.title.html
> News
>
> With this command I preproces every template of a settings variable and I
> get something like this:
>
> news.unify.html
>
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> http://www.w3.org/1999/xhtml"; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
>
> News
>
>
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
>
>
>
> So I have a two improves:
>
>1. It is more fast. And in a real project a view can render easyly 50
>templates
>2. I use news.html to develop and news.unify.html to production. So I
>don't lose legilibility.
>
>
> What do you think about "unify templates feature"? Do you know if exists a
> similar public project in github/gitlab/bitbucket etc?
>
>
> Best,
>
> --
> Pablo Martín Cobos
> Computer engineer
> Python/Django developer
> 652 53 37 36
> goi...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CALNyWLGNcuK8DTnU9w9fyGFhFfT3dAz7vfj3B%2BnDHWTfneLNFw%40mail.gmail.com
>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMsYeuFV3EV_3H%2BR0q9xi5Q6EQq6L2cLkatcvrTtSYW%3D2zRk7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable
actually i am new to django i am not able to understand the problem which
ur dealing with?
On Thu, Jan 17, 2019 at 3:33 AM Santiago Basulto
wrote:
> Hey folks, I was about to submit a ticket but i thought it might be better
> to ask everybody for opinions on the matter first. I am running a couple of
> medium (not even large) Django websites (around +20K users) and we rely on
> the admin heavily. We have multiple models pointing to Users (or other
> derived models) and every time we create a new model, we MUST remember to
> include User in `raw_id_fields` for that model. If we forget to do so, the
> whole testing site crashes when the whole `SELECT * FROM User` query is run.
>
> To add to the problem, some derived models (for example Customer) include
> in their `__str__` both the User + something else. Think about the model
> Customer in this way:
>
> class Customer(models.Model):
> user = models.ForeignKey(User)
> plan = models.ForeignKey(Plan)
>
>
> def __str__(self):
> return f"{self.user} - {self.plan}"
>
>
> (Not a real example, but to make the point)
>
> Imagine any other model with an FK to Customer, an `Inquiry`, for example.
> If you open the `Inquiry` add/change page on the admin, the whole thing
> will blow up.
>
> I know the related select field is an amazing feature, and looks slick on
> the admin when starting a new Django projects (specially for beginners),
> but it just doesn't scale for large websites.
>
> *My proposal*
>
> I think just a project-wide setting `settings.ADMIN_DEFAULT_FK_WIDGET =
> [raw|select]` would work and help us (running a medium/large site) a lot.
>
> What do you think?
>
> Thanks for all the support, this community rocks 🤘!
>
> PS: I can create a ticket if that's a better medium of discussion, just
> let me know?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5dae8b31-356c-45f3-b707-83b5ef33f396%40googlegroups.com
>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMsYeuFUNE3W8Cc2RGwn7L-LZ%2BhrNy9NPxiYVx_ZH7H4kUzR0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
