Django - Image crop using a widget as a field in the form

[Paul]

I have a Product Model and Image Model with a Foreign key to the product 
model. 


So in a form for Product creation I will have/need multiple Image File 
Upload inputs. 


I want to replace the default Image file-upload form field with a Image 
(like a plus sign, like add a new image, using a widget). 


When the user click on a add a new image a pop-up will apear with a 
javascript crop. I need to get the data(coordinates) from the javascript 
crop back to Django, use Pillow to crop and fill the Image Model field.


What is the best approach for this mechanism for the form field(will not be 
a real upload) ? , maybe a link to a tutorial 


(I know there are some Django package that do something like that but are 
really what I want regarding crop control)









-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/dca42a40-1bb2-4912-a91c-4e8225a34ed4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deploying Django Tutorials or Guides - mod_wsgi, Apache, Linux

[Antonis Christofides]

Hi,

Shameless plug: http://djangodeployment.com/ is the best :-)

However it doesn't treat mod_wsgi. I have explained
 that
when deploying on Unix/Linux, there is no reason to prefer it over Gunicorn (and
Apache+Gunicorn is a perfectly valid solution
).

Regards,

Antonis

Antonis Christofides
http://djangodeployment.com


On 2017-08-22 22:11, pieceofkayk2...@gmail.com wrote:
> Does anyone have any good tutorials or guides on how to deploy a Django
> project using mod_wsgi, Apache, and Linux?  The documentation isn't really
> cutting it for my beginner self.
> Thanks in advance!
>
>
> -- 
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com
> .
> To post to this group, send email to django-users@googlegroups.com
> .
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/5f80d0bf-bbb9-491c-9066-ff36a6479a50%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ca9f3952-23d7-4741-8802-7d052b81a927%40djangodeployment.com.
For more options, visit https://groups.google.com/d/optout.

Re: A lot of Problems with Migrating (conceptual)

[Antonis Christofides]

Hi,

> I read in "2 Scoops of Django" that, in general, if you have more than 5
> models per model file then you should think about splitting the model up into
> different apps, rather than having long models files.
I don't claim to be more experienced than the authors—on the contrary—and I have
learnt loads from this book. However I disagree with this assertion. Five models
is very few. In addition, I've found early splitting to usually be YAGNI
. It causes more
problems than it solves. Unless there is an obvious logical distinction of
functionality right from the start, put all your models in the same app. When it
grows and you see an obvious way to improve its structure, go on and refactor.
Don't "refactor" from the start before you even understand your app's structure.

Regards,

Antonis

Antonis Christofides
http://djangodeployment.com


On 2017-08-22 22:37, Alexander Joseph wrote:
> Thanks for all the advice.
>
> One more question - could project structure be causing issues with migrations?
> I'm working on a large project and many apps in my project have several layers
> of "sub-apps". My structure looks something like this...
>
>
> |
>
> my_project/
>     config/ 
>     docs/
>     accounting/
>         invoices/
>             __init__.py
>             admin.py
>             models.py
>             urls.py
>             views.py
>         purchase_orders/
>             __init__.py
>             admin.py
>             models.py
>             urls.py
>             views.py 
>         __init__.py
>         admin.py
>         models.py
>         urls.py
>         views.py
>     engineering/
>         products/
>             product1/
>                 sub_product1/
>                     __init__.py
>                     admin.py
>                     models.py
>                     urls.py
>                     views.py
>                 __init__.py
>                 admin.py
>                 models.py
>                 urls.py
>                 views.py
>             product2/
>                 __init__.py
>                 admin.py
>                 models.py
>                 urls.py
>                 views.py
>             __init__.py
>             admin.py
>             models.py
>             urls.py
>             views.py
>     requirements/
>     utility/
>
> |
>
> A few things about my structure - I read in "2 Scoops of Django" that, in
> general, if you have more than 5 models per model file then you should think
> about splitting the model up into different apps, rather than having long
> models files. And I structured it this way so that it would be a little easier
> to manage - instead of having all apps under the project folder, engineering
> apps would belong in the engineering folder, etc.
>
> Thanks again
>
>
>
>
> On Thursday, August 17, 2017 at 11:10:01 AM UTC-6, Alexander Joseph wrote:
>
> I'm pretty new to django and I've been having problems with
> makemigrations/migrate and I wonder if Im doing things right.
>
> I'm using MySQL backend and after reading in the documentation a little it
> sounds like Postgresql might make migrating more painless. Usually my
> problems stem from changing table fields, adding new tables/models, and
> migrating both on my development server and my production server
> (PythonAnywhere)
>
> More than once I've had to drop my database, delete all my migrations, and
> start over with initial migrations on the development server. This wont
> fly for long on production though of course .. once I actually have users
> and data.
>
> I'm wondering if I should switch to postgresql or if theres any further
> resources that you might know of that would help me out? Thanks
>
> -- 
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com
> .
> To post to this group, send email to django-users@googlegroups.com
> .
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/d4cc32e5-c9c1-48d7-bb19-a6646800ce3d%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discus

