Jump to content

Jim Lekas

Members
  • Content count

    13
  • Joined

  • Last visited

About Jim Lekas

  • Birthday 05/03/1957

Profile Information

  • Real Name
    Jim Lekas
  • Gender
    Male
  • Location
    Martinez, CA, USA
  • Website
  1. Jim Lekas

    Internal Code Documentation

    Thanks for taking on the job. I'll attempt to add some descriptive comments in the meanwhile.
  2. Jim Lekas

    Internal Code Documentation

    Sorry about the delay. I've had some problems with my development environment. If it is convenient, please set up a subversion server. If you don't have the time, I can probably set one up (I'd have to check with my ISP to be sure). If I can check in modified files on a branch from oscommerce-3.0a4, then the changes I've made will be easy to see. Otherwise, let me know what version you prefer, and I'll see about a merge. I'm assuming you would just set up a new server with one version of the code, rather than a copy of the whole oscommerce revision history? It would be helpful to have a place for PHPDocumentor and Doxygen output, so we can see what those two programs make of the code. The documentation programs could be run on our respective local machines, and the results uploaded I would think.
  3. Jim Lekas

    Internal Code Documentation

    I'd be happy to collaborate. From what I've read (and it isn't much), Doxygen is used by some PHP projects. One writer gives this comparison of PhpDocumentor and Doxygen: [font="Courier New"] [b]PHPDocumentor[/b] [b]Doxygen[/b] Easy to Use Multi-language (not just PHP) Made for PHP Windows GUI Written in PHP RTF Output Several Layouts Creates class diagrams Created Peardoc Files Writes DocBook Format [/font] Doxygen appears to accept a superset of the tags accepted by PHPDoc. Perhaps a common subset can be identified which either PhpDoc or Doxygen can parse. Doxygen will accept JavaDoc style tags, which begin with "@". If the osCommerce community wants to exploit the unique features of Doxygen, then it would probably be better to adopt it as a de facto standard and forget PHPDocumentor. On the other hand, PHPDocumentor might be more widely used by PHP developers. For instance, Joomla uses PHPDocumentor, I think. It seems to me that documentation should be present for each file, class, public function, and global variable, at least. The documentation should state purpose of the item, and explain how to use it. For functions, it should include descriptions of the input and output values and any side effects, such as changes in the data store. In my opinion, the osCommerce project should be partitioned into packages along functional rather than structural lines. That is, it's better to group the files that handle customer accounts together than to put all the functions together, all the classes together, etc. I've done this to some extent, leaving the current directory structure alone for the time being. For instance, my osCommerce_customer package encompasses account.php, includes/content/account/account.php, and includes/classes/account.php, among other files. Other documentation could employ DocBook, or IDE output. For instance, I use Enterprise Architect to create entity-relationship diagrams to document the data store, and various UML diagrams to express aspects of the osCommerce structure. What is your thinking about the amount and type of documentation needed? Also, do you know what it would take to get internal code documentation accepted into the osCommerce development tree?
  4. I'm adding some phpDocumentor tags to my copy of osCommerce 3.0a4 as I go through the code to allow me to produce some basic internal documentation. I see others have inserted similar tags (@param, etc.), but also some unrecognized tags (@seeAlso). Does anyone know whether some other document extractor is used by osCommerce developers?
  5. As far as I know, there is no comprehensive developer's guide. However, there are some useful technical notes about key elements of the osCommerce 3.0 system at the Development Server: You might find the information about the files which implement the template system helpful for example.
  6. Jim Lekas

    NEW! Complete Order Editing Tool!

    Changing edit_orders to update the quantity in inventory will take a little work. It appears that pattern established in checkout_process can be followed, but the quantity adjustment will probably have to compare the "after" order with a "before" order to find out what changes were made. It would be helpful to consolidate the quantities for each unique product id when it occurs on two order lines (if the product attributes mechansims don't interfere.) Unlike checkout_process, which only reduces inventory quantities, edit_orders will have to increase inventory quantities when an order quantity is reduced or when an order or order line is deleted. The inventory adjustments of checkout_process and edit_orders probably should be combined in an inventory module, and the inventory probably should be kept in a record separate from the products record.
  7. Jim Lekas

    NEW! Complete Order Editing Tool!

    Hi akkinmore. When you say "When you add product to the order the quantity is not updated", do you mean that you press the "Add Product" button to add more of a product already on the order? In that case you probably see a new line item for the added quantity. Probably identical items should be merged, but it is easy enough just to change the quantity field if you are adding more of something already on the order. Perhaps you are altering the quantity on a line, but not seeing the order price change? In that case, maybe you need to scroll to the bottom of the order edit page and press the "Update" button? Or are you saying that it worked before you introduced my changes? In that case I will be grateful for an example or other detail to rectify the changes as soon as possible. -- Jim
  8. Jim Lekas

    NEW! Complete Order Editing Tool!

    Regarding akkinmore's question about negative option prices being registered as positive prices: The problem appears to be that products_attributes table carries the sign (+ or -) in a separate "price_prefix" field, but edit_orders doesn't make use of it. To take the price_prefix into account, I suggest the following two changes. WARNING: These changes have been only lightly tested. Back up your file. At about line 366 of edit_orders.php (v 1.3), replace extract($row, EXTR_PREFIX_ALL, "opt"); $AddedOptionsPrice += $opt_options_values_price; $option_value_details[$option_id][$option_value_id] = array ("options_values_price" => $opt_options_values_price); with extract($row, EXTR_PREFIX_ALL, "opt"); if ($opt_price_prefix == '+') { $AddedOptionsPrice += $opt_options_values_price; } else { $AddedOptionsPrice -= $opt_options_values_price; } $option_value_details[$option_id][$option_value_id] = array ( "options_values_price" => $opt_options_values_price, "price_prefix" => $opt_price_prefix); and at about line 407 of edit_orders.php, replace price_prefix = '+';"; with price_prefix = '" . $option_value_details[$option_id][$option_value_id]["price_prefix"] . "';";
  9. Jim Lekas

    NEW! Complete Order Editing Tool!

    Hi Morb. I'm happy to hear that you got it working. That is one strange error. When you have time you might want to call in an exorcist.
  10. Jim Lekas

    NEW! Complete Order Editing Tool!

    Morb, The second SQL statement -- at the bottom of my previous message -- corrects the problems I see, assuming that every product has a product description, every category has a category description, and the program doesn't need the product results repeated for each language in the system. From my reading of the code these assumptions are correct, but I thought I'd better check with people who know the system. You can just replace the first query from my earlier message with the second to correct the problems. Note that I presented the first query in a multi-line format for easier reading, but otherwise it is identical to the query in your edit_orders.php file. In case you were wondering, the original SQL query had a minor typographical error (x.categories_name=ptc.categories_name) which caused it to expect a nonexistent product_name field in the table specified by TABLE_PRODUCTS_TO_CATEGORIES. Changing "ptc" to "cd" in that one expression will cause the Add Product feature to start working. However, by leaving the language constraint out, the query retrieves a separate result for each langauge. E.g. products_id 1, categories_id 1, english categories_name products_id 1, categories_id 1, german categories_name products_id 1, categories_id 1, spanish categories_name Thus you get three times the number of rows you might expect from the query. (You only see one copy on the Order Edit display because the ensuing loop in edit_orders.php writes all of the product_name fields into the same array variable, so the last language wins.) Furthermore, the second join on TABLE_CATEGORIES_DESCRIPTION will duplicate each result for each duplicated category name. For example, I have a category with a name in English, but blank names in German and Spanish. The "extra" join matches on the blank names, which produces two more copies of the result, increasing the total to five times the number of products. Normally the category names would vary according to the language, but I still don't see how this extra join is helpful. Using an outer join (LEFT JOIN) causes a record containing only null fields to be provided where no record from the right hand side matches a given record from the left hand side. For instance, if a products_description record were missing, the result for (products_id, products_name) might be (1, NULL). Had an ordinary join been used, no row would have been returned because of the missing products_description record. I think the outer join is more expensive, and it suggests to the reader that an empty record might normally occur on the right side. The latter is technically true (I created a product outside all categories), but it doesn't seem to fit the way the system works. In summary, by adding the language constraint I reduced the number or records returned from five per product to one per product. Dropping the "extra" join on categories_description appears to eliminate superfluous work, but I might be missing something clever there. Replacing outer joins with ordinary joins should be more efficient, and probably reflects the semantics of the system better.
  11. Jim Lekas

    NEW! Complete Order Editing Tool!

    Thanks to the authors for the useful OrderEditor v. 1.3. I'm just evaluation osCommerce to see if I can make it work for my small web site, so I don't know too much about it yet. The Add Product SQL in edit_orders.php, v. 1.3, line 903 contains an error which prevents Add Product from working: //##################################### // Get List of All Products //##################################### $result = tep_db_query("SELECT products_name, p.products_id, ptc.categories_name, ptc.categories_id" . " FROM " . TABLE_PRODUCTS . " p " . " LEFT JOIN " . TABLE_PRODUCTS_DESCRIPTION . " pd ON pd.products_id=p.products_id" . " LEFT JOIN " . TABLE_PRODUCTS_TO_CATEGORIES . " ptc ON ptc.products_id=p.products_id" . " LEFT JOIN " . TABLE_CATEGORIES_DESCRIPTION . " cd ON cd.categories_id=ptc.categories_id" . " LEFT JOIN " . TABLE_CATEGORIES_DESCRIPTION . " x ON x.categories_name=ptc.categories_name" . " ORDER BY categories_id"); The immediate problem can be fixed by changing "ptc.categories_name" to "cd.categories_name". However, this query raises some questions. 1. Why is there a join between x.categories_name and ptc.categories_name (cd.categories_name) at all? 2. Why aren't pd and cd constrained as to language (language_id = $languages_id)? 3. Is it permitted to have a product with no name? If not, why use an outer join between pd.products_id and p.products_id? 4. Is it permitted to have a category with no name? If not, why use an outer join between cd.categories_id and ptc.categories_id? 5. Is it permitted to have a product not in any category? (It can be done, but the product can't be reached on the order page, etc.) If not, then why use an outer join between p.products_id and ptc.products_id? Does anyone know where to find more information about the intended semantics of the database schema? I have the tep_database-pr2.2-CVS.pdf schema, for which I am very grateful, but it doesn't say just how the category-product intersection table can be used. The following query produces similar results, with far fewer rows to be filtered by the ensuing loop. $result = tep_db_query("SELECT products_name, p.products_id, cd.categories_name, ptc.categories_id" . " FROM " . TABLE_PRODUCTS . " p, " . TABLE_PRODUCTS_DESCRIPTION . " pd, " . TABLE_PRODUCTS_TO_CATEGORIES . " ptc, " . TABLE_CATEGORIES_DESCRIPTION . " cd " . " WHERE pd.products_id = p.products_id " . " AND ptc.products_id = p.products_id " . " AND cd.categories_id = ptc.categories_id " . " AND cd.language_id = '" . (int)$languages_id . "'" . " AND pd.language_id = '" . (int)$languages_id . "'" . " ORDER BY ptc.categories_id, p.products_id");
×