[development] Advice Needed
Bèr Kessels
ber at webschuur.com
Tue Aug 28 21:08:41 UTC 2007
About the assembly thing: sure; but lets not get too meta here.
Op dinsdag 28 augustus 2007, schreef Jeff Eaton:
> Having helped build a number of remarkably large sites that use Views
> quite heavily, I can say that its queries are just as efficient as
> hand-rolled ones, save the cases where its query building mechanism
> just can't handle certain SQL constructs. (Use of aggregate
> functions, for example).
Point is; that the original poster asked for a specific page to that he needed
to display. He did not ask how to maintain hundreds of snippets.
Though I tend to agree (and tend to use views a lot) I simply wanted to warn
not only the original poster, but others about the viewsCCK kneejerk. These
make a brilliant combination. But are often WAY overkill to achieve something
simple. Regardless of performance (I never used that word in my arguments,
for a reason).
> The benefits of hand-rolled SQL and direct-to-html 15-line PHP
> snippets are certainly compelling. It just needs to be acknowledged
> that on any site of reasonable complexity, that 15-line snippet will
> exist in a hundred different locations, each with minor variations
> and tweaks and hacks and customizations. As will the 'hand-tuned' SQL
> query.
This is simply untrue. Because it al comes down to how well you architecture
your code. If one needs a single piece of code on 100 places, you must really
learn about functions (and yes, I know Jeff knos about them, he's a grand
master of PHP), but I am charging the point to make my point clear.
To an extend you are right. Hence I deliberately mentioned the
word 'reusability'. But serious and honoust:
http://skimadriver.com/snowreport.php. Would you *really* advice someone to
build a views display plugin, being a layer on a seriously complex layer
(views), using another extremely complex layer (cck) mingled inbetween trough
and pressed on top of theme layers, DBas etc? I certainly wont.
Here you go:
function resort_statii_load(&$node) {
$node->resort_statii = db_fetch_object(db_query('SELECT * from
{resort_statii} WHERE nid = %d', $node->nid));
}
function resort_statii_view(&$node) {
$node->content = array(
'content' => theme('resort_statii_statii_node_table',
$node->resort_statii);
'weight' => 10);
}
function theme_'resort_statii_statii_node_table($resort_statii) {
$out = '<table width="100%" cellpadding="2px">
<tr><td colspan="4"><strong>Last Update:</strong>'.
$resort_statii->updated_at .'</td></tr>
<tr>
<td colspan="2"><strong>Snow Base Up To:</strong>'.
$resort_statii->base_up_to .'</td>
<td colspan="2"><strong>Runs Open:</strong>'.
$resort_statii->open_runs .'<strong>of</strong> '.
$resort_statii->total_runs '.</td>
</tr>
<table width="100%" cellpadding="2px">';
return $out;
}
Pseudo-code. But it explains my point: Its pragmatic++. Sure: I could develop
hook_views tables, views display plugins, CCK fields and so forth. But if
this cuts the crap, then why bother?
Sure: you should bother if you aer going to build the CMs for snow-resorts.
But as long as all you *really* need is a simple table listing all sorts of
statii, values from a table, or a few tables, then why squeeze yourself into
all that complexity?
In the end, however, I think its a matter of taste.
Bèr
--
Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting:
www.sympal.nl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20070828/ad8551ed/attachment.pgp
More information about the development
mailing list