[ic] Anybody using 4.7?

Dan B db@cyclonehq.dnsalias.net
Tue, 24 Apr 2001 15:55:04 -0700


At 02:37 PM 4/24/2001 -0400, you wrote:
>Quoting Dan B (db@cyclonehq.dnsalias.net):
> > Yes, but I wasn't talking about catalog<-->ic compatibility. I was talking
> > about the foundation catalog itself.  My hypothesis was that foundation
> > itself will have improvements that one might like to take advantage of
> > between now and 4.7 release.
> >
> > For example:  I started building my catalog in 4.5 somewhere.  As part of
> > building my catalog, I made a lot of customizations to the catalog
> > files.  When 4.6 was released, it had an updated catalog (with new 
> features
> > such as multiple ship-to's, bugfixes, etc.) that I wanted to take 
> advantage
> > of.  However, I didn't want to re-write all the html customizations that I
> > had done.  That's where a method of forward-porting your own
> > "customizations" becomes valuable.  (Or, back-porting changes to the
> > template: same effect).
>
>Think about this. How would you have us do this? I can't see a way, and
>if I can't it probably ain't going to happen.
>
>I don't know of any program that, other than providing components as we
>do with things like the templates/components/* stuff,  which can do that.
>If you customized those, you are probably going to have to repeat the
>process to integrate any new features.
>
>Our main changes are usually to the order features, and the method there
>is to standardize on the same fields as we have.
>
>In the payment area, one thing I am looking at is:
>
>         [charge-param send_form=1]
>
>which would provide a standard form for each payment type based
>on payment processor (more are requiring ccv2, for example). For the
>dummy "PO" payment processor, you would get a form asking for po_number
>instead of mv_credit_card_number; for online checks you would get the
>bank routing fields, etc.

(this looks really cool, and would really shorten checkout.html by a chunk 
of kilobytes)


> >
> > But yes, it is amazing how well compatibility is maintained between ic
> > versions.
> >
>
>That is most of what we can hope for. I know of plenty of applications 
>that can
>claim backward compatibility to some degree, but I have seen very few 
>claims of
>forward compatibility. 8-)

Thanks for your input, Mike.  For some specific situations it *is* easy to 
"forward-port" catalog changes between minor versions.  The scenario I was 
talking about was a novice user making minor (often aesthetic) changes to 
the foundation templates during the development cycle (4.7.x).  Then, when 
the final foundation catalog comes out (4.8.0) one could do a "directory 
diff" (Alan Cox style) of one's existing catalog (modified from 
'foundation' at some point in time during 4.7.x), and apply it to a new 
4.8.x template catalog.  Merge a few conflicts, and boom, you have a 
catalog with the new features/bugfixes of the final "foundation" catalog, 
without having to make all of your "minor aestheic" changes over again.

The alternative is to backport changes to the catalog during development 
cycle, build your own catalog from scratch, or any other plethera of 
alternatives.  But the above is what I did during 4.5.x development cycle 
to take advantage of the new multiple ship-to's code.  But it wouldn't work 
with any valuable, substantial changes (like what we did at 
diabeticsupplies.com -- sorry, last plug ever, I promise).

Dan Browning, Cyclone Computer Systems, danb@cyclonecomputers.com