Hi TEAM,
I have to think more and more and I think this is absolutely wrong idea guys
to force us specify VALUES of LIST in the product itself !!!!
Wrong! Wrong! Wrong!
Let me explain.
1) I must be able construct Custom Field as OOP Entity absolutely independent from product !
2) I must be able construct Custom Field absolutely completly in ONE PLACE -- Custom Field panel.
This means that I must be able
a) define VALUE or LIST of Values
b) define if I want DropDown Menu for list of values
or I want radio buttons for values.
or combo box with multi-selection.
Now ask me as I see it?
Solution is quite simple I think. You need just EXTEND your custom field types. You have now SIMPLE types as string, date, Cart Variant, ... and you have aggregator type PARENT.
But can be added more complex aggregators: ListAsDropDownMenu, ListAsRadioButtons, ListAsComboBox.
Then I could simply do:
** - NEW ListAsDropDownMenu
- Specify values "mac, win, linux"
May be define other params for menu as Title on left or on top
and this is DONE !!!
now I can define 150 products using this SINGLE custom fields.
and if tomorrow I will want change list of values, I have only SINGLE PLACE to correct **OBJECT** ListAsDropDownMenu.
You see?
================
I hope you see SCREAM of a lots of people here which CRY because they do not see SIMPLE WAY modify custom fields used in N products ...
And I think solution which I suggest perfectly fit into your new model of Custom Fields, just extend it.
May be only ... values ... you was going define them on PRODUCT LEVEL (???)
Of course they must be defined yet at time when I create a Custom Field
continue:
I have look into DB TABLES ... I see table jos_virtuemart_product_customfields contains for each PRODUCT ALL items of list
1 1 1 mac
win
linux
mac
win
linux
win
linux
COMON GUYS !!!!!
This is absolute mistake from point of view of DB design!! Duplication of data !!!
You repeat THE SAME object many times ...
If tomorrow I will want change mac to MacOS what todo ??? UPDATE command will not help in general case ...
===============
It very looks to me, that when you have "invent" Custom Fields, you did think only about SIMPLE attributes, as
Book
Title:
IBN:
For such SINGLE-item attributes, we really need save VALUE related to A product XX into that table.
But for N-items Lists, this is absolutely wrong idea ...
List values must be with all its possible values stored in the table jos_virtuemart_customs
In my first post I have show fine solution IMO ...
And you may want to CHANGE this ASAP ... for 2.1
As I see this will not break already existed Custom Fields in table jos_virtuemart_product_customfields
because we just introduce new type of custom field -- TRUE ListAsXXXXXXX
I totally agree !
I'm with you ruslan_zasukhin.
The Custom Fileds must be like object, that every product can use and get reference with . Not contain the value, only the pointer to the value.
This is the origin of relational database. Universe to save us with VirtueMart 2.x.x. We will suffer it, very well....
Not to mention OOP (Object Oriented Programing, for who's not know what is this). How in year 2012 there is programmers that can do that with VirtueMart?
Sorry, I know, you are voluntaries, making the VirtueMart, but sometime will be good ast some profesionals for at least planning. Yea, it's hurt.
But now VirtueMart is a BIG SPAGHUETTI INCIDENT with his design.
I would soooooo like this to be implemented and heres why, I sell stickers online in a lot of different colors. The thing is, these colors change every now and then.
The best thing for me is to change these colors ONE single time in the attribute. Not change the colors in every single product... (Im planning to add over 1000 products but i wont untill this simple tweak is sorted out in a next release.)