Author Topic: One more Suggestion: Custom Fields must give us List, RadioButtons, ...  (Read 2311 times)

ruslan_zasukhin

  • Beginner
  • *
  • Posts: 9
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










ruslan_zasukhin

  • Beginner
  • *
  • Posts: 9
Re: One more Suggestion: Custom Fields must give us List, RadioButtons, ...
« Reply #1 on: February 12, 2012, 15:46:52 pm »
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



postkat

  • Beginner
  • *
  • Posts: 35
Re: One more Suggestion: Custom Fields must give us List, RadioButtons, ...
« Reply #2 on: February 14, 2012, 16:52:08 pm »
I totally  agree !

some

  • Beginner
  • *
  • Posts: 17
Re: One more Suggestion: Custom Fields must give us List, RadioButtons, ...
« Reply #3 on: February 15, 2012, 09:21:02 am »
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.

nickson

  • Beginner
  • *
  • Posts: 28
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.)