Product Type Book (by moku)

[quailbooks]

Hi,

Sorry that I didn't respond yesterday, but I teach a class at the college and had to get ready for that Wednesday and Thursday.

My comments are interspersed:

Hi
The ideas about bulk book upload would really make a better contribution, but whatever method is used there needs to be a lot of internal product checks at the server end to avoid upsetting the zencart database.

As I probably said already, I tried the popular contrib that does this for standard products, I found it was very secretive, gave no feedback about any errors. Certainly the excel-style Comma Separated Values (CSV) are an obvious starting point, but whatever is at the 'web' end needs to be far more intelligent than the contribs I've used. If corrupted or only part-updated, the zencart database will just show crazy entries on a live website!

I agree as I've tried to use it also with very little success and didn't feel like paying to try the commercial version.

BTW, I looked at the MySQL documentation and found out why it is that stored procedures are not used in Zen Cart. Simple answer is that MySQL didn't support them fully until V5.0.1. Until the Zen Cart development team makes the decision to restrict development to MySQL 5.0 and above then I'll have to use the Zen standard for the upload module.

You had an excellent suggestion in the PM about storing the CVS data and processing with an error report. That's the way most uploads seem to work. Delimiters aren't really a problem as a selection of checkboxes for delimiter type (tab, comma, semicolon, etc.) seems to be the standard.

If you want to work on the book product while I do the upload module it would work for me.

if various people do consistently work on the book contrib, 'we' could set up better ways of progressing. The V3 contrib is on my Hareslade site in beta, merely because it takes ages to identify bugs, and once on the Zencart download site its not so easy to update (in my view!) . Its not because I'm a control freak!

Not a bad idea! Some sort of cooperative area on the web? A restricted forum for developers with a file exchange area probably is best. That's something to think about.

The 'version 3 beta' is the current offering, see the top area at
http://www.hareslade.com/zc/index.ph...roducts_id=482
it tries to meet requirements for multilanguage sites for book products, and that is the one to consider as the most advanced, for 1.3.7 carts. It also works in single language.

Yes, I've downloaded it and I'll make a fresh install this weekend. I'll be interested in what the changes have been.

On that subject, perhaps you'd like to keep an idea or wish list of items --maybe you already do-- of identified features that users would like. I'd suggest putting them in as named items instead of the generic terms you've used in the past. It would make the product more standardized and since users can turn features on/off through product layout they can customize there.

I'll start with some ideas:

1. Multi-volume sets needs a bool flag and volume # of volumes #
2. Model number identifier from dropdown (ie: ISBN10, ISBN13, LCCN, whatever) as most older books don't use ISBN and ISBN has changed from a 10 digit to 13 digit number this year.
3. Book Club Edition boolean flag and maybe a text identifier of what club --I'm not sure about the last.
4. Some method of setting the default value of a dropdown selection. IE: for the model number identifier above. I'm not sure how this would work, but will think about it.

Because sql instructions (which can add or delete database tables or fields etc.) sometimes fail, -(even just because you might be running the latest mysql version, and the contrib. was made before that version) - its best to ***always*** install the 'database backup/restore' contribution, which I think is still available.

With that backup contrib. you can save the existing zencart database before applying an 'sql patch'. And believe me, sometimes the sql patch will only half complete, so you just must have the original database to restore, or you end up having to install the cart again, to get a useable clean database.

However, for those who know how to use phpmyadmin, its easier because you can go in and correct/change the database as required, if you know what to do.

I've already run into the problem of the SQL not reading the file completely, reporting errors that don't exist, etc. from the tool. So I fully support the idea of running backups --often!

My apologies if the readme files in the pack are not always easily understandable, its difficult to put suitable texts when I know the actual contrib inside out, where others do not!
-----------------

Not a problem at all. You should see some of the code that I've had to deal with in the past and what they considered documentation. Yours look absolutely wonderful in comparison.

In Summary:

I'm going to concentrate on the uploader and leave the book product development to Paul. In parallel, I'm also using the book product as a starting point for a movie product type (type 9 for now) that supports the various movie formats. The two are so similar that the project is trivial.