TulipTools Confessions

[misteroriginal]

Much of my time last year was INVESTED (not wasted, Diger!!!!) trying to single-handedly build a ZenCart beating eCommerce solution. I never told anybody, because I was afraid it might fail, which it did. Well, I told Vital, and she basically said MrO is a MO-RON (in so many words).

Well, I still think it can be done, and here's why. First, if you look at ZenCart, it is true that it represents thousands of hours worth of effort spread out over the years. BUT, it also has a lot of features that can be written off as DNA (Does Not Apply) for any given reseller. It is a generalist eCommerce solution using a shotgun approach in the hopes that some of the features will hit the "must have" targets of most online businesses. It includes a calendar, RSS feeds, MP3 downloads, etc. A lot of the complexity and volume of needed code disappears if you ask the simple question, "What do I need for my specific store" before you dive into it. It's similar to the clipart issue, in my mind. "Free" clipart requires you to invest your time (time=money) to find something that sort of fits, while creating your own content allows you to invest that time on something that can be a more exacting fit.

Second, much of the ZenCart Admin complexity is designed to adjust the website without having to dive into the code. The ability to dynamically adjust image size, for one example, is completely unecessary if you batch-process manufacturer photos in Photoshop. Reports, page layout, etc ('cuz I forget) add complexity without adding features that will be needed by everybody.

Finally, the buzz in the Interent world centers on RMAs (Rich Media Applications) which renders ZenCart completely obsolete. The idea behind rich media is that the customer will interact with a one-page website in much the same way prople presently interact with Microsoft Word, and not have to flip through hundred of pages for content.

"So, MrO, how do I build my own Rich Media Application?" you may ask. Well, that's a bigass question, little britches. But I tell ya, it starts with the database. There's a certain efficiency in determining the features you NEED, then developing a site with only those features. With Object-Oriented code, you can write a HECK of a lot less code than ZenCart has, you can write clearer code (WITH comments) that is easier for others to understand (so they can add features), and you have a fraction of the debugging issues that can be a project killer. The database is the foundation, the business tier addresses business logic issues, and the presentation tier show the world what beautious work you have done. "Ya gotta keep 'em seperated," as they say, so the end result is scalable, modifiable, and maintainable. For example, you want a login page for the customer that asks them to .... ummm, login. Start with the database so everything has a tidy place to go. Then you can build the presentation layer with the appropriate crap. Finally, you tie the two together. Done! Simple!

"If it's so simple, why didn't you git 'er done?" you ask??? I gotta go smoke! I don't have time for all these stupid questions.

[misteroriginal]

[quote author=vitalfinds link=topic=4648.msg19852#msg19852 date=1154884942]

... But I tell ya, it starts with the database.

I'm not sure about that, but both need to tie together somehow.  I'm doing a something a little different for my vitalfinds.com site that will include a way to handle multi-vendors, but I guess that some of the principles would probably be the same if it was just your own products.

The solution I'm looking for at the moment would be something like directory software, but would allow the submitter to upload a product photo.  So let's say that my code on vitalfinds went somethng like this:

a001> nbsp a002> nbsp a003>...

So let's say that there was an art seller who had ad a001 (in the database).  That art seller would have their own login and could make any changes they wanted at anytime to their product picture, and it would be transparant to me, because the system would always call up the latest image that was stored in the a001 location.

You might be talking about something using flash, but I guess the similiarity is that it's a stab at tackling that paging issue by offering some other way to be able to see a whole bunch of stuff at once.
[/quote]I'm talking about Flash or Ajax, but you're right. The whole process begins before the database. I'm just saying, from a programing perspective, it's helpful to do the database first before you design the logic. The programming has to query something.

Is it safe to assume the pictures will have to be associated with some data about the person who owns them so you can pay them their nickel each time it's downloaded? Or are you talking about people uploading banner ads to your site?