Show Fields Anywhere

Great now you can see what I am after!

This is the ORIGINAL site (no PC) - here

The new site looks similar and uses PC. The designer didn't integrate with PC at all, but you can see this page can have PC easily embedded into it. It shows a desc/price/image, the first on works on "details" - you click it and it goes to the cart and this is hard coded too (can have PC embeded as well). Once you add it, I coded it to use PC and pull the price. Once at the checkout you can see the price difference. BTW - SKU is hard coded as well, this again is very bad design.
New page - here

Greg, thank!
SDI

Greg,

Thanks for the input and I see your point. My client already paid a designer to do the site pages and the CSS. I cant go about and change all the layouts, unfortunately, unless I can convince my client. My job entails me to get PC involved in the products listings on the new page designs. Those websites you showed both have hard coded information. I needed to have those pulled from the database. These examples have the description/sku and price being hard coded. Can pulling that data on that page be done with PC?

Thanks again
SDI

Hi SDI
Prices are never hardcoded on ProductCart pages, nor is description or anything else specific to a Product or Category.
Trying to build a website to fit exactly to a design by a designer who has no knowledge of ProductCart is, as Greg has pointed out, a recipe for lots of pain and expense, both now and in the future - this would be true of any e-commerce application. In fact, ProductCart offers more flexibility than most.
I think you need to have a conversation with your client to make this clear to them.

An analogy would be designing a car without taking into account the engineering side, like engines wheels etc. Yes, you can design a very pretty vehicle, but then doing the engineering to fit within the enforced limitations of the sketches means you will end up with an impractical, very hard to maintain and overly expesive vehicle.
Working in collaboration with the designer, so that they are aware of the options available, means you can keep the stock functionality, along with the lower costs and easier maintenance that results in.
You can still change the CSS (and keep your designers CSS) buttons etc and select from many layout options etc as well as wrapping a very stylish header and footer around the pages. The flexibility is huge - just look at the sites here : http://www.earlyimpact.com/stores.asp .       

Looking at http://www.cpapplus.com/aed/aed.php the centre of the page looks to me like a fairly standard ProductCart layout (all dynamically created -or would be by ProductCart) and the category menu could equally be standard ProductCart.

ProductCart uses an included header/footer as well.  By choosing PHP, you are likely doubling the header/footer pairs that must be maintained in your store - one for the PHP pages and the stock pair for the store. As such, if you changed to .ASP pages then you could use the included header/footer from the store for all pages.

So if I go the ASP route with this instead of PHP, and go through the store front in PC, the prices/descriptions, images, etc are all through the DB right? I believe PC has layouts available to setup different styles of the store front. The store front can use the new CSS from the designer and still use the DB as its products? My client has the BTO system of PC. I want minimize the work ahead of maintainace to the website. So, if its possible to use the header/footer.asp that I created for the viewCart, the same can be used for the store front. I think I am on the right track here as far as how I want this to go with PC, I just want to make sure the look and feel is what my client is after, or looks similar to the new style layout.

Thanks for the help fellas
SDI