Re: is there any way to dump all sqlmigrations automatically ?

[Daniel Hepper]

You can try this command:

 python manage.py showmigrations -p | sed -e 's/\[ ] \(.*\)\.\(.*\)/\1 \2/' 
|  xargs -L1 python manage.py sqlmigrate

Here is what it does:

1. "python manage.py showmigrations -p" shows all migrations in the order 
they will be applied as a list with checkboxes.
2. "sed -e 's/\[ ] \(.*\)\.\(.*\)/\1 \2/'" will remove the checkboxes and 
split the migrations into app and migration name
3. "xargs -L1 python manage.py sqlmigrate" will execute python manage.py 
sqlmigrate for each line

Alternatively, why not just call python manage.py migrate?

On Wednesday, August 23, 2017 at 3:41:24 AM UTC+2, Victor Wang wrote:
>
> use "sqlmigrate " is too ineffective  to get all sql script to setup new 
> database . 
>
> is there anyway to dump all "sqlmigrate" for all apps ?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/923bcb7b-982c-4e14-b04f-c3fd492ab06d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Need help: webrtc signalling with django app

[OM555]

Hi all,

 Is there any way of integrating webrtc signaling with django apps? From 
what I understand django channels do not support this. I need user 
authentication from django app to be used along with the webrtc feature. 
Thanks...
OM

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/dca802bc-331d-4e6c-8e9e-82f7db5dc4c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Need help: webrtc signalling with django app

[Andrew Godwin]

My impression was that RTC signalling was not specified or defined so apps
could do it how they wish - so you could use normal AJAX, or WebSockets,
etc. Channels doesn't have RTC support as, as far as I could tell, the
specified parts are all browser-to-browser.

Andrew

On Wed, Aug 23, 2017 at 7:16 AM, OM555  wrote:

> Hi all,
>
>  Is there any way of integrating webrtc signaling with django apps? From
> what I understand django channels do not support this. I need user
> authentication from django app to be used along with the webrtc feature.
> Thanks...
> OM
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/dca802bc-331d-4e6c-8e9e-82f7db5dc4c8%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFwN1uqWcU3JyDtPZbjXbTnnw%2BPUO79H00B%3DKjARst_gbMG5Jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

ManyToManyField's add() function is doing nada for me.

[pieceofkayk2718]

I am simply trying to add a Bundle model to my Instrument model.  It should 
be really easy but I can't seem to figure out why it's not working.

context.models.py

class Instrument(models.Model):
title = models.CharField(max_length=200)
bundle = models.ManyToManyField(Bundle, blank=True)




build.models.py

class Bundle(models.Model):
title = models.CharField(max_length=200)


views.py

def instrument_host_detail(request, pk_bundle, pk_instrument_host):
form_choose_instruments = ChooseInstrumentsForm()
form_choose_targets = ChooseTargetsForm()
bundle = Bundle.objects.get(pk=pk_bundle)
context_dict = {}

