Hi Cs-cart,
I think you should come up with a book, a comprehensive book like
Cs-cart development - the complete reference
Most of the popular technologies like wordpress, magento, drupal have such books.
This book should not be a freebie and thus should give enough motivation to the cs-cart company or the author to work on it.
Even after being associated with Cs-cart for 2 years, I sometimes feel crippled when it comes to implementing something new.
docs.cs-cart.com is a good starting point but not enough.
regds,
Shikhar
Massive difference in the user base for the products you list though. Those books are normally written by 3rd parties who know there are enough users out there that even if they only sell to 1% of the user base they will still make money.
Compare the documentation that CS-Cart has against other products with low user numbers (in terms of the ones you listed) such as CubeCart and you'll find that CS-Cart is light years ahead.
Never work with cs-cart. Things change too frequently and there is little to no compatibility between versions.
@NairdaCart
I understand what you are saying. But after a couple of years I would want Cs-cart to be as big as Magento and not just be another open cart.
Secondly, niche topics with smaller user bases also do have books.
@tbirnseth
I see from your other forum posts that you are pissed off with cs-cart 4, I haven't yet looket at it and I am scared now.
You can't publish an interface to something that undergoes continual change. Hence, a book is not viable.
I'm pissed that as an addon developer, they have caused me massive amounts of rework with zero added value for either me or my customers. But this is from an addon developer perspective.
I have no real opinion on most of the V4 product as it relates to the merchant's use of the new admin (wasn't needed) and the theme editor will probably help many merchants to tailor their store in a standard way as well as provide a way for theme developers to simply describe the new theme to the system and let it unfold. Once the store import is done, some of the more experienced users will start to migrate to V4. This is when the real bugs will be revealed and the pain/pleasure of doing so will unveil.
V4.0.1 is for new users and/or for people to “try”. I doubt there are any V2 or V3 production sites that have gone to V4.0.1. If they have, then they have far too much time on their hands…
I feel tbirnseth's frustration,
I have not been posting much in this forum lately. Mainly because I am losing interest in cs-cart. I spent a lot of time learning how to modify version 1.3.5, 2.x and 3.06. It is hard enough maintaining all these different versions for my existing clients without learning an entire new version again.
Cs-cart makes unnecessary changes in each new version without really adding any new benefit.
I do not have the time or patience for this anymore.
Another point of view is that I originally tried CS-Cart 2 and CS-Cart 3 and couldn't get on with them at all because of the messy admin layout and the way the code was written.
When 4 came out in Beta I decided to have another look and I liked it so much I decided to move from my previous cart to it. The admin is much better in my opinion and the code is much clearer and easier to understand.
I fully appreciate that if I had a working V3 store the last thing I would do is spend time converting it to V4. There's nothing in it (that I can see) that would be useful to someone in that position. However I fully expect, now that the ground work has been done, that v4.2 etc will offer improvement that will make the pain of upgrading worthwhile.
As someone who has run large software companies I know there does come a time when you have to look at the product and realise you have to take the time to make sure the foundations are correct before moving on. Ripping everything back to this level is often traumatic for existing users but is essential for the future.
Yeah, but you don't do it annually unless you're trying to alienate your partners.
[quote name='tbirnseth' timestamp='1376601913' post='166893']
You can't publish an interface to something that undergoes continual change. Hence, a book is not viable.
I'm pissed that as an addon developer, they have caused me massive amounts of rework with zero added value for either me or my customers. But this is from an addon developer perspective.
I have no real opinion on most of the V4 product as it relates to the merchant's use of the new admin (wasn't needed) and the theme editor will probably help many merchants to tailor their store in a standard way as well as provide a way for theme developers to simply describe the new theme to the system and let it unfold. Once the store import is done, some of the more experienced users will start to migrate to V4. This is when the real bugs will be revealed and the pain/pleasure of doing so will unveil.
V4.0.1 is for new users and/or for people to “try”. I doubt there are any V2 or V3 production sites that have gone to V4.0.1. If they have, then they have far too much time on their hands…
[/quote]
I agree with you.
The v4 for us developers (and not only for us) is nothing other than a marketing b…t.
The structure introduced is not properly user/developer friendly…
I don't see how introducing proper coding standards and industry standard templates into a product that had neither could be construed as being developer unfriendly.
@NairdaCart,
They already had coding standards in place (snake case versus camel back). If you've been in SW development, you know that coding standards are a dime a dozen and the important thing is to pick something and then stick with it versus changing when another one comes along. I can't tell you how many I've seen that are the next industry standard only to be used by some and ignored by others.
There are no industry standard templates being used. They simply use an auto-loader for classes (a design choice) that the latest version of which now expects class names to be in a particular format (this is fine and doesn't affect the developer at all since it's auto). It is the method naming changes that are annoying and make moving an existing addon (that has been designed, tested and deployed) painful to move to V4 and these naming issues are not syntactical issues, but are only identified at runtime. Note also that some of the functions like fn_send_mail() no longer exist and are now methods like Mailer::sendMail() that utilize different parameters then previous. If they cared about their partners, they would have left the funciton interface in place and done what was needed to utilize the method within that functional interface.
Changing all the DIR_* constants into registry variables is a BAD idea. A hacker can easily now change the reference of the cache directory to another (possibly off-site) location and have the system do basically whatever they want. No reason to move a constant to a variable.
$config = Registry::get('config');
$config['dir']['cache'] = ROOT_DIR."/my_funky_directory_with_my_own_registry_info";
or maybe even
$config['dir']['cache'] = "http://some_hacker_site.com/some_directory";
Registry::set('config', $config);
If constants were used/maintained, this would not be possible.
And so while I'm on a roll, fn_get_lang_var() changed to __() and then template variables all changed from using variables to a new template tag. I.e.
```php
{$lang.foo}
to
{__("foo")}
```
is also a pain in the ass (especially if you derive your language variable from context other than literal). Though I do understand why they did this one. I find the use of "__" rather unreadable since it tends to blend in with other PHP constants like __FUNCTION__ and it's not a constant. Wonder what part of the coding standard drove this one (I.e. __(__FUNCTION__)) - boy is that readable). Why not just introduce a new tag like {lang name="foo"} would certainly be more clear for reading.
The layout goes from 2-3 root directories (admin, customer and mail) to no less than 10 and admin=backend, customer=frontend). There was no value (other than breaking stuff) for them to change these names and cause everyone to do more work.
As an addon developer, we used to be able to rely on the ability to reload admin and customer templates from the skins repository when customers screwed up. Now, all admin templates are static and once changed, there is no distributed reference point to restore them from (other than uninstall, re-extract archive, install). Additionally, there is the whole internal "build process" used to create addon archives and versions and to control this process. It too had to be completely rewritten to support these changes. I probably should have taken the opportunity to just move to a more stable cart since the investment to move to V4 versus moving to another cart platform is about the same.
Namespaces are okay, but really unnecessary for the base product. They are valuable to an addon developer who has conflicts in their naming with the distributed software. But using them in the base product (and only for classes) is just extra effort and a waste of time. They don't use namespaces for constants or function names at all.
Just curious how many V2/V3 addons that utilize admin, customer and mail templates that you've ported to V4 and how much time you invested in taking something that had very slight variation between V2/V3 (from a development perspective) and moved these to be viable V4 addons. Or have you just read the marketing info....
Bottom line is that these changes do nothing for our customers and simply cost us many $$ in re-investment with very little ROI on that extra cost. Cs-cart isn't exactly paying us to re-tool.
@tbirnseth
NOW YOU REALLY SCARED ME
And I really don't know why Namespace and all the industry standard is so important ?
If you want to become JAVA, then better use JAVA.
Going to have to agree to disagree.
All I'll say in parting is that I've owned and run companies with over fifty programmers working on single projects and I say that the direction CS-Cart is going is 100% the right way for a commercial software company that has a large support overhead.
If I was an addon developer I would (as a business man) like the changes as it gives me a way of leveraging my existing client base rather than having to rely totally on new sales.
I used to develop plugins for various CAD/CAM applications and I had those set up that the basic logic and display code was written in a high level pseudo code so instead of changing code around whenever a new version of one of the many programs I supported came out all I had to do was to change the rules in the code generator and push the button.
@NairdaCart - Time will tell. I guess we'll have to agree to disagree on the “value” of the changes.
@shikhar - my intent was not to scare you but simply state the facts. SW companies managed by developers are different than SW companies run by business people. There's a sense of 'purity' with developers that rarely equates to business sense. The hack scenario I described above is VERY UNLIKELY. But the point was that moving critical things from CONSTANTS to VARIABLES is a bad thing and does open up vulnterablilites.
@tbirnseth
I am least bothered about the hack scenario, I am scared of the learning curve and time wasted in hit and trial !
They provide skeletal information in the guide. But it is woefully incomplete… But there will be a lot that you just have to waste time digging for. Many things have never been documented (like the Settings class) so it's always hit and miss. Just assume that ANYTHING related to a class will be different and incompatible (including use of $view methods).
If I might direct this thread back to its original theme…
This is a drum that I've beaten more than once here. I agree that a book is not the way to go, as the technology changes too rapidly, but for heaven's sake, why oh why are there not any videos on how to use this fantastic shopping cart?
Check out You Tube and see how many videos CSC has posted on their channel. It's embarrassing. There's a whopping THREE videos there, with the most recent one being 7 months old.
https://www.youtube…rtvideos/videos
I would venture to say that one person who really knew the program could create several dozen “how to” videos in a single day. Just start on the far left of the admin panel and work your way to the right, going over each menu. Point… click… explain! Getting the knowledge out there not only would relieve the work load of tech support, but it would be a great selling tool for potential purchasers of the platform.
Maybe they don't do this because they feel that it has to be done “just right”, but better to just give us a lot of info that's not polished, than none at all.
While the knowledge base in CSC is pretty good, I find as a layman that they tend to skip over certain details, assuming that the user already knows what they know (I can't tell you how many times I've read. re-read, and re-read again certain passages in the knowledge base and still came away scratching my head). With video it's harder to gloss over these minor points. When explaining something technical, you've got to present it as you would to a bright 5th grader IMO.
BTW, while I'm on the soap box, why don't you pros do as I've suggested? Develop a series of videos showcasing how familiar you are with the program and have them accessible on your own site. You'll find a dramatic increase in traffic, straight off, and when lay users need some development work done, you'd be the one they'd naturally think of hiring.
Because some of us aren’t very photogenic 
Producing a quality instructional video is not as easy as you make it sound. The audience has a wide skill set and a poor video can do more harm than good.
Now if someone wants to take my addons and do quality video tutorials of them I’d be happy to give them referrer commission on every addon sold that is referred from one of the videos. Remember a good developer is not always a good visual/graphic designer nor experienced in video technologies and tools.
Not sure how directing a book topic to missing videos is staying on topic, but that’s the fun of a forum!
I'd like to revive this discussion regarding documentation that is so badly needed… I can't tell you how many times I've started looking at writing some code to do something, only to eventually figure out CS-Cart already does what I needed, it just isn't documented well enough (if at all).
I'd like to propose the community take a stab at putting together the documentation, especially since it appears there's now a published documentation standard (documentation standards here).
If everyone picked a topic (ex. select one of the addons or a function/feature in the core app or a page in the admin settings), and put together something complete (heck even incomplete would be more than we have today!), we might be able to at least make a dent in this massive void.
Those folks that have some expertise or experience in a certain area, but don't have time to put the documentation together, could maybe at least take a look at, and add on to, the contributions that another less experienced person has submitted or started. This might help folks feel more comfortable about helping out without having to feel like they had to be an expert or had to cover the subject matter completely before they provided a submission. Again, having 50% of something covered would be better than we have today, and would be easier to then let others chip away at the remainder.
I'm not sure how this would be coordinated, or if it even could be, but I'm willing to give it a shot and will start by putting together some documentation. Still need to review the documentation standards and find out how to submit (if it's even open to external documentation submissions).
Maybe I've got my rose colored glasses on?