Changes in the Site
One-layer comment box added.
There is only one table for comments in the database. That itself will be containing top-level comments as well as replies. It is possible because I simply have a "parent" field in the comments table... So, if you reply to a comment, the parent for your reply becomes that comment under which you are replying. If you reply to an already existing reply, then that becomes the parent... If parent is "null", then it's a top level comment, not a reply. While the backend is ready, the frontend is a bit tricky. So, for the UI, only top-level comment is enabled for My Open Diary section. I haven't added comment boxes in the "Changes in the Site" section because, well, why would anyone need that?
Navigation menu fixed for mobile view.
Originally shifted to the extreme left, now the expandable navigation menu, its borders and its texts appears at the horizontal center of the screen. Additionally, once you scroll down, the menu sticks at the top of the screen. In our language, I set the position of the navigation menu to 'sticky'.
Preliminary dark mode is now functional.
Interior designing often uses the 60-30-20 colour rule to ensure our eyes get a good feel. So I was like, why not use it for this UI too? Maybe I'm not the first one to come up with this brilliant idea, maybe others are already using it. But I like the idea. Hence, light and dark modes are now live.
Home and About pages humanized. Times converted to IST.
I originally deployed this website with Home and About pages having messages by GitHub Copilot. Now, they're from me. The time shown at the start of each log was originally Zulu time, shown as a Java object string. Now, it shows IST, 12-hour time format...
Light mode enabled!
Light mode enabled and colour scheme implemented for all pages.
Mobile view added, paragraphs justified...
Mobile view (max width 768 px) added for navigation bar. Buttons now appear in grid form. Except the auth (sign in/out) button, which stands at the bottom. Paragraphs (home and about pages only), originally left-aligned, are now justify-aligned.
Deployed to domain: akashghoshal.in!
Site moved to my domain. CORS configured. Now active: www.akashghoshal.in!
New-line rendering solved! Viewing data sorted!
For some weird reason the pages couldn't render new lines... Had to use styling ("CSS whitespace wrap")... Also, sorted the entries by time, latest first...
Text Input Problem Solved...
This site is built in a way that allows nobody but me to write and post, so this change may not be visible publicly. However, I felt it... The server refused long text entries, and I couldn't understand why. It was simple. Unless stated explicitly, the database assumes a maximum of 255 characters ("varchar" type)... I had to mention to the database that I wanted it to be a text entry with no limits... That's it. I can now write as long as I want...
SUCCESS!!!!!!! FINALLY!
After the last log, I found some defect with the backend-frontend communication. The entry got saved but wasn't shown as an entry. The GET request failed. Well, professional coders maybe familiar with these debuggings, but for me, it was no less than a detective's work. I'll elaborate... For coders, I deployed the site - the deployed database worked, the deployed frontend worked, the deployed backend worked with Postman as well as with my localhost frontend... Just, with this deployed frontend, it somehow got blank responses from backend... It took me a good deal of reverse-thought-engineering to realise that I was being slapped with CORS... And when I fixed the api CORS configuration and uploaded the fixed code, this stupid frontend was using cached data, which is NOTHING! Literally it was just an empty array... Only after disabling cache, I feel some peace. Now, for non-coders....... This site is divided into three parts - the frontend, the backend and the database. Each of these three run independently, but are connected by a means of a communication channel. This face of the site that you can see, the one running in the browser, is the frontend. Every time you click the "Changes in the Site" button, the frontend asks the backend for all the logs that exist. The backend then fetches the logs from the database and sends them to the frontend... The frontend then decides how to show it to you - the colours, layouts and everything. But, if you can ask the backend to fetch you something, you can also ask it to self-destruct. As backend or as frontend, or even as a database, you can't simply "trust" that whoever is requesting something from you has the best of their intent at heart. So, there are a number of layers of protection, to verify who can see and edit things... When all of the three independent things - frontend, backend and database - were running in my laptop, I didn't really need much protection... But now that I was about to deploy, these layers of protection was (and, in fact, is) a must. So, now, as the three things were no longer in the same device, the default security systems were enabled... (And by no longer being in the same device, here's what I mean... My frontend is running from a device that lives in the US... My backend is in Mumbai. I don't even know where my database resides. In all of these, I forgot that the backend, now being away from the frontend, won't trust any frontend in the world until I pat its head and assure it to trust my chosen frontend... And I was beating about the bush trying to find out why I can't see my logs, for at least half an hour........ Well, anyway, whatever this experience was, it was fun! UPDATE: I wrote this whole thing quite some hours back... The server refused to accept such a bulky text... Now it does...
Site Deployed!
Moved from development to production!