From les at dunawaygroupllc.com  Thu Jun  7 11:29:46 2018
From: les at dunawaygroupllc.com (Les Dunaway)
Date: Thu, 07 Jun 2018 11:29:46 -0400
Subject: [Flask] A best practices question
Message-ID: <1528385386.3707938.1399895040.2D1E2700@webmail.messagingengine.com>

Folks,

There's a common sequence of events - put up a screen with
selection options; put up a screen with detail input options;
process; return results
ie: A screen that says "You can make a new widget, update an existing widget or delete a widget"     The user selects make a new widget and the next screen is the input
     form for a new widget     ...

My question is, after a lot of searching and reading, is there a know /
accepted best practice for structuring this sequence
Les Dunaway
770-490-7546


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/flask/attachments/20180607/1a38ebf4/attachment.html>

From jerry.mccreary at mac.com  Thu Jun  7 13:10:09 2018
From: jerry.mccreary at mac.com (Jerry Mccreary)
Date: Thu, 07 Jun 2018 13:10:09 -0400
Subject: [Flask] A best practices question
In-Reply-To: <1528385386.3707938.1399895040.2D1E2700@webmail.messagingengine.com>
References: <1528385386.3707938.1399895040.2D1E2700@webmail.messagingengine.com>
Message-ID: <2E352E3D-8CFF-4475-8D2C-031E58BB2AED@mac.com>

Are you describing a scenario like Flask-Admin handles? 
i.e. Master list view, Detail view with create/update/delete?

Depending on your needs, implementing a REST api may be useful, in that it doesn?t require a full page-reload to create/update/delete records.

--
Jerry

> On Jun 7, 2018, at 11:29 AM, Les Dunaway <les at dunawaygroupllc.com> wrote:
> 
> Folks,
> 
> There's a common sequence of events - put up a screen with selection options; put up a screen with detail input options; process; return results
> 
> ie: A screen that says "You can make a new widget, update an existing widget or delete a widget"
>      The user selects make a new widget and the next screen is the input form for a new widget
>      ...
> 
> My question is, after a lot of searching and reading, is there a know / accepted best practice for structuring this sequence
> 
> Les Dunaway
> 770-490-7546
> 
> 
> _______________________________________________
> Flask mailing list
> Flask at python.org
> https://mail.python.org/mailman/listinfo/flask

From sidwoodstock at gmail.com  Thu Jun  7 14:29:51 2018
From: sidwoodstock at gmail.com (sidwoodstock)
Date: Thu, 7 Jun 2018 11:29:51 -0700
Subject: [Flask] A best practices question (Les Dunaway),
 Flask Digest Vol 36, Issue 1
In-Reply-To: <mailman.39.1528387203.8237.flask@python.org>
References: <mailman.39.1528387203.8237.flask@python.org>
Message-ID: <CALovGGPZNizmikdDXXGUYqtJam5XuZ7uZ0hYVmK309CJuR6fDA@mail.gmail.com>

I was actually just musing on something similar yesterday and I'd love to
hear the Flask community's ideas on best practices as well.

I got the idea of pursuing a more component-based development approach
while looking at Vue.js, which does this. I realized that I have many
statically written pages with very similar components, and I think this
could be a great place to leverage jinja2 macros. ie.. design a component
in jinja2 and pass it few variables--data objects, actions a user can
perform, and perhaps another for various flags--which would then be
consumed by the jinja2 macro to dynamically render the component based on
what it gets passed.

Is this a good practice?

In the vain of Les Dunaway's example, i've also often wondered if it's
better to have switches in a single html/jinja2 template to render these
various steps of a repeating process with a single route/view function or
to split them up into various routes/functions/templates. As with Les, i've
seen it done a million ways and am curious what's best practice!

I hope i'm not hijacking but rather adding to this discussion.

Cheers all,

-Scott Woodstock

On Thu, Jun 7, 2018 at 9:06 AM <flask-request at python.org> wrote:

