Hi List, I cannot find any documentation about custom field/query handlers for views 2 (D6). Can someone please enlighten me? Regards, Eric
Eric Install both views and advanced help, under advanced help you will find information about custom field/query handlers Nevets On 11/20/2010 9:29 AM, Eric Schaefer wrote:
Hi List,
I cannot find any documentation about custom field/query handlers for views 2 (D6). Can someone please enlighten me?
Regards, Eric
Most of the time I start with one directly from Views that does close to what I want and create a similar one, just renaming the appropriate classes and sticking it in my own module. Also: http://views-help.doc.logrus.com/help/views/api-handlers On Sat, Nov 20, 2010 at 8:35 AM, Steve Ringwood <nevets@tds.net> wrote:
Eric
Install both views and advanced help, under advanced help you will find information about custom field/query handlers
Nevets
On 11/20/2010 9:29 AM, Eric Schaefer wrote:
Hi List,
I cannot find any documentation about custom field/query handlers for views 2 (D6). Can someone please enlighten me?
Regards, Eric
-- ~Jerad Bitner Lead Developer and Drupal Trainer at Lullabot http://lullabot.com | http://sirkitree.net | http://jeradbitner.com
I've been trying to get mine working for weeks, With the advanced help and suggestions from Earl and Dereine. One problem is that apparently I (and I'm just doing a vanilla text field handler) have to extend views-handler-field-field, while every example in the views module extends views-handler-field. The only module I have found so far that does the same is Date, and it is so specialized as to not be a good example. I'm doing D7, but cannot find even an easy. D6 example. Ayen Designs - quality software the first time, every time! -----Original Message----- From: Jerad Bitner <jbitner@lullabot.com> Sender: development-bounces@drupal.org Date: Sat, 20 Nov 2010 10:12:13 To: <development@drupal.org>; <nevets@mailbag.com> Reply-To: development@drupal.org Subject: Re: [development] Custom Handlers for Views 2 Most of the time I start with one directly from Views that does close to what I want and create a similar one, just renaming the appropriate classes and sticking it in my own module. Also: http://views-help.doc.logrus.com/help/views/api-handlers On Sat, Nov 20, 2010 at 8:35 AM, Steve Ringwood <nevets@tds.net> wrote:
Eric
Install both views and advanced help, under advanced help you will find information about custom field/query handlers
Nevets
On 11/20/2010 9:29 AM, Eric Schaefer wrote:
Hi List,
I cannot find any documentation about custom field/query handlers for views 2 (D6). Can someone please enlighten me?
Regards, Eric
-- ~Jerad Bitner Lead Developer and Drupal Trainer at Lullabot http://lullabot.com | http://sirkitree.net | http://jeradbitner.com
On 11/20/2010 9:56 AM, jeff@ayendesigns.com wrote:
I've been trying to get mine working for weeks, With the advanced help and suggestions from Earl and Dereine. One problem is that apparently I (and I'm just doing a vanilla text field handler) have to extend views-handler-field-field, while every example in the views module extends views-handler-field. The only module I have found so far that does the same is Date, and it is so specialized as to not be a good example. I'm doing D7, but cannot find even an easy. D6 example. Ayen Designs - quality software the first time, every time!
To be fair, it's because what you're doing is trying to mess with CCK's handlers which are extra levels of abstraction.
Yes, you're right. I was being unrealistically optimistic stating that I was doing something vanilla, even more so because I am altering the field configuration form, though that is the rendering manipulation part, and it's really the pre-rendering part I've been having trouble with (i.e. getting my hands on the field). At first I looked at it as being vanilla, because it's simply a text field added to a content type. What you state so clearly below was actually somewhat of a leap for me. I mistakenly thought that CCK now being in core meant that a fielded entity field would be somehow more 'native' in terms of accessing it. Of course, that doesn't leave a whole lot of node fields that accept hold content that are NOT abstractions. Title may be the only one...even Body is now an entity field if I'm not mistaken. On 11/21/2010 01:47 AM, Earl Miles wrote:
To be fair, it's because what you're doing is trying to mess with CCK's handlers which are extra levels of abstraction.
On 11/21/2010 7:36 AM, jeff@ayendesigns.com wrote:
Yes, you're right. I was being unrealistically optimistic stating that I was doing something vanilla, even more so because I am altering the field configuration form, though that is the rendering manipulation part, and it's really the pre-rendering part I've been having trouble with (i.e. getting my hands on the field).
At first I looked at it as being vanilla, because it's simply a text field added to a content type. What you state so clearly below was actually somewhat of a leap for me. I mistakenly thought that CCK now being in core meant that a fielded entity field would be somehow more 'native' in terms of accessing it.
Of course, that doesn't leave a whole lot of node fields that accept hold content that are NOT abstractions. Title may be the only one...even Body is now an entity field if I'm not mistaken.
This is an interesting side effect of field API, and you're right. It will be more difficult to make what used to be simple changes. You are blazing new territory with this, and what you are doing may be an uncommon but important need for advanced Views users. Please be sure to write up what you have discovered so that we can document this and hopefully the next person to do it doesn't have to spend weeks figuring out the levels of abstraction to make deep modifications to field api fields.
I will write it up. That said, I got it working this afternoon! I'm a little unsure about one part though, where I pluck the field's value from the value array. It seems that there should be a more elegant way of walking to the correct index than this: $values->_field_cache[$this->field_alias]['object']->{$this->definition['field_name']}['und'][0]['safe_value']; and in particular, the ['und'][0]['safe_value'] part of it. In my case, it is predictable that there will only be one instance of the field in the row, so the [0] is ok, otherwise I'd loop. I guess it's the ['und'] that is bothering me, especially not knowing what 'und' indicates. On 11/21/2010 01:34 PM, Earl Miles wrote:
This is an interesting side effect of field API, and you're right. It will be more difficult to make what used to be simple changes. You are blazing new territory with this, and what you are doing may be an uncommon but important need for advanced Views users. Please be sure to write up what you have discovered so that we can document this and hopefully the next person to do it doesn't have to spend weeks figuring out the levels of abstraction to make deep modifications to field api fields.
'und' indicates that the field's value does not change with the language of the site. If the field had multiple translations, then und would be replaced with the appropriate language code, such as 'en-us' or 'fr'. For that reason you don't want to hard-code 'und', and instead use the appropriate language value there instead. How you get the appropriate language value in that context... I have no idea. I actually find the data structure for Fields in D7 to be completely incomprehensible and virtually unusable so the fact that you managed to make it that far is a miracle. :-) --Larry Garfield On Sunday, November 21, 2010 5:20:23 pm jeff@ayendesigns.com wrote:
I will write it up. That said, I got it working this afternoon! I'm a little unsure about one part though, where I pluck the field's value from the value array. It seems that there should be a more elegant way of walking to the correct index than this:
$values->_field_cache[$this->field_alias]['object']->{$this->definition['fi eld_name']}['und'][0]['safe_value'];
and in particular, the ['und'][0]['safe_value'] part of it. In my case, it is predictable that there will only be one instance of the field in the row, so the [0] is ok, otherwise I'd loop. I guess it's the ['und'] that is bothering me, especially not knowing what 'und' indicates.
On 11/21/2010 01:34 PM, Earl Miles wrote:
This is an interesting side effect of field API, and you're right. It will be more difficult to make what used to be simple changes. You are blazing new territory with this, and what you are doing may be an uncommon but important need for advanced Views users. Please be sure to write up what you have discovered so that we can document this and hopefully the next person to do it doesn't have to spend weeks figuring out the levels of abstraction to make deep modifications to field api fields.
You confirm what I'd inferred from Peter's message. So...off to read and ponder :) On 11/21/2010 06:45 PM, Larry Garfield wrote:Thanks. That clears up the mystery of the term, but implies that I cannot count on 'und' being the index. On 11/21/2010 06:37 PM, Peter Droogmans wrote:
Und indicates unknown language
Met vriendelijke groeten, Peter Droogmans 'und' indicates that the field's value does not change with the language of the site. If the field had multiple translations, then und would be replaced with the appropriate language code, such as 'en-us' or 'fr'. For that reason you don't want to hard-code 'und', and instead use the appropriate language value there instead.
How you get the appropriate language value in that context... I have no idea. I actually find the data structure for Fields in D7 to be completely incomprehensible and virtually unusable so the fact that you managed to make it that far is a miracle. :-)
--Larry Garfield
On Sunday, November 21, 2010 5:20:23 pm jeff@ayendesigns.com wrote:
I will write it up. That said, I got it working this afternoon! I'm a little unsure about one part though, where I pluck the field's value from the value array. It seems that there should be a more elegant way of walking to the correct index than this:
$values->_field_cache[$this->field_alias]['object']->{$this->definition['fi eld_name']}['und'][0]['safe_value'];
and in particular, the ['und'][0]['safe_value'] part of it. In my case, it is predictable that there will only be one instance of the field in the row, so the [0] is ok, otherwise I'd loop. I guess it's the ['und'] that is bothering me, especially not knowing what 'und' indicates.
On 11/21/2010 01:34 PM, Earl Miles wrote:
This is an interesting side effect of field API, and you're right. It will be more difficult to make what used to be simple changes. You are blazing new territory with this, and what you are doing may be an uncommon but important need for advanced Views users. Please be sure to write up what you have discovered so that we can document this and hopefully the next person to do it doesn't have to spend weeks figuring out the levels of abstraction to make deep modifications to field api fields.
You can use field_language() to figure out which language to use for a specific field. It will return an array in the form of 'field_name' => 'language key' ('und' in your case). http://api.drupal.org/api/drupal/modules--field--field.multilingual.inc/func... I am however not sure where to get the necessary arguments for that function from, especially entity_type, no idea if you can get it from the views metadata. On Mon, Nov 22, 2010 at 12:47 AM, <jeff@ayendesigns.com> wrote:
You confirm what I'd inferred from Peter's message. So...off to read and ponder :)
On 11/21/2010 06:45 PM, Larry Garfield wrote:Thanks. That clears up the mystery of the term, but implies that I cannot count on 'und' being the index.
On 11/21/2010 06:37 PM, Peter Droogmans wrote:
Und indicates unknown language
Met vriendelijke groeten, Peter Droogmans 'und' indicates that the field's value does not change with the language of the site. If the field had multiple translations, then und would be replaced with the appropriate language code, such as 'en-us' or 'fr'. For that reason you don't want to hard-code 'und', and instead use the appropriate language value there instead.
How you get the appropriate language value in that context... I have no idea. I actually find the data structure for Fields in D7 to be completely incomprehensible and virtually unusable so the fact that you managed to make it that far is a miracle. :-)
--Larry Garfield
On Sunday, November 21, 2010 5:20:23 pm jeff@ayendesigns.com wrote:
I will write it up. That said, I got it working this afternoon! I'm a little unsure about one part though, where I pluck the field's value from the value array. It seems that there should be a more elegant way of walking to the correct index than this:
$values->_field_cache[$this->field_alias]['object']->{$this->definition['fi eld_name']}['und'][0]['safe_value'];
and in particular, the ['und'][0]['safe_value'] part of it. In my case, it is predictable that there will only be one instance of the field in the row, so the [0] is ok, otherwise I'd loop. I guess it's the ['und'] that is bothering me, especially not knowing what 'und' indicates.
On 11/21/2010 01:34 PM, Earl Miles wrote:
This is an interesting side effect of field API, and you're right. It will be more difficult to make what used to be simple changes. You are blazing new territory with this, and what you are doing may be an uncommon but important need for advanced Views users. Please be sure to write up what you have discovered so that we can document this and hopefully the next person to do it doesn't have to spend weeks figuring out the levels of abstraction to make deep modifications to field api fields.
Yes, both entity_type and entity are available from the views metadata. So that takes care of resolving what to use instead of hardcoding 'und', thanks. The remaining question is whether that long identifier, now with language instead of 'und', is the best way to do it, or whether there's a get_views_field_value_from_humongously_large_object($field_name) api function :)
You can use field_language() to figure out which language to use for a specific field. It will return an array in the form of 'field_name' => 'language key' ('und' in your case).
http://api.drupal.org/api/drupal/modules--field--field.multilingual.inc/func...
I am however not sure where to get the necessary arguments for that function from, especially entity_type, no idea if you can get it from the views metadata.
On 11/21/2010 4:32 PM, jeff@ayendesigns.com wrote:
Yes, both entity_type and entity are available from the views metadata. So that takes care of resolving what to use instead of hardcoding 'und', thanks. The remaining question is whether that long identifier, now with language instead of 'und', is the best way to do it, or whether there's a get_views_field_value_from_humongously_large_object($field_name) api function :)
Keep an eye on this patch: http://drupal.org/node/936196 It could ultimately change what you need to do.
2010/11/20 Steve Ringwood <nevets@tds.net>:
Install both views and advanced help, under advanced help you will find information about custom field/query handlers
*slapsforehead* I new I had seen it somewhere. Thanks, Eric
I recently did something as simple as this and that seems to work (define it in the _data hook). class custom_module_handler_field_yours extends views_handler_field { function render($values) { return '<strong>'.$values->yourfield.'</strong>'; } } HnLn On 21/11/2010 10:36, Eric Schaefer wrote:
2010/11/20 Steve Ringwood<nevets@tds.net>:
Install both views and advanced help, under advanced help you will find information about custom field/query handlers
*slapsforehead* I new I had seen it somewhere.
Thanks, Eric
On 11/21/2010 2:37 AM, Hans Langouche wrote:
I recently did something as simple as this and that seems to work (define it in the _data hook).
class custom_module_handler_field_yours extends views_handler_field { function render($values) { return '<strong>'.$values->yourfield.'</strong>'; } }
If you're not using some kind of filtering, that particular piece of code could be vulnerable to XSS attacks. See http://drupal.org/node/28984 Even if your real code is secure and you were just showing it as an example, others could take the example and miss the security aspect because it's not in the example.
participants (8)
-
Earl Miles -
Eric Schaefer -
Hans Langouche -
jeff＠ayendesigns.com -
Jerad Bitner -
Larry Garfield -
Sascha Grossenbacher -
Steve Ringwood