Ubercart

Ah! I see what's happening.

In this case, you can just use

to print just the body of your product. (The "description"). You can access all parts of the $node object this way. It's an object of arrays.

Here are others you can access. (Using the "Contemplate" module isn't necessary, but it'll help you discover all the different values of your $node object, including values of CCK fields, or custom node types such as Product.) Note, that if you just put

to print the entire Node object. Of course you'll need to learn how to access the Values in the node... they all follow pretty much the same format as the first one I've listed here.

In this way you can create a custom product node template which will only show the fields you specify.

Hope this clears things up

Theming can be done at many levels - it's not one-size-fits-all. I'm not suggesting putting HTML into uc_currency_format(), because like goodeit says it's used in many different contexts. The markup properly belongs in functions like theme_uc_product_display_price() which are specific to a given use of the price.

However, theme_uc_product_display_price() and all the other functions like it still have a need to figure out certain things about how to display a currency number, such as what currency symbol to use, what character should separate the units from the decimals, etc. It makes sense to have these functions all use the same algorithm to figure this out, and to allow a developer to override or supplement that algorithm. *This* is where uc_currency_format() written as a theme function comes in.

I'm proposing theme_uc_product_display_price() (for example) should use uc_currency_format() as it does now, except that uc_currency_format() should be renamed to theme_uc_currency_format() and invoked by $string_price = theme('uc_currency_format', $num_price) rather than $string_price = uc_currency_format($num_price). Wrapping the resulting currency string in div's and other markup would still be the job of the theme function that called theme_uc_currency_format(). The big effect this will have is to allow other code to hook into the process and determine how the currency number is displayed before the markup is applied. I admit I have an ulterior motive - this is how I implemented my multicurrency module (which I really must post to drupal.org soon!).

As far as dealing with parameters - I don't think uc_currency_format() should be accepting parameters specifying explicitly which thousands separator to use, for example. uc_currency_format() currently is trying to do too much. The invoking program shouldn't have to worry about all these details. Likewise, letting the invoking program change the defaults through the parameters breaks the encapsulation of functionality provided by uc_currency_format() - there is then no one place to modify the currency format because it can be "ignored" by anyone's code.

I think a better way to go about it is to provide a parameter to specify the *context* in which the currency will be used. A context could be a string like "localized" to return the currency formatted for the user's locale (this is the default), or "store" to format in the store's default, or "unformatted" to return just a number, etc. An advantage to doing it this way is that, again, theme_uc_currency_format() could be overridden to add additional contexts to meet anyone's needs. So there is no loss of flexibility here by leaving out the parameters. Just the opposite - it allows you to do MORE without breaking other modules or other uses of these functions.

As a use case, let's consider the subject of this thread: How can we display a message to anonymous users, such as "Please log in to see prices", instead of the actual price? Right now, you can either 1) modify a core Ubercart function (uc_currency_format()) as in comment #9 above, or 2) attempt to override all the theme functions, if available, for every module that uses prices. But as shown in comment #12 above, not every module that displays a price provides a theme function, so this second method isn't always possible or practical.

If uc_currency_format() were a theme function, however, it would be a simple matter to add this without modifying core by overriding the theme function (in pseudo-code):