Mapping out new Laravel project

[Korferer]

I am really struggling with the logic aspect of my application. I can't picture the structure and get it clear in my mind. As a result, I can't code anything because I'm second-guessing myself at every turn.

 

My application is pretty simple in reality. It's an application that keeps a record of all the different 'contracts'/'agreements' that my colleagues have signed. Some will have signed three or four depending on what systems they are working on.

 

The application will run a cron, daily, and send out an email to anyone who's contract/agreement is about to expire with an invite for them to renew it.

 

I have already built an application that has a login system and authentication (using Laravel). It was my first Laravel effort and I did it using a tutorial from YouTube. I figured I could use the one login from that to act as the administrator for this whole application. Once the administrator is in, they will be presented with a panel to do various things. This is the part I am stuck on. What do you all think of my "logic"?

 

Here are the basic routes (forgetting the auth stuff which is already done);

• /contracts - to see a list of all the contact templates out there.
• /contracts/{contract-id} - to view the specific contract template
• /contracts/create - GET and POST to be able to add new contract templates for other systems

 

• /people - view all my colleagues on one page
• /people/{person-id} - view a specific colleague and all the contracts they have signed
• /people/create - GET and POST for this too to be able to add new colleagues to the system
• /people/{person-id}/create-new-contract - so this would add a record in to a third table which joins info from the people table and the contracts table to make a list of unique contract agreements for each person and their expiry date. GET and POST for this as well I suppose. Even as I'm writing this, I don't know if this will be needed because I might have an emailing class that might do this job better? Hence the writing of this post!

 

• /agreements/renew/{renew-code} - This will create a new record in the table and amend the old one to show that the previous agreement has expired and that a new one for the next 365 days is in place.

As you can probably tell.. I am struggling a bit. Is there any advice you can give me to help me mentally map out my application before I start coding? I just want to get it right..

[Frank_b]

I do not understand what an emailing class has to do with the creation of a new contract..

 

What i do know is that users do not think about relations and jointables. They want a userfriendly application and press buttons and write forms as less as possible.

 

With that reason in mind i would give the people/{person-id} page a button 'Add contract' what would bring the user to the people/{person-id}/create-new-contract page. There you will need to show a form just to add a new contract. On the background you do allready know for who this new contract will be. And of course as for any form you will need to accept a GET and a POST method. The GET method will just show a new empty form and the POST method will validate input and if validated insert a new record into the table(s). In this case it would insert a record to the contracts table AND insert a record to the JOIN table both.

 

A full working system has four actions per table: CREATE, READ, UPDATE and DELETE. (CRUD). You did not add any actions for READ and DELETE until now.

Besides this four actions you could give a fifth action for many-to-many relations: change the relation. Think about this scenario:

 

One College stops working into your company because he or she accepted another job. Now the contracts need to be moved to another college...

You will need to make an administration tool for that too.

[ignace]

/contracts -- View all contract templates
/contracts/new -- Create new contract template
/contracts/{contractId} -- View contract template
/contracts/{contractId}/edit -- Edit contract template
/contracts/{contractId}/delete -- Delete contract template

/people -- List of people in the organization
/people/add -- Add existing person to the organization (not new since the person already "exists")
/people/{personId} -- View specific person /profile for logged in user
/people/{personId}/edit -- Edit person
/people/{personId}/delete -- Delete person
/profile -- Person's profile
/my/contracts -- Contracts signed by the user

/people/{personId}/contracts -- View contracts signed by person (/portfolio may also be a good candidate)
/people/{personId}/contracts/{contractId}/renew/{renewToken} -- Renew contract for person
/people/{personId}/contracts/{contractId}/sign -- Sign a new contract

Planning an application does not start by defining the URL structure but by writing down a list of the things the application needs to do in as much detail as is required to start work on the item.

 

When you have written down the requirements list then you move on to creating a wireframe giving you an idea how the application will look and work and what content you will need. If your application involves roles, you will also need to write down which role can access which parts of your application.

 

At this point you have a good view of how your application will look and work and the content needed so you can move on to creating your entities and their behaviors for example:

 

class Employee {
  private $portfolio;

  // ..
  
  public function sign(Contract $contract) {
    $contract->signedBy($this);
    // other necessary code to sign a contract and what not.
    $this->portfolio[] = $contract;
  }
}

[Korferer]

Thanks for your views..

 

I think I was approaching the application all wrong. As suggested, I thought about what administrator actions are required and then I went ahead and created a few RESTful routes using this fantastic tutorial I found. I am actually making some good progress on this now