"Application" Architecture Help
Permalink
Hi. I've got a fair amount of PHP experience, but am looking at crashing into Concrete5, as it looks great.
I currently have a several year old app that's about 15% CMS, 15% overhead (user, group mgmt, etc), and 70% a very custom e-commerce solution. I'm looking at redesigning this and porting it over to sit on top of concrete5, and I'd like some feedback as to whether or not I'm thinking of the right sort of architecture here.
In short, there are a few thousand "stores" and a few thousand "users". The users are associated to stores in a many-to-many relationship with a label (ie, store owner, regional manager, etc). Stores have data, including a map image, and a region. There is a wizard, where you pick one of your stores, then a "product" (virtual, like image of a poster), and then pick 1 - 4 images to add to the product, and some text to customize the product. The product and images depend on the store's data (like region). The next step is that a PDF is created with the images placed on top of the image product, sometimes with the map associated with the store you chose in step 1. Then you approve the PDF, email goes out to your regional manager, who has to log in and approve, then and it goes off to one of the vendors which was associated with the product. There is no payment.
So... my plan is to create a package.
I would use the standard user functionality. I thought about modeling the stores as groups, but I think I have to create a specific object for them. And then create the model to tie users and stores. Then I have to create the admin pages to create products, assign attributes, approve the order, view orders, etc.
Would I create all this functionality within blocks, and then basically have a 1-to-1 relationship to a handful of pages? Or would I create one-off pages? Can one-off pages have a CMS block or two within them, so that the client can edit certain parts?
Where should I use existing C5 features, such as the category and tag functionality? Should regions be categories/tags? Or should I set them up as a new object within my model?
I assume I'd use the file objects whenever somebody uploads a new product image, or even when I create a PDF file on the fly. And I'd have created a single set associated with my package, so that they can be separated from the rest of the site's files?
Would there be an admin section for the uploading, modification of products? Or should I try to follow the in-line context model that c5 uses for CMS?
Would I extend the user object to be able to query which stores they're a part of? Or do this somewhere else?
Is there a demo package I can download? Or do I have to buy a real package in order to poke around?
The above questions are just an example of the things I'm looking at... I don't need them answered individually, and I'm always open to more suggestions. I had problems finding this level of theory.
Thanks a lot.
James
I currently have a several year old app that's about 15% CMS, 15% overhead (user, group mgmt, etc), and 70% a very custom e-commerce solution. I'm looking at redesigning this and porting it over to sit on top of concrete5, and I'd like some feedback as to whether or not I'm thinking of the right sort of architecture here.
In short, there are a few thousand "stores" and a few thousand "users". The users are associated to stores in a many-to-many relationship with a label (ie, store owner, regional manager, etc). Stores have data, including a map image, and a region. There is a wizard, where you pick one of your stores, then a "product" (virtual, like image of a poster), and then pick 1 - 4 images to add to the product, and some text to customize the product. The product and images depend on the store's data (like region). The next step is that a PDF is created with the images placed on top of the image product, sometimes with the map associated with the store you chose in step 1. Then you approve the PDF, email goes out to your regional manager, who has to log in and approve, then and it goes off to one of the vendors which was associated with the product. There is no payment.
So... my plan is to create a package.
I would use the standard user functionality. I thought about modeling the stores as groups, but I think I have to create a specific object for them. And then create the model to tie users and stores. Then I have to create the admin pages to create products, assign attributes, approve the order, view orders, etc.
Would I create all this functionality within blocks, and then basically have a 1-to-1 relationship to a handful of pages? Or would I create one-off pages? Can one-off pages have a CMS block or two within them, so that the client can edit certain parts?
Where should I use existing C5 features, such as the category and tag functionality? Should regions be categories/tags? Or should I set them up as a new object within my model?
I assume I'd use the file objects whenever somebody uploads a new product image, or even when I create a PDF file on the fly. And I'd have created a single set associated with my package, so that they can be separated from the rest of the site's files?
Would there be an admin section for the uploading, modification of products? Or should I try to follow the in-line context model that c5 uses for CMS?
Would I extend the user object to be able to query which stores they're a part of? Or do this somewhere else?
Is there a demo package I can download? Or do I have to buy a real package in order to poke around?
The above questions are just an example of the things I'm looking at... I don't need them answered individually, and I'm always open to more suggestions. I had problems finding this level of theory.
Thanks a lot.
James
Create blocks sparingly; I cannot see the need for too many types of blocks for what you've described.
Sounds like you'd be better off using single pages and page types mainly.
A good explanation of single pages usages is at:http://www.concrete5.org/documentation/developers/pages/single-page...
Another good explanation of page types is available here:http://www.concrete5.org/documentation/developers/pages/themes...
Lets take the store map as an example. If you only want a store map available in one location and for it not to be editable via the C5 in-context editing, you could setup a single page to be available atwww.www.yoursite.com/store-maps... and then have it take parameters,www.www.yoursite.com/store-maps/new-york... to show fixed content pulled in from a database.
On the other hand you could create a page type within a theme. This would allow you to say layout 80% of the page in fixed format and then allow users to modify the other 20% of it. This would also work for you better if you wanted a format like:www.www.yoursite.com/stores/new-york/site-map.... and wanted the edit ability. Using page types you can have pages available in multiple paths & multiple instances where as single pages you cannot.
Your dead right about the file sets and file objects, they're real easy to use.
If your going to extend the users object, I would start by possibly modifying the default C5 user profile system into a full user admin panel for people to manage their products etc. Personally, I find C5s dashboard to restrictive in terms of design.
The only model I would generally extend would be the user model. Stores, Products, Orders, etc would have custom written models.
For example you could add a user attribute to the inbuilt user object named sID and have that relating to your sID variable within your Store model.
C5 uses PHP ADODB, so things are very easy to query.
Demo package... C5 is free baby! :)
Hope this helps,
Oli