This is G o o g l e's cache of http://www.ubercart.org/forum/development/950/discuss_product_class_node... as retrieved on Aug 2, 2007 12:26:37 GMT.
G o o g l e's cache is the snapshot that we took of the page as we crawled the web.
The page may have changed since that time. Click here for the current page without highlighting.
This cached page may reference images which are no longer available. Click here for the cached text only.
To link to or bookmark this page, use the following url: http://www.google.com/search?q=cache:hRwvt-64Gw4J:www.ubercart.org/forum...
Google is neither affiliated with the authors of this page nor responsible for its content.
These search terms have been highlighted: druru
Ubercart
* Home
* Documentation
* Forums
* Issues
* Livetest
Home » Forums » Ubercart » Development
Discuss: Product class = node type
Submitted by Lyle on Wed, 05/23/2007 - 14:49
Lyle
Posts: 567
Joined: 09/26/2006
AdministratoreLiTe!
I got a crazy idea, and I want to run it by everybody before I go hacking in the product module. I think this is where you're going, CpILL, but it's never explicitly said. (see http://www.ubercart.org/forum/support/934/field_atributes_vs_cck)
What if the product classes were node types?
Every time a product class is made, a new node type of the same name also became available. By making uc_product_node_info() dynamic, you can have a solution that makes nearly everyone happy. All products are nodes and are therefore handled by Drupal's node system. Yet they can be of different types, so Views, Taxonomy, and anything else can deal with the different node types in different ways. I'm happy because all the node types created from the product classes are still handled by one module and one set of functions.
The only difficulties I see are dealing with the cleanup when a node type or a product class is deleted. Because these node types are defined by uc_product_node_info(), I don't think they can be deleted on their own. I think when a product class is deleted, products of that class/node type should be converted into the generic product node type like they do currently. If you'd rather those products be deleted, I think you should do that first. It's easy with the Content Administration page, filtering by node type.
What do you think? Does this idea appeal to everyone? Or have I gone off the deep end?
* Add new comment
permalinkWed, 05/23/2007 - 16:45
druru
Posts: 221
Joined: 03/21/2007
Brain Stormer
i don't have a lot of time to spend on thinking about the ins and outs or pros and cons of this but i like the idea about making these nodes and moving products towards content types in some way.
a while back, i posted about the reuse of metadata with uc products and it seemed to get lost in the shuffle. something tells me that moving the classes to a node type could help open the door to solving that problem.
quick refresh based upon CPill's mp3 store.
0) i've got 2000 artists
1) i've got 10 albums by each artist.
2) Each artist has a bio, website, label, contact information fields associated with it.
3) Each time i create a new cd title (1 of the 10) for a given artist, i do NOT want to have to retype that same metadata over again. it only needs to be entered once and *referenced* as many times as required for all products by a given artist.
there needs to be a FK (foreign key) or node reference mechanism implemented into the products somehow. again, i think in terms of cds, books, movies, etc.. products that have one author/artist with associated metadata. for other types of products, this is not really an issue.
Not sure anybody every posted a real solution for that scenario so if you did i apologize for reposting and maybe you can post a solution here.
NOTE: using taxonomy is NOT a solution here. sure you can assign an artist to a term id. but again the artist needs to have metadata associated with it. i'm not aware that you can assign a bunch of other fields like url, bio, data, label, contact with a given term id. actually i'm probably sure it's possible but it might makes more sense to make this metadata node based and then create a FK field from a class or attach a cck node reference field to products of a given type versus use the termid as a lookup key in another table.
if a node reference cck field *can* be "attached" to a uc product of a given class/type, then that would probably solve the problem. not sure if this is possible though.
Anyway. just thought this might be the appropriate place to bring this up since you're introducing the notion of classes as node types.
thanks
* reply
permalinkThu, 05/24/2007 - 09:38
Lyle
Posts: 567
Joined: 09/26/2006
AdministratoreLiTe!
I think this situation is exactly what CCK is for. CCK comes with a node reference field that can be applied to any node type. I played around with it a little bit, and you can set which node types are allowable references for any particular field.
For the situation you've described, I would make an artist node type that contained all the information that you wanted. Then, the album nodes could have a node reference field that pointed only to album nodes. Since we're talking about 2000 artists, it makes sense to choose the auto-complete text field rather than the select list.
Because CCK deals with node types, I can see why people want different node types to all be considered products. You can add different kinds of CCK fields that make a particular site better with that extra information that Übercart doesn't provide for. This makes me realize that the product classes don't need to provide fields for data on their own. CCK can do that just fine on its own.
So what are product classes good for? They are the link between the new node types and the product module. Default sets of attributes can still be attached to products based on their class, which is a good thing.
* reply
permalinkThu, 05/24/2007 - 15:58
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
@Lyle
I think your on the right track.
Your thinking of going down (inheritance style, or as best you can in an non-OO API) rather than across, i.e. simple link via a node reference (or are you?). I think if new product types can be created with all the variety of meta data that CCK can offer and they are exposed to things like Views, then that sort of sounds like what I was talking about.
From what i gather, you are thinking of having the new node type create/edit functionality tied in with the Product create/edit process. I was thinking of it the other way around too keep the separation clean, but perhaps thats only because I'm not familiar with Drupal enough. The end result seems the same, but as you said you might have to do some messy stuff with the hook_node_info, will this mean you need to make the hook_insert, hook_update etc dynamic as well?
I think you have to keep it clear in your head what the Classes are used for Functionally, and to me that seems to be modeling the variety of ways products can affect the checkout parameters i.e. SKU, Price, Weight, stock levels etc. In the end thats all a product is: something that can talk to the checkout/order systems.
The other metadata is really just for display purposes and should be left out of it when it comes to the nitty gritty of managing an online shop, hence I was thinking linking to it but keeping the two sets of information seperate: commerce / information display-navigation
--
under Too Much Information
* reply
permalinkThu, 05/24/2007 - 16:28
Lyle
Posts: 567
Joined: 09/26/2006
AdministratoreLiTe!
I don't think that hook_node_info() will get too messy. It'll change from static to dynamic, but it should just be a simple query of all the classes in {uc_product_classes} and making a node type entry for each of those results. The real key to my plan is that each of those node types knows that it is handled by uc_product.module. This means that no matter which node type you want to create (that was made by product classes), the product hook implementations will be used. uc_product_form(), uc_product_insert(), and uc_product_update() would handle all those node types the same way because they are all products.
I agree that we shouldn't get confused about what classes are for, but I think we disagree on what that is. The way products affect their price, SKU, and weight should be attributes. Classes were designed to be a way to keep different pieces of data away from products they don't apply to. Every mp3 has a track length, but it doesn't make sense that every product has a track length. In the same way, the way the track length affects the price to download that mp3 is already factored in to the product's base price. The track length won't change for that product, so it's contribution to the price won't either. Now that this kind of thing will be handled by CCK, we get that kind of separation of metadata from the ecommerce data.
* reply
permalinkThu, 05/24/2007 - 17:18
BullCreek
Posts: 48
Joined: 01/10/2007
Brain StormerGetting busy with the Ubercode.
I've been away lately working on unrelated projects, but I think you may really be on to something here. I will think on this and post more when I have some time this weekend.
* reply
permalinkThu, 05/24/2007 - 17:59
druru
Posts: 221
Joined: 03/21/2007
Brain Stormer
allright!
i'm glad to see the appreciation for the node_type / products as content types finally making it's way into uc architecture. i was having a hard time convincing the team of that early on but it looks like you're starting to see the benefits.
i must admit, i'm not quite sure i completely understand your take on it but the move in that direction will offer up more ability to allow for really robust products to handle a variety of situations. uc's attributes on top of that makes for great product flexibility combined with ease of administration.
that said. lyle, i'm not sure your answer to my question about cck node ref really solves the complete problem (unless your move of classes to node types will).
here's why:
right now, i can add a cck node ref field to a uc product. so it solves the album -> artist problem. cool.
however, because currently you can only have ONE GLOBAL product type in uc called 'product', what happens if i sell tshirts, cars, books and other NON ALBUM products on my site? what happens is every single product is going to have that artist cck node ref field attached to it which doesn't make sense. If each product TYPE requires it's own set of cck fields, the global uc product gets littered with those fields and that's inefficient and hard to manage.
So for a shop that sells only one TYPE of product, we can use cck node ref out of the box right now!
However for MULTITYPE product shops, in it's current state, you can't really reuse 1+ different cck node ref fields. And multiTYPE product shops are more likely the norm in the real world.
You may be addressing my exact problem by moving the CLASSES to node types (separate content types).. that way you attach the cck node ref to the class and not the global product. i think that was what i had recommended 2 months or so back but i'm not sure that's what you're saying here.
By making the classes node types, (e.g. content types), you basically open it up for attachment of cck fields / noderef or otherwise. So you're possibly heading in the right direction we're just not connecting on the lingo.
[POST EDIT]
lyle, I just went back and read your initial post here and i think you are saying exactly what i am.
1) UC product stays the same (master product that keeps it's hooks in tact which allows uc to do what it does).
2) classes become content types (each as a separate node type). this means you can do anything you would with a normal content type including adding any cck fields / noderef etc
3) you still attach the class to the global product but now that class is essentially a node
4) classes as nodes plus attributes essentially gives you product content types plus flexibility
I guess the only question i have is architecturely. Normally content is "attached/appended" to a base node by extending it via hook_nodeapi. you're kind of relating 2 separate nodes (product with a class content type) under the hood. i'm not sure an existing mechanism (hook) exists for that so that may be custom code.
* reply
permalinkFri, 05/25/2007 - 05:19
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
@druru
The CCK node reference works because it doesn't reference a type it references a node, so it can point to anything, not just an Artist node or a T-Shirt node. Its limited only by the types of nodes you can have and in Drupal thats infinite.
@Lyle
You said "Classes were designed to be a way to keep different pieces of data away from products they don't apply to." Which is fair enough and what this is all about really. Both approaches handle this. Whats not clear is what you think the role of classes & attributes are and how they differ from this other information such as track length.
Examples (Use cases) are good for working an idea though so here are two examples from my experience:
1. Clothing shop:
- Size: S, M, L, XL, XXL, 3XL
- Colour: Red, Blue, White
Where
* Each combination of Size and colour gives a different SKU.
* Each Colour has two images front and back.
* All combos have different stock levels that need ot be tracked.
2. Online music shop
- Format: Vinyl, CD, MP3
Where
* Each format has a different Price, Weight (shipping cost), SKU.
* The MP3 format has no shipping (maybe weight of zero?) and has a change in access permissions for that user (i.e. the file becomes available to their account)
* Vinyl and CD have stock level tracking.
This is the sort of info that Classes need to handle as these properties affect the commerce side of the data modeling (although the different picture for different colour is a nasty one)
I guess the way you are thinking of doing it allows for sub projects that can refine each of the product types/classes and provide specialised functionality and interaction between display/organisation and checkout process.
It really hard to say unless you do it really...
--
under Too Much Information
* reply
permalinkFri, 05/25/2007 - 07:32
Ryan
Posts: 1671
Joined: 09/26/2006
AdministratorCode Monkey Head - I eat bugs.
CpILL, I think the things you listed are actually product attributes. Product attributes are piled up on a product so the customer can select a certain configuration. So, if you want a single product node that can be any size/color of t-shirt, you use a product attribute. These are variable. By themselves, these have nothing to do with classes.
Product classes also had class attributes. These are not variable. Per product these are unique, although per product class there may be a selection of options to choose from.
Example. We sell refrigerators. We can sell as a single product one refrigerator that is 49 cu. ft. It is a product of class refrigerator, a class we have already given the class attribute of "size" to. Each product is only going to have one choice. However, the customer may choose whether they want the standard aluminum interior or a full stainless steel interior. This is a product attribute. The customer chooses that prior to adding it to their cart. Product classes don't govern product attributes, but there is a thin connection that Lyle put in that lets you define default attributes for a product of a certain class.
Do you see the separation here? It's all about what the user can change and what they can't before adding it to their cart. Class attributes are really just there to help the customer find the product they want. So, if I'm storing the cu. ft. of every refrigerator we sell, I can let the customer refine a product listing by cu. ft. and end up with a list of products that meet their need. (Think NewEgg... all the data they keep on their products that lets you use their wicked cool catalog browsing would be considered class attributes, standard pieces of data collected for a certain class of products. The options you pick on the product page before adding an item to your cart are individual product attributes.)
* reply
permalinkFri, 05/25/2007 - 10:55
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
So
Product Attributes:
- Options available to customers
- Apply to ALL products of any class
Class Attributes:
- Not available to customers
- Apply to products of that class only
Product Fields:
- ?
By the way, are attributes working at the moment? I added a few to test em out and nothing seems to have happened?
--
under Too Much Information
* reply
permalinkFri, 05/25/2007 - 12:09
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
Oh, they seem to be working. Was looking in the wrong place
--
under Too Much Information
* reply
permalinkFri, 05/25/2007 - 12:11
Lyle
Posts: 567
Joined: 09/26/2006
AdministratoreLiTe!
That's the thing. They only apply to the products you specify. In the edit product screen you can see the attributes and options tabs that let you select the attributes that that product can have. Once it has attributes, you can select which of those attributes' options are available, and what the price and weight changes for choosing those options are.
Attributes can be added to a class so that products of that class will have those attributes attached to it automatically. After that, they're just like any other attributes for that product.
I prefer to say that classes have data fields rather than attributes. These fields are available only to products of that class, and they are set for each product when it is created.
* reply
permalinkFri, 05/25/2007 - 16:01
Andy
Posts: 255
Joined: 09/27/2006
Administrator
CpILL,
Ryan used the term "Class Attributes" when he meant "Product Fields" as you said, or even better "Class Fields."
I will try to summarize:
Ubercart attributes are product options which a customer must choose. For instance a customer has to choose the size of a t-shirt. An attribute may affect many things about the product including price, weight, image, and SKU.
Ubercart Class fields are "meta data" about a product. Class fields are pieces of information about a product which do not change (are not options) and do not change anything about the product like weight, price, SKU etc. . . For example, a specific monitor on Newegg is a 17" monitor. The customer can not choose to get that monitor in a 20" size, but the customer can use this information to limit the number of monitors he has to choose from.
Let's say I want to buy a computer monitor and I know that I want a 19" monitor with speakers and I do not want wide screen. Newegg is using Ubercart Smiling and they have made a class of products called monitors. They made class fields for the monitor class including size, speakers, and wide screen. As a customer I can not use these class fields to buy a 17" monitor in a 19" size, but I can select "19"", "includes speakers", and "wide screen" to limit my search down to 6 monitors from the 357 that they sell.
The reason that these "class fields" are specific to a class, is that a site may sell more then just one class. For instance NewEgg also sells hard drives. It doesn't make sense for hard drives to have class fields like "includes speakers" and "wide screen". Hard drives should be a different class with different fields including "RPM", "seek time", and "Size-Gigabytes".
In the above example the color of the monitor is an attribute. The customer can choose to get black or white. The size, speakers, and wide screen information are product class fields. They are static pieces of information about the product which the customer can use to choose which product from the class they want, but the customer can not modify these class fields.
I hope this clears it up some.
Peace,
Andy
* reply
permalinkFri, 05/25/2007 - 16:15
druru
Posts: 221
Joined: 03/21/2007
Brain Stormer
lyle:
any thoughts on my last post? are we in agreement? is this where you're headed with this or somewhere else?
cpill:
The CCK node reference works because it doesn't reference a type it references a node, so it can point to anything, not just an Artist node or a T-Shirt node. Its limited only by the types of nodes you can have and in Drupal thats infinite.
of course it references nodes directly. that's what it's supposed to do Smiling.
however you DO have the option when you set the noderef field to limit the nodes to a particular type. That's what makes the noderef so powerful. it's also what enforces referential integrity on top of a rapid app type form builder interface (e.g the ability to even add a cck noderef in the first place).
Think of it like this, if you have an album content type you really only want it to reference the artist node types not the author or the 10 other node types you may have defined. that limits your choices to only artist nodes which IS a very good thing.
And if you don't limit the cck field by node type, and you have 5000 nodes spread out across your 10 different nodetypes, it's going to be pretty umananageble to try and select the node to be referenced. whether it's a select box (impossible) or active select (how would you remember the node?).
My lines of thinking are more about how this would be architected / implemented. When you create an album product.. under the scenario i think lyle is talking about.. you:
1) get the base generic product
2) to that is attached the album class (which is now a node/content type) which provides you the form (fields) for entering album-specific product data
3) that album content type ITSELF is what contains the cck noderef to the artist not the original product.
4) the original base product node instance must have a way to associate it's unique nid with one of the album content type nid's that is created in relation to it so that it can pull up the combined data for post initial creation edits and node page views. that's probably going to be done by a lookup table under the hood based on the original nid (similar to the way taxomony terms are associated with nodes).. could this be done via cck noderef? probably but it doesn't make much sense because the user never sees this part of it (it happens automagically under the hood) and it probably can be coded simpler and faster in non-cck fashion.
* reply
permalinkSun, 05/27/2007 - 09:57
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
@ Andy
Thanks for that, that clears things up a lot. I relise now that I DID understand how it worked before all this jargon criss corss got me confused.
So, I think that Lyle SHOULD make the classes content types for the following reasons:
1. 'Class fields' seem to basiclly be doubling up on the functionality of the CCK but they don't provide an interface to things like Views as they are not exposed outside the Product system and don't provide as much varitey as CCK i.e. no node referneces, user refernecs etc. Since they are not types specific taxonomys also can't refernce them.
2. They don't really participate in the ecommerce side of things, as Andy alluded to, in that they help you find what your looking for: organisation and navigation of information. This stuff is already handled by Drupal and is one of its strong points.
@druru
You said:
"However for MULTITYPE product shops, in it's current state, you can't really reuse 1+ different cck node ref fields. And multiTYPE product shops are more likely the norm in the real world."
In which you answered your own question:
"of course it [nodes] references nodes directly. that's what it's supposed to do"
...and since nodes can be of any TYPE you want with the CCK it follows that with node refernece can do "MULTITYPE product shops", ja?
--
under Too Much Information
* reply
permalinkSun, 05/27/2007 - 16:36
druru
Posts: 221
Joined: 03/21/2007
Brain Stormer
cp, i've tried to explain the best i could.
my suggestion to you would be to actually try and create multitype products *right now* in uc's *current* state so that *each* different product has it's *own* unique cck noderef fields. it ain't gonna happen or it's going to be very clumsy or less efficient then it otherwise would be.
if you look at where lyle's going (and the way i'm describing i think it's going) in the *future*, then cck (and node refs) will work and be useable as intended. that will allow you to do a lot of great stuff. cck does not offer all of that *right now* primarily because it's crippled by the fact it can only be allowed on the base product not the class. if you understand that, you'll get what i'm talking about. actually walk through it.
also, you made the perfect case for WHY classes should be nodes in points 1 and 2 above short and succinctly. It sums my sentiments up exactly. Total agreement with you. Smiling.
fwiw, the uc team is probably wanting to tread on this whole idea very slowly / carefully because it means changing their architecture and possibly disrupting the community / growth of the project for a short spell. if they go down this path, they want to get it right the first time. i respect lyle's boldness to step up to the plate and put this issue out there for feedback instead of ignoring it.
imho, i think this feature is the right thing to do and the way lyle has suggested implementing it seems to make sense while disturbing what already exists with the least amount of pain. my thoughts are that if they don't bite the bullet and go down this path now, they're going to regret it later on. And later on when people start calling for this feature as more people start using the sw and realize the absence of robust and reusable metadata via classes, it's going to be much harder for the developers and painful for the community to take it on.
i for one would totally accept a delay in the next or some near future release if it meant getting this functionality implemented. you nail this down now and you have the foundation for the best OS cart on the planet Smiling.
* reply
permalinkTue, 05/29/2007 - 09:08
Lyle
Posts: 567
Joined: 09/26/2006
AdministratoreLiTe!
druru, based on your 4 points in that post, I think I half way agree with you. Points 3 and 4 sound like you think the classes are actual nodes themselves. Like you could go to node/35, and find a class node. That's not what I had in mind. What I was thinking is that you would create a product class like you normally would, and then you could go to node/add and find a link to create a node of a type that's named the same as that class. Since the node type is set when it is created, and so many other things rely on it, I don't think it's a good idea any more to be able to just change a product's class whenever you want. What's probably more useful anyway is adding fields to a class, affecting all of those nodes at once.
To answer your architecture question, you're right. Specifically, I think content_nodeapi() from CCK should do what we need very nicely.
* reply
permalinkTue, 05/29/2007 - 15:51
druru
Posts: 221
Joined: 03/21/2007
Brain Stormer
ok, i *think* i'm starting to follow you here.
i guess i still don't really see the difference between an uc class and a content type. from where i sit they are essentially one and the same thing functionally. it almost seems like you're creating an extra layer of abstraction FROM a class TO a content type you don't need. This might be because your existing uc class is your hook to the base product you don't want to change it and it's easier (but maybe less efficient) to just extend the new functionality out of the class verus replace it from teh ground up by a content type.
Either way, i think the goal is the same.
In many ways it doesn't really matter how you want to implement it. What matters is if it provides the functionality to solve the following problem (sorry to beat this horse to death but a simple yes/no answer nips it in the bud).
0) i've got 2000 artists
1) i've got 10 albums by each artist.
2) Each artist has a bio, website, label, contact information fields associated with it.
3) Each time i create a new cd title (1 of the 10) for a given artist, i do NOT want to have to retype that same metadata over again. a given artist's information only needs to be entered once and *referenced* as many times as required for all products by a given artist.
Does your implementation solve the problem?
And if/when you have the time, post back a very quick walk through example of what steps you envision an end user would take to make that happen using uc forms / interface versus trying to explain it architecturally.
thanks lyle.
* reply
permalinkTue, 05/29/2007 - 16:25
Lyle
Posts: 567
Joined: 09/26/2006
AdministratoreLiTe!
The plan is that there isn't really any difference between product classes and content types, functionally. The main differences is that those content types are in the domain of the product module. This means that all the node hooks that get invoked come from the product module for all of those content types, and not just the 'product' type.
Really, I'm doing away with the product class as a separate thing. Fields can be handled by CCK, default attributes can be keyed to a node type just as easily as a product class, and that's all they were used for currently. There had been some ideas about having tax rules apply only to certain classes, so that might now become an easier thing to code.
For your problem, the CCK node_reference allows you to associate an artist node with an album. I don't know what tools and modules are available to allow you to display the node data in the node that references. I'm not that experienced with CCK, so there's likely something that solves that particular problem.
Quick walkthrough for what I know how to do:
* Go create an artist node type with CCK. Add fields like bio, website, label, and contact info.
* Go to admin/store/products/classes and make an album type. This is basically just getting a machine-readable name and a display name.
* Go to admin/content/types and edit the new album type. Add a node reference that allows you to select artist nodes. Add any other fields that people want to know about albums.
* Make artists and albums. Categorize them in the catalog, etc.
* Theme with contemplate, perhaps?
* Profit.
* reply
permalinkTue, 05/29/2007 - 16:35
druru
Posts: 221
Joined: 03/21/2007
Brain Stormer
That's exactly how i envisioned it would work! Smiling.
We're in agreement. This feature plus your current attributes is the one that makes uc "the" OS cart killer Smiling
Is this a done deal or are you still mulling it over / waiting for more feedback (i'm curious other's aren't jumping in to show their delight over this feature or offer feedback?)?
If the green light is set, any idea what release this is targeted for A7, A8...?
* reply
permalinkTue, 05/29/2007 - 16:39
Lyle
Posts: 567
Joined: 09/26/2006
AdministratoreLiTe!
I haven't any negatives, so it's a go. When it's going to happen...ehh. It's next after order fulfillment, but that's taking a lot more time than it should. Maybe by A8. I don't think it'll take that long to do, just a matter of getting to it.
* reply
permalinkTue, 05/29/2007 - 18:08
druru
Posts: 221
Joined: 03/21/2007
Brain Stormer
Great job lyle!
any *rough* target dates for A7 / A8?
* reply
permalinkTue, 05/29/2007 - 19:24
BullCreek
Posts: 48
Joined: 01/10/2007
Brain StormerGetting busy with the Ubercode.
I think this will add a lot to ubercart over the long haul - and am glad to hear you're going to do it! It will definitely make using CCK, taxonomy, and probably some other things we haven't even thought of a lot easier. Looking forward to helping test when the time comes.
* reply
permalinkWed, 05/30/2007 - 03:26
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
@druru
I think you can implement most of what Lyle was talking about already, so long as you have one product type:
* Go create an artist node type with CCK. Add fields like bio, website, label, and contact info.
-> You can do this already
* Go to admin/store/products/classes and make an album type. This is basically just getting a machine-readable name and a display name.
-> Can do with classes
* Go to admin/content/types and edit the new album type. Add a node reference that allows you to select artist nodes. Add any other fields that people want to know about albums.
-> You can add a node reference with CCK at the moment to Product, the only problem is that this is for all products, but since its a generic reference you can ether not use it for other product types or point to some other node as need be.
* Make artists and albums. Categorize them in the catalog, etc.
-> Easy taxonomy stuff
* Theme with contemplate, perhaps?
-> With the themes you can hide the underlying data structure and make the Album look like a product as you can pull in all the product info with the node reference. Its a bit 'smoke & mirrors' as what you see is not the data structure but if all the links work etc who cares.
* Profit.
-> That balls in your court Eye-wink
--
under Too Much Information
* reply
permalinkWed, 05/30/2007 - 16:53
druru
Posts: 221
Joined: 03/21/2007
Brain Stormer
cp,
not sure if we're on the same page or i'm not being clear. i know how to do everything you already posted. and i know i can do it on the one base product right now if i want to. the whole point is that it's not ideal. most stores aren't only going to sell one product type. everything i've posted was how to move the content typing towards some kind of relationship with the class for reusability and the use of multi cck node refs for different classes/types. currently, there's no code that bridges content typing with the class. you can't see anything related to the class under admin/content/types right now following your instructions as posted. that's what lyle is getting ready to architect. when that's done, this will be really useful for many stores. i'm satisfied with where lyle is heading with this and my current options/limitations as they stand.
thanks for the post dude.
* reply
permalinkMon, 06/04/2007 - 15:57
Lyle
Posts: 567
Joined: 09/26/2006
AdministratoreLiTe!
It is accomplished. Get the latest revision and run the update script to check it out.
* reply
permalinkMon, 06/04/2007 - 16:35
druru
Posts: 221
Joined: 03/21/2007
Brain Stormer
lyle you rock..
i'll be looking at it during the week and provide feedback here.
now i just need to figure out how to import 500 items and put them in all of the right places... any thoughts / examples on this with a hypothetical class plus related content type fields.
also.. i'm assuming you mean version 5.x-1.0-alpha6b (or are you meaning the bazaar code)?
fwi, that 6b version is post dated as may 10 when today is already JUNE 4?
thanks again
PS (may be a double post - wasn't logged in when i tried to post originally)
* reply
permalinkMon, 06/04/2007 - 22:33
Ryan
Posts: 1671
Joined: 09/26/2006
AdministratorCode Monkey Head - I eat bugs.
It's only in the Bazaar code for now... but that's the commit I was waiting on to get another intermediate release out. Assuming all the kinks are worked out, I'll probably try to get an Alpha 6c up soon so folks can also test drive the new settings menus. Smiling
* reply
permalinkMon, 06/04/2007 - 23:25
druru
Posts: 221
Joined: 03/21/2007
Brain Stormer
i bit the bullet and finally downloaded / installed bazaar and then checkout'd uc locally.
for others, it's really easy to do this... follow ryan's suggestions here:
http://www.ubercart.org/forum/development/948/access_development_reposit...
* reply
permalinkTue, 06/05/2007 - 04:30
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
WOW!
Thats great news. I'll have a look immediately!
--
under Too Much Information
* reply
permalinkTue, 06/05/2007 - 07:30
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
@Lyle
when you say its done, what exactly are the changes you've implemented. I notice that you can no longer add attributes to classes, does this mean that classes will eventually be completely removed (and their tables: product_class, class_attribute, class_attribute_options)?
How do I create new product types then?
--
under Too Much Information
* reply
permalinkTue, 06/05/2007 - 09:27
Lyle
Posts: 567
Joined: 09/26/2006
AdministratoreLiTe!
Heh, it wasn't my intention to remove attributes from classes. I need to rework the menu structure of the class administration to allow you to get to the class attributes. Until then, type in 'admin/store/products/classes/[class_name]/attributes' to get to them. I'll probably add a link next to 'edit' and 'delete'.
* reply
permalinkTue, 06/05/2007 - 09:45
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
So, what was the change you made then? The Classes are content types? They don't show up in the 'create content' menu or was it something else?
--
under Too Much Information
* reply
permalinkTue, 06/05/2007 - 10:24
Lyle
Posts: 567
Joined: 09/26/2006
AdministratoreLiTe!
What's supposed to happen when you make a new class, or edit an old one, is that a new node type is created. The image field is added to it, and the catalog vocabulary is updated to allow it to be listed. You should be able to see it in the list of content types when you add a node.
If that's not happening, try clearing the cache. I know there was some stuff that didn't seem to "take" at first when I was testing it. Don't know if that was a fluke or a regular occurrence or what.
Have you gotten any error messages since you got the new code?
* reply
permalinkTue, 06/05/2007 - 14:18
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
OH no, your right!
Maybe it was some sort of cache thing. The new type seems to have eventually appeared. I just tried again with a new type and it doesn't show up, I guess Druapl is caching the menu build. Perhaps you can have a look at the CCK module and see how it manages to force Drupal to clear the menu cache.
--
under Too Much Information
* reply
permalinkTue, 06/05/2007 - 18:09
jensen
Posts: 15
Joined: 05/17/2007
I think it is the exact way to pursue the author function to the node.
As I went throught a article regarding site building using Drupal from Drupal.org, which is great tutial from the web designer of Observator.com, I saw they use nodereference and author node to link each other. There were not much details and it already gave sort of clues to us.
--
The life is so boring ...
check 一æ‹åŸŽå¸‚生活 to get excited. Smiling
* reply
permalinkWed, 06/06/2007 - 04:32
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
yes,
I've managed to extent a product content type with the CCK so the skys the limit on what can be done with products now!
I also found the addnode module (http://drupal.org/project/addnode) which is still in testing, but lest you create the reference node at the same time as you create the referring node, which should remove some of the clunkiness in the interface
Nice work Lyle. You have acquired the rank of eLiTe!
--
under Too Much Information
* reply
permalinkWed, 06/06/2007 - 16:41
druru
Posts: 221
Joined: 03/21/2007
Brain Stormer
didn't know addnode existed.. looks promising.. i'll check it out..
thanks for sharing that.
* reply
permalinkFri, 06/15/2007 - 06:52
kulvik
Posts: 77
Joined: 12/20/2006
Brain StormerBug Finder
Wow.. this thread was rather huge. I've tried to read through most of it, but I still have a question. Could someone just fill me in / summarize why this change is for the better (apart from theming control)?
This is how we did things on one of our previous stores (which sell socks):
The reason we needed product classes was because of some "environmental approval marking". Socks can either have it, or don't have it. So we created a product class with a checkbox so that admins could easily choose this when editing products. This worked perfectly.
After downloading the latest dev-release from bazaar, all this is now gone Sticking out tongue How are we suppose to use the classes now? Adding CCK fields to the new "sockproduct" node type? That could probably work, but this has certainly not been for the better when it comes to accessibility. Store admins now have to deal with both the ubercart admin interface and the standard cck admin interface to create a new product type. Or am I wrong? This change is probably good for us developers, but what about the the guys that actually manage the shops?
Also, depending on how the store is built, there could potentially be a very large number of node types to cope with. Let's say we create a computer shop. To theme and give the user some flexibility, all specs and so forth need to have their own field in the class (node type). This could get really complicated over time. What do you guys think?
--
Thomas Kulvik
Ny Media AS
www.nymedia.no
thomas (at) nymedia.no
* reply
permalinkFri, 06/15/2007 - 08:14
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
I wouldn't say that the complexity would be any better using classes? In fact the idea here is that you can group types of content as their own content type an then link to them via a node reference, or have many links to common parts. This gives two ways to deal with lots of 'types' of products as opposed to the one with classes, which this approach also encapsulates.
So to take your example, you can ether create a filed in the CCK for your "environmental approval marking" schpeal and type it in directly or create another node type for all this type of marketing and then all products can link to that marketing schpeal node with an auto-complete or a select list of existing types. Then you can update it and hence update all instances that refer to it at once.
Given that they are node types now you can write a module that adds this 'checkbox' to the specific node type or you can just use the Product attributes (which still exist) and make the checkbox and then look for this is in the theme, but conceptually you have to decide weather this is for display only or if it has meaning to the 'product'.
You can still do what you could before. This just mean that what were closed and hidden attributes of the Product can now be worked on the same way anything in the CCK. It also means that groups of products can have separate taxonomys, views and templates. Basicllly opens them up to all the things that Drupal can do with all its content types.
--
under Too Much Information
* reply
permalinkFri, 06/15/2007 - 08:37
Lyle
Posts: 567
Joined: 09/26/2006
AdministratoreLiTe!
In addition to theme control, having the product classes be node types allows the Drupal core to preform operations on just a subset of your catalog. At 'admin/content/node', you can perform bulk node operations on a particular node type, or some other combination of filters. Various other contributed modules can act on a particular node type if you don't want them to do the same thing to every product.
You don't have to put every bit of information about a product in it's own field, though. You could just put it all in the description. That's what we've had to do with osCommerce. Of course, it's a royal pain to try to make sure they all look the same and prevent copy/paste errors when listing new products.
CCK is definitely more complex than the class fields were, but it is also that much more powerful. I don't have any experience with setting up a website for someone else, but if I did, I would make a special effort to get them to learn how to use CCK. I think it's that important and useful just as a general purpose tool for a Drupal site administrator. The benefits outweigh the loss of simplicity.
* reply
permalinkFri, 06/15/2007 - 12:25
kulvik
Posts: 77
Joined: 12/20/2006
Brain StormerBug Finder
Thanks for the info. I see the benefits of having the classes as node types now.
Putting all product data in the description will work for some shops, but not all. A lot of stores have a very valuable function that let the users compare products. Most of the big stores for electronic equipment and computers have this (at least norwegian ones), where you can select 1-4 products and hit "compare". You then get a table view of the products with each "attribute" in its own row. The "best" values are automatically highlighted. You cannot do these kind of things of you have the data as a simple string in the description field.
There is no doubt that this class/node type idea is very powerful. I just have to figure out how to make this as easy and intuitive for the users as possible (the store admins). Some customization and a good user manual would be a good start Smiling
--
Thomas Kulvik
Ny Media AS
www.nymedia.no
thomas (at) nymedia.no
* reply
permalinkFri, 06/15/2007 - 12:46
Ryan
Posts: 1671
Joined: 09/26/2006
AdministratorCode Monkey Head - I eat bugs.
+1 on the user manual. We need something with screenshots... anyone willing to do a screencast would be rewarded with smiles and a free beer in Louisville, KY. Eye-wink
* reply
permalinkFri, 06/15/2007 - 15:44
Andy
Posts: 255
Joined: 09/27/2006
Administrator
+1 For a comparison module which would do what Kulvik describes above (let the customer select a few items, and display their information in a table/div with automatic highlighting).
Anyone who writes this will get a smile, hug, and free beer in Louisville, KY from Ryan Smiling
Andy
* reply
permalinkMon, 06/18/2007 - 05:55
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
VIEWS DUDE!
You might have to write a new type of view that turns the table sideways but really, its screaming to be a View for Product Node types
--
under Too Much Information
* reply
permalinkMon, 06/18/2007 - 07:14
Øyvind
Posts: 3
Joined: 06/15/2007
Cool Profile Picture Award
My first post here. Smiling
Not sure whether this has been brought up before or not, but I'm unable to delete the content type left behind after I delete a product class. The option to delete the content type isn't there. I can only edit it. Smiling
Isn't there a way to include both the old product classes where you define fields for each class and the new product classes which creates new content types? Sticking out tongue That would allow me to choose the old version for scenarios where the class only needs to add an additional text field or similiar and the new version for scenarios where the class is a totally different product type.
--
Øyvind Strømsvik
Ny Media AS
www.nymedia.no
* reply
permalinkMon, 06/18/2007 - 09:42
BullCreek
Posts: 48
Joined: 01/10/2007
Brain StormerGetting busy with the Ubercode.
>VIEWS DUDE!
>
>You might have to write a new type of view that turns the table sideways but really, its >screaming to be a View for Product Node types
I'm re-integrating the uc_views to work with these changes this week, and will look into product comparisons. I'm not aware of a views add-on that supports this, but it might not be too hard to pull off. It would certainly be handy. Hopefully someone else has already done some work on it.
* reply
permalinkTue, 07/17/2007 - 13:35
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
Heh, it wasn't my intention to remove attributes from classes. I need to rework the menu structure of the class administration to allow you to get to the class attributes. Until then, type in 'admin/store/products/classes/[class_name]/attributes' to get to them. I'll probably add a link next to 'edit' and 'delete'
Just following up on this. Is this still do be done or is it going the way of the dodo? I tested it and it seems that adding attributes to a class does not automatically add them to new nodes of that class, but this is what we expect or not?
--
under Too Much Information
* reply
permalinkTue, 07/17/2007 - 14:58
Lyle
Posts: 567
Joined: 09/26/2006
AdministratoreLiTe!
I had forgotten about that until just now. I've added the attributes forms as local tasks to the edit class form, like the edit product form is now.
I also squashed the bug that you mentioned. It had been left behind when product classes became node types and class ids became strings instead of integers. It was still working for products because node ids are still integers and were being stored that way. All is better now.
* reply
permalinkWed, 07/18/2007 - 05:12
CpILL
Posts: 168
Joined: 02/08/2007
Getting busy with the Ubercode.
YAY!
(is it checked in?)
--
under Too Much Information
* reply
permalinkWed, 07/18/2007 - 08:21
Lyle
Posts: 567
Joined: 09/26/2006
AdministratoreLiTe!
Now it is Eye-wink
* reply
Joined: 08/07/2007