Figure 1 - Blueprints Modularized version of Biography Application
In a retrospect, the intention that drive me in finishing this Flask Biography Application is because I would like to start a series that extensively talk about Python Cloud Computing. As I deploy the application in PythonAnywhere, I realize that the application structure is far from complete (I dare not to say perfect..). Back at that time, I throw all application's classes, object, method, configuration, etc, into a single Python file (or let's call it Python module. It's much more Pythonic that way). For the sake of simplicity, it's cool actually. But things will become seriously ill, if the application begins to grows.
In the previous article, we have done an initial work of restructuring the single application module into several modules and using Flask-Classy to better manage our routes/views method. But the restructuring work is not yet finished: you can't clearly see any separation of concerns (a.k.a application features) toward the existing application code. And that's where Flask Blueprints nicely fits into our discussion.Taken from Armin own writing, "Blueprints can greatly simplify how large applications work and provide a central means for Flask extensions to register operations on applications. A Blueprint object works similarly to a Flask application object, but it is not actually an application. Rather it is a blueprint of how to construct or extend an application". At the moment we won't talk about Flask Extension, instead we will obey Armin's word, that Flask Blueprints object, is blueprint (sorry for the blueprintception) to construct or extend an application. Meaning, to construct a large Flask application, one must use Flask Blueprint object in doing so. Coupled with the proper use of Python package and module, you will be able to construct a large Flask application in a much effective way.
Great, what are we waiting for? Let's go deeper!(More)
Splitting main.py module/file into several *.py files/modules
If you have followed this Flask series until this article, you will know that up until now our Flask article still lived inside a single file:
main.py. Is it a bad practice? Perhaps. But it really is fun. It is a proof that a web application can be contained within one single Python module, which is a realization of the initial April Fools Joke that drive the creation of our beloved Flask web framework: it's possible to create such, but certainly not advisable.
Having said that, Flask still don't impose any strict directory organization or modules separation. Compare this with Django, where it come up with a monolithinc ready to use project directory that you must adhere, in Flask world, you can freely to choose to follow a simple organization of your Flask application into package as this official guide shows you, or turning your Flask application into a highly modular application using Blueprints. In this article we are going to implement a much more simplified version of Flask project directory organization : splitting
main.py module into several
*.py files/modules that wrap logically related class/code into its own module. The idea is simple: e.g., if you want to add a new form, you don't have to scroll through the code that talks about models. In the next subsequent article, we will then modularize our application using Blueprints.
Let's get started!(More)
Utilizing X-editable to in-place editing our biography page
UPDATED: Previously I said that I use
wsgi/static/upload to store user's uploaded avatar. Although it's working, it still imposed one important problem: the content of
wsgi/static/upload itself will be removed for each subsequent
git push command. We must store user's data into
$OPENSHIFT_DATA_DIR/upload directory. How do we do this? Simple. First, (if it's currently existed) remove the folder
wsgi/static/upload, and then create an executable binary script within the folder
.openshift/action_hooks/post_deploy, with the content:
ln -sf $OPENSHIFT_DATA_DIR/upload $OPENSHIFT_REPO_DIR/wsgi/staticgi/static/. Make sure to set the flag bit into executable using the command:
chmod +x post_deploy (I don't think you can do this in Windows. *nix/OSX will do just fine for this).This script will be run each time we push the repository to Openshift --after the application successfully deployed, making a link to upload directory of user's uploaded avatar. This way, user's avatar will get stored in
$OPENSHIFT_DATA_DIR/upload and will always available each time we push our application to Openshift.
As I start a new series on this blog about Python Cloud Computing and working my first way of making our Flask Biography Application runnable within PythonAnywhere, I realize that I haven't completed the last important thing for this application to be fully functional: editing biography for registered users. This biography application will become practically useless if users don't have the ability to edit their full name, tagline, avatar and short biography. Having said that, let's make it even better by implementing in-place editing for all those fields, where in-place editing simply means users will be able to edit those fields directly within the same page. We are going to use Vitaliy Potapov's X-editable for this purpose. It's an awesome Open Source product!
PythonAnywhere simple and unique online working environment
My first series in this blog was about Python Cloud Computing: developing Flask application and using Openshift to properly manage and deploy it. This is a series that bring another possibility: why don't I complete this blog with practical hands-on using another Python Cloud Computing solution? The internet is filled with this Platform as a Service solution. Some specifically state that they are Python only solution, other are much more general and open in nature. Having practical hands-on on the usage of some of them will add another advantage to this blog. Although, I am not sure that I can dive to all of the existing Cloud Computing/PaaS solution. For the most part, I will be unable to explore at the fullest on cloud solution that require actual billing to use important features such as database access, e.g Google Cloud or Amazon Web Services. In this regard, I really love Openshift way of attracting developers to use their platform: a 1GB storage including user uploaded files and database. I don't think there are other PaaS solution out there that can surpass this free offering.Well then, lets start at our first stop : PythonAnywhere.
Although I never marked our live Bio Application as published, actually at the current state it shouldn't be treated as a production quality application. The main reason is simple : up until now, our database will always be recreated when application started, discarding any data already entered by our users. We do this to allow us focusing our work on perfecting application features than to manage our own database migration script.
Today we are going to have a look on how exactly a database migration technique is implemented. It will allow our application to be stamped as Production Quality application, as it will allow users to registered safely into our application. Whatever development changes we introduce, our users data will not just get thrown to the void. The database schema will be upgraded and existing data will be merged to the new schema.
In our beloved Python world there are plenty of database migration tools available. But as we use SQLAlchemy, well, don't you think that the author of SQLAlchemy should be the the legitimate author to write its database migration tool? Well then, introducing Alembic!
I got to admit something : I really have fun writing this current article! It shows concise way for new comer in Python web development area to truly understand how to integrate Bootstrap and its extensions, jQuery and Flask to build feature that increase user experience in interacting with the application.
Previously we haven't utilize jQuery and many Bootstrap extensions there exist in the web, making our application solely depends on what Flask community gave us (which is great!). But, as we already choose to leverage Bootstrap 3 in our application, this decision bring great advantage : we can easily tap to plethora of Bootstrap extension built by community and add it in our own application to gain benefit of its functionality. Specifically we are going to maximize the use of this open source products to our application:
.postmethod to allow our Portfolio form live as a modal dialog box complete with Ajax validation and Ajax form submission. I got to beg you pardon for this, for thinking in the previous post that we have to use jQuery client side validation. Turn out what I really want is an Ajax based validation technique. I will explain later what are the differences. But one important thing is, we don't have to double our validation mechanism complexity by also implementing it in client-side.
Ready? Let's start!
Figure IX-1 Portofolio grid in Bio Page complete with action buttons
Before we going further on our journey of making a fully functional Bio Application, lets return to our early concept of this application : product portfolio show case. And guess what we missed. Correct. We missed the required application model for a product portfolio. If you rethink our application models until this state, we know we haven't add a portfolio model/table. This part of article series will guide you on how exactly it's done by adding
Portfolio model using SQLAlchemy
relationship field in our existing
I assess myself as no security expert, but storing a plain text password in a database is surely a bad practice. If someone (probably hacker) gain access to your database, (s)he can easily read your users password. Without any hassle. In this article I will show how you can easily utilize python
md5 package to convert our users password into MD5 string and making curious hacker not that easy in reading it.
rahasia is Indonesian word for
In adding Sign In feature for our Bio Application, I have decided one important thing : the login status or form should always available and already opened in Navbar. Because Bootstrap 3 Navbar if properly setup will always available at the top of every page, this will result in a persuasive sign in form : a kind of form that engage user to directly fill its input fields and hit Submit button! Wherever (s)he is... (More)
Welcome to the sixth instalment of this Bio Application Development Tutorial. I constructed this tutorial, in such a way that even a newcomer in Python will be able to grasp its content and follow it easily. Thanks to Python intuitive coding environment, my job is not that hard. But it is you who really decide whether my goals are met or I still have to refine how I presented ideas, instructions and concepts.
Previously, our Bio Application having its first data access capability by using a great ORM tool, SQLAlchemy. It able to construct Users tables, populate data and query those data. But it still lack an important feature : a visitor still unable to register him/herself into our application. In this article, we are going to show you how exactly it is done.
In this fifth article we are going to liven up our bio application with real data coming from the database. From our previous post, we already have a nice visual representation of our bio application. Now it is time to supply its content with user very own data. It will make your application feels so nice. Alive.
We are going to utilize SQLAlchemy to do :
A sharp eyed reader may notice, "How do you populate those data? I don't see any user signup action there!". Correct! We are going o skip those important feature for now. Here, I am going to concentrate you on the SQLAlchemy part. I think my next article will going to talk about those Signup form.
If you have followed this article until this point, it means that you really curious on how you can develop a working Python web application. Previously we have understand how to create a working (but dumb) Flask application. Today we are going to start by laying out our application user interface using a very cool front-end framework : Bootstrap.
As I write my 4th article talking about using Bootstrap 3 and Jinja for application layout and templating, I realize that in my last post, I neglect a clear and complete instructions of preparing local Python environment both for Windows and OSX users. I only focusing on Linux users (or, Ubuntu/Debian derived distro to be precise). As I use those three OSes in a VirtualBox environment, I feel like I had to write it. Let's begin with the most irritating development environment to work with : Windows.
Now that we have a clear understanding of what the application that we are going to build, we can directly start our code. I am going to use bio as the project name of our application. If you haven't create it, you can follow the first series of the article here. From inside bio folder you will find several files and folders. For starter, lets open the file setup.py and inspect its contents :
from setuptools import setup setup(name='YourAppName', version='1.0', description='OpenShift App', author='Your Name', email@example.com', url='http://www.python.org/sigs/distutils-sig/', # install_requires=['Django>=1.3'], )
If you followed this article series until now, I can safely assumed that you have already registered to Openshift and able to use RHC client tool to create a Python application there. If not, you may want to follow the first article here. In Part II of series of this article, I would like to create a solid ground understanding of what the application we built like.
Copyright(c) 2014 - PythonBlogs.com
All rights reserved