if request.method == 'POST':
form_choose_instruments = ChooseInstrumentsForm(request.POST)
form_choose_targets = ChooseTargetsForm(request.POST)

if form_choose_instruments.is_valid() and 
form_choose_targets.is_valid():
for instrument_name in 
form_choose_instruments.cleaned_data['instrument_list']:
instrument = Instrument.objects.get(title=instrument_name)
print bundle
print '{} -- {}'.format(instrument.pk, instrument)
instrument.bundle.add(bundle)
#instrument.save()
print instrument.bundle

context_dict['bundle'] = bundle
context_dict['form_choose_instruments'] = form_choose_instruments
context_dict['form_choose_targets'] = form_choose_targets


return render(request, 'detail.html', context_dict)

When my view hits print bundle it will print the bundle title.  When my 
view hits print instrument.pk and instrument it will show it is an 
instrument model.  However, if I try to add the bundle to my instrument 
model, I don't get any action.  The print statement returns 
build.Bundle.None (where build_a_bundle is the app that Bundle model lives 
in).  Also in the shell and admin I'm seeing that my bundle model isn't 
being added.  

Note:  The comment on instrument.save() was me toggling whether or not it 
was necessary and in both cases I'm not getting anything.  The 
documentation didn't show that it was necessary.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6f24c68d-c199-4c47-8ddc-ff1124cf5d35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A lot of Problems with Migrating (conceptual)

['Tom Evans' via Django users]

On Tue, Aug 22, 2017 at 8:37 PM, Alexander Joseph
 wrote:
> Thanks for all the advice.
>
> One more question - could project structure be causing issues with
> migrations? I'm working on a large project and many apps in my project have
> several layers of "sub-apps". My structure looks something like this...

This approach seems appealing, but personally I think it is a bad idea
because the ease of introducing dependencies between apps is extremely
high. Even when the apps are all tightly related to a particular
project (to the extent their package name is
"fooproject-some-function"), I think its better to simply develop each
one as a standalone app, separate from the other apps and not
requiring the other apps in order to test/develop.

With this approach, you will not get unnecessarily thin apps simply
because you cannot easily couple two apps together, and everything
within the app should have high cohesion. Remember (or discover :)
that in software engineering, high quality code is loosely coupled (it
doesn't depend on many external things) and highly cohesive (the
things within the module are related to each other).

