What is the biggest default / less of Oscommerce

[piernas]

@@burt for development you should really work on a public roadmap and a list of tasks with priorities and global directions, and assign those tasks to people who want to take them - just to avoid working on something that you consider is not urgent or un-needed. That's the only way a team can do things as a team and pull together.

[burt]

I did that, and even then people did/do as they want with little to no regard for directions.

 

That can be seen even today.

[piernas]

I did that, and even then people did/do as they want with little to no regard for directions.

 

That can be seen even today.

 

I think I missed it. Where's it?

[ShaGGy]

@@burt Would it be possible to assign someone with a basic example / tutorial of how to modify a old addon to become modular based?
I think this may help a lot of amateur coders in updating the addons they use and thus uploading the new version after they have made the changes.

 

Also re the urlencode issue i had, i see there have been a few others now experiencing the same issue with the cart (on item with attribs) can the urlencode not be added to the core as this would not impact on the core in any way but would increase host compatibility.

[♥kymation]

@@ShaGGy  I'm not sure that's possible.

1. Some of the Addons written for osC 2.3.4 are already modular, so they will take very little effort to make them use Bootstrap. My Theme Switcher module is a good example; I converted that with an hour's work.
2. Some others are mostly modular but require some core code changes. Those can be improved by using Header Tag modules, Hooks, or a bit of code finessing to get rid of the core changes. These will need to be examined on a case-by-case basis to determine the best way to proceed.
3. The remainder require a lot of core code changes, or are old 2.2x code patched to work with 2.3. These will probably have to be rewritten, or at least require a lot of changes. (I'm not looking forward to updating MVS. Anybody want to adopt it?)

I don't think there's any way to write a guide for that that's less than a medium-sized book. Too may different options.

 

If you have a particular Addon in mind, I might venture an opinion on what it would take, and maybe an outline of the steps. If it's not too complicated, and I have the time.

 

Regards

Jim

[burt]

Actions.  https://github.com/gburton/Responsive-osCommerce/blob/master/includes/application_top.php#L335-L423

 

Needs to be a class, then have modules which just drop into an /actions/ folder.  Would solve a lot of core code changes.

 

@@Tsimi and I played with doing this a while back, but what we came up with worked but not well enough for prime-time.

[♥kymation]

@@burt  Could the actions be hooks? One hook file per action value would make them easy to replace or add to.

 

Regards

Jim

[burt]

@@kymation it could be a hook, no reason why not I guess.  I had not thought of that.

 

The reason I was thinking about a class was because of this work done by wHiTeHaT, but as he has disappeared...I have no way to ask him to recreate it for the BS version, and I just don't have time to do it :(

[♥bruyndoncx]

you've lost me along the way,

 

what is the essential difference / limitation between hooks and this action class ?

any pro/con ?

 

The whitehat action class doesn't seem to rely too much on the product class, or am I mistaken ?

[oscMarket]

you've lost me along the way,

 

what is the essential difference / limitation between hooks and this action class ?

any pro/con ?

 

The whitehat action class doesn't seem to rely too much on the product class, or am I mistaken ?

 

The action class is kind of a router what controls any "actions".

The use of the 

$osC_Product 

class is not required in the action class itself but in the action modules...

include('includes/modules /actions/' . $module . '.php');

$module could be a class file that is named : cart_add.php

As you can see when investigate the cart_add.php class file you will notice the usage of the product class $osC_Product.

 

The benefit of such an action class is that it can control many different actions (mostly form/posts).

-Login procedure.

-Check a discount coupon's code.

-Wishlist etc....

 

Before all these actions where inside the application_top.php now each action have their own class.

[ecommunlimited]

Just my 2 cents, regarding the zones and taxes. If the countries, zones, tax zones, tax classes and tax rates were all combined into one with some sort of drop down menu, that would be great. There's people that have trouble with that when installing mods like MZMT. It can be pretty confusing when you have to bounce back and forth through them. The sql for all of that is not in the newer MZMT. I had to go back and find it in an older version. But before I went back to an old version, I was trying to do it myself and was having a heck of a time because I couldn't see what I did when I clicked out of one into another. I'm not sure if you would class that as a down fall but with the core the way it is, there's a whole lot of clicking from one thing to another through out the admin.

 

Piernas put out Improved Content Modules Admin For 2.3.4 Responsive and it simplified things for people. What I'm getting at is that the core and each related group of function should be condensed it to one and simplified. That's just my 2 cent.

 

Bill

[♥kymation]

@@burt @@wHiTeHaT  Is there any advantage to either the Action class or Hooks for this purpose? Hooks are already in core, while Actions would require another class that must be maintained. That seem (to me anyway) to give Hooks a slight edge. What am I missing here?

 

Regards

Jim

[oscMarket]

@@kymation

 

It is hard to say exactly, but this is what i can tell you about the 2 systems (just by quickly looking)

 

action class:

if ( isset($_GET['action']) && !empty($_GET['action']) ) {.............

Here the action class is called by the custom attribute 'action'

An example usage in product_info.php is:

echo tep_draw_form('cart_quantity', tep_href_link($PHP_SELF, $osC_Product->getKeyword() . '&action=cart_add', 'NONSSL'), 'post', 'class="form-horizontal" role="form"');

For what i notice in the Hooks class is, that it is mainly used when are within a specific section of the site.

The first usage of the hooks when introduced it was inside the admin orders page.

 

This is how it is described :

parameters:

Hooks::call($group, $hook, $action, $flatten)

Usage:

// no output expected 
 $OSCOM_Hooks->call('Account', 'Logout');

Somehow, even that it is possible to just use the Hooks class, i get the idea that it would become a mess in the end.

 

The action class is specifically when executing forms/posts from anywhere on the website.

The Hooks class on the other hand has some more exact rules and parameters what needs to be respected when implement "later".

 

For you and me and many others using the Hooks class would work, simply because we know the system, but i think when another advanced programmer would take a look at it, it would confuse him.

Infact i even see the same happening with the ht_ class, we say HeaderTags, but if look for example the equal heights add-on you see it is loaded from the footer_scripts.

 

Grtzzzz

[azpro]

@@kymation

 

I did some testing with the Variants solution of @@wHiTeHaT over a year ago .. It seemed at that time to be a good solution to keep together different Actions (shopping_cart - variants - etc.etc.) in a logical / comprehensive way  ... But I believe it could be done also with hooks - as long as the naming is properly done .. Otherwise we risk ending up with Spaghetti Code ...

 

Might be nice to test when you re-develop your Products Specifications for BS :)   http://addons.oscommerce.com/info/8096

 

Regards,

 

Arjan

[♥kymation]

@@azpro  I'm not looking forward to that one either. There's the beginnings of a nice class in there, but the rest is a horrible mess of spaghetti and core code mods. Not fun.

 

Regards

Jim

[azpro]

I'm not looking forward to that one either. There's the beginnings of a nice class in there, but the rest is a horrible mess of spaghetti and core code mods. Not fun.

 

Regards

Jim

 

@@kymation Yep - I used your work and adopted to BS .. Unfortunately I lacked time to re-develop ... The approach / framework you set is good but needs smarter coding ... I lack true experience in software engineering / architecture to come up with a good solution ..

 

IMHO a well-designed Specifications  / Filtering add-on would be the BOMB ... We have over 30.000 SKU's ... Growing every day ,,,

 

Regards,

 

Arjan

[♥kymation]

@@azpro  I have completed the design for a new modular version. Different functions could be separated out so that the store owner need only install the modules they wanted to use. Unfortunately this architecture exists only in my head and I don't have the time right now to code it up. Maybe once osCommerce 2.4 is released I'll get motivated to do it.

 

Regards

Jim

[♥Gyakutsuki]

@@kymation : Unfortunately this architecture exists only in my head . For me that I make but the difference is so big that we can compare  a new software, just the heart I take and I rewrite the architecture.
I think this post could share in 2 post, one based on functionnal approach  and one coding / architecture approach. The architecture for the next release must to be close to the 2.3 than I saw on the development.