[ic] products using inactive
Mike Heins
interchange-users@icdevgroup.org
Sat Aug 24 22:33:01 2002
Quoting Barry Treahy, Jr. (Treahy@MMaz.com):
> Mike Heins wrote:
>
> >Quoting Barry Treahy, Jr. (Treahy@MMaz.com):
> >
> >
> >>Philip S. Hempel wrote:
> >>
> >>
> >>
> >>>Just befor I pull my har out, does the usage
> >>>of the inactive function through interchange
> >>>or is it built by me into the webstore?
> >>>
> >>>I don't want to start off looking in the
> >>>wrong location to make this work for
> >>>me
> >>>
> >>>
> >>>
> >>I just did a grep on the sources for the key word inactive and with the
> >>exception of the UI for customers, I saw nothing so my initial guess is
> >>that it would be a feature that you would need to build into your site...
> >>
> >>
> >
> >You won't find that many hardcoded field names in the IC core. Almost all
> >that are there can be remapped.
> >
> Good morning Mike...
>
> This is meants as a learning question for me, not to 'question' you; But
> if there is a fielded defined in a table, that is instrumental to the
> logical or processing of IC, then at one point or another would there
> not have to be a hard coded reference to that field, be that in IC or
> one of the Vend libraries? Putting aside the inactive column and
> looking at something more fundamental like price for example?
No. It does not have to be hardcoded at all.
>
> My reason for asking is that I often grep the core program and libraries
> to try and better understand how a field or tag might interact and
> relate to other actions in IC. If this approach is flawed, what could
> you recommend to aid in the Q/A process so that folks like me that are
> in a 'perpetual' ramp up on IC don't have to bug the list frequently
> with what might otherwise be considered mundane or novice questions?
There are usually hardcoded defaults, but you will mostly see this type
of thing:
my $cfield = $opt->{country_field}
|| $Variable->{MV_COUNTRY_FIELD}
|| 'country';
In the case of the special price and description basic to all ecommerce,
those are directives:
DescriptionField description
PriceField price
You can set them to whatever you want.
When there are lists, like in the Vend::Payment stuff, you will
find a remapping facility:
Variable MV_PAYMENT_REMAP <<EOR
address=address1
province=state
ctry=country
EOR
Much of this behavior is documented.
> >There is a new feature in IC4.9/5.0, called HIDE_FIELD. It automatically
> >blocks records where a field contains a true value for searches and such.
> >
> Perhaps you could expand on this further? Blocks fields, or entire
> rows?
You need to read the WHATSNEW file.
> This could be extremely useful as some products that we list can
> only be seen by US customers, others only by International customers,
> yet the standard search could find both on the same search. A crude
> example that really doesn't apply to our products but presume prior to
> switching power supplies, you could have two blenders, one at 120VAC
> 60Hz and a second at 240VAC 50Hz.
> To show both could create confusion.
> In our case, I have four new columns in our product table that searchs
> must use to include/exclude records depending on who they are:
> allow_us allow_uk allow_intl allow_disty
That is the type of specific custom function best handled in your
catalog logic with the [query ...] tag. Or with Locale. Or Profile.
There are many facilities to help with this type of thing.
>
> Are you stating that 4.9 could/would make these process more automated
> and if so, is it worth be attempting to pull from the CVS to snag that
> portion and attempt to integrate it into 4.8.5 now?
I never will suggest that. It would be more reliable to use 4.9 at
this point.
--
Mike Heins
Perusion -- Expert Interchange Consulting http://www.perusion.com/
phone +1.513.523.7621 <mike@perusion.com>
Nature, to be commanded, must be obeyed. -- Francis Bacon