A lot needs to be rewritten to seperate data from presentation.

Posts: 3
Joined: 08/22/2007

Ubercart is really good, but it does have a pretty major flaw that I would like to help address.

My problem is trying to change the way data it is presented. A lot of HTML is hard-coded without any theme hooks, and a lot of that uses outdated attributes like width, style, cellpadding, cellspacing, etc.

First, TAPIr is interesting, but limited. For instance, here is the HTML output for /products:

<table>
  <thead>
    <tr>
      <th> ... </th>
    ...
    </tr>
  </thead>

  <tbody>
    <tr class="odd">
      <td> ... </td>
      ...
    </tr>
    <tr class="even">
    ...

As you can see there are no class attributes on any of the tags to distinguish this table from any other. Unfortunately, as far as I can tell, TAPIr does implement a few hooks to let you add columns to the table, but it does not let you add or change attributes at the table, head, row, cell, or footer level.

Second, a lot of HTML is hard-coded into non-theme functions, especially in the checkout where the tables don't even use TAPIr, for example here are lines 302-303 in uc_cart.module:

$output .= '<table style="border-bottom-width: 2px;" cellpadding="2">'
              .'<tbody style="border-top: 0px;">';

This is not an acceptable way to style anything in 2007. At the very least, these elements should be assigned classes, and all of the style information should be moved to a stylesheet. It would be even better, if this type of code was taken out of the existing function and moved to a theme function.

If you need an example, take a look at how menus are handled by the theming system. First, the entire data structure is passed to theme_menu_tree(), then each item is passed to theme_menu_item() and then each link is sent to theme_menu_item_link().

This may seem convoluted, but it is very powerful. At each point, you can override the default theme so that you can change from lists to divs, or tables, or spans, or XML, or whatever. More importantly, you can add, change or remove information in the data at each step. Ubercart needs this level of functionality, and I would be glad to give as much help as I can.

Posts: 5378
Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

I definitely agree... there is much work to be done here. I can't find the lines you're referring to in your example, but it may be because I have recently been doing a lot of work like this. I'd encourage you to check out the latest version from Bazaar and see what may be different nowadays.

I'm definitely up for advice, patches, slaps on the head, or even just forum posts pointing out changes. A lot of stuff was put in as a place holder and forgotten about, so the clunky initial code (like in your example) remains. Also, I'm all for improving TAPIr. It was an early module of mine on the project, and I have a much fuller understanding of Drupal and its APIs nowadays... so TAPIr makes me cringe a little. Smiling I feel like it was the first step in the right direction, but it's got several steps to go.

Posts: 176
Joined: 08/08/2007
Early adopter... addicted to alphas.Getting busy with the Ubercode.

I think its a good idea to kick around system design ideas in the forums. TAPIr is a good idea but it needs some more work. Two things I found that needed improving where:

1. hook_alter_table() doesn't pass in the whole table structure like hook_alter_form() which is what you might need some times especially if you want to allow other modules to extend it or something that uses it.

2. It would be nice if it used the same rendering engine that the Forms API does so the two could be used together to create tabulated forms which I think Drupal is screaming out for. But this might be a general Drupal problem. I don't know if they are doing something about it in 6 but I'm guessing not.

As a general note on CSS, I think a naming convention would be a good idea...?

--

suffering from too much information

Posts: 16
Joined: 10/30/2007

There has been some work done on tabulated forms for CCK.
Personally I think tying in with cck and views wherever possible would be a huge plus.
Maybe create a cck_uber_product node type that fulfills the product api.

The setup might be more complex, but then almost everything would be customizable via CCK or Views.

Posts: 176
Joined: 08/08/2007
Early adopter... addicted to alphas.Getting busy with the Ubercode.

The product classes become their own node types. The you can CCK each type up to your liking. So the product already integrates with CCK, more or less.

--

suffering from too much information