Then you would want to establish a query in your page to retrieve the product record and set the variables to be displayed on the page.  A good place to start is to dig into viewPrd.asp, viewPrdL.asp and viewPrdCode.asp to understand how the cart handles this task.

 

 

 

Thanks for any info you can provide.

SDI

<<<mmmm, well I took a look at some of the sample sights using ProductCart and it seems they have hard coded prices in their web pages. Once you click "add to cart" and view it, the page shows the product added and the price from the database. But if you are not in the cart yet and on a html/php/asp page the pages that shows the details they have the hard coded prices on them. From the sites I saw, this is not logical for updating the prices/descriptions or what ever you edit with the ProductCart interface>>>

 

Would it be possible for you to post links to these sample sites you refer to?  It's just not possible to help without seeing what you are looking at.

 

<<<A developer never wants to hard code the values and if the client changes it in the database, the developer needs to redo a whole page(s) and upload it. Instead it should be read across any page anywhere and never touched by a developer. It seems ProductCart can do this, I jsut dont see anyone doing it or any samples on doing it. Has anyone done this? Dynamic images/descriptions/prices, etc.. >>>

 

That is why Hamish stated what he did.  How about showing us the old site as well so that we have in context just what you are trying to do.

 

 

The prices/images/descriptions are all hard coded, not optimal. My client has something similar to this website. Shows the product, image/description/ListPrice, then you can click add to cart and its in the cart with the OnlinePrice showing in the cart ASP.

 

Thanks for the assistance

SDI

 

Once one reaches a product page such as this, further explanation can clarify the behavior:

http://www.webtappeti.it/productcart/pc/CASCADE-BLACKREDWHITE-4p1295.htm - http://www.webtappeti.it/productcart/pc/CASCADE-BLACKREDWHITE-4p1295.htm

 

PC has price-sensitive attribute.  The base product in this case is set to 0, and the attributes themselves are priced.  Only when you select a size from the dropdown does the price appear.  I'll also point out that the layout of this page, and I'm pretty certain the manner in which the prices in the dropdown are displayed, is totaly custom.  It's all nice, and far from stock presentation.

 

So, with all that said, may we see the site you are migrating FROM (and perhaps the new design) so we understand the context of your original questions?

 

 

Apparently one of your challenges is that your designer created the site design outside of the context of knowing ProductCart so that they could take advantage of something close to the stock layout characteristics of the application.

 

I also question mixing PHP pages with ASP pages in the same application.  Among other issues, you exclude from the site any potential of grabbing the cart totals for display in the header.  Perhaps there are other reasons why you want PHP, other than perhaps greater familiarity with that language.  But if that is the only hurdle, it's probable that a pure ASP solution could be crafted here.

 

Seeing where you are going, creating all of these static pages with hard-coded references to all of the product data is going to create a nightmare - both for initial creation as well as ongoing maintenance.  Let me show you a different approach.

 

Compare, for a moment, these pages:
http://www.cpapplus.com/miscellaneous/care-pad.php - http://www.cpapplus.com/miscellaneous/care-pad.php

http://www.systemthree.com/store/pc/Board-Defense-c24.htm - http://www.systemthree.com/store/pc/Board-Defense-c24.htm

 

Consistent to both of these pages is that there are two product sizes listed, available for purchase.  Distinction is that you hard-coded your page, and SystemThree is using a stock PC page.  Big difference is that your description is below, ours is above, but that's just a code placement issue.

 

PC supports a variety of category display formats that are switch-selectable.  In the case of SystemThree, we manipulated the format M (multiple add to cart) layout into what I show above. 

 

Now look at this page to understand what the page looked like before we started:
http://www.earlyimpact.com/demos/standard/pc/Jewelry-c10.htm - http://www.earlyimpact.com/demos/standard/pc/Jewelry-c10.htm

 

I think you might be able to imagine that the care-pad.php page could become a category page, and that the format you are showing on that page could be closely achieved, while maintaining stock functionality and not having to go the route of beating your head against the wall with all of these static pages.

 

Does this help you understand that there is an option beyond your current approach that would have a much easier future maintenance life?

 

And what I am saying is that a knowledgable PC developer can likely replicate something in the area of 90% or greater of what you show on http://www.cpapplus.com/miscellaneous/care-pad.php - http://www.cpapplus.com/miscellaneous/care-pad.php  within PC alone, albeit with modifications as stated above.

 

Just to be clear, I'm not trying to sell a job to you.  We have plenty of work on our plate at the moment. I'm just trying to point out that from the perspective of many years experience working with different e-commerce sites and platforms, and having seen sites where all of the product data was being incorporated into static pages such as you are, you are creating a monster that will be difficult to tame.  With that said, were I to do precisely what you are doing in terms of all these static pages, the part of this approach I would change is to change to .ASP, and use some functionality such as I mentioned early in this thread.  I'd have variable on the page that would represent category or product ID values, and that those values would be used to pull data from the PC database. (You could do the same thing in PHP as that appears to be the environment you are most comfortable.)  At least that way if the product data is changed in the future those changes will be reflected on the pages dynamically.  This is not the option I would choose, but it is an option.

 

The bottom line is that now that I have shown you an alternative approach that would make your site fully dynamic, I'd be very seriously discussing a new direction with your client as the lifetime maintenance headaches you are creating with the current approach will easily outweigh the short term cost impact associated with implementing a better solution today.

 

I'm just trying to help and have no vested interest in this - but since you don't know PC I hope all of this gives you a deeper insight as to possibilities.

 

You are making your project so much harder on yourself and your client than is necessary.

 

If you build the store as I am suggesting you will replace the significant effort of messing with all those static pages with an effort to knock the category page layout into shape.  It's not an easy task, and it's going to take some hours for even someone skilled with PC and ASP, but the payback is that when finished you have a totally dynamic store.

 

So - do you any ASP coding at all?  Or does this sound like something you want to push to a developer who has the above skills, knowing that when it's done you don't have to deal with all those static pages, and with the proper category + product data prepared in the  database that basic goal will have been achieved?

 

As for .htaccess, my servers and those of selected developers around here are equipped with http://www.helicontech.com - www.helicontech.com ISAPI_Rewrite 3, and that is a feature of our standard hosting plans.  You can build all the rewrite rules you can think of.

 

Give me a shout if you want to discuss all of this.

 

I still think that we may be talking past each other.  You do not need to make custom ASP pages.  You want to do this with strategic changes to viewcategories.asp.