Re: User accessibility to multiple versions of an app.

[James Schneider]

On Thu, Jul 20, 2017 at 11:34 AM,  wrote:

> Thanks James.  I'm working with Data Labels =].  Give me a minute to go
> over my project to see which of the two design patterns would best suit my
> needs.  I really appreciate the long and in-depth response.  Will get back
> to you after some analysis.
>
> K
>

I would also highly recommend the book Fluent Python, which discusses these
two design patterns in detail with comparative examples, among a myriad of
other topics that made me realize I'm a terrible programmer.

-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%2BciXZZSqWCmwSfOnScM5F5uOGmvThP%3D6DE2cmmVFAHopC%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: User accessibility to multiple versions of an app.

[James Schneider]

On Thu, Jul 20, 2017 at 11:23 AM, m1chael  wrote:

> James, you rock dude. lol
>

Yeah, apparently I got a bit excited.

-- 
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%2BciWm6F-huL5864srYUE2uEZFQd06%2BU7BCOCb%3DWa%2BeyKHjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: User accessibility to multiple versions of an app.

[pieceofkayk2718]

Thanks James.  I'm working with Data Labels =].  Give me a minute to go 
over my project to see which of the two design patterns would best suit my 
needs.  I really appreciate the long and in-depth response.  Will get back 
to you after some analysis.

K

-- 
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/18d1f1f7-5d5b-41d8-8d72-45f89d796d9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: User accessibility to multiple versions of an app.

[m1chael]

James, you rock dude. lol

On Thu, Jul 20, 2017 at 2:20 PM, James Schneider 
wrote:

