John Cox

Zen Cart / OSC Thoughts

From a post I did on the Zen Cart Forums. I am trying to start some discussion of the OSC's or Zen's of the world to start an API. It would make their lives easier, and others as well.

<snip>
I think that it makes a lot of sense to group the functionality / tables via the functionality that they provide. In doing this we have the start modularizing the codebase just a bit and separating the output from the functions.

The idea is this:

Master class for functionality piece. For purposes of discussion, use our imagination a bit.

In Zen Cart what would need to be done is to separate out the display and the user input from the actual processing of the code. I click on a product to add to the cart. This is a display function. Zen Cart takes the action, validates the input and then sends the validated input to a master "cart" class. The master cart class will add the product to the cart and return true to let the display function know that indeed this was added in.

The same process is handled on other platforms as well. For instance in Mambo, Xaraya, or Typo3, we handle the display part, validate the input, and then send to the master class for processing on the DB level. The master class takes the validated input, adds the record into the table and then returns true to let us know that it has been processed.

Updating and deleting should be handled in the exact same way, return either true (the request happened) or false (the request did not happen) and deal with the results in their own manner.

When the master class fails to respond add an attempt, it returns false. In each of the packages the processing takes over to handle the false return instead of the master class handling anything. The master class should not return an exception, just a yes or a no in this case.

The gets are a little more difficult to handle, because we are getting into the individual permission structures of each package. For instance in Xaraya we use an ACL based system which looks to the inherent permissions that a user has in order to display the item. In Mambo there is a completely different thing happening. In Zen from what I can ascertain there is a separation between "admin" and "user" and not really a distinction of levels. My guess is this would be the best way to keep the components. So for argument sake:

A request is sent to the master class to show an individual item. The class gets the individual item and returns an array of that request. The individual projects would need to handle the perms on their end whether or not to send the request or to just send an exception before the request is sent.

Getting a list of items is even more difficult in terms of integrating through multiple projects, since I may not want to show but a portion of the request, while in Zen you always want to show all from what I see. I would rather see the individual projects worry about sorting instead of trying to get us all to agree on how best to limit requests. So once again, the master class gets the request to list all and just returns an array of items.

A final function in the master class should be to count the items that are there and return the simple count.

If each functionality grouping can follow this standard, then integration into different projects would be very easy to do because Zen Cart is separating the processing of the actions from the actual IO basis. For Xaraya, we would take the individual classes and call them in our API and then process them in our GUI. Each master class would be a separate module to us. In Mambo I would imagine that the entire package would be wrapped in for the classes into one package and Mambo would handle the display functionality from their. Same with Typo3 but I am just guessing.

The advantages for Zen is you have now abstracted out the processing of components in a natural progression, and you have control over the API and the Classes that the individual projects are working from. I doubt that you would get help for the display part of Zen besides a bunch of examples of integration, but what you would get from the individual projects is help on the backend of processing, which after all is the hard part.

Looking through the code base, it appears that you have started moving towards an OO basis, but instead of mixing the presentation in those classes, along with the validation, I am suggestion to sub-class that on the Zen Cart side. Obviously I am just throwing ideas out for discussion, so please don't feel that this is the only way to do this. However for max extensibility I really think the master classes need to only return arrays / true / false, and then let the individual codebases handle the input / output from there.

What needs to be done before anything can happen?

An identification of what the master classes should be. IE, Cart / Tax / Payments / Customers / Locales / Orders / Sessions / Coupons / etc. From there we can start drilling down the the structure for each. Obviously the individual projects are going to have some of the items already resolved and will not need the functionality of all of these classes, but to move forward and in the spirit of cooperation, I would throw some development time in all of the areas that are identified, and I think it would be fair for the other projects to do the same. If we are talking about modularizing the code base for both a stand alone project as well as to be reused elsewhere then it makes sense to look at it via a team project.

Next the DB needs to be looked at. Just looking at the structure there are some opportunities to normalize the structure as well as get some performance gains, as well as add to the extensibility of the project itself (IE timestamps vs unix timestamps). In addition, I am not sure if I understand a couple of the decisions to not serialize and instead store individual components as separate rows. I think that there could be some opportunities to talk about the data structure just a bit.

Once that is done, then we all need to agree on code standards as well as documenting and commenting, since the development could be wide range and we are talking about extensibility with other projects. My preference would be to use a PEAR standard with PHPDOC in the code base for readability. I think that it would really push the project along quite a bit. The commenting currently is sparse, and that is OK, but it can be difficult to follow. I am open to any standards, but I really feel that there should be some sort of agreed upon coding requirements so that we can rapidly develop these ideas.

Anywho, those are my thoughts. Feel free to reprint this post anywhere for further discussion. I'd also like to suggest a chat from all interested parties if Zen Cart has a room anywhere. If not, I can set something up, or we can find a neutral location. I really think that these ideas can be further developed, and I am excited to get started, as I need the functionality as I said, and I hate developing alone;)
</snip>

Warning: Invalid argument supplied for foreach() in /home/niceguy/public_html/var/cache/templates/c71f60f688f84ae1cdfd7639a9815a39.php on line 3