I would also avoid the use of subapps. First off, Django only uses the
final part of the dotted import path as the app name -
'engineering.products.product1' has the same name as
'accounting.invoices.product1' (I know that doesn't exist, but...). I
have a (unsubstantiated) theory that your migration woes are down to
subapps.

Long model files are not good, but I'd also disagree with 2SoD that
getting to 5 models means a new app because of long files - what
ridiculousness! If your model file is getting long, replace it with a
model directory, each model in a separate module, and all of them
imported in the __init__. You should split your app when it is no
longer cohesive (or more accurately, when the level of cohesion is
upsetting and/or slows development). 2SoD is good, but its not a holy
text!

Cheers

Tom

PS

Make sure you have a sensible workflow for migrations - I'm assuming
you are using some sort of version control. While you are developing
your changes, you might generate a lot of temporary migrations. You do
not want to apply these migrations to live, so you should squash them
- either manually, using squashmigrations or by migrating the DB back
to before they existed, remove them and recreate them. If you do the
last one, remember to preserve any custom logic you have placed in the
migration.

At the end of the day, the migrations you commit are what will run on
your production database, so you should ensure they do exactly what
you are expecting them to do and are running in the correct order.
Particularly if you have a lot of small apps, getting the dependencies
right is essential.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFHbX1J-Oxam2oHB37ap3rY5Sio2%2BR0WGMKKpmPtT-5JMaGDHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use separate apps or only one app in my project

[pieceofkayk2718]

Can you give a more concrete example?  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7ab1d838-b594-4ab2-9a02-edc81f8c7f46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Retrieving objects created in trasaction

[pieceofkayk2718]

Try foo.save() before foo.bars.add(). 

>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/39fc5e90-e030-44f4-b129-765def7e985b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: include template in a page

[pieceofkayk2718]

Do you have an action on your register form?  Like 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ce2a92c4-270a-46c9-9b49-06a2d72cf72b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Retrieving objects created in trasaction

[James Schneider]

On Aug 16, 2017 11:27 AM, "roboslone -"  wrote:

Hi,

I have some function (fetcher) that runs in transaction (it has to) and it
creates a bunch if new objects that are written to database after
transaction is commited. Those objects are added to a many-to-many
relation. And on that relation change a signal is fired and handled by my
signal handler, that collects objects from relation and writes them into
some cache.

The problem is that during signal handling newly created objects do have
PKs, but are not in database yet. So signal_handler in code below always
gets empty queryset.


def fetcher():
with transaction.atomic():
foo = Foo.objects.create(...)
foo.bars.add(
Bar.objects.create(...),
Bar.objects.create(...),
Bar.objects.create(...),
...
)

@receiver(m2m_changed, sender=Foo.bars.through)
def signal_handler(pk_set=None, **kwargs):
# signal_handler is being called inside of a transaction block
Bar.objects.filter(pk__in=pk_set)  # <-- returns empty QuerySet!


Is there a way to delay signal handling until transaction is committed or
to get newly created objects by PKs?



Perhaps you can try nesting the transactions?

https://docs.djangoproject.com/en/1.11/topics/db/transactions/#savepoints

-James

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVTBFTQwHR01eEJqdqDfEiOu5nZZOtbGPrW-Lf2sUrmag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A lot of Problems with Migrating (conceptual)

[Alexander Joseph]

Thanks James, and thanks for your post on my other thread about structure.
I agree I need to get more into conceptual introductory material. I think I
will restructure my project and merge a lot of the apps/subapps I have now
as you suggested. From what Tom said it sounds like that could be a lot of
where my migration issues are coming from. I've seen a lot of dependency
related errors when trying to run migrations.

Thanks all for the ongoing advice. I'll try to keep this thread updated on
how issues are resolved as I restructure my project according to your
suggestions

On Tue, Aug 22, 2017 at 3:57 PM, James Schneider 
wrote:

>
>
> On Tue, Aug 22, 2017 at 12:37 PM, Alexander Joseph <
> alexander.v.jos...@gmail.com> wrote:
>
>> Thanks for all the advice.
>>
>> One more question - could project structure be causing issues with
>> migrations? I'm working on a large project and many apps in my project have
>> several layers of "sub-apps". My structure looks something like this...
>>
>
> Possibly, especially if you're introducing any import loops. It's easy to
> do. Trying to get the autodiscover mechanism for models to run through
> nested apps can also be fun.
>
> 
>
> A few things about my structure - I read in "2 Scoops of Django" that, in
>> general, if you have more than 5 models per model file then you should
>> think about splitting the model up into different apps, rather than having
>> long models files. And I structured it this way so that it would be a
>> little easier to manage - instead of having all apps under the project
>> folder, engineering apps would belong in the engineering folder, etc.
>>
>> Thanks again
>>
>>
>
> It depends. Your structure will likely change throughout the life of your
> project. Start with what you have now and mold accordingly. Loose coupling
> is key, though, to make it easier to move things around.
>
> Like I mentioned in your other thread, you need to redefine what you are
> considering an 'app'. Your current definition is way too specific/narrow,
> which is why you are ending up with so many. Almost certainly each product
> does not need its own app. That's not to say you shouldn't break them
> apart. I'm saying keep your 'apps' generalized (ie engineering, accounting,
> etc.) and break up the models into importable Python modules with a
> sensible structure. Using modules will alleviate much of the pain of the
> app and model discovery process using the pattern I described in the other
> thread. It also provides a mechanism for loose coupling, and keeps your
> models in separate files/folders using any structure you'd like. Reducing
> the number of apps also reduces the number of files present in your
> project, since you only need a single apps.py for a larger app, rather than
> managing 20 apps.py files for 20 smaller apps.
>
> 2SoD is an excellent resource, and in no way to do I claim to have a
> modicum of the knowledge and experience that the authors do. I don't even
> program for a living. I have a copy for 1.8. You will notice in the book
> that they do not have separate apps for an ice cream cone vs. ice cream
> sandwiches vs. toppings, even though these may be analogous to your
> product_1, product_2, etc. It's hard to tell though, because I'm assuming
> you generalized your structure, so I don't know if you are talking about
> different ice cream-based treat types, or cars vs. rocket ships. The latter
> would likely use separate apps because there would be little overlapping
> workflows and logic, along with multiple models associated with each.
>
> I'd recommend looking in to some introductory material on database
> normalization, not so much for the mechanics, but rather more conceptually.
> The way you would break things apart for normalization often coincides
> neatly with the way you should break apart apps (and builds your model list
> for you), somewhere around the 2nd normal form. Again, your structure will
> likely change as you go, so use the loose coupling via the __init__.py
> module imports as I've shown, and that should help with the transition.
>
> -James
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/django-users/kzNqB9lEIGA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/CA%2Be%2BciV7tZS8WJeFyn1p5MQrctM6pymp
> BPK2btm38FshX%3DSX1Q%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Re: A lot of Problems with Migrating (conceptual)