> Send Flask mailing list submissions to
>         flask at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.python.org/mailman/listinfo/flask
> or, via email, send a message with subject or body 'help' to
>         flask-request at python.org
>
> You can reach the person managing the list at
>         flask-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Flask digest..."
>
>
> Today's Topics:
>
>    1. A best practices question (Les Dunaway)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 07 Jun 2018 11:29:46 -0400
> From: Les Dunaway <les at dunawaygroupllc.com>
> To: flask at python.org
> Subject: [Flask] A best practices question
> Message-ID:
>         <
> 1528385386.3707938.1399895040.2D1E2700 at webmail.messagingengine.com>
> Content-Type: text/plain; charset="utf-8"
>
> Folks,
>
> There's a common sequence of events - put up a screen with
> selection options; put up a screen with detail input options;
> process; return results
> ie: A screen that says "You can make a new widget, update an existing
> widget or delete a widget"     The user selects make a new widget and the
> next screen is the input
>      form for a new widget     ...
>
> My question is, after a lot of searching and reading, is there a know /
> accepted best practice for structuring this sequence
> Les Dunaway
> 770-490-7546
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/flask/attachments/20180607/1a38ebf4/attachment-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Flask mailing list
> Flask at python.org
> https://mail.python.org/mailman/listinfo/flask
>
>
> ------------------------------
>
> End of Flask Digest, Vol 36, Issue 1
> ************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/flask/attachments/20180607/43abb295/attachment.html>

From les at dunawaygroupllc.com  Thu Jun  7 20:05:34 2018
From: les at dunawaygroupllc.com (Les Dunaway)
Date: Thu, 07 Jun 2018 20:05:34 -0400
Subject: [Flask] A best practices question
In-Reply-To: <2E352E3D-8CFF-4475-8D2C-031E58BB2AED@mac.com>
References: <1528385386.3707938.1399895040.2D1E2700@webmail.messagingengine.com>
 <2E352E3D-8CFF-4475-8D2C-031E58BB2AED@mac.com>
Message-ID: <1528416334.3553223.1400404736.314E3240@webmail.messagingengine.com>

Yes, it is like that - however, the question wasn't like that 
I can implement a route to catch a click from a selection;  I can write code to put up the next screen; ... 

My question is is there an accepted way to avoid writing, essentially, the same code for each choice (seems like there must be ;-)

Les Dunaway
770-490-7546

On Thu, Jun 7, 2018, at 13:10, Jerry Mccreary wrote:
> Are you describing a scenario like Flask-Admin handles? 
> i.e. Master list view, Detail view with create/update/delete?
> 
> Depending on your needs, implementing a REST api may be useful, in that 
> it doesn?t require a full page-reload to create/update/delete records.
> 
> --
> Jerry
> 
> > On Jun 7, 2018, at 11:29 AM, Les Dunaway <les at dunawaygroupllc.com> wrote:
> > 
> > Folks,
> > 
> > There's a common sequence of events - put up a screen with selection options; put up a screen with detail input options; process; return results
> > 
> > ie: A screen that says "You can make a new widget, update an existing widget or delete a widget"
> >      The user selects make a new widget and the next screen is the input form for a new widget
> >      ...
> > 
> > My question is, after a lot of searching and reading, is there a know / accepted best practice for structuring this sequence
> > 
> > Les Dunaway
> > 770-490-7546
> > 
> > 
> > _______________________________________________
> > Flask mailing list
> > Flask at python.org
> > https://mail.python.org/mailman/listinfo/flask

From mail at williammayor.co.uk  Fri Jun  8 05:03:40 2018
From: mail at williammayor.co.uk (William Mayor)
Date: Fri, 8 Jun 2018 10:03:40 +0100
Subject: [Flask] A best practices question
In-Reply-To: <2E352E3D-8CFF-4475-8D2C-031E58BB2AED@mac.com>
References: <1528385386.3707938.1399895040.2D1E2700@webmail.messagingengine.com>
 <2E352E3D-8CFF-4475-8D2C-031E58BB2AED@mac.com>
Message-ID: <c7e5fad3-0a76-cdca-4576-1d9cc9f668bc@williammayor.co.uk>

