I need to create an active select in a CCK type.
So i created a CCK module.
I want to have a field in the field creation form presenting the other existing fields.
In order to do that my widget needs to know the type on which it is being used.
So i added in content_admin.inc another paremeter to the hook:
$additions = module_invoke($widget_type['module'], 'widget_settings', 'form', $field['widget'],$type);

does that make sense?

hed

Comments

yched’s picture

yched commented

If i understand correctly, you want to be able to point to another field of the same content type, from your widget's settings form, so you need a list of the valid fields to have the user pick one from a drop-down ?

I don't know if it's a good thing widgets have a knowledge of the context they're used in (content type). Your use case seems valid, but it seems adding this in the API 'encourages' this idea of context sensitive widgets, and I'm not sure this is really in line with CCK 'philosophy'.
Maybe it's just me, I'm mainly thinking out loud here. Does anyone have other ideas or examples of use cases for this ?

Meanwhile, for your particular needs (if I get them right), maybe you could use a simple textfield in which the user enters the id of the field ?
I'm aware :
- it's not as user-friendly as a drop-down,
- you won't be able to do a proper validation
but you could at least have the effect ?

hedb’s picture

hedb commented

The simple text field would work ofcourse, but is very error prone.
As my use case is valid (said who?), i would claim that we should adopt the widget philosophy to it - and not vice versa.
I understand your concern but i want to point to a subtle point that might allow this dependance
The dependance is actually
"widget configuration" => specific type
the widget itself only knows it's being configured in the context of a CCK type.

Having said that it's true that once that is in the API i can develop staff like
if type.name = 'myType'

i'll open a project with my module - and you can judge

hed

coupet’s picture

coupet commented

we would greatly appreciate status or further discussions of proposed changes.

Reference:
-------------------
dependantDropdown
http://drupal.org/project/dependantDropdown

Darly

karens’s picture

karens commented

Field name info is already available to the widget:

* Hook_widget has a $field parameter that has the field name in it ($field['field_name']).

* The field settings form now includes form values for type_name (that is the content type name), field_name, field_type, and module (this is a fairly recent change).

* Type info is also available in the arg (arg(3) is the content type name and arg(5) is the field name), so it is also possible to use args. However, we need to quit relying on args for values because when forms are submitted programmatically, as they can be in 5.x, the args aren't available.

I think what yched is referring to is that JonBob has always said his intention was for widgets and fields to operate completely independently of each other, but I can't think of any reason why it would hurt for the widget to know what type it's being created in, and at any rate it's not that hard to determine.

Do any of these address the issue, or am I missing the point?

dopry’s picture

dopry commented

I think the problem is that the widget_settings hook isn't invoked consistently and if $field were passed in the context would be available. See http://drupal.org/node/108491

morphir’s picture

morphir commented
Version: 4.7.x-1.x-dev » 5.x-1.4

Is there any solution to this? I could need this 'Filter according to field'-feature.

dopry’s picture

dopry commented
Status: Active » Closed (fixed)

nope no solution... and widgets should be unaware of their field context. the can get field information when their callbacks are invoked, but not for the settings form... just the way it works.. dont' shoot the messenger, unless you come with patch in hand.