proposal for theming nodes
Hi, way too often i have to hack modules or even core (upload) to make it *not* append HTML to $node->body. I think this practice of appending stuff to the body is very bad, since it makes it impossible to add thatdata elsewhere, without duplication. I think that teh best option is an additional variable in $node $node->extra containing structured data added by all the modules. $node->extra->upload could, for example contain that uplaod/attachement table, that is now hardcoded to the body. In the very very end, the theme_node will iterate over all these ->extra 's and append them to teh body. Now, the code, the patch, should not be too hard to make, its just a few lines to the theme_node functions The hard part, imho is to convert **all** core modules to use this. and with All i mean all :). Taxononomy, for example, should add its terms in there, while book module should add its navigation. The other thing is, that while this annoys me a huge lot, i just don't have time to get a patch going, untill at least end of Januari. Waht do others think Bèr PS: Im not to sure about tis crossposting thing, but there are loads of theme and developers issues; is it safe to assume that interested parties at least read development? (so that we can keep this on development) -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
On 12/14/05, Bèr Kessels <ber@webschuur.com> wrote:
Hi,
way too often i have to hack modules or even core (upload) to make it *not* append HTML to $node->body.
I think this practice of appending stuff to the body is very bad, since it makes it impossible to add thatdata elsewhere, without duplication.
We've noticed this now with trackbacks and other such items (even book module navigation, althought this may have been fixed now) appearing in "full text feed" mode in RSS...you have to do special checking in your module to exclude extra data when it's being uses in the RSS feed. The hard part, imho is to convert **all** core modules to use this. and with
All i mean all :). Taxononomy, for example, should add its terms in there, while book module should add its navigation.
Taxonomy I don't think so, but book module navigation, certainly. Which brings up the point...do we then need an extra.tpl.php? Or options in taxonomy that says "Append taxonomy terms after node body"? Best not to touch the taxonomy issue for now, I think. -- Boris Mann http://www.bryght.com Vancouver 778-896-2747 / San Francisco 415-367-3595 IM boris_mann@jabber.org / SKYPE borismann
I agree regarding Taxonomy. I'm already looking at simple ways to split out different vocabularies -- I want free-tagging terms listed differently than hierarchial stuff. It's a different set of problems, I think. I do agree wholeheartedly with Ber, though, about the problem of modules monkeying around with node->body before the theming process takes place. Anything that needs to ALTER the contents of the node should, IMO, be a filter. --Jeff -----Original Message----- From: Boris Mann [mailto:boris@bryght.com] Sent: Wednesday, December 14, 2005 10:15 AM To: development@drupal.org Subject: Re: [development] proposal for theming nodes Taxonomy I don't think so, but book module navigation, certainly. Which brings up the point...do we then need an extra.tpl.php? Or options in taxonomy that says "Append taxonomy terms after node body"? Best not to touch the taxonomy issue for now, I think.
On 12/14/05 11:24 AM, Jeff Eaton wrote:
I agree regarding Taxonomy. I'm already looking at simple ways to split out different vocabularies -- I want free-tagging terms listed differently than hierarchial stuff. It's a different set of problems, I think.
that'd be really nice, and yeah - 2 different problems. for instance, if i have an image in a "gallery" (term from one "special" vocabulary) - i may want to style it differently from the list of tags also attributed to the image. oh my, did i say image as node... wrong thread ;) -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
On 14-Dec-05, at 8:33 AM, James Walker wrote:
On 12/14/05 11:24 AM, Jeff Eaton wrote:
I agree regarding Taxonomy. I'm already looking at simple ways to split out different vocabularies -- I want free-tagging terms listed differently than hierarchial stuff. It's a different set of problems, I think.
that'd be really nice, and yeah - 2 different problems.
for instance, if i have an image in a "gallery" (term from one "special" vocabulary) - i may want to style it differently from the list of tags also attributed to the image.
This is doable already through theming...Richard had a little theme snippet for this, I think. Weblink module used to split this up as well. Image might want to support this directly by including an example node-image.tpl.php, perhaps? -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
On 12/14/05 11:42 AM, Boris Mann wrote:
On 14-Dec-05, at 8:33 AM, James Walker wrote:
On 12/14/05 11:24 AM, Jeff Eaton wrote:
I agree regarding Taxonomy. I'm already looking at simple ways to split out different vocabularies -- I want free-tagging terms listed differently than hierarchial stuff. It's a different set of problems, I think.
that'd be really nice, and yeah - 2 different problems.
for instance, if i have an image in a "gallery" (term from one "special" vocabulary) - i may want to style it differently from the list of tags also attributed to the image.
This is doable already through theming...Richard had a little theme snippet for this, I think.
Weblink module used to split this up as well. Image might want to support this directly by including an example node-image.tpl.php, perhaps?
shows ya the last time I wrote a theme ;) -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
On 12/14/05, Boris Mann <boris@bryght.com> wrote:
On 14-Dec-05, at 8:33 AM, James Walker wrote:
for instance, if i have an image in a "gallery" (term from one "special" vocabulary) - i may want to style it differently from the list of tags also attributed to the image.
This is doable already through theming...Richard had a little theme snippet for this, I think.
I wrote the snippet at http://drupal.org/node/38768 which shows the terms from a certain vocabulary (tags, in that case). -- Richard Eriksson http://www.bryght.com/
Good thinking, Ber.
I think this practice of appending stuff to the body is very bad, since it makes it impossible to add thatdata elsewhere, without duplication.
Agreed. We end up appending to $node->body in e.g. 'view' nodeapi hooks ($node->body .= $whatever), or prepending, simply because there's no other way to get additional content rendered by themes' _node() functions--short of editing an individual theme. The result is a lump of undifferentiated content, that the theme can only blindly repeat. Consider the case of an image that's meant to accompany a node. What we really want to do is define something like a $node->thumbnail_image, that the theme can then decide how to render. But if we do so the theme won't know about this newly-defined property of the node object, so no image will render.
I think that teh best option is an additional variable in $node $node->extra containing structured data added by all the modules. $node->extra->upload could, for example contain that uplaod/attachement table, that is now hardcoded to the body.
So I like this idea a lot. And, if for example we required that all $extra content be valid XHTML, e.g., be contained in an enclosing tag, we could include logic in the theme-side parsing that defined different handling for different types of tags. I.e., theme parses first tag name, and, e.g., if it's an img, encloses it in a div with a particular style to define its placement on the page.
Bèr Kessels wrote:
Hi,
way too often i have to hack modules or even core (upload) to make it *not* append HTML to $node->body.
I think this practice of appending stuff to the body is very bad, since it makes it impossible to add thatdata elsewhere, without duplication.
Yep, I agree, same problem here
I think that teh best option is an additional variable in $node $node->extra containing structured data added by all the modules. $node->extra->upload could, for example contain that uplaod/attachement table, that is now hardcoded to the body.
First I would like to insist in that *all html* produced should be themeable. About this specific issue, I think we could a) Just use themeable functions, that can be overridden, like a 'theme_upload_node_body' but, anyway, don't store it into node->body, but in node->output or similar b) Use that $node->extra->upload you propose but maybe better make it an array, $node->extra['upload'] so we can use a simple 'implode' at the end. Maybe weights could be useful here too The ideal would be using both, themeable functions that produce structured data, but any of them used separately would just fix the problem. However, the way to go, thinking big, would be kind of 'generalized form API' that could be useful to build any object -page, block, node..- as structured data and then render it to HTML.
Waht do others think Bèr
PS: Im not to sure about tis crossposting thing, but there are loads of theme and developers issues; is it safe to assume that interested parties at least read development? (so that we can keep this on development)
too bad I don't know PHP, as it would be nice for me to comprehend these theme changes you guys are discussing. I think this is the disconnect we typically have between themers and developers. People will carry on a conversation about something and perhaps it'll seem like a good idea at the time, until someone finally codes it, and then we go... "huh"? heh I'm simply saying to keep us non-hackers in mind while having all these discussions. Thank you, drive through. Trae Jose A. Reyero wrote:
Bèr Kessels wrote:
Hi,
way too often i have to hack modules or even core (upload) to make it *not* append HTML to $node->body.
I think this practice of appending stuff to the body is very bad, since it makes it impossible to add thatdata elsewhere, without duplication.
Yep, I agree, same problem here
I think that teh best option is an additional variable in $node $node->extra containing structured data added by all the modules. $node->extra->upload could, for example contain that uplaod/attachement table, that is now hardcoded to the body.
First I would like to insist in that *all html* produced should be themeable.
About this specific issue, I think we could a) Just use themeable functions, that can be overridden, like a 'theme_upload_node_body' but, anyway, don't store it into node->body, but in node->output or similar b) Use that $node->extra->upload you propose but maybe better make it an array, $node->extra['upload'] so we can use a simple 'implode' at the end. Maybe weights could be useful here too
The ideal would be using both, themeable functions that produce structured data, but any of them used separately would just fix the problem. However, the way to go, thinking big, would be kind of 'generalized form API' that could be useful to build any object -page, block, node..- as structured data and then render it to HTML.
Waht do others think Bèr
PS: Im not to sure about tis crossposting thing, but there are loads of theme and developers issues; is it safe to assume that interested parties at least read development? (so that we can keep this on development)
-- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/
too bad I don't know PHP, as it would be nice for me to comprehend these theme changes you guys are discussing. I think this is the disconnect we typically have between themers and developers.
People will carry on a conversation about something and perhaps it'll seem like a good idea at the time, until someone finally codes it, and then we go... "huh"? heh
I'm simply saying to keep us non-hackers in mind while having all these discussions.
Thank you, drive through. Trae
Lots of modules stick their own bits of HTML into nodes. Theme designers have little control over those bits, and where they get displayes. Ber is proposing that we change the way modules append their data onto nodes, to allow themers easier, cleaner control over them. That means less esoteric PHP hacking by themers to get hooha.module to stop slapping all its weird markup into their nodes. --Jeff
oooh, then... ber++ (I'm sorta understand what that means, haven't gotten further than that in the PHP for dummies book heh) Trae Jeff Eaton wrote:
too bad I don't know PHP, as it would be nice for me to comprehend these theme changes you guys are discussing. I think this is the disconnect we typically have between themers and developers.
People will carry on a conversation about something and perhaps it'll seem like a good idea at the time, until someone finally codes it, and then we go... "huh"? heh
I'm simply saying to keep us non-hackers in mind while having all these discussions.
Thank you, drive through. Trae
Lots of modules stick their own bits of HTML into nodes. Theme designers have little control over those bits, and where they get displayes. Ber is proposing that we change the way modules append their data onto nodes, to allow themers easier, cleaner control over them. That means less esoteric PHP hacking by themers to get hooha.module to stop slapping all its weird markup into their nodes.
--Jeff
-- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/
it would be nice for me to comprehend these theme changes you guys are discussing.
Trae, here's a quick explanation. When data on a 'node' is passed to a theme, it comes as an object, called $node, that has various 'properties'. So, for example, there's $node->links, which is a set of links, $node->body, which is the main text, and so on. A themer can do anything she/he wants with these. It's the separating out into separate 'properties' of the $node object that allows us to say "the body should look like this and be presented here". But how to we add extra things that the theme doesn't already know about? Say we want to add an image to a node. This is the sort of thing you can do easily in a module. You can say, "you know this $node object, well, I want to add another property to it, let's call it $node->image, and let's make it a tag like <img src="somepath.png" />". The problem is that the theme won't know anything about this 'image' property of the node. It just knows about the standard set of properties (body, links, and so on). True, we can edit a particular theme so that it looks for $node->image and does something with it. But then the code will only work with that particular theme. Everyone else won't see anything. So how module authors handle this now is to say, "Well, I guess I can't add my content as a new property of $node, so I'll just add it to one of the existing properties. $node->body makes the most sense. So you know this image we want to add? We'll just add it to whatever's already in the node body. So now $node->body equals whatever it had before plus my image." Then, when this hits the theme, the theme outputs the body, and along with it whatever was added along the way. What Ber is saying is, that kinda sucks. We should have some way of adding content without just lumping it together with whatever we already have in the body. Let's find a way of separating it out, and let's make themes smarter, so they can discover new properties that have been added. That way, we'll end up with a lot more control over display. Once this sort of thing was done, you as a themer could say--Any images added? Okay, let's do this with them.
Mabey we should offer free "learn PHP ultra-quick" ebooks for themers? It's a shame there isn't a way to query variables and other php bits and knowledge from drupaldocs, as well as functions. Robin On 12/14/05, Trae McCombs <occy@occy.net> wrote:
too bad I don't know PHP, as it would be nice for me to comprehend these theme changes you guys are discussing. I think this is the disconnect we typically have between themers and developers.
People will carry on a conversation about something and perhaps it'll seem like a good idea at the time, until someone finally codes it, and then we go... "huh"? heh
I'm simply saying to keep us non-hackers in mind while having all these discussions.
Thank you, drive through. Trae
Jose A. Reyero wrote:
Bèr Kessels wrote:
Hi,
way too often i have to hack modules or even core (upload) to make it *not* append HTML to $node->body.
I think this practice of appending stuff to the body is very bad, since it makes it impossible to add thatdata elsewhere, without duplication.
Yep, I agree, same problem here
I think that teh best option is an additional variable in $node $node->extra containing structured data added by all the modules. $node->extra->upload could, for example contain that uplaod/attachement table, that is now hardcoded to the body.
First I would like to insist in that *all html* produced should be themeable.
About this specific issue, I think we could a) Just use themeable functions, that can be overridden, like a 'theme_upload_node_body' but, anyway, don't store it into node->body, but in node->output or similar b) Use that $node->extra->upload you propose but maybe better make it an array, $node->extra['upload'] so we can use a simple 'implode' at the end. Maybe weights could be useful here too
The ideal would be using both, themeable functions that produce structured data, but any of them used separately would just fix the problem. However, the way to go, thinking big, would be kind of 'generalized form API' that could be useful to build any object -page, block, node..- as structured data and then render it to HTML.
Waht do others think Bèr
PS: Im not to sure about tis crossposting thing, but there are loads of theme and developers issues; is it safe to assume that interested parties at least read development? (so that we can keep this on development)
-- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/
-- Robin Monks, CSL Web Administrator robin@civicspacelabs.org
On 14 Dec 2005, at 6:28 PM, Jose A. Reyero wrote:
The ideal would be using both, themeable functions that produce structured data, but any of them used separately would just fix the problem. However, the way to go, thinking big, would be kind of 'generalized form API' that could be useful to build any object -page, block, node..- as structured data and then render it to HTML.
I didn't get the original mail for this thread .. but i'll throw my 2c in here. The forms api is not really a forms api .. it's a structured way of driving the theme system with arrays. Realistically, we will need to use the forms api to output nodes generated with CCK (something it was designed to do) , and I plan to introduce this for themeing at the very least, all nodes .. but possibly even more output. The forms api is basically a kind of model / view / controller system , except in the current implementation .. the structure of the model and the view are merged. Which is .. incredibly .. not ideal (it also wasn't my call). We need to separate out the actual variables needed, into their own function (ie: getting rid of all that horrendous '#tree' logic, and actually just defining the two trees separately). We also define the actual type of the variable (ie: integer, blah), wether they are optional or not. etc, which ties into the validation. This is the level where CCK would get integrated. Then each model, can have multiple views. Only one of these views is a form. Thus we introduce another function which places all these variables defined, into a new structure (ie: adding fieldsets, and tables etc) Then this final structure gets either rendered by the theme system, or gets rendered by the default render() function, which knows how to traverse trees and call theme functions. Each element has a default theme function, but can also have a specific theme function used for a specific view. Basically so the default theme functions for all views would be to display the text / image / whatever, but the form view will have use the <input> theme elements. This means that adding a file element to the form could automatically render a file link (or an image if it's an image element), but render a file input dialog in the form view. A lot of the complexity related to the form system is due to the (probably correct) decision to not get into the menu system at that stage of the development .. ,but the major hurdle of transition is almost over, and there are enough benefits to the current system to live with it for a while, but the next phase is where it will truly shine (and become a _lot_ cleaner). -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
We need to separate out the actual variables needed, into their own function (ie: getting rid of all that horrendous '#tree' logic, and actually just defining the two trees separately). We also define the actual type of the variable (ie: integer, blah), wether they are optional or not. etc, which ties into the validation. This is the level where CCK would get integrated.
Then each model, can have multiple views. Only one of these views is a form.
I just want to comment on that last sentence, in case it didn't jump out at everyone else; Adrian is saying we will be able to theme atomic data... not just whole nodes, with multiple views. This data, thanks to CCK, will be available at two levels; the field level, and the type level (sorry if the terms aren't in CCK-speak). That means, in an event, you can theme the calendar widget for the date (field level), as well as the whole event (including location, ticket price etc). And you can do each of these tasks several times, giving each different representation a name, called a view. If you can get your hands on the appropriate data and make the right function call, you can generate any view of any data and embed it into anything else. So if I wanted show the *when* of my concert schedule, I'd call a function that asked for "Events as times". I'd get a list of starting and ending times for my events (because the event@time view of an event returns only times). And if I wanted to show the *where* of my events, I'd use the "Events as locations" view. perhaps this would return a Google map, because that's the way I built the event@location view. Of course there is the "Event as form" view (for editing events), and the "Event as event" view, which shows the whole event and all its info. Adrian's plans for us are pretty incredible. If anyone hasn't comprehended his meta-view of Drupal, you should pester him with questions until you do. -Robert
The ideal would be using both, themeable functions that produce structured data, but any of them used separately would just fix the problem. However, the way to go, thinking big, would be kind of 'generalized form API' that could be useful to build any object -page, block, node..- as structured data and then render it to HTML.
[Adrian just posted a longer version of this ...] yup. our form api lets modules collaboratively build a big nested array and then the API renders the array as HTML. it is a logical extension for our views to be rendered similarly (i.e. $node, profile, etc.).
On Wed, 2005-12-14 at 17:28 +0100, Jose A. Reyero wrote:
Bèr Kessels wrote:
Hi,
way too often i have to hack modules or even core (upload) to make it *not* append HTML to $node->body.
I think this practice of appending stuff to the body is very bad, since it makes it impossible to add thatdata elsewhere, without duplication.
Yep, I agree, same problem here
I think that teh best option is an additional variable in $node $node->extra containing structured data added by all the modules. $node->extra->upload could, for example contain that uplaod/attachement table, that is now hardcoded to the body.
I'm in full agreement. posted the same thing on the theme list. I think node->extra is probably a better name than the node->html i suggested, but still a little too abstract. Maybe node->rendered since we are talking about themed output whether its html, xhtml, rss, atom, or whatever.
First I would like to insist in that *all html* produced should be themeable.
About this specific issue, I think we could a) Just use themeable functions, that can be overridden, like a 'theme_upload_node_body' but, anyway, don't store it into node->body, but in node->output or similar b) Use that $node->extra->upload you propose but maybe better make it an array, $node->extra['upload'] so we can use a simple 'implode' at the end. Maybe weights could be useful here too
The ideal would be using both, themeable functions that produce structured data, but any of them used separately would just fix the problem. However, the way to go, thinking big, would be kind of 'generalized form API' that could be useful to build any object -page, block, node..- as structured data and then render it to HTML.
I dig this idea, but its not something that I seeing being plausable ASAP. The quick and dirty $node->extra can be done in the next day or two and modules can catch up as need be. There output appended to body will still be displayed, and the concatenated $node->extra can be appended to $content to emulate the current functionality. The we can look at weighting module's themed output through the UI at a later date or moving the functionality to be based on the forms api, which I'm starting to get the idea is more of a data model than a forms api.... Just need to agree on what to call this new output property and I'll try to a make an acceptable patch that is backwards compatible as far as themes are concerned... I'm guessing its probably just some touch ups on the default theme_node and theme engines. Then the modules can be incrementally updated. Should this be slated for 4.7 or 4.8... I personally consider modules altering node->body to be a bug, unless they're a filter module. .darrel.
On Wednesday 14 December 2005 12:38, Darrel O'Pry wrote:
I'm in full agreement. posted the same thing on the theme list. I think node->extra is probably a better name than the node->html i suggested, but still a little too abstract. Maybe node->rendered since we are talking about themed output whether its html, xhtml, rss, atom, or whatever.
What about three arrays: $node->before[] and $node->after[], to tell the themer that the added content is logically before or after the node body $node->extra[], to add content that has no specific sequential relation to the node Note that this is *not* intended to imply any particular placement on the page, but rather a relationship to the node having to do with the order in which the user should see the content. How the theme places it could be left-to-right (or the reverse, for some languages), top-to-bottom, on a diagonal, or ... whatever. In many themes, this may imply order of HTML emitted, but in other themes, it may relate to prominence (size and/or decoration) rather than strictly sequence. The behavior would be that each module can optionally add pre-themed content to $node->before[$module_name] (and so on), and the page theme would then insert the concatenation of these arrays in a place of its choosing. The before, after, and extra semantic is advisory to theme developers, not binding upon them. Default themes could take the simple course and simply prepend and append before[] and after[], respectively, and put extra[] in some reasonable place (maybe between the node body and after[]). Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
On Wed, 2005-12-14 at 16:00 -0500, Syscrusher wrote:
On Wednesday 14 December 2005 12:38, Darrel O'Pry wrote:
I'm in full agreement. posted the same thing on the theme list. I think node->extra is probably a better name than the node->html i suggested, but still a little too abstract. Maybe node->rendered since we are talking about themed output whether its html, xhtml, rss, atom, or whatever.
What about three arrays:
$node->before[] and $node->after[], to tell the themer that the added content is logically before or after the node body
$node->extra[], to add content that has no specific sequential relation to the node
Note that this is *not* intended to imply any particular placement on the page, but rather a relationship to the node having to do with the order in which the user should see the content. How the theme places it could be left-to-right (or the reverse, for some languages), top-to-bottom, on a diagonal, or ... whatever. In many themes, this may imply order of HTML emitted, but in other themes, it may relate to prominence (size and/or decoration) rather than strictly sequence.
The behavior would be that each module can optionally add pre-themed content to $node->before[$module_name] (and so on), and the page theme would then insert the concatenation of these arrays in a place of its choosing.
The before, after, and extra semantic is advisory to theme developers, not binding upon them. Default themes could take the simple course and simply prepend and append before[] and after[], respectively, and put extra[] in some reasonable place (maybe between the node body and after[]).
Scott
I've been testing a local branch using the snippet below.. ordering is important, and should be a ui option, but a simple before and after won't really suffice. I don't think the cms should have any set notions of where things belong. I think a more generic weighting would be more appropriate, maybe prepended to the key of $node->rendered... so a simple ksort of node->rendered or $value can handle the ordering... 0_nodevote, 1_node, 3_book it gets pretty easy to make them sortable... but making the key naming consistent and programmatic is what I need to figure out. in theme.inc: theme_node foreach($node->rendered as $key => $value) { $output .= is_array($value) ? join("\n", $value) : $value; } phptemplate.engine: phptemplate_node foreach($node->rendered as $key => $value) { $variable['content'] .= is_array($value) ? join("\n", $value) : $value; }
On Wednesday 14 December 2005 16:30, Darrel O'Pry wrote:
I don't think the cms should have any set notions of where things belong.
I agree with the notion that the CMS shouldn't have any set notion of where things belong *in page layout*, but I disagree when it comes to the content relationship. I'm currently working on the links_related module, which generates content that is a web equivalent to footnotes, in that it is not germane to the node body but rather provides links to further information. It is very unlikely that a web designer would think putting this before the content itself made any sense, because the links are probably meaningless until the viewer has at least skimmed the content. So yes, the content-generating module needs some way to "tell" the theme that it's doing something that's an appendix to the content, vs. something that introduces the content, vs. something that is not sequentially-related at all. I think your weighting thing sounds cool, and maybe could be adapted to handle what I suggest. But I have concerns about this:
0_nodevote, 1_node, 3_book it gets pretty easy to make them sortable... but making the key naming consistent and programmatic is what I need to figure out.
How does 05_abc sort relative to 5_xyz or 539_def or 57_ghi? If we're going to use true weighting, then instead of strings, let's follow Drupal convention and use true integer weighting. I like your ideal, Darrel, but let's take it to its fulfillment. Consider the following hypothetical array, where the order in which I show the sub-arrays represents a hypothetical order in which they are added by a hook invocation: $node->extra = array(); $node->extra[] = array( 'module'=>'example_module_1', 'weight'=>-1, 'value'=> "This is logically before the main node body, but probably " ."after other insertions." ); $node->extra[] = array( 'module'=>'example_module_2', 'weight'=>5, 'value'=> "This is a footnote-like item that logically follows the body." ); $node->extra[] = array( 'module'=>'example_module_3', 'weight'=>5, 'value'=> "Another footnote-like item." ); $node->extra[] = array( 'module'=>'example_module_4', 'weight'=>-10, 'value'=> "I want this to be seen as early as possible by the user." ); $node->extra[] = array( 'module'=>'example_module_5', 'weight'=>10, 'value'=> "This is something of little importance that is logically last." ); $node->extra[] = array( 'module'=>'example_module_6', 'weight'=>0, 'value'=> "It doesn't matter where on the page this renders." ); In practice, the order of rendering for these would be: I want this to be seen as early as possible by the user. This is logically before the main node body, but probably after other insertions. ($node->body) It doesn't matter where on the page this renders. This is a footnote-like item that logically follows the body. Another footnote-like item. This is something of little importance that is logically last. I'm betting that most existing modules append, rather than prepend, to $node->body, so the zero-weights probably ought to go after rather than before the body *in the default theme*. But a custom theme might render them beside the body, or watermarked under the body text, or in a popup window, or ... whatever. The hook could be robustly written so that implementing modules could return: * A simple string (themed HTML), in which case Drupal core wraps an array around it with a default weight of zero and the appropriate module name. Simple nodes that don't want to bother with the complex array can exploit this. * An array of strings, in which case Drupal core does the above for each one. * An array of arrays, in the $node->extra[] format, in which case Drupal core merges this array with what it's already built from other modules' return values. After the hook invocation, core needs to use PHP's user-defined sorting feature to sort the outer array by the weights of the inner arrays. Items that have the same weight can render in any order. Sidenote: The 'module' element of the subarrays is for debugging purposes mostly; Drupal core wouldn't necessarily need to enforce the presence of this element. But it does allow a theme to recognize and specially-handle the output of particular modules. I don't recommend that as a general rule for *published* themes, but if you're creating a theme for your own site... why not? :-) Even published themes might want to specially-handle module names that are part of Drupal core. Darrel, I like this merger of our ideas better than my original proposal. For one thing, it accomplishes with a single array what I did with three. The weight of zero is an elegant "I don't care" value, eliminating my $node-extra array's need. Your concept is more elegant than mine, and with the above adaptation, it encapsulates everything I wanted to incorporate as well, but with simpler semantics and with only one new hook. In effect, what I'm proposing is that $node->body intrinsically fits into this with an implied weight of zero, so that all the negative-value weights float "above" the body and all the positive-value weights sink "below". I quote the two relative positions to emphasize that it is up to the *theme* to decide what these mean. Modules get to ask for the relationship they want vis-a-vis the node body, and themes get to decide how that actually renders on the page. If there is interest in this concept, I'll volunteer to submit a patch to node.module. "Talk is silver, code is gold." :-) Scott -- ------------------------------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them scott@4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/scott.pubkey
Scott Courtney wrote:
If there is interest in this concept, I'll volunteer to submit a patch to node.module. "Talk is silver, code is gold." :-)
You have my vote - I like it. Its clear clean simple and flexible. One question $node-body will get an implied weight of zero - I assume that anything else with a weight of zero is still heavier than body of zero. andre ___________________________________________________________ NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/
On Wednesday 14 December 2005 20:50, andre wrote:
You have my vote - I like it. Its clear clean simple and flexible.
Thanks.
One question $node-body will get an implied weight of zero
Yes, but I was not planning to actually put $node->body into the new array. A lot of existing code, both core and contrib, relies on $node->body existing.
- I assume that anything else with a weight of zero is still heavier than body of zero.
Actually, I'd planned to do it the other way, based on the assumption that existing contributed modules tend, as a rule, to append rather than prepending. If there's a concensus that it should be as you describe, though, this is a negotiable point. Also, Darrel O'Pry wrote:
I would still like this modification to remain light, and I don't think it needs to implement a new hook, just some massaging of the existing theme code, and a UI..
I think I agree with this, but need to take a more detailed look at the code. The UI for designing things is beyond the scope of what I have time to do right now. I was just planning to provide the framework for node.module to handle the extra content. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
Op donderdag 15 december 2005 03:07, schreef Syscrusher:
Yes, but I was not planning to actually put $node->body into the new array. A lot of existing code, both core and contrib, relies on $node->body existing.
That was something I have been thinking about a lot too. If we watn to Do It Good [tm], body should be in the array too. And I think that backwards compatibility is not that bad. The changes required are simple search nad replace things. But.... If we go down that route, then this one little thingy will become a huge issue, holding down all development. So a -1 on the theoratically better $node->extra[] body. On another note, should we not use a better $node->data? Since we are no longer talking about an "extra" array, but about putting all data in a structured variable. Ber -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On Thursday 15 December 2005 07:29, Bèr Kessels wrote:
Op donderdag 15 december 2005 03:07, schreef Syscrusher:
Yes, but I was not planning to actually put $node->body into the new array. A lot of existing code, both core and contrib, relies on $node->body existing.
That was something I have been thinking about a lot too. If we watn to Do It Good [tm], body should be in the array too. And I think that backwards compatibility is not that bad. The changes required are simple search nad replace things.
But.... If we go down that route, then this one little thingy will become a huge issue, holding down all development. So a -1 on the theoratically better $node->extra[] body.
To clarify.... I meant, "$node->body shouldn't move into the new array *now*". What I've proposed as the add-on doesn't break anything that exists today, so existing modules can safely ignore the changes. I was thinking to move the node body in a future release, not this one.
On another note, should we not use a better $node->data? Since we are no longer talking about an "extra" array, but about putting all data in a structured variable.
What about $node->content, if we are thinking along those lines? Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
On Thursday 15 December 2005 11:20, Syscrusher wrote:
To clarify.... I meant, "$node->body shouldn't move into the new array *now*". What I've proposed as the add-on doesn't break anything that exists today, so existing modules can safely ignore the changes.
I was thinking to move the node body in a future release, not this one.
And in light of Adrian's comments about forms API, maybe the interim solution is to make a copy of $node->body into the array just before rendering, so that the forms API and the themes it calls can render the whole thing. This is starting to smell as if it just might work. :-) Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
From: Bèr Kessels <ber@webschuur.com>
On another note, should we not use a better $node->data? Since we are no longer talking about an "extra" array, but about putting all data in a structured variable.
+1 on structured data. Perhaps even just alias $node->data->body/main/foo to $node->body. Changes to a generic yet structured data would be fantastic for modules that analyze nodes (*ahem* machine learning *ahem*). -Mark
Op vrijdag 16 december 2005 20:11, schreef Mark Fredrickson:
Changes to a generic yet structured data would be fantastic for modules that analyze nodes (*ahem* machine learning *ahem*).
Guess what triggered this, with me? That recent discussion about AI, indeed. :) -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
How about forcing module developers to only append themed content to nodes during a hook_nodeapi view call. Problem solved. function mymodule_nodeapi(args){ switch($op){ case 'view': $stuff = get_stuff(); $stuff_i_want_in_node = theme('mymodule_theme_function', $stuff); $node->body .= $stuff_i_want_in_node; break; } } Then the theme developer can override whatever is appended/prepended to the node. andre Bèr Kessels wrote:
Hi,
way too often i have to hack modules or even core (upload) to make it *not* append HTML to $node->body.
I think this practice of appending stuff to the body is very bad, since it makes it impossible to add thatdata elsewhere, without duplication.
I think that teh best option is an additional variable in $node $node->extra containing structured data added by all the modules. $node->extra->upload could, for example contain that uplaod/attachement table, that is now hardcoded to the body.
In the very very end, the theme_node will iterate over all these ->extra 's and append them to teh body.
Now, the code, the patch, should not be too hard to make, its just a few lines to the theme_node functions
The hard part, imho is to convert **all** core modules to use this. and with All i mean all :). Taxononomy, for example, should add its terms in there, while book module should add its navigation.
The other thing is, that while this annoys me a huge lot, i just don't have time to get a patch going, untill at least end of Januari.
Waht do others think Bèr
PS: Im not to sure about tis crossposting thing, but there are loads of theme and developers issues; is it safe to assume that interested parties at least read development? (so that we can keep this on development)
___________________________________________________________ Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - http://santas-christmas-party.yahoo.net/
Andre, your solution is close to an ideal one, but still stuffers from body being appended to. I am not an expert in this area, but the idea is to provide both: 1. Discrete elements from modules as part of a node (this is the "extra" elements) 2. Ability to display them anywhere on the page (via theme_*() function). Perhaps ... function mymodule_nodeapi(&$node, ... args){ switch($op){ case 'view': $stuff = get_stuff(); $node->extra['mymodule']['element'] = theme('mymodule_theme_function', $stuff); break; } } The issue here is this is still missing a default way to display those extra things, and requires a custom addition to a theme. Someone else may think of a way to tie those two concepts. On 12/14/05, andre <mcsparkerton@yahoo.co.uk> wrote:
How about forcing module developers to only append themed content to nodes during a hook_nodeapi view call.
Problem solved.
function mymodule_nodeapi(args){
switch($op){ case 'view': $stuff = get_stuff(); $stuff_i_want_in_node = theme('mymodule_theme_function', $stuff);
$node->body .= $stuff_i_want_in_node; break; } }
Then the theme developer can override whatever is appended/prepended to the node.
andre
On Wed, 2005-12-14 at 12:27 -0500, Khalid B wrote:
Andre, your solution is close to an ideal one, but still stuffers from body being appended to.
I am not an expert in this area, but the idea is to provide both:
1. Discrete elements from modules as part of a node (this is the "extra" elements)
2. Ability to display them anywhere on the page (via theme_*() function).
Perhaps ...
function mymodule_nodeapi(&$node, ... args){
switch($op){ case 'view': $stuff = get_stuff(); $node->extra['mymodule']['element'] = theme('mymodule_theme_function', $stuff);
break; } }
The issue here is this is still missing a default way to display those extra things, and requires a custom addition to a theme.
Someone else may think of a way to tie those two concepts.
On 12/14/05, andre <mcsparkerton@yahoo.co.uk> wrote:
How about forcing module developers to only append themed content to nodes during a hook_nodeapi view call.
Problem solved.
function mymodule_nodeapi(args){
switch($op){ case 'view': $stuff = get_stuff(); $stuff_i_want_in_node = theme('mymodule_theme_function', $stuff);
$node->body .= $stuff_i_want_in_node; break; }
foreach ($node->extra as $key => $value) { if(is_array($value)) { $output .= join("\n",$value); } else { $output .= $value; } }
Op woensdag 14 december 2005 17:53, schreef andre:
switch($op){ case 'view': $stuff = get_stuff(); $stuff_i_want_in_node = theme('mymodule_theme_function', $stuff);
$node->body .= $stuff_i_want_in_node; break; } }
Then the theme developer can override whatever is appended/prepended to the node.
This happens now (most of the times) but is very inflexible. -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
Bèr Kessels wrote:
Waht do others think
Good idea.. for after 4.7 final is released. I'd like to see the extra property concept be where eveything is placed, including the node body. With a weight for each. Then provide a UI (not theme layer) for reweighting. And a UI for choosing different layouts (defined by the theme) which define regions (within the main content area, these are *not* block regions). If a non-default layout is chosen, the reweighting UI changes to a region choosing and reweighting UI. -- Neil Drumm http://delocalizedham.com/
Neil Drumm wrote:
And a UI for choosing different layouts (defined by the theme) which define regions (within the main content area, these are *not* block regions). If a non-default layout is chosen, the reweighting UI changes to a region choosing and reweighting UI.
No to the UI for this. Default rendering should be how the module developers intended - Themers should be able to clobber that for their own needs. There is no reason in the world why I would want a user then in turn to clobber the theme. I suppose a contributed module could provide this sort of UI $node content shuffling - but it shouldn't be in core. andre ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
andre wrote:
Neil Drumm wrote:
And a UI for choosing different layouts (defined by the theme) which define regions (within the main content area, these are *not* block regions). If a non-default layout is chosen, the reweighting UI changes to a region choosing and reweighting UI.
No to the UI for this.
Default rendering should be how the module developers intended - Themers should be able to clobber that for their own needs. There is no reason in the world why I would want a user then in turn to clobber the theme.
I suppose a contributed module could provide this sort of UI $node content shuffling - but it shouldn't be in core.
Just as blocks positioning is not hard coded into the theme, content positioning shouldn't be hard coded into the theme. The stuff that belongs in the theme, xhtml and css, stays in the theme as the code for page layouts. -- Neil Drumm http://delocalizedham.com/
Neil Drumm wrote:
No to the UI for this.
Default rendering should be how the module developers intended - Themers should be able to clobber that for their own needs. There is no reason in the world why I would want a user then in turn to clobber the theme.
I suppose a contributed module could provide this sort of UI $node content shuffling - but it shouldn't be in core.
Just as blocks positioning is not hard coded into the theme, content positioning shouldn't be hard coded into the theme. The stuff that belongs in the theme, xhtml and css, stays in the theme as the code for page layouts.
Actually - block positioning is very often 'hard coded' (I prefer the term 'modified') in the theme. Module and UI say position this block [say] right. Theme says - if block right toss it on the left hand side anyway - because that's where the design demands that it be. andre ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
andre wrote:
Module and UI say position this block [say] right. Theme says - if block right toss it on the left hand side anyway - because that's where the design demands that it be.
Then your theme shouldn't even offer a right sidebar block region. -- Neil Drumm http://delocalizedham.com/
On Wed, 2005-12-14 at 21:03 -0500, andre wrote:
Neil Drumm wrote:
And a UI for choosing different layouts (defined by the theme) which define regions (within the main content area, these are *not* block regions). If a non-default layout is chosen, the reweighting UI changes to a region choosing and reweighting UI.
No to the UI for this.
Default rendering should be how the module developers intended - Themers should be able to clobber that for their own needs. There is no reason in the world why I would want a user then in turn to clobber the theme.
I suppose a contributed module could provide this sort of UI $node content shuffling - but it shouldn't be in core.
andre
I think we're talking ui, as in admin ui... not necessarily exposing this to user who do not have 'administer theme weights' permission.
___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Darrel O'Pry wrote:
I suppose a contributed module could provide this sort of UI $node content shuffling - but it shouldn't be in core.
I think we're talking ui, as in admin ui... not necessarily exposing this to user who do not have 'administer theme weights' permission.
Yup - I assumed an Admin UI - Still don't think its a good idea ;-) At any rate - after reading Adrian's post it looks like this whole thread is a moot point as it turns out that Form API is a misnomer (much like the menu system - which only incidentally deals with 'menus' - the fapi only incidentally deals with 'forms' - whereas I thought it ONLY dealt with forms). andre ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
We are probably talking about different things, but all my nodes are themed by default based on the css file the taxonomy is using (taxonomy_theme.module)
Hi,
way too often i have to hack modules or even core (upload) to make it *not* append HTML to $node->body.
I think this practice of appending stuff to the body is very bad, since it makes it impossible to add thatdata elsewhere, without duplication.
I think that teh best option is an additional variable in $node $node->extra containing structured data added by all the modules. $node->extra->upload could, for example contain that uplaod/attachement table, that is now hardcoded to the body.
In the very very end, the theme_node will iterate over all these ->extra 's and append them to teh body.
Now, the code, the patch, should not be too hard to make, its just a few lines to the theme_node functions
The hard part, imho is to convert **all** core modules to use this. and with All i mean all :). Taxononomy, for example, should add its terms in there, while book module should add its navigation.
The other thing is, that while this annoys me a huge lot, i just don't have time to get a patch going, untill at least end of Januari.
Waht do others think Bèr
PS: Im not to sure about tis crossposting thing, but there are loads of theme and developers issues; is it safe to assume that interested parties at least read development? (so that we can keep this on development) -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
participants (20)
-
Adrian Rossouw -
andre -
Boris Mann -
Bèr Kessels -
Darrel O'Pry -
James Walker -
Jeff Eaton -
Jose A. Reyero -
Khalid B -
Mark Fredrickson -
Moshe Weitzman -
Nedjo Rogers -
Neil Drumm -
Richard Eriksson -
Robert Douglass -
Robin Monks -
Scott Courtney -
Syscrusher -
Trae McCombs -
VJ