[ic] stable interchange-4.7.x.tar.gz + adjusted docs

cfm@maine.com cfm@maine.com
Thu, 5 Apr 2001 12:34:55 -0400

On Thu, Apr 05, 2001 at 11:19:13AM -0400, Doug Alcorn wrote:
> cfm@maine.com writes:
> > The strength is the core.  ic is not very good at page building 
> > and of no use at all that way when one's site is bigger than the 
> > catalog.  Me, I'd say leave the site construction -"construct" 
> > and templating - to other tools that do it better.  IC is plenty
> > stable right now as far as the core is concerned.
> Would you mind writing up something more about this?  How are you
> doing development from just the "core"?  What does the source of your
> pages look like?

That's a **long** story.  Close to my heart though, so I'll humor
the request a bit.

We're a 7 year old ISP with a mission to help clients publish.  We
don't do access.  We've been doing "database publishing" for a long
time.  We've built a system that more or less parallels Arsdigita's
ACS, only using minivend and perl instead of AOLserver and TCL.

A lot of what we do now amounts to reinventing the wheel, we have
our own UI and maybe 25 table editors, a system-wide data schema
and so forth (see ACS).  Much of that functionality is now in
the UI.  We use it, however, for data entry for what amounts
to a content management system, for Intranets and Extranets, not
just for catalogs.  That's why the core is so great;
it's a dynamite session manager.  And that's why the presentation
doesn't cut it for our purposes; it is simply not big picture, 
beyond minivend.

We've been using a perl DTD for many years.  We build sites from
templates and parts that are "expressed" through the DTD and several
layers of "accounts", a default, a "site config", a "merchant" and
sometimes an end user "account".  There is next to no mixing of
content, code and presentation.  Subject to rollout, all our catalogs
are the same: www.mainelyscrubs.com, www.mainelobsterdirect.com and
www.epifanes.com are the same code, only configured differently
in database and DTD.  Some of this happens on the fly, some is
built on crons and cached, some is static.  None of that DTD/page
building is minivend but none of this would work without it.

All of our catalogs **require** a category hierarchy.  Those categories
a site uses define the structure.  We are merging our own home grown
structure, originally an extract of the big search engines into a
mapping to DMOZ + our own local categories.  That allows consistent
aggregation of catalogs and looks ahead to multi-site data shuffling, 
slashconcept.  Not just products, but directories, links, classifieds,
reviews, etc....

We're at the point now where we can create a basic minivend storefront
by registering a user (online) and configuring his merchant setup (not
yet online).  Actually, we've been at that point several times over
the past couple of years and had to back off and rip apart, the
current rip apart is systemwide "enterprise keys".  The result we
want is pretty much a site + Yahoo! store requiring no presence on file 
system, everthing dynamic.  I told you we were reinventing 
the wheel.

> I have heard sentiments like yours from more than one place.  I'm
> still pretty new to IC, but I've had suspicions that are similar.  I'm
> just not sure how to make the transition of how I do things now to how
> you are doing things.

There are a whole slew of business and workflow issues that have brought
us to this point - I think Mike H described it once simply as a "custom"
system.  I can't imagine why you'd want to do things the way we do.


Below sig I've appended our typical page in the "checkout" sequence, after
the basket.  It's all perl modules.  We do perl, c and a little bit of
javascript; nothing else.  This particular checkout code hooks all of
the checkout code for every one of our checkout pages in every catalog.
Think maintenance.

I'll shut up now.



Christopher F. Miller, Publisher                             cfm@maine.com
MaineStreet Communications, Inc         208 Portland Road, Gray, ME  04039
1.207.657.5078                                       http://www.maine.com/
Content management, electronic commerce, internet integration, Debian linux

# Checkout.pm
    use MV::Checkout;
    use MS::D;
    use MV::Merchants;	
    use MV::Opts;
    use MV::SC;



    if ($opt{merchant}&&($m=$M->{$opt{merchant}})) {
        if($opt{verbose}) {
    $Z{templates}=__SC{templates}__; # need this for final and receipt (at least)

    return &MV::SC::dtd(\%opt,\@OUT,undef,'wrap',$m); # requires 'wrap' AND $opt->{wrapper}