4elements, Amsterdam, Holland

  1. Create a Custom Payment Method Module in Magento: Part One

    Being a successful e­-commerce framework, Magento provides lots of payment methods in the core itself. However, you can also create a custom payment method extension to plug in your choice of payment gateway, if it's not already available. 

    In this series, we're going to look at the process of creating a custom payment method extension. In this article, we'll start with the back­-end section by setting up a configuration for our custom payment method.

    I assume that you're familiar with basic module creation process in Magento. If not, you can refer to this article on custom module development.

    A Glance at the File Setup

    We'll create a custom module "Custompaymentmethod", so let's have a look at the list of files required for the back­-end configuration setup.

    • app/etc/modules/Envato_All.xml: It's a file used to enable our custom module.
    • app/code/local/Envato/Custompaymentmethod/etc/config.xml: It's a module configuration file in which we'll declare our custom payment method.
    • app/code/local/Envato/Custompaymentmethod/etc/system.xml: It's a system configuration file in which we'll set up configuration options for our custom payment method.
    • app/code/local/Envato/Custompaymentmethod/sql/custompaymentmethod_setup/install­-1.0.0.0.php: It's an SQL file which we'll use to create custom fields for our custom payment method.

    Create Files and Folders

    First, we need to create a module enabler file. Create a file "app/etc/modules/Envato_All.xml" and paste the following contents in that file. We've used "Envato" as our module namespace and "Custompaymentmethod" as our module name. It'll enable our "Custompaymentmethod" module by default.

    Nothing fancy here—we've just declared our module under the "local" code pool. However, the important thing to note here is that we've declared that our extension depends on the core "Mage_Payment" extension.

    Moving ahead, create an "app/code/local/Envato/Custompaymentmethod/sql/custompaymentmethod_setup/install­-1.0.0.0.php" file with the following contents.

    It's an install file of our module which will create "custom_field_one" and "custom_field_two" fields in the payment related tables.

    Next, we need to create a module configuration file. Create "app/code/local/Envato/Custompaymentmethod/etc/config.xml" and paste the following contents in that file.

    Let's have a look at some of the important elements in a "config.xml" file. In the front­-end checkout process, when a user selects our custom payment method, we'll show two text boxes for inputting the information. These are just for the purpose of demonstrating the use of custom fields in a front­-end payment method. 

    We'll see that in detail a bit later, but for now just assume that we need to save custom fields related to our custom payment method during the order creation. The <fieldsets> and <sales_convert_quote_payment> tags are exactly for that purpose—they'll tell Magento to save these fields as well with order information.

    Next, we've declared the usual helpers, blocks and models related tags, which we'll implement in the other parts of this series. Further, we've declared resources for our custom module using the <custompaymentmethod_setup> tag. Recall the "install­-1.0.0.0.php" file we mentioned earlier. Yes, it's exactly related to that install file. Magento will detect this file, and run the necessary SQL install scripts for our module.

    Finally, we plug in our custom payment method using the <custompaymentmethod> tag under the <payment> tag. Under that tag, we've set up the default configuration for our payment method like "active", "order_status", "payment_action", etc. At the end of the file, we've declared a front­-end router for our module, which will be implemented in the other parts of this series.

    Let's move on to the next important file, the "system.xml" file. Create a file "app/code/local/Envato/Custompaymentmethod/etc/system.xml" and paste the following contents in that file.

    In this file, we simply declare configurable fields for our custom payment method. Go ahead and enable the module from the back­-end. Go to System > Configuration > Sales > Payment Methods, which will list all the payment methods. You should see "CustomPaymentMethod Module" listed as one of the payment methods!

    Back-End Payment Method Configuration

    Conclusion

    Today, we've just looked at the initial back-end configuration setup for our custom payment method. In the upcoming articles of this series, we'll see its front-end counterpart. Don't forget to share your thoughts using the feed below.

     

    0 Comments

    Leave a comment › Posted in: Daily

    1. Create a Custom API in Magento: Part One

      Introduction

      For any successful platform, it's vital to keep up with the cutting edge features and provide them to compete in the market. Exposing APIs for your platform is one of the important features which allows integration with third-party systems, thus opening the doors to reach the larger community. Magento, being one of the most successful e­Commerce platforms, provides a plethora of useful features and utilities which proves it a truly enterprise level framework.

      Exposing APIs for your resources is beneficial in many ways. One of the most apparent is that it makes your resources available on different platforms, thus making them platform independent, thanks to protocols like XML­-RPC/SOAP, which allows you to expose your resources in a streamlined manner. We'll use SOAP for our custom module.

      In this tutorial, we'll create a custom module "Customapimodule". I assume that you're familiar with the basic module creation process in Magento. Here's a nice article explaining the basics of custom module creation.

      A Glance at the File Setup

      Here's the list of files required for the desired setup:

      • app/etc/modules/Envato_All.xml: It's a file used to enable our custom module.
      • app/code/local/Envato/Customapimodule/etc/config.xml: It's a module configuration file.
      • app/code/local/Envato/Customapimodule/etc/api.xml: It's a file which declares the APIs provided by our module.
      • app/code/local/Envato/Customapimodule/etc/wsdl.xml: In this file, we'll define the API methods as per the conventions of WSDL.
      • app/code/local/Envato/Customapimodule/Helper/Data.php: It's a file used by the Magento translation system.
      • app/code/local/Envato/Customapimodule/Model/Product/Api.php: It's a model file which implements the logic of our API methods.
      • app/code/local/Envato/Customapimodule/Model/Product/Api/V2.php: It's a file to support Magento's v2 API.

      Custom Module Creation: Setting Up the Files

      To start with, we'll create a module enabler file. Create a file "app/etc/modules/Envato_All.xml" and paste the following contents in that file. We've used "Envato" as our module namespace and "Customapimodule" as our module name. It'll enable our "Customapimodule" module by default.

      Next, we need to create a module configuration file. Create "app/code/local/Envato/Customapimodule/etc/config.xml" and paste the following contents in that file.

      Nothing fancy here—we've just declared the "Model" and "Helper" classes as per the Magento conventions.

      Moving ahead, create "app/code/local/Envato/Customapimodule/etc/api.xml" and paste the following contents in that file. The "api.xml" file is used to declare the API methods exposed by your module.

      We'll start with the <resources> tag, which wraps all the resources declared by your module. You could think of "resource" as an entity, using which you would like to categorize your API methods. 

      In our example, we've just declared a single resource named <customapimodule_product>. You can name it whatever you like, as long as it's a unique identifier. Under the <customapimodule_product> resource tag, we've declared the <model> tag to link the Magento "Model" file, where we'll define the API method definitions. The methods for our resources are wrapped by the <methods> tag. In our case, we've only defined a single method, "items", under the <list> tag, which will provide a list of products.

      Further, the <acl> tag under <customapimodule_product> is used to provide access control for our resources. The value defined in the <acl> tag "customapimodule/product" references the definition at the bottom of the file. 

      At the bottom of the file, you can see that we've declared a separate <acl> tag which defines the "customapimodule/product". In short, it's used to put our resources under access control, so that they can be accessed by certain "API Roles" if they're defined in that way in the Magento back­-end. We'll discuss this more in detail in the next part of this tutorial.

      At the moment, two versions of the Magento API are supported, v1 and v2, using which you can create and expose APIs. In our example, we'll see both the methods. The <resources_alias> tag is used to define a resource alias name by which our method will be called. We've defined it as <product>, so whenever you want to call an API method using Magento v1 API, you will use "product" as a resource prefix. In the same way <v2> defines a resource alias for the Magento v2 API, so the resource prefix will be "customapimoduleProduct". These things will be clearer when we see how to call our APIs in the next tutorial.

      Next, let's create the "app/code/local/Envato/Customapimodule/etc/wsdl.xml" file and paste the following contents.

      The "wsdl.xml" file is used to define the API method definitions as per the SOAP syntax. We'll see some of the important tags in this file in the context of this tutorial. 

      First, we've defined the "fieldInfo" complex type, which contains two elements: "entity_id" and "name". Further, we've defined the "fieldInfoArray" complex type, which is derived from the "fieldInfo" complex type. It's an array of the "fieldInfo" complex type. 

      In simple terms, we've defined the object properties which will be returned in the response of the API method call. In our case, we'll return an array of products. Each item of an array will have two properties: "entity_id" and "name" of the product. You can define more properties as per your requirements.

      Next, under the <message> tag "customapimoduleProductListRequest", we've defined the input parameters required using the <part> tag. In the same way, under the <message> tag "customapimoduleProductListResponse", we've defined the type of the output objects. When we call an API method, we need to pass "sessionId", and the response of the API method will contain the array of products. The rest of the tags will make our method appear when you call http://yourmagentostore/api/v2_soap?wsdl=1.

      Next, we'll need to create the "app/code/local/Envato/Customapimodule/Helper/Data.php" file just to make sure the translation system of Magento works properly. It's almost an empty file, but should be there as per the conventions!

      Next, let's create a model file "app/code/local/Envato/Customapimodule/Model/Product/Api.php".

      Recall that earlier in the "api.xml" we defined an "items" method wrapped by a <list> tag. So in the above model class, we've just implemented this. 

      In this method, we simply fetch five recent products, and iterate through each of the items to prepare an array of products with the properties "entity_id" and "name". So now you should probably understand the reason for the "Complex Type" created in "wsdl.xml"!

      Further, we also need to create a model file to support the Magento v2 API. Let's create a model file "app/code/local/Envato/Customapimodule/Model/Product/Api/v2.php" with the following contents.

      As you can see, it's just extending a model class defined earlier in the "app/code/local/Envato/Customapimodule/Model/Product/Api.php" file.

      So that's it as far as the file setup is concerned for the custom API implementation. If you're curious, enable the module from the back­-end and clear the cache. Now, when you visit the http://yourmagentostore/api/v2_soap?wsdl=1 page, you should see our method "customapimoduleProductList" is listed along with the other APIs!

      In the next part, we'll go ahead and see how to create API user and API role, and of course, how to use our custom API method defined in this tutorial!

       

      0 Comments

      Leave a comment › Posted in: Daily

    1. Creating a Web App From Scratch Using Python Flask and MySQL: Part 7

      In the previous part of this series, we implemented image upload functionality for the users while adding a wish. We also added a few more options related to a user's wish on the Add Wish page. In this tutorial, we'll take it to the next level by implementing the functionality to like a particular wish.

      Getting Started 

      Let's start by cloning the previous part of the tutorial from GitHub.

      Once the source code has been cloned, navigate to the project directory and start the web server. 

      Point your browser to http://localhost:5002/ and you should have the application running.

      Creating the Dashboard UI

      We'll be creating a new page called dashboard where all the wishes from different users will be displayed. Any user can like or comment on the wishes displayed in the dashboard. So navigate to the templates folder and create a file called dashboard.html. Open up dashboard.html and add the following HTML code:

      Open up app.py and create a new route called /showDashboard. Using this route we'll render the dashboard page.

      Modify the /validateLogin method to redirect the user on successful sign-in to the dashboard page instead of the user home page.

      Save the above changes and restart the server. Point your browser to http://localhost:50002 and sign in using a valid email address and password. Once signed in, you should be able to see the dashboard page.

      Dashboard Page

      As seen in the image above, we'll be showing all the wishes created by different users and giving access to other users to like them.

      Populate the Dashboard

      First, we need to fetch the data from the database to populate the dashboard. So let's create a stored procedure to get the wishes created by users.

      The above stored procedure will fetch all the wishes from tbl_wish which are not marked as private.

      Next, we'll create a new Python method to call the stored procedure sp_GetAllWishes. Open app.py and add the following code for the getAllWishes method.

      In the above method, we have first checked for a valid user session and then created a MySQL connection. Using the MySQL connection conn, we used a cursor to call the stored procedure sp_GetAllWishes to get the required data. Once the data has been fetched, we have parsed the result and returned a proper JSON string.

      We'll call the above created /getAllWishes method when the dashboard page loads. Open dashboard.html and, using jQuery AJAX, make a call to /getAllWishes on document.ready.

      Save the above changes and restart the server. Once logged in to the application, check your browser console and you should be able to view the data fetched from the database.

      Using the data from the response, we'll populate our dashboard page. First, remove the HTML code between the .well div from dashboard.html.

      In the success callback of the AJAX call, parse the response to a JavaScript object.

      We'll need to create the thumbnail HTML code dynamically using jQuery for each set of three wishes in a row. So first let's create a JavaScript function to create the HTML code dynamically. Here is the HTML code that we'll be creating dynamically using jQuery:

      We'll name the JavaScript function CreateThumb. In this function, we'll create the HTML elements and append them to their parent elements to get the HTML code shown above.

      The above code is quite straightforward so I won't be going into the details.

      Moving forward, we'll iterate the parsed JSON response and create the HTML using the CreateThumb function. We plan to display three wishes per row. So we'll check for that and create a new row each time for three wishes. Add the following code to the success callback of the AJAX call in dashboard.html.

      Save the changes and restart the server. Sign in to the application and when on the dashboard page, you should be able to view the wishes added by different users, with an option to like them.

      Next, let's add a click event to the like buttons under the wishes thumbnails. Since we have dynamically created the buttons, we'll need to attach the click event to the buttons using the jQuery on method. 

      Implementing Like Functionality

      Let's start by creating a table which will keep track of the likes a particular wish has garnered. Create a table called tbl_likes

      Now whenever a user likes or dislikes a particular wish, we'll update this table. Let's create a MySQL stored procedure to update the above table.

      In this stored procedure, we have simply checked if the person has already liked the wish or not. If he or she has already liked, then we have updated that like entry or added a new one.

      Let's create a Python method to call the above stored procedure.

      This is the Python method which will call the stored procedure sp_AddUpdateLikes. In this method we have checked for a valid user session and then passed the wish ID and like status to the stored procedure for update. When the user clicks the like button, we need to call the Python method /addUpdateLike. So add the following code to the like button click event function in dashboard.html

      For the time being, we have hard-coded the value of like in the above call. So save the changes and restart the server. Sign in to the application and click on the like button under any wish thumbnail. Now check tbl_likes and you should have an entry in there.

      Conclusion

      In this part of the tutorial, we populated the dashboard page of our application with the wishes created by different users. We also attached a like button to each so that users can like a particular wish. In the next part, we'll see how to toggle the like display and show the total number of likes received by a particular wish.

      Post your suggestions or any corrections in the comment box below. Source code from this tutorial is available on GitHub.

       

      0 Comments

      Leave a comment › Posted in: Daily

    1. The Tuts+ Guide to Template Tags: Third Batch

      In the third part of the series, we went through the second batch of WordPress template tags. In this fourth part, we're going to go through the third batch of the almost 200 template tags. Throughout the tutorial, we'll see template tags about comments.

      Getting & Displaying the Comment Author's Name: get_comment_author() & comment_author()

      These template tags return or display the name of the commenter.

      Parameters

      Both template tags accept only one parameter:

      • $comment_ID (optional—integer):
        The ID of the comment to work with.
        (Default: current comment's ID)

      Usage

      Getting & Displaying the Comment Author's Name for Feeds: get_comment_author_rss() & comment_author_rss()

      These template tags return or echo the comment author's name and makes it ready to display on feeds.

      Parameters

      These template tags don't accept any parameters.

      Usage

      Getting & Displaying the Comment Author's Email Address: get_comment_author_email() & comment_author_email()

      These template tags let you return or echo the email address of the commenter. (Warning: It's not cool to display commenters' email addresses in the front-end to the public, so make sure you're using it right.)

      Parameters

      Both template tags accept only one parameter:

      • $comment_ID (optional—integer):
        The ID of the comment to work with.
        (Default: current comment's ID)

      Usage

      Getting & Displaying a Link of the Comment Author's Email Address: get_comment_author_email_link() & comment_author_email_link()

      These template tags let you return or echo the commenter's email address as a mailto: link.

      Parameters

      Both template tags accept three parameters:

      • $linktext (optional—string):
        Text to display instead of the comment author's email address.
        (Default: The email address)
      • $before (optional—string):
        The text or HTML code to display before the output.
        (Default: Empty)
      • $after (optional—string):
        The text or HTML code to display after the output.
        (Default: Empty)

      Usage

      Getting & Displaying the URL of the Commenter: get_comment_author_url() & comment_author_url()

      These template tags let you return or display the URL of the website of the comment author.

      Parameters

      Both template tags accept only one parameter:

      • $comment_ID (optional—integer):
        The ID of the comment to work with.
        (Default: current comment's ID)

      Usage

      Getting & Displaying the Link of the Commenter (With Author Name as Anchor Text): get_comment_author_link() & comment_author_link()

      These template tags get or echo the website link of the commenter with the commenter's name as the anchor text.

      Parameters

      Both template tags accept only one parameter:

      • $comment_ID (optional—integer):
        The ID of the comment to work with.
        (Default: current comment's ID)

      Usage

      Getting & Displaying the Link of the Commenter (With Custom Text): get_comment_author_url_link() & comment_author_url_link()

      These template tags allow you to get or echo the link of the commenter's website with a custom text as the anchor.

      Parameters

      Both template tags accept three parameters:

      • $linktext (optional—string):
        Text to display.
        (Default: The URL)
      • $before (optional—string):
        The text or HTML code to display before the output.
        (Default: Empty)
      • $after (optional—string):
        The text or HTML code to display after the output.
        (Default: Empty)

      Usage

      Getting & Displaying the IP Address of the Commenter: get_comment_author_IP() & comment_author_IP()

      These template tags return or display the IP address of the comment author.

      Parameters

      Both template tags accept only one parameter:

      • $comment_ID (optional—integer):
        The ID of the comment to work with.
        (Default: current comment's ID)

      Usage

      Getting & Displaying the Content of the Comment: get_comment_text() & comment_text()

      These template tags get and display the comment's content.

      Parameters

      Both template tags accept only one parameter:

      • $comment_ID (optional—integer):
        The ID of the comment to work with.
        (Default: Current comment's ID)

      Usage

      Displaying the Content of the Comment for Feeds: comment_text_rss()

      This template tag takes the comment content and makes it ready to display in feeds.

      Parameters

      This template tag doesn't accept any parameters.

      Usage

      Getting & Displaying the Excerpt of the Comment: get_comment_excerpt() & comment_excerpt()

      These template tags take the comment's content and cut it to show an "excerpt" of it.

      Parameters

      Both template tags accept only one parameter:

      • $comment_ID (optional—integer):
        The ID of the comment to work with.
        (Default: current comment's ID)

      Usage

      Getting & Displaying the Date of the Comment: get_comment_date() & comment_date()

      These template tags echo or return the date when the comment was posted.

      Parameters

      Both template tags accept two parameters:

      • $date_format (optional—string):
        The format of the date.
        (Default: Date format set in the General Options page)
      • $comment_ID (optional—integer):
        The ID of the comment to work with.
        (Default: Current comment's ID)

      Usage

      Getting & Displaying the Time of the Comment: get_comment_time() & comment_time()

      These template tags return or echo the time the comment was posted.

      Parameters

      get_comment_time() accepts three parameters:

      • $time_format (optional—string):
        The format of the time.
        (Default: Time format set in the General Options page)
      • $gmt (optional—boolean):
        Whether to use the GMT date.
        (Default: FALSE)
      • $translate (optional—boolean):
        Whether to pass to date_i18n() function to translate the date.
        (Default: TRUE)

      And comment_time() accepts only one parameter:

      • $time_format (optional—string):
        The format of the time.
        (Default: Time format set in the General Options page)

      Usage

      Getting & Displaying the ID of the Comment: get_comment_ID() & comment_ID()

      These template tags do a very simple job: They get the ID of the comment.

      Parameters

      These template tags don't accept any parameters.

      Usage

      Displaying the Type of the Comment: comment_type()

      This template tag lets you display the type of the comment—a normal comment, a trackback, or a pingback.

      Parameters

      This template tag accepts three parameters:

      • $commenttxt (optional—string):
        Text to display for "comment" type.
        (Default: 'Comment' )
      • $trackbacktxt (optional—string):
        Text to display for "trackback" type.
        (Default: 'Trackback')
      • $pingbacktxt (optional—string):
        Text to display for "pingback" type.
        (Default: 'Pingback')

      Usage

      Getting the Avatar of a User: get_avatar()

      This template tag lets you get the "avatar" of a user.

      Parameters

      This template tag accepts four parameters:

      • $id_or_email (required—string, integer or object):
        A user ID, email address, or comment object.
        (Default: NULL)
      • $size (optional—integer):
        The size of the avatar in pixels.
        (Default: 96)
      • $default (optional—string):
        URL of the custom "default image", if there's no avatar available.
        (Default: Empty)
      • $alt (optional—string):
        The alternative text (alt parameter) for the image.
        (Default: FALSE)

      Usage

      Conclusion

      Hope you liked this third batch of template tags. There are five more batches to go, so stay tuned for more template tags!

      If you have any questions, comments or corrections, you can share your thoughts with us in the Comments section. And if you liked the article, don't forget to share it with your friends!

       

      0 Comments

      Leave a comment › Posted in: Daily

    1. Creating a Web App From Scratch Using Python Flask and MySQL: Part 6

      In the previous part of this series, we implemented paging for the wish list on the user home page. In this part of the series, we'll implement an option for the user to upload an image representing a wish, an option to mark the wish as accomplished, and an option to set privacy.

      Getting Started 

      Let's start by cloning the previous part of the tutorial from GitHub.

      Once the source code has been cloned, navigate to the project directory and start the web server. 

      Point your browser to http://localhost:5002/ and you should have the application running.

      Modifying the User Interface

      Let's start by modifying our "add wish" page to include an option to upload an image. Navigate to templates/addWish.html. Our form in addWish.html looks quite small, so let's modify the bootstrap HTML code to make the form vertical. 

      First, we'll modify the form-horizontal to a vertical form, so remove the class form-horizontal from the form. We'll also add three new controls: a file upload control to upload photos, a check box to mark the wish as private, and another check box to mark the wish as completed. Here is the modified addWish.html.

      Save the above change and restart the server. After signing in successfully, click on the Add Wish link and you should be able to see the modified add wish page.

      Add Wish Page with Image Upload

      Implementing Upload Functionality 

      We'll be using blueimp jQuery-File-Upload to implement the file upload functionality. Download the required the files from GitHub. Extract the source and add the following script references to addWish.html.

      On addWish.html page load, add the plugin initiation code to the file upload button click.

      As seen in the above code, we have attached the file upload plugin to the #fileupload button. The file upload plugin posts the file to the /upload request handler, which we'll define in our Python code. We have also defined an add function to submit the data, and defined success and failure callbacks to handle the upload success and failures.

      Next, let's define the upload Python file upload handler in app.py. Define a route /upload as shown:

      Check if the request is a POST request, and if so read the file from request.

      We'll also need to get the image file extension to save the file. So import os and then split the extension name from the file name.

      Once we have the file extension, we'll create a new unique file name using uuid. Import uuid and create the file name.

      Create a folder called Uploads in the static folder. This is where we'll keep the uploaded images. Add the path to the Upload folder in the app configuration.

      Now save the posted file into the UPLOAD_FOLDER location and return the file name as a response.

      Save the above changes and restart the server. Point your browser to the http://localhost:5002 and sign in using valid credentials. Try to upload an image using the browse button, and when done, check your browser console. You should be able to see the returned uploaded file name. 

      Instead of the read-only input text field, let's add an image element to display the uploaded image. So replace the read-only input text field with the following HTML code.

      In the file upload success callback, update #imgUpload's src to the uploaded image.

      Save the above changes and restart the server. Sign in to the application and try to upload a new image file, and you should be able to see the uploaded image.

      Add Wish Page With Upload

      We'll need to modify our tbl_wish table structure to include three new fields. Alter the tbl_wish as shown below:

      Next let's modify our stored procedures sp_addWish and sp_updateWish to include the newly added fields to the database. 

      Modify the sp_addWish stored procedure to include the three newly added fields.

      Also modify the stored procedure sp_updateWish to include the three newly added fields.

      Next, modify the /addWish request handler's method to read the newly posted fields and pass them to the stored procedure.

      Once the values have been read, we'll pass them to the MySQL stored procedure call.

      In the addWish.html page we'll need to set the name attribute for the elements to be posted. So add name to both the newly-added check boxes.

      Now we also need to pass the upload file path. So we'll create a hidden input field and set its value in the file upload success callback.

      Set its value in the file upload success callback.

      Save the above changes and restart the server. Sign in using valid credentials and try to add a new wish with all the required details. Once added successfully, it should be listed on the user home page.

      Modify the Edit Wish Implementation

      First, we need to add some HTML code for the three new fields. So open up userHome.html and add the following HTML code after the title and description HTML.

      We'll need to fetch the required data to populate the above fields on edit. So let's modify the stored procedure sp_GetWishById to include the additional fields as shown: 

      Next, we'll need to modify the JSON string in the /getWishById route method to include the new fields. Modify the wish list in /getWishById as shown:

      To render the result, we need to parse the data received in the success callback of the Edit JavaScript function in userHome.html.

      Save the changes and restart the server. Sign in using valid credentials, and when on the user home page, try to edit a wish from the wish list. You should have the data populated in the Edit popup.

      Edit Pop Up With Additional Fields

      Now, similar to what we did on the add wish page, add the jQuery-File-Upload script reference in userHome.html.

      Initialize the file upload control in the edit popup using the same code we used on the add wish page.

      Next we need to modify the Update button click in the Edit popup to include the extra fields added. So, in the btnUpdate button click, modify the data parameters passed to include the three new fields as shown:

      Open up app.py and modify the /updateWish request handler method to parse the newly added fields.

      Modify the procedure calling method to include the extra parameters.

      Now open up sp_updateWish and modify it to include the newly added fields.

      Save all the above changes and restart the server. Sign in using valid credentials and try to edit and update the existing entries.

      Wrapping It Up

      In this part of the tutorial series, we saw how to integrate and use the blueimp jQuery-File-Upload plugin to upload images in our Python Flask application. In the next part of this series, we'll show the wishes accomplished by users on the application home page and add the functionality to like the wishes.

      Do let us know your thoughts, corrections and suggestions in the comments below. Source code from this tutorial is available on GitHub.

       

      0 Comments

      Leave a comment › Posted in: Daily

  • Page 3 of 74 pages  < 1 2 3 4 5 >  Last ›
  • Browse the Blog

    Syndicate

    governing-bruise