How do you work?

[Polar_Bear]

hi,

 

I'm a newbie, but very keen on learning PHP and Mysql.

 

I have a half decent skillset with the two so what i really need is an understanding of best practices of laying out a project. i know certain frameworks come with their models, views, controller folders etc.

 

but if you were to coach me on laying out a project what would your advice be?

 

i want to start with creating a simple site, based on templates and a datase for a guesthouse. So, i would imagine i'd have an images folder, template folder (templates for room pages, welcome, booking etc) and so on.

 

what should i know so that i can learn things properly the first time around?

 

thanks so much.

 

-PB

[QuickOldCar]

I already know is gonna be piles of different advice given for this.

 

Each person works in different ways, in ways that may work best for them.

 

My advice is to try to make as much as can able to be removed/added or modified easily or with less effort on recoding or major changes. How that pertains to the project could vary greatly.

 

Using functions and classes helps.

As for folders, they can always be added at any time.

 

Start small and basic and work your way up from there, eventually you will have a large project.

 

Try to keep organized , it's horrible to not find what you need.

[Mr_J]

Guess there is some info available but from my own experience, I usually summarize what I need e.g. Site functionality. If you know what your requirements are, you can work according to that. Like a cart, I will use a cart folder, same with a gallery, if I use a Gallery viewer, I will use a Gallery folder and even more, I have an Images folder and a sub-folder for my index pics etc. It makes it easy for me when I change the site...

Enjoy

[Polar_Bear]

thanks for the thoughts guys.

 

cheers

PB

[TomFromKWD]

I'd also add,

 

If you are going to have a menu/nav bar do something along the lines of a "includes" folder.

Have one single PHP file with the code for your menu/nav bar, then in each page you want the menu to display use a

 

<? include ('includes folder name/menubar file name.php') ?>

 

and then that way, if you need to make a change, you just have to edit the menu bar file, not every single page its actually on

 

Saves time and effort to update as the site grows 

 

Edit: Obviously this can apply to more than just menu bars, anything you want displaying in multiple pages that may need editing in future could be saved as an include

[cherryaa]

It sounds like you're a better programmer than me, so it feels odd to be offering advice. My biggest problem is clients who change their requirements frequently. I create a site that's appropriate to their current needs and foreseen evolutions, but then they go and evolve in unforeseen ways. As a result, I've realised I'm  going to have to do the following in future:

• Add half a dozen dummy fields to every table I create (so my queries will only need small alterations)
  
• Keep each table down to one discrete purpose, and use a lot of index tables - I do this already, but need to do it more!
  
• Use more classes. I use functions and includes for everything already, but it's easier to adapt a class than a procedure.
  
• Build in redundant functionality. Example: current client switched from a payment gateway that collects delivery details to one that doesn't, then expected to receive his customer information automagically.
  

In my previous sales career, I had a motto: never assume. I'm now painfully aware this applies to websites, too!

 

It's a great question, I'm looking forward to learning from your replies.

[Mahngiel]

When laying out a single page or an entire site, I go back to my childhood creation method:  pencil and paper.  Start with a center "tree" and branch out.  Once I've determined a good majority of what I initially think I want to be there, then I can begin designing the link system.  Once I know the menu/link system, I can roughly draw out a page around it with all the various elements I've included in my notes.  It's not until I know the structure of my site that I write a smidgen of code, but once it's done, it's like I can already see the code.

[crmamx]

They are right when they say layout and design is the most important aspect of a project. Forget the code until you finish this step.

 

My career was as a mainframe system designer with a fair amount of programming thrown in. Several years into it, I undertook a complete manufacturing information system. It took me and 1 programmer three years to finish, 8 hours a day, 5 1/2 days a week.

 

The first step is defining what you want from the system. I don't know your business so I will use examples from what I know.

 

1. Order entry

2. Production scheduling

3. Shipping

4. Inventory control

ect.

 

Next, what files do you need to support the system?

 

1. Order file

2. Customer file

3. Part master file

4. Inventory file

5. Bills of material

ect, many files to support production scheduling and shipping

 

Next, do your data base design.

 

1. Define the fields and size and characteristics of each field in each file.

2. Do you need to link from one file to another? For example, a Bill of Material has to have a link to the Part Master file. If so, plan for it.

 

Next, what screens do you need:

 

1. Order entry and changes

2. Updates to inventory

3. Updates to all other files

ect.

 

Next, what documents do you need to produce

 

1. Part master listing, various sequences

2. Customer master

3. Open orders

4. Shipped orders

ect

 

Next, make a list of all the programs you need to operate the system. Do a sketch of the screen layout. List the input or output files you will need.

 

Now you can start the coding.

 

 

 

 

 

[KevinM1]

I tend to start with the domain model - what entities do I need?  How will they interact with each other?  How will the 'outside' interact with them for CRUD purposes?

 

I then build a mockup of the various pages I need and play with them to see if the process I thought was good in my head makes sense in practice.  I modify either the mockups or domain model as necessary.

 

Once I get the domain locked down, I translate it to the db for persistence.  Entities have to be stored, after all.

 

Then, finally, I finish the pages themselves and add any JavaScript bells and whistles I need.