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 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, 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/

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

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.

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

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 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 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

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

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

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

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; } }

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/

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/

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