Re: The problem of versioning a large project.

2023-04-04 Thread Piyush Prasad 
Why not use a mono repo?

From: django-developers@googlegroups.com  
on behalf of Alex Sonar 
Sent: Sunday, April 2, 2023 10:21:33 PM
To: Django developers (Contributions to Django itself) 

Subject: Re: The problem of versioning a large project.

It is about one project that includes many applications.

We would like to separate the repository specifically for front-end guest 
groups.

With access to parts like: views_groups, templates, dummy_data, forms_group, 
helpers_group, static_blob and media_blob as an example.

Now our application tier and the file structure of the project looks something 
like in the picture below.


   .

├── apps

 . ├── .DS_Store

   ├── app_alpha

   │   ├── .git  <   git alpha

   │   └── alpha

   │ ├── __init__.py

   │ ├── admin_alpha.py

   │ ├── api_connectors

   │ ├── apps_alpha.py

   │ ├── conf_parser_alpha.py

   │ ├── controllers_groups

   │ ├── dummy_data_alpha

   │ ├── db_router_alpha.py

   │ ├── forms_group

   │ ├── helpers_group

   │ ├── media_blob_alpha

   │ ├── metadata

   │ ├── migrations

   │ ├── models_groups

   │ ├── signals_alpha.py

   │ ├── static_blob__alpha

   │ ├── templates

   │ ├── urls_alpha.py

   │ └── views_groups

   ├── app_beta

   │   ├── .git  Now we have organized versioning, where our project is divided into separate 
>GIT repositories which are created for each application.



why? what's the reasoning for this? django already has apps, so why do you need 
to make multiple projects for single components?
On Friday, March 31, 2023 at 10:15:06 AM UTC-4 cha...@gmail.com wrote:

Like Aharon, I'm not entirely certain what you mean but this line:
> The task looks like bad practice, where we have to create a repository within 
> another one.
reminded me of git submodules, which I don't think are considered bad practice. 
Is that what you mean?
On Thursday, March 30, 2023 at 5:17:41 AM UTC+9 Alex Sonar wrote:

The problem of versioning a large project.

Hi guys, I really got stuck with the challenge, with the design of versioning 
for a large project.

Now we have organized versioning, where our project is divided into separate 
GIT repositories which are created for each application.

The new necessity point is to split some of them for front-end and back-and 
developers.

The task looks like bad practice, where we have to create a repository within 
another one.

Or redesign the file structures of the application itself, to meet this 
requirement.


If someone has a similar challenge or practice and helps me make the right 
decision, I will be very grateful.

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1c2df2fc-0158-4da1-a686-5f2a69435f43n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/PH0PR15MB5640DD26A7890FC754671486FC929%40PH0PR15MB5640.namprd15.prod.outlook.com.

Issue with get_FOO_display not working in Django admin

2023-04-04 Thread 'Ibrahim Abou Elenein' via Django developers (Contributions to Django itself) 
Dear All,

I am writing to report an issue I encountered while working with Django 
admin. I had a model with a field that uses Choices as follows:

```
status = FSMField(default=STATUSES.PENDING, choices=STATUSES, 
protected=True)
```
I overrode the get_status_display method, but to my surprise, it did not 
have any effect in the Django admin.

Upon investigating Django's code, I found the following method in 
contrib.admin

```
def display_for_field(value, field, empty_value_display):
from django.contrib.admin.templatetags.admin_list import _boolean_icon

if getattr(field, "flatchoices", None):
return dict(field.flatchoices).get(value, empty_value_display)
```
I noticed that this method uses flatchoices to get the display value for 
fields with choices. However, it does not take into account any custom 
display methods that may have been defined for the field.

To resolve this issue, I modified the code to use get_FOO_display instead 
of flatchoices as follows:

```
def display_for_field(value, field, empty_value_display, model=None):
from django.contrib.admin.templatetags.admin_list import _boolean_icon

if getattr(field, "flatchoices", None):
if model:
return getattr(model, "get_%s_display" % field.name)()
return dict(field.flatchoices).get(value, empty_value_display)
```
This modification allowed my custom display method to work as expected in 
the Django admin.

However, I am curious to know why Django's code behaves this way and how I 
can make use of this behavior in my application.

Thank you for your attention to this matter.

Sincerely,
Ibrahim.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4f432f39-b959-422e-b062-5db54722b18en%40googlegroups.com.

Re: Issue with get_FOO_display not working in Django admin

2023-04-04 Thread David Sanders 
Hi Ibrahim,

get_FOO_display() isn't intended to be overridden like that, it's just a
convenience method for use in templates/whatever that refers to the
underlying flatchoices.

For clarity, please see the documentation:
https://docs.djangoproject.com/en/4.2/ref/models/instances/#django.db.models.Model.get_FOO_display

Kind regards,
David

On Wed, 5 Apr 2023 at 09:10, 'Ibrahim Abou Elenein' via Django developers
(Contributions to Django itself)  wrote:

> Dear All,
>
> I am writing to report an issue I encountered while working with Django
> admin. I had a model with a field that uses Choices as follows:
>
> ```
> status = FSMField(default=STATUSES.PENDING, choices=STATUSES,
> protected=True)
> ```
> I overrode the get_status_display method, but to my surprise, it did not
> have any effect in the Django admin.
>
> Upon investigating Django's code, I found the following method in
> contrib.admin
>
> ```
> def display_for_field(value, field, empty_value_display):
> from django.contrib.admin.templatetags.admin_list import _boolean_icon
>
> if getattr(field, "flatchoices", None):
> return dict(field.flatchoices).get(value, empty_value_display)
> ```
> I noticed that this method uses flatchoices to get the display value for
> fields with choices. However, it does not take into account any custom
> display methods that may have been defined for the field.
>
> To resolve this issue, I modified the code to use get_FOO_display instead
> of flatchoices as follows:
>
> ```
> def display_for_field(value, field, empty_value_display, model=None):
> from django.contrib.admin.templatetags.admin_list import _boolean_icon
>
> if getattr(field, "flatchoices", None):
> if model:
> return getattr(model, "get_%s_display" % field.name)()
> return dict(field.flatchoices).get(value, empty_value_display)
> ```
> This modification allowed my custom display method to work as expected in
> the Django admin.
>
> However, I am curious to know why Django's code behaves this way and how I
> can make use of this behavior in my application.
>
> Thank you for your attention to this matter.
>
> Sincerely,
> Ibrahim.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4f432f39-b959-422e-b062-5db54722b18en%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADyZw-65tb_3LZq0D%2BVbU4Dh71V%3DGMRWDeFHCuhT8pDcChVn_w%40mail.gmail.com.