Almost ready to abandon my views and control

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:

  • preview
  • publish
  • publish a comment

Instead of having three major modes, it was possible to change the flow so there were three possible paths:

  • preview
  • 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.

  1. retrieve the draft
  2. process uploaded files
  3. validate the new data from the $_POST
  4. 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.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s