>
>
> On Thu, Jul 20, 2017 at 8:44 AM,  wrote:
>
>> Hey, I've been running into issues trying to figure out how a user could
>> be able to access multiple versions of an app.  Here is the following
>> example:
>>
>> I have an app named ANNA.  ANNA is used to build labels and these labels
>> are dependent upon different standards that come out.  For example, we have
>> standard 1700, standard 1800, standard 1900.  The DjangoProject website has
>> a bottom corner button that allows you to go to different versions of the
>> django docs.  I would like to implement that into ANNA, however I've come
>> across a number of problems.  So ANNA has the following app structure:
>>
>>
> Those buttons refer to different releases of the same application. They
> really are just shortcuts to a folder path that points at the particular
> release:
>
> https://docs.djangoproject.com/en/1.7/
> https://docs.djangoproject.com/en/1.11/
> https://docs.djangoproject.com/en/dev/
>
> I haven't investigated, but I'm guessing that each of those URL paths map
> back to a directory containing a full release of the Django docs at the
> appropriate version.
>
> my_project
>>  - ANNA
>>  - build(development)
>>  - search (development)
>>
>> I have tried to implement this versioning by the following partition
>>
>> *PARTITION 1*
>>
>> my_project
>> - ANNA
>> - build   (development)
>> - search (development)
>> - build1700
>> - search1700
>> - build1800
>> - search1800
>> - build1900
>> - search1900
>>
>> Unfortunately, the models used in all versions of build are the same
>> across the board, and Django's reverse lookup for these models is giving me
>> issues.  For instance if I have a label model in build, I will also have a
>> label model in build1700, build1800, etc.  So I have to change the model
>> names for each version, which means I have to change all of the business
>> code to be version specific -- and I really do not want to do that since
>> our label standards are also in development and change quite rapidly (like
>> every four months right now).  The versions are also similar enough to
>> where when a new one comes out, I would like to be able to pretty much copy
>> and paste the last version's code into the new version's code and make my
>> changes like so.
>>
>>
> Has anyone ever had to do anything like this or have any ideas of how to
>> go about it?
>>
>
> Disclaimer: I'm obviously not familiar with your application or workflow,
> so take this with a grain of salt. My assumption is that you are creating
> output for something like shipping labels that have to follow particular
> formatting standards. If not, clarity via a brief overview of what your app
> does would be helpful.
>
> The abbreviated version of what I have below is "I highly doubt you need
> separate apps, but rather a single app with a better model design to
> support multiple label/build types."
>
>
> It appears you are creating a separate application for each label type. In
> doing so, I'm assuming that you are copying the code from another "version"
> (presumably development) and then modifying the entire application
> accordingly. From what I gather, the work being performed in each "version"
> is very similar with only a few minor differences (standard number, label
> size, address placement, font used, etc.). If that is the case, the
> versioning scheme you've developed is very inefficient and difficult to
> maintain.
>
> I would recommend that you examine the workflow processes from a much
> broader view. For example, to print a label, you would need to know it's
> total size, type (water resistant, semi-gloss, etc.), printable area, and
> so on. Presumably all of your labels have common attributes like these
> (don't think about specific values at this point).
>
> Gather all of those common attributes for handy reference. In addition,
> generate a list of unique attributes specific to a label type (perhaps a
> built-in RFID tag ID that only higher-end labels have or something like
> that).
>
> Now the fun/tricky part. There are two design patterns I see to address
> your design.
>
> First pattern:
>
> Generate an abstract model that contains all of the common attributes that
> most or all of your labels will have. This could be things like standard
> number, size, weight, etc. You would then create regular models that
> inherit from your new abstract model. Each of these models would either
> contain no new fields (if everything they need is contained in the abstract
> model), or would add the label-specific fields in. Things like the standard
> number can be made available via class-level attributes (ie standard_number
> = 1700) or via a common function defined in the abstract model that each
> regular model can override if necessary. Here's how I would handle the

Re: User accessibility to multiple versions of an app.

[James Schneider]

On Thu, Jul 20, 2017 at 8:44 AM,  wrote:

> Hey, I've been running into issues trying to figure out how a user could
> be able to access multiple versions of an app.  Here is the following
> example:
>
> I have an app named ANNA.  ANNA is used to build labels and these labels
> are dependent upon different standards that come out.  For example, we have
> standard 1700, standard 1800, standard 1900.  The DjangoProject website has
> a bottom corner button that allows you to go to different versions of the
> django docs.  I would like to implement that into ANNA, however I've come
> across a number of problems.  So ANNA has the following app structure:
>
>
Those buttons refer to different releases of the same application. They
really are just shortcuts to a folder path that points at the particular
release:

https://docs.djangoproject.com/en/1.7/
https://docs.djangoproject.com/en/1.11/
https://docs.djangoproject.com/en/dev/

I haven't investigated, but I'm guessing that each of those URL paths map
back to a directory containing a full release of the Django docs at the
appropriate version.

my_project
>  - ANNA
>  - build(development)
>  - search (development)
>
> I have tried to implement this versioning by the following partition
>
> *PARTITION 1*
>
> my_project
> - ANNA
> - build   (development)
> - search (development)
> - build1700
> - search1700
> - build1800
> - search1800
> - build1900
> - search1900
>
> Unfortunately, the models used in all versions of build are the same
> across the board, and Django's reverse lookup for these models is giving me
> issues.  For instance if I have a label model in build, I will also have a
> label model in build1700, build1800, etc.  So I have to change the model
> names for each version, which means I have to change all of the business
> code to be version specific -- and I really do not want to do that since
> our label standards are also in development and change quite rapidly (like
> every four months right now).  The versions are also similar enough to
> where when a new one comes out, I would like to be able to pretty much copy
> and paste the last version's code into the new version's code and make my
> changes like so.
>
>
Has anyone ever had to do anything like this or have any ideas of how to go
> about it?
>

Disclaimer: I'm obviously not familiar with your application or workflow,
so take this with a grain of salt. My assumption is that you are creating
output for something like shipping labels that have to follow particular
formatting standards. If not, clarity via a brief overview of what your app
does would be helpful.

The abbreviated version of what I have below is "I highly doubt you need
separate apps, but rather a single app with a better model design to
support multiple label/build types."


It appears you are creating a separate application for each label type. In
doing so, I'm assuming that you are copying the code from another "version"
(presumably development) and then modifying the entire application
accordingly. From what I gather, the work being performed in each "version"
is very similar with only a few minor differences (standard number, label
size, address placement, font used, etc.). If that is the case, the
versioning scheme you've developed is very inefficient and difficult to
maintain.

I would recommend that you examine the workflow processes from a much
broader view. For example, to print a label, you would need to know it's
total size, type (water resistant, semi-gloss, etc.), printable area, and
so on. Presumably all of your labels have common attributes like these
(don't think about specific values at this point).

Gather all of those common attributes for handy reference. In addition,
generate a list of unique attributes specific to a label type (perhaps a
built-in RFID tag ID that only higher-end labels have or something like
that).

Now the fun/tricky part. There are two design patterns I see to address
your design.

First pattern:

Generate an abstract model that contains all of the common attributes that
most or all of your labels will have. This could be things like standard
number, size, weight, etc. You would then create regular models that
inherit from your new abstract model. Each of these models would either
contain no new fields (if everything they need is contained in the abstract
model), or would add the label-specific fields in. Things like the standard
number can be made available via class-level attributes (ie standard_number
= 1700) or via a common function defined in the abstract model that each
regular model can override if necessary. Here's how I would handle the
standard number:

class AbstractLabel(models.Model):

_standard_number = None

size_horizontal = models.FloatField...
size_vertical = models.FloatField...
other fields

def get_standard_number(self):
return getattr(self,