[Alexander Joseph]

One more question - is there a way to put apps in folders/sub-folders
instead of creating sub-apps/modules? I just want to keep things easier to
navigate on the development side. I will eventually have about 20 sub-apps
in the 'Engineering' app alone.

Even if I could just group all the engineering sub-apps i have now under an
engineering folder without any further hierarchy that would help as there
will also be HR, financial apps, administration apps, etc.

Thanks again



On Wed, Aug 23, 2017 at 5:28 PM, Alexander Joseph <
alexander.v.jos...@gmail.com> wrote:

> Thanks James, and thanks for your post on my other thread about structure.
> I agree I need to get more into conceptual introductory material. I think I
> will restructure my project and merge a lot of the apps/subapps I have now
> as you suggested. From what Tom said it sounds like that could be a lot of
> where my migration issues are coming from. I've seen a lot of dependency
> related errors when trying to run migrations.
>
> Thanks all for the ongoing advice. I'll try to keep this thread updated on
> how issues are resolved as I restructure my project according to your
> suggestions
>
> On Tue, Aug 22, 2017 at 3:57 PM, James Schneider 
> wrote:
>
>>
>>
>> On Tue, Aug 22, 2017 at 12:37 PM, Alexander Joseph <
>> alexander.v.jos...@gmail.com> wrote:
>>
>>> Thanks for all the advice.
>>>
>>> One more question - could project structure be causing issues with
>>> migrations? I'm working on a large project and many apps in my project have
>>> several layers of "sub-apps". My structure looks something like this...
>>>
>>
>> Possibly, especially if you're introducing any import loops. It's easy to
>> do. Trying to get the autodiscover mechanism for models to run through
>> nested apps can also be fun.
>>
>> 
>>
>> A few things about my structure - I read in "2 Scoops of Django" that, in
>>> general, if you have more than 5 models per model file then you should
>>> think about splitting the model up into different apps, rather than having
>>> long models files. And I structured it this way so that it would be a
>>> little easier to manage - instead of having all apps under the project
>>> folder, engineering apps would belong in the engineering folder, etc.
>>>
>>> Thanks again
>>>
>>>
>>
>> It depends. Your structure will likely change throughout the life of your
>> project. Start with what you have now and mold accordingly. Loose coupling
>> is key, though, to make it easier to move things around.
>>
>> Like I mentioned in your other thread, you need to redefine what you are
>> considering an 'app'. Your current definition is way too specific/narrow,
>> which is why you are ending up with so many. Almost certainly each product
>> does not need its own app. That's not to say you shouldn't break them
>> apart. I'm saying keep your 'apps' generalized (ie engineering, accounting,
>> etc.) and break up the models into importable Python modules with a
>> sensible structure. Using modules will alleviate much of the pain of the
>> app and model discovery process using the pattern I described in the other
>> thread. It also provides a mechanism for loose coupling, and keeps your
>> models in separate files/folders using any structure you'd like. Reducing
>> the number of apps also reduces the number of files present in your
>> project, since you only need a single apps.py for a larger app, rather than
>> managing 20 apps.py files for 20 smaller apps.
>>
>> 2SoD is an excellent resource, and in no way to do I claim to have a
>> modicum of the knowledge and experience that the authors do. I don't even
>> program for a living. I have a copy for 1.8. You will notice in the book
>> that they do not have separate apps for an ice cream cone vs. ice cream
>> sandwiches vs. toppings, even though these may be analogous to your
>> product_1, product_2, etc. It's hard to tell though, because I'm assuming
>> you generalized your structure, so I don't know if you are talking about
>> different ice cream-based treat types, or cars vs. rocket ships. The latter
>> would likely use separate apps because there would be little overlapping
>> workflows and logic, along with multiple models associated with each.
>>
>> I'd recommend looking in to some introductory material on database
>> normalization, not so much for the mechanics, but rather more conceptually.
>> The way you would break things apart for normalization often coincides
>> neatly with the way you should break apart apps (and builds your model list
>> for you), somewhere around the 2nd normal form. Again, your structure will
>> likely change as you go, so use the loose coupling via the __init__.py
>> module imports as I've shown, and that should help with the transition.
>>
>> -James
>>
>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django users" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/django-users/kzNqB9lEIGA/unsub

