I need someone to point me in the right direction...

[eluser]rdawkins[/eluser]
Hi all, im new here totally in love with CI (only discovered it last week). This is basically what i want to build:

an ecommerce site with digital downloads based on a credits system, ie you buy 100 credits for $100 and then you use your credits to purchase the items.

The items for sale are digital documents which are sold/bought by the users themselves, they can upload word or pdf documents and it gets converted to pdf and added to that user's own store.

there are different categories and the users can only buy and sell items within that category. after looking on the internet, the only site i found which i can compare the functionalities i need is www.notehall.com

Im basically looking to replicate this but for another industry etc..

where do i start?

after checking out the tutorials, i can create a basic e-commerce site, how do i then proceed with the digital downloads aspect? as well as the conversion of word, powerpoint files to pdf?

Any assistance would be greatly appreciated!

[eluser]DarkManX[/eluser]
i dont get your problem. you fimiliar with php? you just code the parser/converter or use existing classes.

[eluser]rdawkins[/eluser]
hi, not that familiar, still learning

[eluser]DarkManX[/eluser]
well, thats the first step you got to take. you wont be able to create a complex page by just reading some tutorials. ofc you could just type the same code and modify a bit but still you wont be able to structure new individual features. just try something thiner so you wont get frustrated.

[eluser]rdawkins[/eluser]
agreed! i have a lot of learning left to do. Thanks for the help, will start small and add more features as i progress.

[eluser]johnpeace[/eluser]

where do i start?

With a functional specification...then a technical specification.

[eluser]rdawkins[/eluser]
that makes sense.. so something like pseudo-code then figure out how to do it in php right?

[eluser]johnpeace[/eluser]
[quote author="rdawkins" date="1346165195"]that makes sense.. so something like pseudo-code then figure out how to do it in php right?[/quote]

No, pseudo-code comes last...I don't really even do that, just stup out the methods I'll need in controllers/models and write docblocks explaining what each will do, what data it needs, where that will come from and what will be returned.

Write a detailed description of each function a user can perform FROM THE USERS PERSPECTIVE. That's your functional spec.

Then write a detailed description of same features FROM A PROGRAMMERS PERSPECTIVE. That's your technical spec.

Then build your DB schema and write model method docs and controller method docs.

Then write code.

That's one way to do it that will help manage feeling overwhelmed by the scope of the WHOLE project. The fundamental skill developers have/need is being able to break a large complex problem down into small component problems...then solve each of those.

[eluser]rdawkins[/eluser]
probably the best piece of advice ive ever received! Thanks, at least ill now be able to structure the project properly. Much appreciated.

[eluser]boltsabre[/eluser]
Going on from what Johnpeace wrote, when I tackle a large project I like to nut out a few things first:

1. Who are the user groups? (Public users, Registered/Private users? What about Admins? Management? SuperAdmins? Or "Groups"? And if you have a "Group" can they have their own "Admins, or SuperAdmins, or Managers"?)

2. What are the roles of each user group (starting to get into CRUD)? At this stage, just keep it broad and general, it helps to get an overall sense/feel for the application.
ie, Public Users can only "view" public pages, Registered Users can "update" (in this case, upload a file), "delete" (delete an uploaded file) and create/read/update/delete their own profile information. Anything else? What can Admin do (is this you, or will you have admin staff?)??? Do you need different levels/access levels? Perhaps you could be a SuperAdmin with total CRUD capabilities, and normal Admin can only do certain things?

3. Now start to break it up into "use cases".
Examples could be: create account, edit account, delete account, edit password, reset password (these last two are actually different use cases), login, logout, upload file, edit file, delete file, newsletter sign-up, etc etc. Are there "admin" use cases, perhaps black list user, approve user file upload, suspend user account, and so on.

4. Now you can start to get into the technical stuff, I like to "flow chart" it at this stage. Each and every use case should now be nutted out individually.
For example, what happens in "Create Account"...?
- User navigates to "Create Account" page
- User enters data and submits form
- Validate to make sure all mandatory files have data
- Validate all data fits it's data type
- If it fails return form to user with validation messages
- What about their email address, it should be unique in the database... or should it...??? How will you handle users who "delete" their account? If you delete the complete table row you lose historic data. But if you don't delete the row and just set a "deleted" flag in the table how do you handle when they sign up for their second account with the same email account? Reactivate the existing database row, or create a new row? If it's the second option then you cannot set the "unique" contraint on the table column... it all has to be figured out.
- Okay... so user finally submits a valid form with valid data... now what? Do you send them an "activation" email with a link they have to click? If so then that's another whole new use case "activate account"... but if you don't do it via this method you can never be sure that the email address they entered is a valid and active one.
- Moving on... now that you have their data, you have to enter it into the database
- Once done, where do you redirect them? To the home page, a "landing page", the last page they were on before they clicked "Create Account" link? If the last option, and you have that "activation" email I was just talking about, where do you redirect them if they click their email link a week after you sent it to them? And on that note, if you do go with an "activation" email, do they have to click that link within a certain time (I don't know, lets say 30 minutes)? If they do, then you have to handle that as well in the "activate account" use case somehow.

So that's your "create account" use case at a quick casual glance, I'm sure I've missed stuff in there (what about SSL???).

Sooooo, once you have all your use cases correctly sorted out, you then need to figure out "data flows", and by that I mean what data is moving around? In the "create account" use case we know that we will have to get certain data from the user, such as email address, password, first name, last name, profile name, date of birth, what about other stuff? Gender? Licence details? Hobbies??? Once you have all that, you can then figure out what datatypes each should be
Gender for example, how will you store that in the database? a m or f, a 0 or 1? What is the best way to help the user enter this data on forms? In the case of gender, it would be radio buttons. For first name, you may decide that it must just be alpha character, min 2 max 25. Now you know your form validation rules, and what the table column should be in your database (varchar(25)), and you'll need a text input on your form. What about date of birth... will you have 3 different selects boxes or text inputs??? Either way, they should only be numeric (days between 1-31), months (1-12) years (ouch... do they have to be 18 to sign up for an account... if so that means the minimum year must be this year - 18 years... oh wait... now we also have to take months into account... ahhhhh you see, you have to really think about these things!!!!) How will you store it in your db? Combine dd/mm/yyyy into a string and store it in one column or seperate columns for dd, mm, yyyy.
But anyway, once you have all this data worked out, you should almost have the complete scheme for your "user_table" for your database (although there will be other columns such as "date_created", "last_update", "blacklisted", etc etc what wont come from the user that you will have to figure out yourself.

And so on and so on... Sounds tedious and boring, but trust me, get this sorted out correctly now and you'll save yourself a lot of headaches, bugs, and whatnot down the road.

But as mentioned previously, if you're not that great with PHP yet, this kind of project is likely to be way beyond your skill set. I'd start making some simple little things first and work your way up.