Hello world, this is just a friendly note to let you know that it is less than 2 weeks until the code freeze (for real). I'm currently traveling, but I'll compile a detailed list of what I believe are important patches somewhere next week. In the mean time, the list mentioned in the last status update on drupal.org will do. At the top of my head are (no internet connection): 1. Various patches that improve performance and/or scalability. I'm specifically interested in (i) splitting SQL reads and writes and (ii) merging the node and node_comment_statistics tables. There are pending issues for both, spear-headed by David. There are other performance related patches too. 2. Various menu module fixes -- it's time to get these taken care of and to unleash teh chx and polowadin. ;) 3. Actions module patch that John is working on. I spent quite a bit of time reviewing this patch, as did Gabor and it is nearing completion. There is a couple of things we need to figure out still, but overall, it looks well on its way to get committed this week. 4. The module notification module that Derek and Earl are working on. 5. The node render patch that Eaton started work on a while ago. I don't think that is been committed yet, but Eaton recently reminded me about how important this is to further unify and clean-up the CCK and core. That should get us started! ;-) -- Dries Buytaert :: http://www.buytaert.net/
On Jun 20, 2007, at 11:36 AM, Dries Buytaert wrote:
4. The module notification module that Derek and Earl are working on.
For those who wish to help... a) Please test update_status 5.x-2.0-beta: http://drupal.org/node/153410 b) Please test the 2 patches I have in the queue: http://drupal.org/node/153502 (make it E_ALL compliant, for both 5.x and 6.x) http://drupal.org/node/153503 (porting to the 6.x API) c) After those land, I'll be working on making it a patch against system.module, instead of a stand-alone module (at Dries's request), but the issues in (b) are a first step. d) 2 other D6 issues are related to moving update_status into core: http://drupal.org/node/147000 ("unify module_rebuild_cache() and system_theme_data()") http://drupal.org/node/152926 ("Introduce hook_info_alter()") If someone wanted to work on patches for either/both of those, I'd be thrilled.
5. The node render patch that Eaton started work on a while ago. I don't think that is been committed yet, but Eaton recently reminded me about how important this is to further unify and clean- up the CCK and core.
Eaton and I spoke about this at length last week. We decided the next step for both node rendering and killing the evil $node namespace bugs I was ranting about earlier is to convert $node from an object into a #FAPI-style array. This is a huge undertaking, but will solve a *bunch* of issues and open up tons of new possibilities. I've been so busy with update_status that I haven't had a chance to work on the initial patch for this. If anyone else wants to get the ball rolling, that'd be great: http://drupal.org/node/148420 Cheers, -Derek (dww)
Derek Wright a ecrit le 21/06/2007 15:48:
5. The node render patch that Eaton started work on a while ago. I don't think that is been committed yet, but Eaton recently reminded me about how important this is to further unify and clean-up the CCK and core.
Eaton and I spoke about this at length last week. We decided the next step for both node rendering and killing the evil $node namespace bugs I was ranting about earlier is to convert $node from an object into a #FAPI-style array. This is a huge undertaking, but will solve a *bunch* of issues and open up tons of new possibilities. I've been so busy with update_status that I haven't had a chance to work on the initial patch for this. If anyone else wants to get the ball rolling, that'd be great: http://drupal.org/node/148420 As I said to Eaton on many occasions on IRC, I'd be really willing to help on this. I came to the same conclusion that $node refactoring was a prerequisite for a generic notion of fields for core. Unfortunately, I find myself with limited amount of spare time these few days (some site to drive live within the fortnight...). Do you think something is achievable within the 10 days before D6 freeze ?
On a related note, and _if_ D6 has to go out without Eaton's much awaited node rendering / nodes styles patches, I opened an issue to at least try to get a D6 workaround for node 'search index' rendering. Feedback welcome in http://drupal.org/node/152493 Last point : a few days ago I started some work on reviving killes' "block cache for core" patch in http://drupal.org/node/80951, with the intent of merging with jjeff's 'Block cache' contrib module (which works just great but suffers from painful usability issues mainly due to its being 'contrib'). This is semi-but-not-quite ready for public eye yet. I've been told one of the biggest points would be getting Dries acceptance :-), so I'd welcome even an informal 'go', or a hint that my time could be more useful somewhere else. Yched.
Derek Wright wrote:
5. The node render patch that Eaton started work on a while ago. I don't think that is been committed yet, but Eaton recently reminded me about how important this is to further unify and clean-up the CCK and core.
Eaton and I spoke about this at length last week. We decided the next step for both node rendering and killing the evil $node namespace bugs I was ranting about earlier is to convert $node from an object into a #FAPI-style array. This is a huge undertaking, but will solve a *bunch* of issues and open up tons of new possibilities. I've been so busy with update_status that I haven't had a chance to work on the initial patch for this. If anyone else wants to get the ball rolling, that'd be great: http://drupal.org/node/148420
After giving this some long thought, I think I'm basically against this idea. The FAPI-style array will give more accessibility to developers, but designers don't get FAPI and I fear that it's the wrong direction. I sent Eaton a proposal that he's not yet responded to (bad Eaton) but that I think works particularly well: The short version of the proposal goes like this: We create a hook (maybe hook_node_render($node_type)) that creates a list of theme functions that will be used to get output for the node. This is all inclusive and should get comments, taxonomy terms, pretty much anything that'll be attached to a node. We render this stuff in template_preprocess_node(). We use variable_set/variable_get to determine what variable in the array to put it in. We default this to 'content' -- meaning stuff that isn't set just gets appended to $content. This means our hook, above, does have to do a little work with weights. We provide sensible defaults for things like $terms, $links, and other node bits that are already separated out. We expose a UI to let the administrator modify what variable these items are placed in. This gives complete visibility to the designer layer. It also means we have completely perfect defaults. Themers don't have to mess with drupal_render() (which is a really difficult function to work with at the theme layer) and it becomes very easy to see everything that can go into a node. Moving it around is cake. I know Jeff has visions of something more complex that can do nesting, but I'm really very concerned about the complexity and opacity that this provides. Ask any non-developer themer what it's like to work with FAPI. Is this *really* the model we want to follow for node rendering?
Earl Miles schrieb:
Derek Wright wrote:
5. The node render patch that Eaton started work on a while ago. I don't think that is been committed yet, but Eaton recently reminded me about how important this is to further unify and clean-up the CCK and core.
Eaton and I spoke about this at length last week. We decided the next step for both node rendering and killing the evil $node namespace bugs I was ranting about earlier is to convert $node from an object into a #FAPI-style array. This is a huge undertaking, but will solve a *bunch* of issues and open up tons of new possibilities. I've been so busy with update_status that I haven't had a chance to work on the initial patch for this. If anyone else wants to get the ball rolling, that'd be great: http://drupal.org/node/148420
After giving this some long thought, I think I'm basically against this idea. The FAPI-style array will give more accessibility to developers, but designers don't get FAPI and I fear that it's the wrong direction.
I sent Eaton a proposal that he's not yet responded to (bad Eaton) but that I think works particularly well:
The short version of the proposal goes like this:
We create a hook (maybe hook_node_render($node_type)) that creates a list of theme functions that will be used to get output for the node. This is all inclusive and should get comments, taxonomy terms, pretty much anything that'll be attached to a node.
We render this stuff in template_preprocess_node(). We use variable_set/variable_get to determine what variable in the array to put it in. We default this to 'content' -- meaning stuff that isn't set just gets appended to $content. This means our hook, above, does have to do a little work with weights. We provide sensible defaults for things like $terms, $links, and other node bits that are already separated out.
We expose a UI to let the administrator modify what variable these items are placed in. This gives complete visibility to the designer layer. It also means we have completely perfect defaults. Themers don't have to mess with drupal_render() (which is a really difficult function to work with at the theme layer) and it becomes very easy to see everything that can go into a node. Moving it around is cake.
I know Jeff has visions of something more complex that can do nesting, but I'm really very concerned about the complexity and opacity that this provides. Ask any non-developer themer what it's like to work with FAPI. Is this *really* the model we want to follow for node rendering?
Hm - what about sticking to the FAPI-model (as it provides really a great level of flexibility, and consistency), and providing some really easy helper functions for designers? This came up in the node rendering thread. That would mean that we'd just pass a #fapi-style structured array into node.tpl.php. There, as a designer, in node.tpl.php, you could do things like: hide('links/readmore', $node); hide('comments', $node); And do show('attachments', $node) at the exact place where you want to display the (rendered) attachments. At the end of node.tpl.php, you'd then just put render($node) or something, which drupal_renders everything that is not hidden by hide() and not yet shown by show(). Under the hood, show('links/readmore', $node) would return drupal_render($node['links']['readmore']) and set $node['links']['readmore']['#rendered'] to true. hide() just sets #rendered to true for the element, which should then cause it to not be displayed by the final render() call (which is just a wrapper for drupal_render). They would of course all operate on $node by reference. This sounds like a solution that gives us lots of flexibilty for the developer's side, yet keeping this simple for designers. regards, frando
Frando (Franz Heinzmann) wrote:
Earl Miles schrieb:
Derek Wright wrote:
5. The node render patch that Eaton started work on a while ago. I don't think that is been committed yet, but Eaton recently reminded me about how important this is to further unify and clean-up the CCK and core.
Eaton and I spoke about this at length last week. We decided the next step for both node rendering and killing the evil $node namespace bugs I was ranting about earlier is to convert $node from an object into a #FAPI-style array. This is a huge undertaking, but will solve a *bunch* of issues and open up tons of new possibilities. I've been so busy with update_status that I haven't had a chance to work on the initial patch for this. If anyone else wants to get the ball rolling, that'd be great: http://drupal.org/node/148420
After giving this some long thought, I think I'm basically against this idea. The FAPI-style array will give more accessibility to developers, but designers don't get FAPI and I fear that it's the wrong direction.
I sent Eaton a proposal that he's not yet responded to (bad Eaton) but that I think works particularly well:
The short version of the proposal goes like this:
We create a hook (maybe hook_node_render($node_type)) that creates a list of theme functions that will be used to get output for the node. This is all inclusive and should get comments, taxonomy terms, pretty much anything that'll be attached to a node.
We render this stuff in template_preprocess_node(). We use variable_set/variable_get to determine what variable in the array to put it in. We default this to 'content' -- meaning stuff that isn't set just gets appended to $content. This means our hook, above, does have to do a little work with weights. We provide sensible defaults for things like $terms, $links, and other node bits that are already separated out.
We expose a UI to let the administrator modify what variable these items are placed in. This gives complete visibility to the designer layer. It also means we have completely perfect defaults. Themers don't have to mess with drupal_render() (which is a really difficult function to work with at the theme layer) and it becomes very easy to see everything that can go into a node. Moving it around is cake.
I know Jeff has visions of something more complex that can do nesting, but I'm really very concerned about the complexity and opacity that this provides. Ask any non-developer themer what it's like to work with FAPI. Is this *really* the model we want to follow for node rendering?
Hm - what about sticking to the FAPI-model (as it provides really a great level of flexibility, and consistency), and providing some really easy helper functions for designers? This came up in the node rendering thread.
That would mean that we'd just pass a #fapi-style structured array into node.tpl.php.
There, as a designer, in node.tpl.php, you could do things like: hide('links/readmore', $node); hide('comments', $node);
And do show('attachments', $node) at the exact place where you want to display the (rendered) attachments.
At the end of node.tpl.php, you'd then just put render($node) or something, which drupal_renders everything that is not hidden by hide() and not yet shown by show().
Under the hood, show('links/readmore', $node) would return drupal_render($node['links']['readmore']) and set $node['links']['readmore']['#rendered'] to true. hide() just sets #rendered to true for the element, which should then cause it to not be displayed by the final render() call (which is just a wrapper for drupal_render). They would of course all operate on $node by reference.
My primary issue with this is this: How do I know the name 'links/readmore' or 'comments'? Ok, so core has a few variables and they're documented. Now fivestar comes along and adds 'fivestar_voting_widget'. I have to search the module's documentation to find that? This is the real problem I'm trying to address here. Modules name this stuff and it's very difficult to find. This is especially true of FAPI which has lots of little widgets and gears and each form names things differently and figuring out what you want to tweak is simply difficult. Also, you have to worry about module naming collusions, which means you end up with extra long names. And calling functions in a .tpl.php is supposed to be something we discourage, not encourage.
On Jun 21, 2007, at 12:08 PM, Earl Miles wrote:
Now fivestar comes along and adds 'fivestar_voting_widget'. I have to search the module's documentation to find that?
This is the real problem I'm trying to address here. Modules name this stuff and it's very difficult to find. This is especially true of FAPI which has lots of little widgets and gears and each form names things differently and figuring out what you want to tweak is simply difficult.
That's actually one of the primary reasons I advocate using Drupal rendering systems. We face the same problems when rendering a form -- how can my themed form include fields that other modules altered in? I don't know what they are! Right now, the node theming problem is the all-or-nothing approach. You print out $content, or you abandon it and start slinging around individual node properties yourself. It's essential that themers be able to say, 'Pull this piece out -- I know it's there. And this piece, too. Stick those over here in a span. Now, print everything else that's left over in this div.' Drupal's rendering system -- in addition to capturing lots of rich metadata, etc -- gives us that for free. Render $node['content'] in one div, $node['info'] in another, and $node['comments'] in a third... or just pull out $node['links'], then printing all of $node to pick up whatever is left over. --Jeff
Derek Wright wrote:
5. The node render patch that Eaton started work on a while ago. I don't think that is been committed yet, but Eaton recently reminded me about how important this is to further unify and clean-up the CCK and core.
Eaton and I spoke about this at length last week. We decided the next step for both node rendering and killing the evil $node namespace bugs I was ranting about earlier is to convert $node from an object into a #FAPI-style array. This is a huge undertaking, but will solve a *bunch* of issues and open up tons of new possibilities. I've been so busy with update_status that I haven't had a chance to work on the initial patch for this. If anyone else wants to get the ball rolling, that'd be great: http://drupal.org/node/148420
I think this would be a bad idea, too. $nodes should be ultra-clean representations of data. I often digest several form widgets to a single item in the $node and perform a corresponding expansion to allow the user to edit the node again. If any simplification is to be had, it would be working with node data in five hooks: * Load $node from DB * Render $node * Convert $node to FAPI * Convert FAPI to $node * Save $node to DB The only way I'd go for a FAPI-based $node is if we have a really clean system for modules creating custom controls: $form['complex_option'] = array( '#type' => 'module_control_callback', ... ); function module_control_callback(Contents of $form['complex_option']) { $form['yes_no'] = array( '#type' => 'checkbox', '#title' => 'Custom etching', ... ); $form['text'] = array( '#type' => 'textfield', '#title' => 'Custom etching text', ... ); // FAPI prefixes the items returned here to control the namespace return $form; } function module_control_callback_validate(Form state within namespace) { // Return an error if "Custom etching" is checked // but the text is empty } function module_control_callback_submit(Form state within namespace) { // Returns NULL if "Custom etching" is unchecked or the text // from "Custom etching text" return $value_from_control; } It'd basically be a recursive Form API, but it would allow easy control reuse, validation, and digestion.
On Jun 21, 2007, at 12:50 PM, David Strauss wrote:
The only way I'd go for a FAPI-based $node is if we have a really clean system for modules creating custom controls...
I'd like to jump in quickly and note that it's CRITICAL to distinguish between two thing: 1) FormAPI 2) #prefixed arrays storing structured data The former is *only to be used for forms*. It is a complete workflow model and set of explicit callbacks. The latter is a *data format with provisions for complex structured information*. It is something we can use to capture and represent lots of stuff, and solve lots of problems very cleanly. One of the primary benefits of this format is that it can be altered via hooks VERY easily, it can capture hierarchies very cleanly, and it can be rendered in bits using drupal_render() and our theming system very easily. node_load() can build the node itself in a #prefixed array structure to solve the problem of namespace collisions, and never touch FAPI. node_view() can build a #prefixed array structure in order to leverage the rendering and altering functions, but never touch FAPI. There are also 'middle ground' solutions -- node_load() could build a #prefixed structure that can be passed to drupal_render() directly, and node_load() could be responsible for adding to and altering that structure in different display contexts. This approach has a lot of potential upsides; flagging specific fields as 'indexable' is one example. --Jeff
I also disagree with FAPI. I know how hard that'll be for a non-PHP developer to use when themeing a site. Robin On 6/21/07, David Strauss <david@fourkitchens.com> wrote:
Derek Wright wrote:
5. The node render patch that Eaton started work on a while ago. I don't think that is been committed yet, but Eaton recently reminded me about how important this is to further unify and clean-up the CCK and core.
Eaton and I spoke about this at length last week. We decided the next step for both node rendering and killing the evil $node namespace bugs I was ranting about earlier is to convert $node from an object into a #FAPI-style array. This is a huge undertaking, but will solve a *bunch* of issues and open up tons of new possibilities. I've been so busy with update_status that I haven't had a chance to work on the initial patch for this. If anyone else wants to get the ball rolling, that'd be great: http://drupal.org/node/148420
-- Robin Monks @ www.civicspacelabs.org @ www.gmking.org Fax: (419) 791-8076 "Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems." ~IRC
Please (re-)read Jeff's post above. # prefixed arrays are not FAPI., and match quite precisely what we are trying to achieve here, so let's not ditch the idea out of miscunception :-) Robin Monks a ecrit le 21/06/2007 20:50:
I also disagree with FAPI. I know how hard that'll be for a non-PHP developer to use when themeing a site.
Robin
Can we get some examples of how it might be used by a themer? Robin On 6/21/07, Yves Chedemois <yched.drupal@free.fr> wrote:
Please (re-)read Jeff's post above. # prefixed arrays are not FAPI., and match quite precisely what we are trying to achieve here, so let's not ditch the idea out of miscunception :-)
Robin Monks a ecrit le 21/06/2007 20:50:
I also disagree with FAPI. I know how hard that'll be for a non-PHP developer to use when themeing a site.
Robin
-- Robin Monks @ www.civicspacelabs.org @ www.gmking.org Fax: (419) 791-8076 "Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems." ~IRC
Robin Monks schrieb:
Can we get some examples of how it might be used by a themer?
Robin
Please see the message I posted a few hours ago. Right now, working with #structured arrays is not yet "super-easy", however, it'll be quite simple to add a few helper functions, namely show(), hide() and render(), to make it "super-easy". The big problem with node rendering IMO is, that a) we want to give themers complete and simple control over how and where stuff is displayed and b) we want to give module developers the chance to insert their stuff into the nodes. With structured arrays and these few helper functions we can achieve exactly that. By default, render($node) or something like that would render all children, one by one below the other. However, all elements that are printed elsewhere would be excluded from that, as would be all elements hidden via hide(). As I said, see my last mail for another description. Regards, frando P.S. I actually just took a little first step at these functions. They are already basially working nicely .. function hide($path, &$object) { $e =& move_to_path($path, $object); $e['#printed'] = TRUE; } function show($path, &$object, $return = FALSE) { $e =& move_to_path($path, $object); $e['#printed'] = FALSE; if ($return) { return drupal_render($e); } print drupal_render($e); } function render(&$object, $return = FALSE) { if ($return) { return drupal_render($object); } print drupal_render($object); } function &move_to_path($path, &$object) { $e = &$object; $path = explode('/', $path); foreach ($path as $segment) { $e = &$e[$segment]; } return $e; }
On 6/21/07, *Yves Chedemois* <yched.drupal@free.fr <mailto:yched.drupal@free.fr>> wrote:
Please (re-)read Jeff's post above. # prefixed arrays are not FAPI., and match quite precisely what we are trying to achieve here, so let's not ditch the idea out of miscunception :-)
Robin Monks a ecrit le 21/06/2007 20:50: > I also disagree with FAPI. I know how hard that'll be for a non-PHP > developer to use when themeing a site. > > Robin >
-- Robin Monks @ www.civicspacelabs.org <http://www.civicspacelabs.org> @ www.gmking.org <http://www.gmking.org>
Fax: (419) 791-8076
"Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems." ~IRC
On Jun 21, 2007, at 2:50 PM, Robin Monks wrote:
I also disagree with FAPI. I know how hard that'll be for a non- PHP developer to use when themeing a site... ... Can we get some examples of how it might be used by a themer?
For example: <span class="my_field"><?php print check_format($node->content ['field_details'][0]['value'], $node->content['field_details'][0] ['format']) ?></span> Vs. <span class="my_field"><?php print drupal_render($node['details']) ?
</span>
The latter is what we do now when we need something more granular than the $content variable. The latter is what a cleanly renderable node would give us. --Jeff
I should've forked this on my original post. I apologize for not doing that, and request everyone reply to this thread instead. Jeff Eaton wrote:
On Jun 21, 2007, at 2:50 PM, Robin Monks wrote:
I also disagree with FAPI. I know how hard that'll be for a non-PHP developer to use when themeing a site... ... Can we get some examples of how it might be used by a themer?
For example:
<span class="my_field"><?php print check_format($node->content['field_details'][0]['value'], $node->content['field_details'][0]['format']) ?></span>
Vs.
<span class="my_field"><?php print drupal_render($node['details']) ?></span>
The latter is what we do now when we need something more granular than the $content variable. The latter is what a cleanly renderable node would give us.
--Jeff
Vs, with my proposal: [assuming I've set the CCK field 'myfield' to show up in the $my_field variable in the theoretical UI that will exist for this] <span class="my_field"><?php print $my_field;?></span>
oh, that's exciting too. +1 on that too... :-! aaron Earl Miles wrote:
Vs, with my proposal:
[assuming I've set the CCK field 'myfield' to show up in the $my_field variable in the theoretical UI that will exist for this]
<span class="my_field"><?php print $my_field;?></span>
On 21 Jun 2007, at 21:30, Aaron Winborn wrote:
oh, that's exciting too. +1 on that too... :-!
These kind of comments are not really helpful. We're trying to fix an architectural problem in this thread. -- Dries Buytaert :: http://www.buytaert.net/
Vs, with my proposal:
[assuming I've set the CCK field 'myfield' to show up in the $my_field
variable in the theoretical UI that will exist for this]
<span class="my_field"><?php print $my_field;?></span>
There's little question about which is easier. One is fairly intuitive and whereas the other is not so much. The 'former way' would *definitely* need a print_r / var_dump to figure out (something beyond what most designers can/want-to grok), whereas the way Earl cited (above) would not require that for all but the_most_clueless_users. - Caleb
Earl's right. Replies in this thread help keep the code freeze discussion from getting cluttered. Thanks! --Jeff On Jun 21, 2007, at 3:25 PM, Earl Miles wrote:
I should've forked this on my original post. I apologize for not doing that, and request everyone reply to this thread instead.
+infinity for this. I really feel like template files should only have straight variables and simple logic.
Vs, with my proposal:
[assuming I've set the CCK field 'myfield' to show up in the $my_field variable in the theoretical UI that will exist for this]
<span class="my_field"><?php print $my_field;?></span>
____________________________________________________________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/
On 21 Jun 2007, at 11:23 PM, Farsheed wrote:
+infinity for this. I really feel like template files should only have straight variables and simple logic.
In drupal 5 parlance (not really sure how drupal 6 does it yet) : $vars = $node; array_walk($vars, "drupal_render"); return _phptemplate_callback("node", array("node" => $node) + $vars); I am 100% against you needing to use an interface to assign variable names, because it makes node template un-distributable, without distributing the additional configuration too. Also, I don't think a drupal_render call over and above the already existing print call is too much to ask, because quite frankly we are already going to be requiring it for localisation (ie: print t("Some text") ). Also. there's a difference between themers , and end users. Requiring an interface to be able to assign variables is going to help the latter, but not the former. It's going to make their life more complicated. What I really think we should do, if we want to make an interface for the latter, is make a proper version of the contemplate module, using the token replacement code (ie: use %my_field) in the text editor to place field, with a list of possible tokens. That then translates to <? print drupal_render($node['my_field']);?> in the final template file it uses.
I am 100% against you needing to use an interface to assign variable names, because it makes node template un-distributable, without distributing the additional configuration too.
True, but I also don't think it's super easy for themers to rename or assign variables. What happens is that themers inevitably have to figure out what drupal is sending them - and it's annoying having to print_r just to understand what kind of output you are getting. I think a UI is a great idea. And I also think it's important for configurations to stay in the theme. Maybe theme configurations could be written to a special file by the UI and shipped with the theme instead of stored in the database. That way all the configurations are in one place and end users and themers can both modify it either in a UI or by hand. ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/
On Thu, 2007-06-21 at 18:32 -0700, Farsheed wrote:
I am 100% against you needing to use an interface to assign variable names, because it makes node template un-distributable, without distributing the additional configuration too.
True, but I also don't think it's super easy for themers to rename or assign variables. What happens is that themers inevitably have to figure out what drupal is sending them - and it's annoying having to print_r just to understand what kind of output you are getting.
I think a UI is a great idea. And I also think it's important for configurations to stay in the theme. Maybe theme configurations could be written to a special file by the UI and shipped with the theme instead of stored in the database. That way all the configurations are in one place and end users and themers can both modify it either in a UI or by hand.
Ugh! is it really that hard to print_r($node) in your theme during development when you're looking for a var? I personally think the print_r(object structure) is much easier to deal with than having to get_defined_vars, which is normally a big interesting mess. And both are easier when I'm editing a file than make a couple click through my website to find the right admin ui and variable interface, then having one more window I have to switch to regularly.
On 04 Jul 2007, at 12:36 AM, Darrel O'Pry wrote:
And both are easier when I'm editing a file than make a couple click through my website to find the right admin ui and variable interface, then having one more window I have to switch to regularly.
Also, calling the field one thing in the cck admin , and then another thing in yet another admin section. Seems rather superfluous.
Ugh! is it really that hard to print_r($node) in your theme during development when you're looking for a var?
I personally think the print_r(object structure) is much easier to deal with than having to get_defined_vars, which is normally a big interesting mess.
Print_r is a fine way to see what variables are *available*. How to assign or create new variables and make that data available to the theme is an entirely separate and more complicated issue. And that involves knowing what is literally available from drupal to assign. It often leads to having to code dive into someone elses module to figure out how to get the information you need to print out. A UI could help the themer have access to more data from other parts of Drupal and format it the way they want. I think saying that print_r solves the problem is oversimplifying the issue. We should think about this some more. ____________________________________________________________________________________ Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather
Alternately, we can simply instruct people to build their presentation data drupal_render()able structures, then pass them on to the theming layer, where the are collapsed into strings or exposed as complex structures depending on the application. Drupal has too many nooks and crannies were the same data is stored and accessed in completely, counter-intuitively different ways. Layering another vocabulary, another set of mapped variables, another slice of metaphor and abastraction, on top of the current models is not IMO a solution. That's one of the reasons that I think any real solution will overlap with the node object's internal structure, our APIs for outputting different formats (JSON, XML, HTML, etc) as well as our rendering and theming systems. Our goal must be to make the system more consistent and flexible, to eliminate special cases and edge-case exceptions. --Jeff On Jul 4, 2007, at 10:05 AM, Farsheed wrote:
Print_r is a fine way to see what variables are *available*. How to assign or create new variables and make that data available to the theme is an entirely separate and more complicated issue. And that involves knowing what is literally available from drupal to assign. It often leads to having to code dive into someone elses module to figure out how to get the information you need to print out.
On Wed, 2007-07-04 at 08:05 -0700, Farsheed wrote:
Ugh! is it really that hard to print_r($node) in your theme during development when you're looking for a var?
I personally think the print_r(object structure) is much easier to deal with than having to get_defined_vars, which is normally a big interesting mess.
Print_r is a fine way to see what variables are *available*. How to assign or create new variables and make that data available to the theme is an entirely separate and more complicated issue. And that involves knowing what is literally available from drupal to assign. It often leads to having to code dive into someone elses module to figure out how to get the information you need to print out.
A UI could help the themer have access to more data from other parts of Drupal and format it the way they want.
I think saying that print_r solves the problem is oversimplifying the issue. We should think about this some more.
The issue is node rendering with drupal_render or and additional api for node data to be renamed to specific variable names for themes. I think print_r is a perfectly acceptable solution, you can look at the variables hook in your template.php. this isn't to be confused with more general issue about getting more data into the theme layer from nodes, or how do access data that isn't exposed to the theme layer, dynamic layouts, etc. Much of which the renderingAPI can accomplish. There are some really cool things in CCK such as field groups that provide a basic demonstration of how the layout can be manipulated through a UI, and CCK's handlers which can be translated to the renderAPI via the #theme or as a custom element type. Rendering more content using drupal_render give us more access to manipulate the output through _alter and #whatever callbacks we choose to create in the rendering pipeline. The problem with drupal_render currently is we're limiting it to generating node bodies. This is a highly nestable API... I'm not sure why we aren't rendering pages using this as a starting point and having new renderAPI element type like 'page', 'section', 'block', 'container', 'node'... I know we all probably think of this as FormAPI at the moment, but formAPI is the renderAPI with some form processing specifics built on top of it. FormAPI is a misnomer, and some people quip about it being the everything api. The really awesome part of formAPI that makes it so flexible is the rendering API it is built on top of. The nested processing with override-able callbacks, and the build abstraction / inspect abstraction / process abstraction / render abstraction processing phases. This makes the core of it highly adaptable and extensible. DataAPI will be build on top of the same general process I assume. I'm not sure if I have the proper diction to describe what I'm calling the renderAPI, if you have better words or better explanations I'd love to learn them. I need to see something really elegant and usable to convince me that there is any reason to focus my energy on building a new platform for abstraction, instead of maturing the ones we have.
The problem with drupal_render
currently is we're limiting it to generating node bodies. This is a highly nestable API... I'm not sure why we aren't rendering pages using this as a starting point and having new renderAPI element type like 'page', 'section', 'block', 'container', 'node'...
in drupal6, user profiles are printed via drupal_render(). and unlike nodes, this call comes right in the .tpl.php file. see user_profile.tpl.php in /modules/user
I know we all probably think of this as FormAPI at the moment, but formAPI is the renderAPI with some form processing specifics built on top of it.
i think many people now understand this distinction. it took us a while, but we are leaving that confusion behind ...
On Wed, 2007-07-04 at 20:05 -0400, Moshe Weitzman wrote:
The problem with drupal_render
currently is we're limiting it to generating node bodies. This is a highly nestable API... I'm not sure why we aren't rendering pages using this as a starting point and having new renderAPI element type like 'page', 'section', 'block', 'container', 'node'...
in drupal6, user profiles are printed via drupal_render(). and unlike nodes, this call comes right in the .tpl.php file. see user_profile.tpl.php in /modules/user
Oooh. I gotta go look at that and the schema stuff that got added as well.
I know we all probably think of this as FormAPI at the moment, but formAPI is the renderAPI with some form processing specifics built on top of it.
i think many people now understand this distinction. it took us a while, but we are leaving that confusion behind ...
/me stops sounding like a broken record...
Darrel O'Pry wrote:
Much of which the renderingAPI can accomplish. There are some really cool things in CCK such as field groups that provide a basic demonstration of how the layout can be manipulated through a UI, and CCK's handlers which can be translated to the renderAPI via the #theme or as a custom element type.
Rendering more content using drupal_render give us more access to manipulate the output through _alter and #whatever callbacks we choose to create in the rendering pipeline. The problem with drupal_render currently is we're limiting it to generating node bodies. This is a highly nestable API... I'm not sure why we aren't rendering pages using this as a starting point and having new renderAPI element type like 'page', 'section', 'block', 'container', 'node'...
What's interesting is that in my vision, CCK's UI basically goes away, replaced by a more global one. CCK just ends up adding stuff to that UI. And I still have my doubts that the drupal_render() stuff will be transparent enough for themers to use. I worry, very strongly, that this path is going to make it so that only developers can theme nodes.
On Wed, 2007-07-04 at 22:12 -0700, Earl Miles wrote:
Darrel O'Pry wrote:
Much of which the renderingAPI can accomplish. There are some really cool things in CCK such as field groups that provide a basic demonstration of how the layout can be manipulated through a UI, and CCK's handlers which can be translated to the renderAPI via the #theme or as a custom element type.
Rendering more content using drupal_render give us more access to manipulate the output through _alter and #whatever callbacks we choose to create in the rendering pipeline. The problem with drupal_render currently is we're limiting it to generating node bodies. This is a highly nestable API... I'm not sure why we aren't rendering pages using this as a starting point and having new renderAPI element type like 'page', 'section', 'block', 'container', 'node'...
What's interesting is that in my vision, CCK's UI basically goes away, replaced by a more global one. CCK just ends up adding stuff to that UI.
And I still have my doubts that the drupal_render() stuff will be transparent enough for themers to use. I worry, very strongly, that this path is going to make it so that only developers can theme nodes.
I totally agree with your view point on CCK's display fields tab, and the field_group module. They're only remedial examples of what is possibly and should have a scope much wider than CCK. I just feel that you approach tends to cater to designers that think of design in a page by page manner, instead of a collection of widgets with many potential layouts. Then again I may be completely mis-understanding your idea, after all you did do that panels thang :). There are also technical merits to drupal_render that I wouldn't want to see lost... the most important one for me is the potential for caching Creating a central pipe line for the processing means we have a single point of focus for caching based optimizations and process improvements. Personally, I'd like to see it become capable of caching branches in the render array tree in various states including built abstraction, altered abstraction, processed abstraction, rendered abstraction. It at least seems like it would be fun to experiment with. Since the DataAPI and FormAPI extend the model, they too would probably benefit over time as we gain more expertise with it.
Darrel O'Pry wrote:
And I still have my doubts that the drupal_render() stuff will be transparent enough for themers to use. I worry, very strongly, that this path is going to make it so that only developers can theme nodes.
I totally agree with your view point on CCK's display fields tab, and the field_group module. They're only remedial examples of what is possibly and should have a scope much wider than CCK.
I just feel that you approach tends to cater to designers that think of design in a page by page manner, instead of a collection of widgets with many potential layouts. Then again I may be completely mis-understanding your idea, after all you did do that panels thang :).
That's interesting. I'm not sure how that really follows, though; but since thinking about it this way may help, I think of the UI as CCK's field-ordering/grouping UI except with *Everything* in it, not just CCK fields. I don't immediately see how that caters to not having many potential layouts; the easieast way to do that is to put everything into named variables and then do those potential layouts.
There are also technical merits to drupal_render that I wouldn't want to see lost... the most important one for me is the potential for caching Creating a central pipe line for the processing means we have a single point of focus for caching based optimizations and process improvements.
I'm not sure they'd be lost; I think they'd be moved up to happening much earlier in the process, perhaps. Then again, perhaps they would be, since their internal name mapping would disappear (as it becomes unnecessary).
Personally, I'd like to see it become capable of caching branches in the render array tree in various states including built abstraction, altered abstraction, processed abstraction, rendered abstraction. It at least seems like it would be fun to experiment with.
Repeat that sentence to a designer. =)
On Jul 5, 2007, at 11:19 AM, Earl Miles wrote:
That's interesting. I'm not sure how that really follows, though; but since thinking about it this way may help, I think of the UI as CCK's field-ordering/grouping UI except with *Everything* in it, not just CCK fields.
My concern is that any given design will become a combination of database configuration information AND a custom tpl.php file. Any non- trivial design changes would require admin configuration changes, then edits to the tpl.php file, with great care taken to keep custom variable names, etc in sync. I support the idea of passing on a consistent, structured array to these tpl.php files by default, and giving designers a simple output () style function that prints strings, AND renders/prints drupal structures. output($profile) would print out the whole kit and kaboodle. output($profile['personal']) would output just the personal information. output($profile['personal'][1]) would print out the first item, and so on and so forth. That gives us the ability to: 1) use variable overrides to pre-render the structure into flattened strings if we absolutely don't want themers seeing anything but print(). 2) pass on the full structure an allow them to use simple syntax to print out various chunks of a node, a profile, etc. without keeping additional configuration information in sync 3) give advanced designers the ability to use familiar CSS3 syntax to manipulate the structure itself, using fQuery. Rendering all elements that match certain critiera, etc. This may be considered 'fluff', but it's a way to give designers a much smoother transition from 'simple templates' to 'complex' ones without just throwing them into the pit and telling them to learn to iterate over nested arrays.
I don't immediately see how that caters to not having many potential layouts; the easieast way to do that is to put everything into named variables and then do those potential layouts.
I agree. I just think that those named variables should contain renderable structures, so that it's easy to drill down and print sub- elements without going back to the configuration screen and re- tweaking all the 'mappings'.
Print_r is a fine way to see what variables are *available*. How to assign or create new variables and make that data available to the theme is an entirely separate and more complicated issue. And that involves knowing what is literally available from drupal to assign. It often leads to having to code dive into someone elses module to figure out how to get the information you need to print out.
I think the problem is more that modules do not append enough informations to node. If the informations were available somewhere inside the node data array, there would be no need to look at the module sources. In order to know what is missing for themers, maybe we could ask them what they *really* need. imho, what is complicated at the moment when doing a drupal theme, is the number of layers involved. You can create theme functions that return html (theme hooks), use an UI to define which fields are shown (contemplate and others), add some logic to your template, use module hooks... Often you don't understand where data is coming from. I'd keep the existing sytem which returns a fully rendered node body for beginners and provide a super detailed array for advanced use. By super detailed array, I mean something like this : (hypothetical book node type with an image cover) $node->data['title'] $node->data['title']['label'] (as entered in the content type definition UI) $node->data['body'] $node->data['body']['label'] $node->data['body']['filtered'] $node->data['body']['text'] $node->data['teaser'] $node->data['author'] $node->data['author']['label'] $node->data['author']['id'] $node->data['author']['link'] $node->data['author']['link']['contact_page'] $node->data['author']['link']['profile_page'] $node->data['author']['username'] $node->data['author']['avatar'] $node->data['links']['comments']['label'] $node->data['links']['comments']['link'] $node->data['links']['send']['label'] (added by send to a friend module) $node->data['links']['send']['link'] $node->data['cck']['cover'] (a custom image cck field) $node->data['cck']['cover'][0]['title'] $node->data['cck']['cover'][0]['path'] $node->data['cck']['cover'][0]['label'] $node->data['cck']['cover'][0]['width'] $node->data['cck']['cover'][0]['height'] $node->data['cck']['cover'][0]['filesize'] $node->data['cck']['cover'][0]['imagecache']['thumbnail'] (imagecache profiles) $node->data['cck']['cover'][0]['imagecache']['big'] [...] If all the content "parts" are available, there is no need to use a UI. A "themer" module could be created. It would explain what php snippet must be used to print something inside a node template (ala devel module). At the end of the day, themers need to do a few things in their templates : - check if a variable exists : isset - loop over an array : foreach - branch when apropriate : if - print something : print No UI will avoid this kind of stuff. A competent themer need to know and understand those php constructs. The beginner can use CSS + Drupal administration to do basic theming. my 0.02 Philippe
A UI could help the themer have access to more data from other parts of Drupal and format it the way they want.
I think saying that print_r solves the problem is oversimplifying the issue. We should think about this some more.
On 21 Jun 2007, at 9:25 PM, Earl Miles wrote:
[assuming I've set the CCK field 'myfield' to show up in the $my_field variable in the theoretical UI that will exist for this]
I'm against requiring a UI to do anything of the sort. It should just happen. The variable shouldn't sometime be called one thing, and sometime called something else.
On Thursday 21 June 2007, adrian rossouw wrote:
On 21 Jun 2007, at 9:25 PM, Earl Miles wrote:
[assuming I've set the CCK field 'myfield' to show up in the $my_field variable in the theoretical UI that will exist for this]
I'm against requiring a UI to do anything of the sort. It should just happen.
The variable shouldn't sometime be called one thing, and sometime called something else.
Let me give a few real world examples of what my themers keep asking my help to do. node 5, of type foo, has a multi-value cck field called bar and another baz, and non-multi-value cck fields gah and ugh. It also has a value that's been added to the node directly by some custom module that we also want. "I want fields bar, baz, baz, and baz to show in a table. If they're multi-value, then bar should be comma-separted but baz should be <br /> delimited, and oh yeah any of those could have no value in which case that row shouldn't appear." What I do now is tell them to go away while I do muck about with arrays, implode, and theme('table') inside a phptemplate_ function and then feed them a single final variable into the template that they can't control. They can handle "just use $node->content['foo'][0] and go away" just fine. I don't think they'd care between that and "just use show('foo', 0) and go away". Anything more complex than that always gets given to me anyway. Nothing against my themers, mind you. They're all smart cookies and very good at what they do, but I just had to talk one of them through the l() function today. (Yes, we had one in a template file. It was necessary.) I really wonder what the use case for any of these complex template file setups is, when even a multi-value CCK text field scares them away because they'd have to use implode() (what's that?). If you (collectively) can give me a way to let my themers do that sort of setup without actually having me do it instead, I'll sit up and take notice. Otherwise, I really don't see what we're accomplishing. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Jeff Eaton wrote:
On Jun 21, 2007, at 12:50 PM, David Strauss wrote:
The only way I'd go for a FAPI-based $node is if we have a really clean system for modules creating custom controls...
I'd like to jump in quickly and note that it's CRITICAL to distinguish between two thing:
1) FormAPI 2) #prefixed arrays storing structured data
The former is *only to be used for forms*. It is a complete workflow model and set of explicit callbacks.
The latter is a *data format with provisions for complex structured information*. It is something we can use to capture and represent lots of stuff, and solve lots of problems very cleanly. One of the primary benefits of this format is that it can be altered via hooks VERY easily, it can capture hierarchies very cleanly, and it can be rendered in bits using drupal_render() and our theming system very easily.
node_load() can build the node itself in a #prefixed array structure to solve the problem of namespace collisions, and never touch FAPI. node_view() can build a #prefixed array structure in order to leverage the rendering and altering functions, but never touch FAPI.
There are also 'middle ground' solutions -- node_load() could build a #prefixed structure that can be passed to drupal_render() directly, and node_load() could be responsible for adding to and altering that structure in different display contexts. This approach has a lot of potential upsides; flagging specific fields as 'indexable' is one example.
--Jeff
If the drupal_render on a node is made possible, would you be able insert, say, a form somewhere in the tree and have it render? Would you be able to nest additional nodes in the tree? Would you be able to insert parts of the node under a fapi fieldset elements? Bear in mind, I'm not thinking about the ramifications on theming, more I'm interested in where we see drupal_render going.
It would be perfectly possible to *render* a form in that fashion, but unless you called drupal_get_form() it would not actually enter the full form lifecycle. In fact this is already possible using Drupal 5's infrastructure. Try this in your hook_nodeapi op view: $node->content['my_thing'] = array( '#type' => 'fieldset', '#title' => t('Test fieldset'), '#collapsible' => TRUE, '#collapsed' => FALSE, ); $node->content['my_thing']['content'] = array( '#value' => 'Test content goes here...', ); It will add a collapsible fieldset to your view containing static content. renderable elements are renderable elements. Form elements just render into <input> tags and so on. FormAPI adds additional behavior on top of that, but under the hood, the rendering infrastructure is a way of taking a metadata rich array structure and rendering it into raw HTML (or JSON, or XML, if you feel like layering a new set of theme functions onto it.) It is a tremendously powerful system. We shouldn't jump into using it unawares, but we would also be missing a huge opportunity to pass up this system of storing meta-data rich structures and renderable content. --Jeff On Jun 21, 2007, at 6:16 PM, sime wrote:
If the drupal_render on a node is made possible, would you be able insert, say, a form somewhere in the tree and have it render? Would you be able to nest additional nodes in the tree? Would you be able to insert parts of the node under a fapi fieldset elements? Bear in mind, I'm not thinking about the ramifications on theming, more I'm interested in where we see drupal_render going.
I love what I'm hearing. Can we call it a "Render API"? We really are risking the term "fapi" being synonymous with #everything while the distinction is not clear. Jeff Eaton wrote:
It would be perfectly possible to *render* a form in that fashion, but unless you called drupal_get_form() it would not actually enter the full form lifecycle. In fact this is already possible using Drupal 5's infrastructure. Try this in your hook_nodeapi op view:
$node->content['my_thing'] = array( '#type' => 'fieldset', '#title' => t('Test fieldset'), '#collapsible' => TRUE, '#collapsed' => FALSE, );
$node->content['my_thing']['content'] = array( '#value' => 'Test content goes here...', );
It will add a collapsible fieldset to your view containing static content.
renderable elements are renderable elements. Form elements just render into <input> tags and so on. FormAPI adds additional behavior on top of that, but under the hood, the rendering infrastructure is a way of taking a metadata rich array structure and rendering it into raw HTML (or JSON, or XML, if you feel like layering a new set of theme functions onto it.)
It is a tremendously powerful system. We shouldn't jump into using it unawares, but we would also be missing a huge opportunity to pass up this system of storing meta-data rich structures and renderable content.
--Jeff
On Jun 21, 2007, at 6:16 PM, sime wrote:
If the drupal_render on a node is made possible, would you be able insert, say, a form somewhere in the tree and have it render? Would you be able to nest additional nodes in the tree? Would you be able to insert parts of the node under a fapi fieldset elements? Bear in mind, I'm not thinking about the ramifications on theming, more I'm interested in where we see drupal_render going.
On Jun 21, 2007, at 6:42 PM, Jeff Eaton wrote:
It is a tremendously powerful system. We shouldn't jump into using it unawares, but we would also be missing a huge opportunity to pass up this system of storing meta-data rich structures and renderable content.
Jeff and I just discussed on IRC... Whereas, there's no solid agreement yet on if/how this should happen, and Whereas, even a partial implementation of this to fix $node namespace bugs would require a massive patch that breaks all of contrib and every patch in the core queue right now, and Whereas, neither of us has time for the massive effort it would take to write and maintain such a patch, and, Whereas, neither of us want to be responsible for the D6 equivalent of the "4.7 FAPI debacle" at this late hour in the development cycle, and Whereas, there are lots of other great patches that could use our collective attention that *do* still have a chance of landing for D6... Therefore, be it resolved, that we're hereby "throwing in the towel" (giving up) on trying to get this into D6. Jeff already added a section on "node structuring" to the DrupalCon agenda in September. We both agree that giving this proper thought and doing it completely and early in D7 is the best course of action. Active >> Postponed ;) Thanks, -Derek
On Jun 21, 2007, at 10:10 PM, Derek Wright wrote:
On Jun 21, 2007, at 6:42 PM, Jeff Eaton wrote:
It is a tremendously powerful system. We shouldn't jump into using it unawares, but we would also be missing a huge opportunity to pass up this system of storing meta-data rich structures and renderable content.
[snip] Jeff already added a section on "node structuring" to the DrupalCon agenda in September. We both agree that giving this proper thought and doing it completely and early in D7 is the best course of action.
Active >> Postponed
When this is discussed, one thing that would be nice to think about is whether this could be leveraged to fix the problem with input filters. Specifically, that input filters don't get any context (such as a node object), so the most useful ones have to implement themselves via hook_nodeapi() (cf inline.module). If drupal_render is going to be called on nodes to render them, we could do something like: $node['content']['my_field'] = array( '#value' => $node['my_module']['my_data'], '#filter' => $node['my_module']['filter'], ); Which when rendered would generate call the input filters, but be able to give them the context of the node. We could even support something like $node['content']['my_field'] = array( '#value' => 'This is my @interesting text', '#keys' => array('@interesting' => '<b>special</b>'), '#filter' => get_filter('default'), ); Or, if you wanted to be even more interesting, $node['content']['my_field'] = array( 'first_part' => array( '#value' => 'This is, after all, ', '#filter' => 1, ), 'middle_part' => array( '#value' => '<blink>not</blink>', '#filter' => 0, ), 'end_part' => array( '#value' => ' rocket science; is it?', '#filter' => get_filter('php'), ), ); If done right, this could entirely eliminate the need to call check_plain and check_markup as well... But the key point is that if we use '#filter', we could get a context object to input filters, and that would make many input filters easier to create. Ricky The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
Wish I could be at drupalCon for that one. One useful thing would be to have that node structuring conversation outside of the question about objects or not. In php 5, object properties can be iterated in the same way that arrays can, both in terms of extract and foreach as is illustrated by the following php5 code: <?php $object = simplexml_load_string('<node><var1>value1</ var1><var2>value2</var2></node>'); extract((array)$object); ?> <?php print "Variable1:".$var1; ?> I wrote a RAILS partials knock-off in an insanely simple php library, which I'll include a modified version to illustrate my point. It seems that a well structured node (object or array) with some good rendering functions kind of like the way views theming works, would be a very powerful way to implement this. Can't wait till PHP5 and Drupal 7 ;) <?php /** * Render a partial template from an array. * @param $info an two dimensional array to iterate through for partial * @param $template the template to execute for the partial. */ function render_partial($item,$partial,$name='',$extract=true) { if ((is_array($item) || is_object($item)) && $extract==true) { extract((array)$item); } include("partials/".$partial.".php"); } /** * Render a partial template from an array. * @param $info an array to itterate through as the partical * @param $template the template to execute for the partial. */ function render_collection_of_partials($collection,$partial,$name='', $extract=true) { foreach ($collection as $item) { render_partial($item,$partial,$name,$extract); } } On Jun 21, 2007, at 7:10 PM, Derek Wright wrote:
On Jun 21, 2007, at 6:42 PM, Jeff Eaton wrote:
It is a tremendously powerful system. We shouldn't jump into using it unawares, but we would also be missing a huge opportunity to pass up this system of storing meta-data rich structures and renderable content.
Jeff and I just discussed on IRC...
Whereas, there's no solid agreement yet on if/how this should happen, and
Whereas, even a partial implementation of this to fix $node namespace bugs would require a massive patch that breaks all of contrib and every patch in the core queue right now, and
Whereas, neither of us has time for the massive effort it would take to write and maintain such a patch, and,
Whereas, neither of us want to be responsible for the D6 equivalent of the "4.7 FAPI debacle" at this late hour in the development cycle, and
Whereas, there are lots of other great patches that could use our collective attention that *do* still have a chance of landing for D6...
Therefore, be it resolved, that we're hereby "throwing in the towel" (giving up) on trying to get this into D6.
Jeff already added a section on "node structuring" to the DrupalCon agenda in September. We both agree that giving this proper thought and doing it completely and early in D7 is the best course of action.
Active >> Postponed
;)
Thanks, -Derek
I don't think a UI is needed for assigning theme variables and I don't think drupal_render($node['details']) is that much bad for themers, it has an obvious name and function and I don't see why it would be hard to describe it to themers. The issue I see here (which you all are aware of I know, and the UI solution is also trying to solve), and that always bugged me when trying to explain it to themers is that how you know that $node['details'] is available and has what you are looking for. I think a good solution is to have a generated custom help page where it lists all the defined variables and their descriptions. And by letting modules specify a #description attribute when adding to the $node->content we can use that to generate such a help page. I'm not up to date with the changes of the theming layer in D6 so I'm not sure of the do-ability of this. So to conclude, I think drupal_render() is great, a help page would accomplish one of the UI goals but would spare us the trouble of naming variables because as a themer, why would I care if the variable is 'field_details' or 'mydetails'... etc. I will just use it whatever it's. - Amr
The new user profile .tpl.php files include a line which prints this information for the themer. See modules/user/user_profile.tpl.php in HEAD, for example. Amr Mostafa wrote:
I don't think a UI is needed for assigning theme variables and I don't think drupal_render($node['details']) is that much bad for themers, it has an obvious name and function and I don't see why it would be hard to describe it to themers.
The issue I see here (which you all are aware of I know, and the UI solution is also trying to solve), and that always bugged me when trying to explain it to themers is that how you know that $node['details'] is available and has what you are looking for. I think a good solution is to have a generated custom help page where it lists all the defined variables and their descriptions. And by letting modules specify a #description attribute when adding to the $node->content we can use that to generate such a help page. I'm not up to date with the changes of the theming layer in D6 so I'm not sure of the do-ability of this.
So to conclude, I think drupal_render() is great, a help page would accomplish one of the UI goals but would spare us the trouble of naming variables because as a themer, why would I care if the variable is 'field_details' or 'mydetails'... etc. I will just use it whatever it's.
- Amr
Moshe Weitzman wrote:
The new user profile .tpl.php files include a line which prints this information for the themer. See modules/user/user_profile.tpl.php in HEAD, for example.
Which works great for .tpl.php files that aren't too likely to have random variables added into them. Unlike the node table which is going to have data from a bunch of sources that is going to vary. A lot.
OK, I guess I should have just pasted the commented out line. It prints all the variables that are available, dynamically. It deals with the "bunch of sources" problem just fine. // Uncomment the line below to see what data is available in this template. # print '<pre>'. check_plain(print_r($account->content, 1)) .'</pre>'; Earl Miles wrote:
Moshe Weitzman wrote:
The new user profile .tpl.php files include a line which prints this information for the themer. See modules/user/user_profile.tpl.php in HEAD, for example.
Which works great for .tpl.php files that aren't too likely to have random variables added into them.
Unlike the node table which is going to have data from a bunch of sources that is going to vary. A lot.
--- Moshe Weitzman <weitzman@tejasa.com> wrote:
OK, I guess I should have just pasted the commented out line. It prints all the variables that are available, dynamically.
This is useful, but still doesn't solve the communication gap. As I see it (and perhaps I don't know the whole story), Earl's UI is a good first step to exposing these variables *just before* they reach the theme. Yes, themers can use _phptemplate_variables in template.php, but if themers are writing hundreds of lines of code just to reassign variable names, something is wrong. My opinion is that functions don't belong in a template because they mix logic into presentation. If I have a generic template for one node type with $top, $middle, $bottom regions I should be able to copy that node template to a new tpl.php file and just reassign what gets sent to those variables, without having to go into the template file and change what's actually printed out. I should only have to go into a template file to change the way something looks. Asking themers to "just deal with it" doesn't really solve the problem, so we might as well create some useful tools for manipulating data before it gets sent to the theme. If people are worried about portability of the theme, I would suggest some sort of "dump/export theme configurations" that could then get imported when the theme is installed. ____________________________________________________________________________________ Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433
My opinion is that functions don't belong in a template because they mix logic into presentation.
what about presentation logic? A themer should be able to see what is available to them. Fair enough, not everything conceivable should be included, since there will be an information overload. For php template tpl files we are collecting the variables visible inside the lambda, so that is not really a problem. I don't have an answer about how to deal with nested templates, etc... In my opinion a UI might not be needed in the general case, but there should be a summary of what is available for use in a theme. A UI, which creates a proxy between some variable pool and a template has it's uses, but it shouldn't be a central feature, it is just that - a helper proxy.
On Jun 21, 2007, at 12:25 PM, Earl Miles wrote:
[assuming I've set the CCK field 'myfield' to show up in the $my_field variable in the theoretical UI that will exist for this]
<span class="my_field"><?php print $my_field;?></span>
My large objection to this approach is that it makes namespace collisions inevitable. That's the primary reason I started caring about this topic in the first place. So, what happens when 4 different modules think $node->pid is theirs, and someone tries this in a theme: <span class="pid"><?php print $pid;?></span> ? This seems like a recipe for much badness and confusion, perpetuating the bugs we already have for developers down into the theme layer, too. I agree with Adrian about the problems of relying on some UI for this, since that makes it basically impossible to distribute themes. Big -1 from me, -Derek
Derek Wright wrote:
On Jun 21, 2007, at 12:25 PM, Earl Miles wrote:
[assuming I've set the CCK field 'myfield' to show up in the $my_field variable in the theoretical UI that will exist for this]
<span class="my_field"><?php print $my_field;?></span>
My large objection to this approach is that it makes namespace collisions inevitable. That's the primary reason I started caring about this topic in the first place. So, what happens when 4 different modules think $node->pid is theirs, and someone tries this in a theme:
<span class="pid"><?php print $pid;?></span>
? This seems like a recipe for much badness and confusion, perpetuating the bugs we already have for developers down into the theme layer, too. I agree with Adrian about the problems of relying on some UI for this, since that makes it basically impossible to distribute themes.
You have clearly missed the point:
[assuming I've set the CCK field 'myfield' to show up in the $my_field variable in the theoretical UI that will exist for this]
I'm the one setting the variables. Not the modules. It's designed to avoid namespace collisions by taking the namespace away from the modules entirely.
This sounds like it will really make it harder to reuse themes, since you'd have to make sure the variables were all assigned the same. If you had a dozen themers, you'd end up with a dozen ways of naming each variable. I'd prefer things be kept as consistent across all Drupal installations as possible, so if I inherit another user's site, I don;t have to figure out how they did everything. Earl Miles wrote:
Derek Wright wrote:
On Jun 21, 2007, at 12:25 PM, Earl Miles wrote:
[assuming I've set the CCK field 'myfield' to show up in the $my_field variable in the theoretical UI that will exist for this]
<span class="my_field"><?php print $my_field;?></span>
My large objection to this approach is that it makes namespace collisions inevitable. That's the primary reason I started caring about this topic in the first place. So, what happens when 4 different modules think $node->pid is theirs, and someone tries this in a theme:
<span class="pid"><?php print $pid;?></span>
? This seems like a recipe for much badness and confusion, perpetuating the bugs we already have for developers down into the theme layer, too. I agree with Adrian about the problems of relying on some UI for this, since that makes it basically impossible to distribute themes.
You have clearly missed the point:
[assuming I've set the CCK field 'myfield' to show up in the $my_field variable in the theoretical UI that will exist for this]
I'm the one setting the variables. Not the modules. It's designed to avoid namespace collisions by taking the namespace away from the modules entirely.
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
Sean Robertson wrote:
This sounds like it will really make it harder to reuse themes, since you'd have to make sure the variables were all assigned the same. If you had a dozen themers, you'd end up with a dozen ways of naming each variable. I'd prefer things be kept as consistent across all Drupal installations as possible, so if I inherit another user's site, I don;t have to figure out how they did everything.
The UI for doing this would be all in one place. And right now, themes aren't going to be able to handle module-contributed node content *anyway*. Whether I'm using <span class="my_field"><?php print drupal_render($node['details']) ?></span> or <span class="my_field"><?php print $my_field;?></span> Stock themes aren't going to be able to include this code. You're already restricted by the fact that CCK items are named via UI. Standard Drupal core stuff will already be broken out into "well-named variables" so that themes can handle that stuff, and module contributed extras are going to suffer no matter which way we do it. From the perspective of the theme, in my opinion, whether the contributed module names the field or the administrator/themer/designer names the field, it's completely arbitrary and not portable anyway.
Here are my thoughts, most of which I'm just stealing from other people and mashing together. I like the earlier idea of show() and hide() functions. The first argument of show() is a region name, so page.tpl.php becomes a NO BRAINER!: <html> <head> <?php show('head'); ?> </head> <body> <div id="sidebar-left"> <?php show('left'); ?> </div> <div id="content-main"> <?php show('content'); ?> </div> <div id="sidebar-right"> <?php show('right'); ?> </div> <div id="footer"> <?php show('footer'); ?> </div> </body> </html> This is easier than current system, because the order of the various components ($picture, $messages, etc) is no longer hard-coded. (Not to mention that confusing if/else wrappers around the variables which require a themer to understand control structures). And by controlling the order of components internally by weight we've subsequently opened up the option for module developers to write "theme control modules" that define custom order and location of components via the UI. This is future-proof against new variables, and it's easy, easy, easy for theme developers, while the advanced themer can decide the order manually like this: <div id="content-main"> <?php show('content', 'messages'); ?> <?php hide('content', 'picture'); ?> <?php show('content'); // print the remaining ?> </div> .s
very exciting! +1 for this. aaron winborn Jeff Eaton wrote:
For example:
<span class="my_field"><?php print check_format($node->content['field_details'][0]['value'], $node->content['field_details'][0]['format']) ?></span>
Vs.
<span class="my_field"><?php print drupal_render($node['details']) ?></span>
The latter is what we do now when we need something more granular than the $content variable. The latter is what a cleanly renderable node would give us.
--Jeff
I agree, the way we do it now is absurdly confusing. Definitely +1 on the drupal_render option. Aaron Winborn wrote:
very exciting! +1 for this.
aaron winborn
Jeff Eaton wrote:
For example:
<span class="my_field"><?php print check_format($node->content['field_details'][0]['value'], $node->content['field_details'][0]['format']) ?></span>
Vs.
<span class="my_field"><?php print drupal_render($node['details']) ?></span>
The latter is what we do now when we need something more granular than the $content variable. The latter is what a cleanly renderable node would give us.
--Jeff
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
On 21 Jun 2007, at 21:43, Sean Robertson wrote:
I agree, the way we do it now is absurdly confusing. Definitely +1 on the drupal_render option.
This comment is not helpful either. We're not comparing the current system with drupal_render(), we're comparing Eaton's drupal_render() to Earl's solution. Can we get a bit more signal to noise, please? Thanks. -- Dries Buytaert :: http://www.buytaert.net/
participants (22)
-
Aaron Winborn -
adrian rossouw -
Amr Mostafa -
Caleb Gilbert -
Darrel O'Pry -
David Metzler -
David Strauss -
Derek Wright -
Dries Buytaert -
Earl Miles -
Farsheed -
Frando (Franz Heinzmann) -
Jeff Eaton -
Larry Garfield -
Moshe Weitzman -
Philippe Jadin -
Richard Morse -
Robin Monks -
Sean Robertson -
sime -
Vladimir Zlatanov -
Yves Chedemois