This SF Active port has been a real pain in the ass, largely because I’m trying to preserve the old program’s functionality.
As I’ve refactored the code, it’s gotten better, but some bigger architectural headaches are emerging. The Template class issue in the last post was a real headache. It was doubly frustrating because I figured out that the templating language had some code to enable nested templates, but the feature wasn’t used.
So, in theory, you can load up a few templates, some which contain others, and then render and re-render them.
Unfortunately, that’s not how the views were originally built. They were concatenated together, as was the PHP style in the 2000s. So I took that apart and broke that into separate functions, so you can compose each view from subviews.
Slowly, the code started to resemble something that could be re-implemented in Twig.
The advantage of Twig or any template system is that it’s uniform and well known. Using it simplifies the code further.
New Logic in the Controller
I already took the leap and reorganized the logic. The old code was logic pyramids and a little spaghetti, with three paths through the code, intertwined with “if” statements.
do thisdo that if A then do thisdo this if B then do thisdo that if A do thisdo that if B do thisdo this if C do this
The new code was three blocks with top-to-bottom code, at least in theory.
if a then do this do that do this if b then do this do that do this other thing do this thing if c then do this do that do this do something else
Some of the code was repetitive.
It also revealed that the major states could be reorganized using a completely different model of operation.
The original had three major modes:
- publish a comment
Instead of having three major modes, it was possible to change the flow so there were three possible paths:
- preview -> publish
- preview a comment -> publish a comment
Preview could be implemented by having a
draft table to hold the intermediate object.
The CommentModel is a subclass of the ArticleModel class.
Now, all the important code is in preview, not publishing.
Publishing is reduced to copying a preview object over into the published
webcast table, moving uploaded files, and writing new links. Likewise, publishing a comment is the same thing.
This also completely alters when file uploads are processed. In the old code, uploads were part of the “publish” state. Now, it’s in the preview. Preview has this flow.
- retrieve the draft
- process uploaded files
- validate the new data from the $_POST
- produce an array of values to merge into the template
This sequence can be repeated, over and over, allowing the user to edit the document, upload additional files, and even leave and come back to the editing.
Previewing and publishing a comment should be performed by the CommentModel, which is a subclass of ArticleModel. The main difference with the comment is:
- only one attachment
- fewer fields
- different form to display
So, there’s some new backend stuff happening, and the functionality remains the same, but the UX changes. Refactoring isn’t supposed to be this drastic, but, the old system was already looking more complex.
Why Didn’t I Rewrite this Code the First Place?
Mainly, I didn’t know what the old code was doing. It seemed to hold some magic (or crud) in there.
Refactoring was like a big edit to understand the code’s intent.
I could have probably been sloppier about it and figured out the code well enough to replace these parts.