Below I describe the second week of my #100DaysOfCode challenge.
In the opening blogpost you can find out more about my Why, my goals and the rules which I set for myself.
Or find the collection of all my posts related to the #100DaysOfCode challenge.
Table of Contents
HTML form for Django project | Day 015 (2022-01-21)
- delete detail-vote-page-merge branch
- create new branch to implement ad-creation functionality
- add idea for target group to freeplane mindmap
- write html for simple project creation form
The form does not have any functionality. Until that point it was only a plain HTML form which could not handle any data at all.
Logo for Django project: CoderMatching | Day 016 (2022-01-22)
- add thoughts to jira project
- add images directory to project (& make .gitignore ignoring it) to create a logo for the header
- design a logo in several styles (took way too much time😅)
- replace „< back to index“ link with logo
- sort bunch of changes in git repository to focus on implementation of ad creation feature again
- just noticed that I have actually messed with the git branches, while working on non-branch-related features (image inclusion instead of ad creation functionality)
Jira: getting stuck in planning?
That’s what I wrote down at the end of that day:
don’t get stuck on jira (in pseudo-planning) -> do code!
– desperate Sam on day 16 of #100DaysOfCode
Compensate weaknesses
Later on that day I actually went on doing some more things:
- contacting some people on collaborations and knowledge exchange regarding wireframing (mainly via Twitter – not very successful)
- research on how to validate user input and unit tests in Django
- found that Django has a built-in functionality to create forms from Django – so you actually don’t need to create them in HTML!?
- And you are even able to create forms directly from your models.
- found that Django has a built-in functionality to create forms from Django – so you actually don’t need to create them in HTML!?
- learn basics(!) of wireframing and research wireframing tools
Git commit message in command line| Day 017 (2022-01-23)
- learn to write commit messages with subject and detailed description directly from the command line:
git commit -m "subject" -m "detailed description" - amend view to be at least able to create an ad with dummy data
❓Process HTML form in view
Questions❓ and thoughts🤔 for that day:
- How can I receive the input from the HTML form to work on it in the view?
Probabaly the easiest approach would be to use Djangos built-in Working with forms functionality.
But at the moment I believe that it may be a good idea to figure out the underlying mechanism.
Does it make sense to learn it that way first? Can it even work?
database error, functional form and desperation| Day 018 (2022-01-24)
On that day I’ve spent quite some time fixing an error on my MySQL database, after my computer shut down unexpectedly.
Besides I was able to build a first usable form with some kind of functionality.
MySQL error: database crash after unexpected shutdown
- crash MySQL database for the first time (due to unexpected shutdown of MySQL – because computer shutdown unexpectedly – so XAMPP, hence MySQL shut down, too)
- solution which worked for me different from accepted anwser
- afterwards able to set up my original setup again using my documentation of week 1 (corresponding Twitter post)
Form in Django manually: low-level approach
I made the form from before functional using a low level approach.
Or to put it another way: I finished the form functionality with django basic mechanisms (Twitter post)
views.py
def createAd(request):
"""
This view method enables to publish own individual ads on the page.
"""
#if it's a post request: create a new object by posting the form data & display the created ad
if request.method == 'POST':
projectTitle = request.POST['project-title']
creatorName = request.POST['creator-name']
projectDescription = request.POST['project-description']
contactDetails = request.POST['contact-details']
newAd = Ad(projectTitle=projectTitle,
creatorName=creatorName,
projectDescription=projectDescription,
contactDetails=contactDetails)
newAd.save()
return HttpResponseRedirect(reverse('codermatch:adDetail', args=(newAd.id,)))
#if it's a get request: show the form
else: #if request.method == 'GET'
return render(request, 'codermatch/createAd.html')createAd.html
{% extends 'base.html' %}
{% block main %}
<form action="{% url 'codermatch:createAd' %}" method="post">
{% csrf_token %}
<label for="project-title">Project Title:</label>
<input type="text" name="project-title" id="project-title" required>
<label for="project-description">Project Description:</label>
<input type="text" name="project-description" id="project-description" required>
<label for="creator-name">Name:</label>
<input type="text" name="creator-name" id="creator-name" placeholder="What's your name?" required>
<label for="contact-details">Contact Details:</label>
<input type="text" name="contact-details" id="contact-details" required>
<label for="project-start-date">Date of project start</label>
<input type="date" name="project-start-date" id="project-start-date" placeholder="When did you start your project?">
<input type="submit" name="submit-ad" id="submit-ad" value="Create Ad">
</form>
{% endblock main %}form in Django: visible and functional with low-level approach
Using a manual, low-level approach, this form finally creates objects in the database (in contrast to the version before) and shows their real title and description after creation.
Documentation: avoid it to save time?
On that day I thought:
Twitter and progress documentation takes way too much time actually🥴 Should spend relatively more time on coding then on documenting⁉️
– singleminded Sam after errors and lot’s of documentation
… And while I am writing that blogpost here, I realize again that I spend waaay more time documenting what I do, compared to coding and compared to the work on my actual project.
This makes me quite dissatisfied in a way, since I would like to work on the CoderMatching project more and improve my Django skills.
Improve coding skills by documenting the learned?
On the other hand I have recently listened to another Simple Programmer podcast from John Sonmez, where he recommends to teach others by writing blog posts.
You can read the summary of that episode in my corresponding blog post.
Therefore I am hopeful that this documenting has some value and that you can learn something from it.
Furthermore I actually enjoy writing blog posts and documentation.
Doing it has actually some advantages:
- improve English writing skills and vocabulary
- gather experience in writing blog posts + improve blog writing and formatting skills
- help people with blog posts (hopefully) in the long run
- documenting solutions for later recycling in other projects
Maybe you know any other advantages?
Forms reference: the answer?| Day 019 (2022-01-25)
That day I’ve educate myself about working with forms in Django.
This is what I did in short:
- attend FreeCodeCamp Berlin❤️
- amend view and HTML to improve my form (failed)
- skim some learning material:
- 🎯goal: get overview of keywords, recurring methods, classes and standard applications
- find out and document where to find what
- skim MDN’s Working with forms
- skim Django Girls Tutorial
Forms reference: all you need to know about forms in Django
Furtunately I’ve quickly discovered the Forms reference, which is a great collection for basic knowledge about the functionality of forms in Django.
Hence I just wanted to skim it’s sub-categories, which in hindsight took me a complete day…
But I’ve learned a lot… hopefully🤔
Forms API reference
💡LEARNED from The forms API reference:
- form classes can inherit multiple other form classes (and even add more fields)
Form Fields reference
Skimming the Form Fields reference I’ve done and learned the following:
- some (redundand?) concepts from The Forms API applied
- short, but clear descriptions about the basic application and working concepts with form fields
- short investigation on the location and code of the NumberInput widget in the docs
- 💡LEARNED: got an overview of the Built-in Field classes and their default widgets and their normalization types
Model Form Functions
skimming Model Form Functions:
- looks like a collection of really cool shortcuts to build pre-defined forms from models simply
The modelform_factory seems to include several methods from The Forms API as parameters to simply build a form which handles the methods in a standardized way
Widgets
skim Widgets:
- explanation of yet overwhelmingly complicated widget handling
- helpful overview of the built-in widgets and their HTML representation
Form and field valitation
skim Form and field valitation
- 💡LEARNED: Validation is about checking whether the input given to the form by the user can be saved in the correct format. To make sure the input is valid, Django „cleans“ the input data and tries to render it as a normalized Python object.
- seems to be a very important step since it has a very extensive description in human language (not code)
- 💡LEARNED: steps in validation (can be adjusted) – but hardly understand…😵
- to_python() takes input from Field and converts it to Python type OR returns ValidationError
- clean() performs to_python(), validate() and run_validators() in the correct order to check the validity of input and returns the cleaned data into the cleaned_data dictionary of the form
Working with forms in Django
- skim Working with forms in Django
- amend html form and view (does not work as expected)
Some questions left
- Still thinking about: How does the HttpResponseRedirect(reverse(…)) actually work…?🤔
- How would Field.help_text displayed?
- (Why) do we need the clean() method? Isn’t the is_valid() sufficient?
More time coding, less time documenting?
And again I questioned my extensive documenting of what I did.
This is what I’ve noted down:
Maybe I shouldn’t have taken so much time to investigate all the other topics before in such depth, but rather focus on applying the topic quickly.
Does it make more sense to skim documentation extensively before, in contrast to just finding the simplest, explanatory part of the documentation (probably a tutorial, a topic guide or a How-to guide in most cases!?) rather than just applying right from the beginning – hence skipping the basics and only use the shortcuts from the beginning.
I think that way I would rather feel like never really understanding what I am actually doing.
But let’s see where the journey takes us…
What I promise myself from this is that in the moment when I start to apply the topic, I already have quite some idea where to find certain topics and details in the documentation. Besides I’ve then already established several associations to further process and connect the content which I am applying.
❗ I’d actually really like to contribute to the Django project.
At the latest after finishing the 100DaysOfCode challenge, I will find a simple issue to contribute to the Django project!
Didn’t write any code so far, but reading lot’s of documentation🥴
Git stash: save code without committing| Day 020 (2022-01-26)
Since I failed improving my form on the day before I was searching for a way to discard my changes without really discarding them.
More precisely I wanted to save them somehow without having them in my commits.
Fortunately I’ve attended the weekly FreeCodeCamp Meetup on the day before.
There Linda adviced me to try stashing my changes.
A word and a blow.
I’ve summarized my experiences with git stash and how it works in a blogpost.
What I’ve learned and accomplished this week – retrospective summary
Aside from creating a somehow working form this week, I’ve learned several things:
- stashing code changes to save it for eventual use later🥳
- basics of project management software for coding – Jira
- importance of documentation to learn while teaching
- writing commit messages on the command line, including both subject and description
- endurance despite slow learning and even slower pace of practial implementation (forms)
- lot’s of theoretical knowledge and many associations around forms in Django (now: time to implement!🔌)
- low-level implementation of manually created forms🎉
- fixing certain database errors
How to go on?
In the subsequent blogpost about the following week of my #100DaysOfCode challenge you can read how I really continued my journey.
Or find the collection of all my posts related to the #100DaysOfCode challenge.
Besides you are very welcome to follow my daily progress on Twitter.
Taking up the #100DaysOfCode challenge too?
Are you also working on the #100DaysOfCode challenge?
Are you planning to take up the challenge in the future or did you already do it in the past?
What are your personal challenges on the way?
Neueste Kommentare