Re: A lot of Problems with Migrating (conceptual)

[James Schneider]

On Wed, Aug 23, 2017 at 4:40 PM, Alexander Joseph <
alexander.v.jos...@gmail.com> wrote:

> One more question - is there a way to put apps in folders/sub-folders
> instead of creating sub-apps/modules? I just want to keep things easier to
> navigate on the development side. I will eventually have about 20 sub-apps
> in the 'Engineering' app alone.
>
> Even if I could just group all the engineering sub-apps i have now under
> an engineering folder without any further hierarchy that would help as
> there will also be HR, financial apps, administration apps, etc.
>
> Thanks again
>

Technically you can go as deep as you'd like. You can use the module
strategy to emulate a Django 'app' without all the registration fuss. A
couple abbreviated examples:


# 1. Group resources and references by object type
project/
engineering/
__init__.py
models/
__init__.py
 widgets.py
 gadgets.py
 product1.py
 product2.py
views/
__init__.py
product1.py
product2.py
 # etc.

All of the models for engineering would be grouped in a single 'models'
module. Imports would look like 'from engineering.models.widgets import
WonderWidget'

The engineering/models/__init__.py file would contain lines like 'from
.widgets import *' for all of your files that contain models.


# 2. Group by business segment or workflow
project/
engineering/
__init__.py
models.py
product1/
__init__.py
models.py
views.py
urls.py
product2/
__init__.py
models.py
views.py
urls.py
 # etc.

In this case, you're replicating the structure of an 'app' without creating
one by Django's definition. The engineering/models.py file would then
contain imports like 'from .product1.models import *' in order to get the
model auto-discovery to work correctly.

I'm under the impression that most developers use layout #1, but a large
project might work better with #2 if there aren't a lot of
cross-dependencies.

Note that using Python modules rather than real Django apps will also keep
your settings.INSTALLED_APPS list minimized. With as many 'apps' as you
were originally talking about, that list could be dozens or hundreds of
items long.

IMHO I would start with #1 and see how it works for you. It could be the
generalized term 'product' that you're using, but to me, a product would
not trigger a new 'app' for me, just extra model/view/url/etc. files,
especially given how often products change or are added/removed. In that
case, #2 might work better since all of the related code is within a single
sub-folder (but all the references to that code aren't, so there is still
work to be done). YMMV

-James

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciWr9GGYERPYDAYHvYdryRMq5NkWN3ws1zaKw8MxusoGJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.