In my experience you can avoid writing lots of boilerplate code using 
libraries like WTForms, Marshmallow, SQLAlchemy, Flask-RESTful, etc. etc.

This mostly leaves you with writing just those bits of code that matter 
to you. What type of ID is this field? How should it validate? etc. etc.

When it comes to gluing the libraries together I just plump for really 
simple, mostly identical routes. Anytime I've tried to refactor these 
routes into reusable classes or helper functions I've found that there 
are always too many exceptions to the rule that force me to deviate.

When there are times that I'm writing substantial bits of route code 
that are all identical, I refactor them into a decorator that I use on 
the routes that need them. This doesn't happen often, as most of the 
time the substantial yet identical code is taken care of by the 
libraries I'm using.

Hope that helps :)

<https://www.postbox-inc.com>


> Les Dunaway <mailto:les at dunawaygroupllc.com>
> 8 June 2018 at 01:05
> Yes, it is like that - however, the question wasn't like that
> I can implement a route to catch a click from a selection; I can write 
> code to put up the next screen; ...
>
> My question is is there an accepted way to avoid writing, essentially, 
> the same code for each choice (seems like there must be ;-)
>
> Les Dunaway
> 770-490-7546
> _______________________________________________
> Flask mailing list
> Flask at python.org
> https://mail.python.org/mailman/listinfo/flask
> Jerry Mccreary <mailto:jerry.mccreary at mac.com>
> 7 June 2018 at 18:10
> Are you describing a scenario like Flask-Admin handles?
> i.e. Master list view, Detail view with create/update/delete?
>
> Depending on your needs, implementing a REST api may be useful, in 
> that it doesn?t require a full page-reload to create/update/delete 
> records.
>
> --
> Jerry
>
> _______________________________________________
> Flask mailing list
> Flask at python.org
> https://mail.python.org/mailman/listinfo/flask
> Les Dunaway <mailto:les at dunawaygroupllc.com>
> 7 June 2018 at 16:29
> Folks,
>
> There's a common sequence of events - put up a screen with selection 
> options; put up a screen with detail input options; process; return 
> results
>
> ie: A screen that says "You can make a new widget, update an existing 
> widget or delete a widget"
>      The user selects make a new widget and the next screen is the 
> input form for a new widget
>      ...
>
> My question is, after a lot of searching and reading, is there a know 
> / accepted best practice for structuring this sequence
>
> ------------------------------------------------------------------------
> Les Dunaway
> 770-490-7546
>
>
> _______________________________________________
> Flask mailing list
> Flask at python.org
> https://mail.python.org/mailman/listinfo/flask

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/flask/attachments/20180608/a90e762e/attachment-0001.html>

From rbw at vault13.org  Wed Jun 20 21:12:12 2018
From: rbw at vault13.org (Robert Wikman)
Date: Thu, 21 Jun 2018 03:12:12 +0200
Subject: [Flask] Introducing Lapdance
Message-ID: <CAEXOqsZA_+3VWhCNOd-RaBr__ww-J2kGOdx2jXeVVtCKTHMX1w@mail.gmail.com>

Hello,

I'm working on an HTTP/LDAP gateway, it's conceptually similar to
Addict?but with more sugar.

Thought I'd share it here as its core is created on Flask.
I'd very much like to hear what you think its application structure?or if
you're interested and have the time?test it out in your environment.

More details here:
https://github.com/rbw0/lapdance

Thanks :)

--
Robert Wikman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/flask/attachments/20180621/d9c4dc78/attachment.html>

From tylerwilliamsct at gmail.com  Sun Jun 24 20:57:27 2018
From: tylerwilliamsct at gmail.com (Tyler Williams)
Date: Sun, 24 Jun 2018 18:57:27 -0600
Subject: [Flask] Contributing Passenger WSGI Instructions
Message-ID: <CADGuvQih_cFvbnM8VCvWe3aqrwmUe3_N1iX5cBN-sjzuZrODpw@mail.gmail.com>

Hey folks,

