Implementation Plan for Commerce Product Reference View Widget

If a "product reference" field makes use of the "commerce product reference view" widget; the widget will still save an expected array of product id's.

But the module "commerce product reference view" still needs access of the user selected views for a particular entity record of a field instance. For example:

On product display id -- 5 on field "field_testa", initially a user saves the product id's (1,2,3,4) under the select list widget.
User then changes widget to "commerce product reference view" then selects view "my_view" that returns products id's (1,2,3,4,6)

Under the product display entity record 5 the field_testa will have an array of product id's (1,2,3,4,6) additionally an additional record on table "field_widget_commerce_product_reference_view"

array(
'entity_type'=>'node',
'bundle'=>'product_display',
'field_id'=>17,
'field_name'=>'field_testa',
'deleted'=>0,
'entity_id'=>5,
'revision_id'=>5,
'language'=>'und',
'delta'=>0,
'vname'=>'my_views|default'
'vargs'=>''
);

@TODO are the columns: entity_type, bundle,field_name even necessary because we already have field_id in the process. ?

Reply to #2 comment http://drupal.org/node/1256922 added all fields. will change if necessary.

Need help on this!

Field instance storage architectural implementation

Some thoughts on the current scaffold of this module:

Is the module building going the right direction? If a "product reference" field -- field name "field_testa" makes use of the "commerce product reference view" widget; the widget will still save an expected array of product id's. But the user input for the field_testa product_reference_view widget still needs to be stored somewhere.

Initially I was thinking about doing this on a custom table field_widget_commerce_product_reference_view; but is this wise? The module architecture is not taking advantage of the drupal/entity/entity api functions at this point. Would it be better to create another field on widget demand and put the user input of selected views there?

Currently looking into hook_field_extra_fields()

Need feeback.

Settings of product_reference_view widget

Copying from the viewfield module the product_reference_view widget has the following settings:

a. ) field level settings "allowed views" this is implemented through hook_field_info_alter (would doing this through entity api be better?) So on a node create/edit event the widget will only display a selection coming from allowed views.
Take note that this is a field level settings level.

b.) field instance level settings "defaults" this is implemented though hook_field_widget_settings_form. So on a node create/edit event the widget will only display a selection coming from allowed views that defaults according to the default settings.
Take note that this is a field instance level settings level.

(chriscalip) keithm hey dude, im trying to pull off product_reference view widget using viewfield as a scaffold module. mind if ask some feedback. i could really use some second opinion
(keithm) chriscalip: shoot
(chriscalip) keithm http://drupal.org/node/1256820#comment-4906600
(keithm) chriscalip: took a quick look at your plan and your code. Since your goal is a replacement widget, if I were doing this I would probably drive the development from the UI, starting with a fixed view/display and use $view->preview() to work out the user interaction. I'm not sure you need all the settings and backend support from viewfield.
(chriscalip) keithm : well the settings "allowed views and default views" would be useful especially on creating a product display and instead of adding all the skus (product ids) , just add a view that gives all those skus.
(keithm) chriscalip: yes, but don't you need just one?
(chriscalip) keithm i thought about that .. but my use case and for example bradwade's use case .. having multiple views to select would be especially be useful. for example imagine
(chriscalip) corresponding product displays types for each product types
(chriscalip) configuring a view on each node (edit/create) is not a prospect id like to expose people with
(chriscalip) keithm your idea of token placeholders is also why i went with scaffolding viewfield .. very useful feature
(chriscalip) keithm but i can certainly see the advantages of doing this just as a replacement widget and drive the development from the UI .. on a lot of use cases that would work.
(keithm) chriscalip: My main concern would be a maintenance one. Viewfield, like other modules, keeps changing and being improved. If the viewfield framework is a suitable one for your cases, I would try to write adapter code to use it directly rather than copying it.
(chriscalip) keithm : yeah i was initially really thinking about just using your functions ... but there was a divergence of need between as a field centric module versus a widget centric module
(keithm) chriscalip: right
(chriscalip) keithm : it's probably more difficult (developing and maintaining this new module); i tried really hard to just use the functions i couldnt pull it off :(
(keithm) chriscalip: well, also viewfield has a more general use case than I think you have. Recursion handling might not be necessary for you.
(chriscalip) keithm in the meantime i could see developing another module widget based on your idea ; it would be of help to people with that type of use case.
(keithm) chriscalip: Going back to my initial suggestion, I think you may find other differences if you drive the process from the UI, or at least rapidly get to the point where you can play around with it.
(chriscalip) keithm in the meantime for this particular use case a widget that saves particular selected views would be ideal... but where do i store this widget information during the node edit/create phase?
(chriscalip) this problem also applies with your idea.. we still need to save that specific node -- views widget information to somewhere.
(keithm) chriscalip: hmmm if you are working with an entity, can't you just just attach a viewfield to it programmatically?
(chriscalip) keithm : yeah i was also thinking about that in that thread using hook_field_extra_fields()
(chriscalip) or maybe entity api
(chriscalip) pretty much instantiate another field (viewfield ) corresponding to that product_reference field
(chriscalip) versus just storing node information in a custom table
(chriscalip) keithm this is where .. i could use some feedback
(keithm) chriscalip: well then, if you feel your cases warrant allowed_views, etc, I would attach a viewfield programmatically.
(chriscalip) keithm : yup a few little details needs to be taken of .. like disabling display of that particular viewfield
(chriscalip) what would be the field name of that particular viewfield for example on product_reference field "field_testa" would it be better to justy attach field_testa_view
(keithm) chriscalip: sure, though there are always ways to do that depending on the context. Also, force_default automatically hides the field on edit forms.
(chriscalip) force_default yup. this is where the placeholder tokens shine a lot!
(chriscalip) so before i go on this path of programmatically creating a corresponding viewfield on widget activation ... are there any minefields i should watch for?
(chriscalip) ill probably just jump and deal with the minefields as it comes.
(keithm) chriscalip: I haven't programmed this specific application but give a shout if you find something on the viewfield side I can help with.
(chriscalip) btw keithm talking for talking to me about this .. sometimes it just helps to talk about the issue and not store it all in my mind.
(keithm) chriscalip: sure. hope it helped.
(chriscalip) keithm thanks for your offer, i might take you on that offer. btw if you look at the module you have more commits than me :)
(chriscalip) keithm it sure did, thanks

Decided to go with integration with viewfield @ http://drupal.org/node/1260046