Building $node->body with arrays like FAPI for viewing
I'm talking about the displaying of nodes using PHPTemplate. Right now hook_nodeapi($op = 'view' or 'links' etc.) has a lot of modules adding to the body like this $node->body .= $output; Maybe there is a module_setting to put it on TOP of the body or on the BOTTOM. But most modules just append. When displaying the node, all of that comes into $content in node.tpl.php. So if you want to configure that, you have to redo the whole body yourself. Then, if you install another module that adds to the node body through hook_nodeapi you have to go manually add that to your node.tpl.php for each one. If we constructed it like FAPI, with weights, etc. We could allow modifications of that right before calling render_body($node) or whatever. So hook_nodeapi('view') could do something like $body['mymodule']['extra_stuff_added_to_node'] = array( '#type' => 'markup', // Any other possible values or is it always markup? What about adding quick forms to send to friend etc.? '#value' => '<div>Cool stuff added to end of node, but can be removed or rearranged with hook_body_alter();</div>', '#weight' => 10, // or could even have variable_get('mymodule_extra_stuff_added_to_node_weight, 10); ); We could even add comments this way and have much more flexibility to configure when, where, and how items are added to the node body. Also, configuring these options (value, weight) in _settings would be that much easier. Then, with hook_body_alter we can mess with the weights, values, remove just this ONE item without manually reconstructing $content in our node.tpl.php. Also, this could be applied to links I believe. This is something I deal with all the time and I'm very interested in this behavior. I'd like any input you guys have. Thanks! -- Rob Roy Barreca Electronic Insight Corporation 12526 High Bluff Drive, Suite 300 San Diego, CA 92130 http://www.electronicinsight.com rob@electronicinsight.com
Also, these could be registered like blocks are on the admin > blocks page. Then, users could rearrange, enable/disable, configure node additions just like blocks and even specify page visibility without messing with any body_form_alter if they don't know PHP. This, API would allow for that much easier IMO. Rob Roy Barreca Electronic Insight Corporation 12526 High Bluff Drive, Suite 300 San Diego, CA 92130 http://www.electronicinsight.com rob@electronicinsight.com Rob Barreca wrote:
I'm talking about the displaying of nodes using PHPTemplate. Right now hook_nodeapi($op = 'view' or 'links' etc.) has a lot of modules adding to the body like this
$node->body .= $output;
Maybe there is a module_setting to put it on TOP of the body or on the BOTTOM. But most modules just append. When displaying the node, all of that comes into $content in node.tpl.php. So if you want to configure that, you have to redo the whole body yourself. Then, if you install another module that adds to the node body through hook_nodeapi you have to go manually add that to your node.tpl.php for each one.
If we constructed it like FAPI, with weights, etc. We could allow modifications of that right before calling render_body($node) or whatever. So hook_nodeapi('view') could do something like
$body['mymodule']['extra_stuff_added_to_node'] = array( '#type' => 'markup', // Any other possible values or is it always markup? What about adding quick forms to send to friend etc.? '#value' => '<div>Cool stuff added to end of node, but can be removed or rearranged with hook_body_alter();</div>', '#weight' => 10, // or could even have variable_get('mymodule_extra_stuff_added_to_node_weight, 10); );
We could even add comments this way and have much more flexibility to configure when, where, and how items are added to the node body. Also, configuring these options (value, weight) in _settings would be that much easier. Then, with hook_body_alter we can mess with the weights, values, remove just this ONE item without manually reconstructing $content in our node.tpl.php. Also, this could be applied to links I believe.
This is something I deal with all the time and I'm very interested in this behavior. I'd like any input you guys have.
Thanks!
Are you aware of the fact that $node is available with all its metadata, like $node->content_driving_directions (when using CCK)? And that PHPtemplate offers these as variables: $content_driving_directions wehn using CCK. IMO, it is far ùmore rewarding to make these modules that append $node->body .= jst like that,smarter. If I *only* $node->body .= '<div>' . $image .'</div>'; then I have created a badly designed module. Doing a $node->body = theme('image_build_body', $node); (note the missing . dot! I create a whole new body in that theme function), i am doing a better job. But if in addition I present a $node->image =$image_file_obj; You, as themer have all the power. No hierarchival-fapi-like Array will help me any more. Summary: Let us find the contribs that are badly coded and improve these. But let's please stop this overengineering fapi-array-complexity-drive. :) Fapi is causing enough pain as it is, IMO. No need for more of em in core. ;) Bèr
Are you aware of the fact that $node is available with all its metadata, like $node->content_driving_directions (when using CCK)? And that PHPtemplate offers these as variables: $content_driving_directions wehn using CCK.
This is much better than simply appending to the node body, I agree. But when using other contrib modules with CCK, one must still either choose $content OR manually construct the body and no $content. Something like form_render() would be awesome too -- allowing you to pull a section out of the body but still use body_render() (a.k.a. $content). I know there are weights in CCK, but for the sake of example: <?php print body_render($node, 'content_driving_directions'); ?> <?php print body_render(); ?>
Doing a $node->body = theme('image_build_body', $node); (note the missing . dot! I create a whole new body in that theme function), i am doing a better job. I agree on that one. Especially for a short term solution. But, reorganizing additions to the node->body still is a pain as we basically still only have the choice to prepend, append, or do nothing at all. The content is still being constructed textually before & after this point.
Fapi is causing enough pain as it is, IMO. No need for more of em in core. ;) I only say FAPI so people know what I mean about building arrays. IMO this /could/ be a very simple solution. ;) Basically, saving the ordering, building of the node body until the last second to allow for modifications.
I know it may seem overkill since I'm drawing parallels to FAPI, but it would be very light. Let's call it NAPI (or FAPI Lite) from now on. :-P Rob Roy Barreca Electronic Insight Corporation 12526 High Bluff Drive, Suite 300 San Diego, CA 92130 http://www.electronicinsight.com rob@electronicinsight.com Bèr Kessels wrote:
Are you aware of the fact that $node is available with all its metadata, like $node->content_driving_directions (when using CCK)? And that PHPtemplate offers these as variables: $content_driving_directions wehn using CCK.
IMO, it is far ùmore rewarding to make these modules that append $node->body .= jst like that,smarter.
If I *only* $node->body .= '<div>' . $image .'</div>'; then I have created a badly designed module.
Doing a $node->body = theme('image_build_body', $node); (note the missing . dot! I create a whole new body in that theme function), i am doing a better job.
But if in addition I present a $node->image =$image_file_obj; You, as themer have all the power. No hierarchival-fapi-like Array will help me any more.
Summary: Let us find the contribs that are badly coded and improve these. But let's please stop this overengineering fapi-array-complexity-drive. :)
Fapi is causing enough pain as it is, IMO. No need for more of em in core. ;)
Bèr
On 14 Jul 2006, at 7:44 PM, Rob Barreca wrote:
I know it may seem overkill since I'm drawing parallels to FAPI, but it would be very light. Let's call it NAPI (or FAPI Lite) from now on. :-P
i've been referring to it as API ^2.0 since eventually it's going to become an API API. (yay) Actually, it's just using declarative programming (http:// en.wikipedia.org/wiki/Declarative_programming) where it makes sense. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Yeah, I don't really think we should call it NAPI nor FAPI Lite. :) But would like to get a bit more input so I know if this is of some interest before a create a patch for review. Rob Roy Barreca Electronic Insight Corporation 12526 High Bluff Drive, Suite 300 San Diego, CA 92130 http://www.electronicinsight.com rob@electronicinsight.com Adrian Rossouw wrote:
On 14 Jul 2006, at 7:44 PM, Rob Barreca wrote:
I know it may seem overkill since I'm drawing parallels to FAPI, but it would be very light. Let's call it NAPI (or FAPI Lite) from now on. :-P
i've been referring to it as API ^2.0
since eventually it's going to become an API API. (yay)
Actually, it's just using declarative programming (http://en.wikipedia.org/wiki/Declarative_programming) where it makes sense.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Jul 14, 2006, at 3:52 PM, Rob Barreca wrote:
But would like to get a bit more input so I know if this is of some interest before a create a patch for review.
i'd love to see this. for example, it's a real pain that there's no way to specify *where* in the body the location fields should show up in a location-enabled node (http://drupal.org/node/47831). i have the same problem with the signup form for signup-enabled nodes. adding this kind of flexibility would be great. +1 to the concept. while we're at it, perhaps we should have an element in this structure that specifies if the given thing should be visible in the teaser, too... i haven't thought this out, yet, but it might be an easier, more logical way to control what you want in the teaser vs. body than the system we have now... just brainstorming here. please shoot down this part of the proposal if it's a crappy idea. ;) thanks, -derek
while we're at it, perhaps we should have an element in this structure that specifies if the given thing should be visible in the teaser, too... i haven't thought this out, yet, but it might be an easier, more logical way to control what you want in the teaser vs. body than the system we have now... just brainstorming here. please shoot down this part of the proposal if it's a crappy idea. ;) I think that's a great idea Derek. A lot of times I'm forced to do this is node-whatever.tpl.php: if ($page) { // Do full node stuff here } else { // Do teaser stuff here }.
This would also allow for greater flexibility in the future to allow users more control over the node body construction through the UI, but not to get ahead of myself. I'm really interested in this and would like to take it on. I'd like to keep everyone's input coming as I'm sure some of you could do it much better. Here is an issue where I'll be posting patches. http://drupal.org/node/74326 Rob Roy Barreca Electronic Insight Corporation 12526 High Bluff Drive, Suite 300 San Diego, CA 92130 http://www.electronicinsight.com rob@electronicinsight.com Derek Wright wrote:
On Jul 14, 2006, at 3:52 PM, Rob Barreca wrote:
But would like to get a bit more input so I know if this is of some interest before a create a patch for review.
i'd love to see this. for example, it's a real pain that there's no way to specify *where* in the body the location fields should show up in a location-enabled node (http://drupal.org/node/47831). i have the same problem with the signup form for signup-enabled nodes. adding this kind of flexibility would be great. +1 to the concept.
while we're at it, perhaps we should have an element in this structure that specifies if the given thing should be visible in the teaser, too... i haven't thought this out, yet, but it might be an easier, more logical way to control what you want in the teaser vs. body than the system we have now... just brainstorming here. please shoot down this part of the proposal if it's a crappy idea. ;)
thanks, -derek
Op dinsdag 18 juli 2006 20:08, schreef Derek Wright:
way to specify *where* in the body the location fields should show up
MVC: nowhere, nothing, should ever build up a body except the theme (V in MVC). That is where the real problem lies. We really don't want to pass large chunks of ugly HTML around. We certainly don't want "developers" to make nice presentations (build HTML and glue that to a $node->bopy blurp :p . We want our modules and core, to present the theme-layer a nice structure filled with metadata. Then let the theme (trough handy APIs) build a body from that. -- [ Bèr Kessels | Drupal services www.webschuur.com ]
MVC: nowhere, nothing, should ever build up a body except the theme (V in MVC).
That is where the real problem lies. We really don't want to pass large chunks of ugly HTML around. We certainly don't want "developers" to make nice presentations (build HTML and glue that to a $node->bopy blurp :p .
We want our modules and core, to present the theme-layer a nice structure filled with metadata. Then let the theme (trough handy APIs) build a body from that.
The man speaks the truth. Although there are some edge cases that get complicated -- modules like inline, insert_view, and so on that all need to filter the final result of an assembled node. What's the best solution for that? --Jeff
Op dinsdag 18 juli 2006 23:18, schreef Jeff Eaton:
The man speaks the truth. Although there are some edge cases that get complicated -- modules like inline, insert_view, and so on that all need to filter the final result of an assembled node. What's the best solution for that?
I honestly don't know. But I think for now the inline-way works: we present $node->... with metadata, as well as some in-text token replacement. Or, in fact it should read as: we add metadata to the node we alter metadata that requests to be altered (textarea asks to be filtered) Bèr -- | Bèr Kessels | webschuur.com | Drupal, Joomla and Ruby on Rails web development | | Jabber & Google Talk: ber@jabber.webschuur.com | | http://bler.webschuur.com | http://www.webschuur.com | Paginas in je site bewerken: http://help.sympal.nl/paginas_in_je_site_bewerken Written while listening to Track 5 by [The User] on Symphony #1 for dot matrix pri
Maybe there is a module_setting to put it on TOP of the body or on the BOTTOM. But most modules just append. When displaying the node, all of that comes into $content in node.tpl.php. So if you want to configure that, you have to redo the whole body yourself. Then, if you install another module that adds to the node body through hook_nodeapi you have to go manually add that to your node.tpl.php for each one.
If we constructed it like FAPI, with weights, etc. We could allow modifications of that right before calling render_body($node) or whatever. So hook_nodeapi('view') could do something like
i think most people agree that the fapi array model should extend beyond forms to viewing as well. i don't think we have much idea yet for how to do this though. there are many more examples beyond $node render, so lets be broad in our thinking.
participants (6)
-
Adrian Rossouw -
Bèr Kessels -
Derek Wright -
Jeff Eaton -
Moshe Weitzman -
Rob Barreca