Recently had to deploy a flask app on Phusion Passenger because I've got
hosting through Dreamhost, and got stumped along the way. I figured it out,
eventually. But then a few weeks later had to re-deploy and hadn't written
down my process anywhere.

Needless to say, I hit the same few road bumps. It took me longer than I'd
like to admit/longer than it should have, but i figured it out again.

This time, I documented my process. I'd love to contribute that
documentation to the Flask website, if that's appropriate. What's the best
way for me to submit this for consideration. Any standards I should keep in
mind in that submission?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/flask/attachments/20180624/db9d94f3/attachment.html>

From coreybrett at gmail.com  Mon Jun 25 08:18:02 2018
From: coreybrett at gmail.com (Corey Boyle)
Date: Mon, 25 Jun 2018 08:18:02 -0400
Subject: [Flask] Contributing Passenger WSGI Instructions
In-Reply-To: <CADGuvQih_cFvbnM8VCvWe3aqrwmUe3_N1iX5cBN-sjzuZrODpw@mail.gmail.com>
References: <CADGuvQih_cFvbnM8VCvWe3aqrwmUe3_N1iX5cBN-sjzuZrODpw@mail.gmail.com>
Message-ID: <CAD=ssw09cyj7kwwZak6U1rMc9-tRnZK9t5BR78H0_ttJ8TY0sQ@mail.gmail.com>

I think you would just do a PR against
https://github.com/pallets/flask/tree/master/docs/deploying

I would love to see what you have for Dreamhost. I have several Flask
sites with them myself.
On Sun, Jun 24, 2018 at 8:59 PM Tyler Williams
<tylerwilliamsct at gmail.com> wrote:
>
> Hey folks,
>
> Recently had to deploy a flask app on Phusion Passenger because I've got hosting through Dreamhost, and got stumped along the way. I figured it out, eventually. But then a few weeks later had to re-deploy and hadn't written down my process anywhere.
>
> Needless to say, I hit the same few road bumps. It took me longer than I'd like to admit/longer than it should have, but i figured it out again.
>
> This time, I documented my process. I'd love to contribute that documentation to the Flask website, if that's appropriate. What's the best way for me to submit this for consideration. Any standards I should keep in mind in that submission?
> _______________________________________________
> Flask mailing list
> Flask at python.org
> https://mail.python.org/mailman/listinfo/flask

From jerry.mccreary at mac.com  Mon Jun 25 09:47:30 2018
From: jerry.mccreary at mac.com (Jerry Mccreary)
Date: Mon, 25 Jun 2018 09:47:30 -0400
Subject: [Flask] Contributing Passenger WSGI Instructions
In-Reply-To: <CADGuvQih_cFvbnM8VCvWe3aqrwmUe3_N1iX5cBN-sjzuZrODpw@mail.gmail.com>
References: <CADGuvQih_cFvbnM8VCvWe3aqrwmUe3_N1iX5cBN-sjzuZrODpw@mail.gmail.com>
Message-ID: <6FBD2A48-92C7-442A-A054-B07F14C853E9@mac.com>

Another compilation of instructions:  https://macfire.github.io/devops16/ <https://macfire.github.io/devops16/>

(Doesn?t answer your question, but is related information)


> On Jun 24, 2018, at 8:57 PM, Tyler Williams <tylerwilliamsct at gmail.com> wrote:
> 
> Hey folks, 
> 
> Recently had to deploy a flask app on Phusion Passenger because I've got hosting through Dreamhost, and got stumped along the way. I figured it out, eventually. But then a few weeks later had to re-deploy and hadn't written down my process anywhere. 
> 
> Needless to say, I hit the same few road bumps. It took me longer than I'd like to admit/longer than it should have, but i figured it out again. 
> 
> This time, I documented my process. I'd love to contribute that documentation to the Flask website, if that's appropriate. What's the best way for me to submit this for consideration. Any standards I should keep in mind in that submission?
> _______________________________________________
> Flask mailing list
> Flask at python.org
> https://mail.python.org/mailman/listinfo/flask

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/flask/attachments/20180625/1459377d/attachment.html>