Mailing List Archive

> I'm currently in the process of building a site from scratch in
interchange,
> and discovering much to my dismay that there is essentially no
documentation
> on actually integrating a site with the UI administrative backend.

The documentation has grown leaps and bounds since the minivend 3.0 days
(when I first started looking at the product). You need to keep in mind
this is a FREE product that allows a lot of us to make a living without a
high overhead. This was a one-man-show up until not too long ago and has
brought a product to market that works better then almost all other
commercial e-com packages.

Since you are doing this from scratch possibly you could document your
actions and post to the list. I've done this on those occasions where the
answers are not in the docs and have not been posted in the past. It helps
everyone!

> if i edit the pages in /interchange/lib/UI/, it's going to change for
> everyone, right? well, that's not going to be any good for those clients
who
> have different userdb fields, is it, as i run multipla catalogs under the
> one install :) so, what do we do here, guys? is there a solution to this
> one? i'm doing my best as i go along to hack and change stuff to get it
> working, but it's tough going without any documentation on how it plugs
> together. any assistance on what's possible here would be greatly
> appreciated :)
>

You can override Admin pages on a catalog basis. Make a directory called
admin in your pages directory. For eahc page you want to mod for that one
store, copy that file into the admin dir. Any changes made to that file
will now only belong to that catalog. BTW this was answered in the list not
too long ago, I used the answer just last week.

http://lists.akopia.com/pipermail/interchange-users/2000-November/001646.htm
l

Good luck,
-Ron

Quoting Cameron Germein (cameron.germein@team.eftel.com):
> I'm currently in the process of building a site from scratch in interchange,
> and discovering much to my dismay that there is essentially no documentation
> on actually integrating a site with the UI administrative backend.
>
> most of this, i can just hack my way past - i'm down to one last issue
> though, and it's got me a little stumped for now.
>
> i'm working on getting the admin section working with a userdb table that
> doesn't use the default fields contained within the demo - and of course,
> things are breaking. with a bit of field wobbling, i can get it to display
> the right users, but i can't edit them through that interface - and it's
> because when it goes to the next page, it's trying to build it with
> information that doesnt exist in the db, and so therefore 500 errors out.
> SO... my question basically is:
>
> if i edit the pages in /interchange/lib/UI/, it's going to change for
> everyone, right? well, that's not going to be any good for those clients who
> have different userdb fields, is it, as i run multipla catalogs under the
> one install :) so, what do we do here, guys? is there a solution to this
> one? i'm doing my best as i go along to hack and change stuff to get it
> working, but it's tough going without any documentation on how it plugs
> together. any assistance on what's possible here would be greatly
> appreciated :)

First of all, you can override only the pages needed. In other words,
if you think you want the admin/customer.html file as it is distributed,
but need a different admin/customer_view.html for every catalog, you just
need to make a pages/admin/customer_view.html that is different for every
catalog. In other words, the admin UI is templated and the common pages
are only shown when they don't exist in the catalog directory. It operates
like this (though not using ITL tags like this):

[if file pages/admin/customer_view.html]
[include pages/admin/customer_view.html]
[else]
[include /usr/local/interchange/lib/UI/pages/admin/customer_view.html]
[/else]
[/if]

Second, if you look at most of the pages the fields to edit are set
at the top of the page (customer_view.html is an exception, though).
You can usually just set the ui_data_fields variable different to change
the names.

The next version will have all of those things encoded in mv_metadata,
i.e. the field list for item_feature, item_edit, item_ship,
customer_bill, customer_ship, etc. can be different for every catalog
and is editable from a meta link on the page.

--
Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH 45056
phone +1.513.523.7621 fax 7501 <heins@akopia.com>

Any man who is under 30, and is not liberal, has not heart; and any man
who is over 30, and is not a conservative, has not brains.
-- Winston Churchill

thanks a lot Ron, I'm aware that it's a free product, and as such I'm really
whining about something that if I don't like, I should bloody go and fix
myself :)

