[Date Prev][Date Next][Thread Prev][Thread Next][Interchange by date
][Interchange by thread
]
[ic] One SKU in multiple Branches of TREE
--=_A9F4D80C.9DFC933D
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
<cut and paste relevant part to comment on>
could just as well be
Ford->Bronco->Shocks
SKU->Ford->Bronco
->Explorer
->Edsel
Deep goo.
<end cut>
Hmm. Interesting point on the latter item leading with SKU as a Trunk item =
rather than a Leaf. I hadn't even considered that. I need to think about =
it a bit more, it sounds promising, but then I am stuck with a way to =
build Reverse Expand/Collapse tree as the user would not want their =
initial interface to start with the SKU, but rather the most generic =
category.
Ugh. My head hurts.
Perhaps I am addressing the problem all wrong. Rather than assuming that =
TREE is what I need, does anyone else have suggestions in implementing a =
hierarchal product structure that a user can browse through?
Thanks again,
Gary
>>> cfm@maine.com 01/11/02 02:32PM >>>
On Fri, Jan 11, 2002 at 12:22:31PM -0800, Ed LaFrance wrote:
> At 01:06 PM 01/11/2002 -0700, you wrote:
> >Ed,
> >
> >Thanks for the reply. So are you suggesting this implementation for =
TREE=20
> >as well, or just in reference to Multiple Categories. It seems like =
a=20
> >delimited field with multiple tree-branch paths could get quite ugly =
very=20
> >quickly. However, I may not be seeing the light at the end of the =
tunnel=20
> >on this either. I would think just for a normalization factor that =
it=20
> >would be best in a separate table, but again I am not a DBA or Perl=20
> >programer by trade. Just a newbie trying expand my skill set and=20
> >understanding.
> >
> >Thanks in advance,
> >Gary
> >
>=20
> I was making a general observation. In all the things I have done with =
MV=20
> and IC, I have never knowingly used the TREE tag, so I have to stay mute =
on=20
> how my comments would fit into that context.
>=20
> - Ed L.
I fall into the "single field gets ugly very fast" camp. If you suspect
that is likely to be an issue, then it probably will be a big issue. :-)
> >>Shocks=3D>Ford=3D>Bronco=3D>77-79=3D>SKU
could just as well be
Ford->Bronco->Shocks
SKU->Ford->Bronco
->Explorer
->Edsel
Deep goo.
=20
> >>>> edl@newmediaems.com 01/11/02 10:58AM >>>
> >At 07:57 PM 01/10/2002 -0700, you wrote:
> >>In searching the archives of the list I didn't see this addressed
> >>specifically, but I did find mention of one SKU in multiple categories.=
> >>Basically the thread mentioned creating a separate table that listed =
only
> >>sku and category (that is an abbreviated explanation of course).
> >>
> >>I am not sure if it is possible (usually it is if you are smart =
enough,
> >>unfortunatly on this subject I am not) to do the same thing to support =
a
> >>single SKU in multiple branches of a tree.
> >>
> >>Example: Auto-parts store sells items that are usually selected by =
auto
> >>make and year:
> >>
> >>Shocks=3D>Ford=3D>Bronco=3D>77-79=3D>SKU
> >>
> >>However many SKU's can be used across multiple branches using the =
previous
> >>logic (ie 81-83 etc.)
> >>
> >>If this is possible, what do you think the best implementation is. I =
had
> >>thought about a 3rd table implementation as listed for the single sku =
in
> >>multiple categories thread, but wasn't sure what would need to be =
tweaked
> >>to support the TREE structure.
> >>
> >>I had a few ideas, but basically my brain-train got derailed when I =
tried
> >>to figure out how I was going to support SEARCHING and other =
features=20
> >etc...
> >>
> >>FYI, I am testing this implementation on a generic install of
> >>"Construct" with the integration of the HOW TO for TREES.
> >>
> >>Thanks in advance,
> >>Gary
> >
> >Fields like category, which are used to classify and group items, need =
not
> >contain just one value - you could theoretically make one sku a member =
of
> >as many categories as you want, by filling the category field with a =
list
> >of delimited values. This will require changes in the UI as well as in
> >front-end code, but it is quite doable - I have done so many times. =
It's
> >just not implemented in the foundation demo, AFAIK.
> >
> >- Ed L.
> >
> >
> >
> >
> >
> >
> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >New Media E.M.S. Software Solutions for Business
> >463 Main St., Suite D eCommerce | Consulting | Hosting
> >Placerville, CA 95667 edl@newmediaems.com=20
> >(530)=20
> >622-9421=20
> ><http://www.newmediaems.com/>http://www.newmediaems.com=20
> >(866) 519-4680 Toll-Free (530) 622-9426 Fax
> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> >_______________________________________________
> >interchange-users mailing list
> >interchange-users@interchange.redhat.com=20
> ><http://interchange.redhat.com/mailman/listinfo/interchange-users>http:/=
/interchange.redhat.com/mailman/listinfo/interchange-users=20
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> New Media E.M.S. Software Solutions for Business
> 463 Main St., Suite D eCommerce | Consulting | Hosting
> Placerville, CA 95667 edl@newmediaems.com=20
> (530) 622-9421 http://www.newmediaems.com=20
> (866) 519-4680 Toll-Free (530) 622-9426 Fax
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> _______________________________________________
> interchange-users mailing list
> interchange-users@interchange.redhat.com=20
> http://interchange.redhat.com/mailman/listinfo/interchange-users=20
--=20
Christopher F. Miller, Publisher cfm@maine.co=
m=20
MaineStreet Communications, Inc 208 Portland Road, Gray, ME =
04039
1.207.657.5078 http://www.maine.com=
/=20
Content/site management, online commerce, internet integration, Debian =
linux
_______________________________________________
interchange-users mailing list
interchange-users@interchange.redhat.com=20
http://interchange.redhat.com/mailman/listinfo/interchange-users
--=_A9F4D80C.9DFC933D
Content-Type: text/plain
Content-Disposition: attachment; filename="Gary Norton.vcf"
BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Gary Norton
EMAIL;WORK;PREF;NGW:GNORTON@broadgap.com
N:Norton;Gary
END:VCARD
--=_A9F4D80C.9DFC933D--