22

Realizing that the former so-called PHP developers based the entirety of their so-called dashboard framework (self-written of course) on GET requests.

Every. Controller. Only. Accepts. Get. Requests.

It creates stuff? So what! It does update? No matter! It deletes? Who cares!

Just call that URL, and it will release all hell, plagued with multiple side-effects, and then issue a redirect.

Of course that one delete button was inside some twitter bootstrap tabs, and due to the redirect the page always reloaded and the content manager landed on a very different tab. Meaning if they wanted to delete multiple records, they had to hit "activate tab" and "delete" and "activate tab" and "delete" -- rinse and repeat.

It's our *job* to make things easier for our users! Not to waste their time. (Unless you are browser game developer. Then do your thing.)

And we are talking basic CRUD! Basic CRUD! I am not even demanding for it to be restful or to have some parts of a HTML page being updated on the fly with such rad and new technologies like ajax!

There is just question I would like to ask whoever build this: Seriously!?

Comments
  • 2
    I've had the pleasure of coming across something like this as well, but I really can't be bothered to redo it because the client is somewhat of a cheapskate so yea nothing to do about it, but I feel your pain
  • 0
    How old is the code?
  • 3
    Call that URL and GET rekt...

    Sorry, I will see myself out.
  • 0
    @liammartens We are our own client. So this means every action as developers undertakes, has repercussion on the productivity of our content managers. So I did bother to fix this; and by fixing I mean at least the delete endpoint behaves like ajax endpoint that; and the delete button is good old ajax jQuery magic. (Yes, jQuery. Deal with it.) It's still GET though. I tried to see if I can make it POST-aware, yet all that did was making me want to go postal on that framework.
Add Comment