as a side note, i've only been using Interchange for about a week now, and
only just subscribed to the mailing list :) it's a pretty steep learning
curve, but i have to say, this package impresses me more than anything i've
come across in a long time :)

----- Original Message -----
From: Ron Phipps <takedown@cdsnet.net>
To: <interchange-users@lists.akopia.com>
Sent: Thursday, January 18, 2001 3:44 PM
Subject: Re: [ic] interchange 4.6.1 UI manual installation.


> > I'm currently in the process of building a site from scratch in
> interchange,
> > and discovering much to my dismay that there is essentially no
> documentation
> > on actually integrating a site with the UI administrative backend.
>
> The documentation has grown leaps and bounds since the minivend 3.0 days
> (when I first started looking at the product). You need to keep in mind
> this is a FREE product that allows a lot of us to make a living without a
> high overhead. This was a one-man-show up until not too long ago and has
> brought a product to market that works better then almost all other
> commercial e-com packages.
>
> Since you are doing this from scratch possibly you could document your
> actions and post to the list. I've done this on those occasions where the
> answers are not in the docs and have not been posted in the past. It
helps
> everyone!
>
> > if i edit the pages in /interchange/lib/UI/, it's going to change for
> > everyone, right? well, that's not going to be any good for those clients
> who
> > have different userdb fields, is it, as i run multipla catalogs under
the
> > one install :) so, what do we do here, guys? is there a solution to this
> > one? i'm doing my best as i go along to hack and change stuff to get it
> > working, but it's tough going without any documentation on how it plugs
> > together. any assistance on what's possible here would be greatly
> > appreciated :)
> >
>
> You can override Admin pages on a catalog basis. Make a directory called
> admin in your pages directory. For eahc page you want to mod for that one
> store, copy that file into the admin dir. Any changes made to that file
> will now only belong to that catalog. BTW this was answered in the list
not
> too long ago, I used the answer just last week.
>
>
http://lists.akopia.com/pipermail/interchange-users/2000-November/001646.htm
> l
>
> Good luck,
> -Ron
>
>
> _______________________________________________
> Interchange-users mailing list
> Interchange-users@lists.akopia.com
> http://lists.akopia.com/mailman/listinfo/interchange-users
>

You can make catalog specific admin pages by creating an admin subdirectory
under the catalog's pages directory. Then copy the files from
lib/UI/pages/admin there. You can edit these any way you need to and the
changes won't affect the global admin pages.

Good luck,

Cameron

> -----Original Message-----
> From: interchange-users-admin@lists.akopia.com
> [mailto:interchange-users-admin@lists.akopia.com]On Behalf Of Cameron
> Germein
> Sent: Thursday, January 18, 2001 1:29 AM
> To: interchange-users@lists.akopia.com
> Subject: [ic] interchange 4.6.1 UI manual installation.
>
>
> I'm currently in the process of building a site from scratch in
> interchange,
> and discovering much to my dismay that there is essentially no
> documentation
> on actually integrating a site with the UI administrative backend.
>
> most of this, i can just hack my way past - i'm down to one last issue
> though, and it's got me a little stumped for now.
>
> i'm working on getting the admin section working with a userdb table that
> doesn't use the default fields contained within the demo - and of course,
> things are breaking. with a bit of field wobbling, i can get it to display
> the right users, but i can't edit them through that interface - and it's
> because when it goes to the next page, it's trying to build it with
> information that doesnt exist in the db, and so therefore 500 errors out.
> SO... my question basically is:
>
> if i edit the pages in /interchange/lib/UI/, it's going to change for
> everyone, right? well, that's not going to be any good for those
> clients who
> have different userdb fields, is it, as i run multipla catalogs under the
> one install :) so, what do we do here, guys? is there a solution to this
> one? i'm doing my best as i go along to hack and change stuff to get it
> working, but it's tough going without any documentation on how it plugs
> together. any assistance on what's possible here would be greatly
> appreciated :)
>
>
> _______________________________________________
> Interchange-users mailing list
> Interchange-users@lists.akopia.com
> http://lists.akopia.com/mailman/listinfo/interchange-users