Hello all, Have a page that has a grid of information that needs to be easily editable and looking for suggestions on how to accomplish it in a drupal-esque way. There is no complex logic. Here is an example of what the page will emulate. http://skimadriver.com/snowreport.php Thanks! -- Mike Bishop
This seems possibly relevant: Two Axis Grid Views Plugin http://groups.drupal.org/node/2879 -Peter On 8/27/07, Mike Bishop <mbishop@adamsonadvertising.com> wrote:
Hello all, Have a page that has a grid of information that needs to be easily editable and looking for suggestions on how to accomplish it in a drupal-esque way. There is no complex logic.
Here is an example of what the page will emulate. http://skimadriver.com/snowreport.php
Thanks!
--
Mike Bishop
Op maandag 27 augustus 2007, schreef Mike Bishop:
Hello all, Have a page that has a grid of information that needs to be easily editable and looking for suggestions on how to accomplish it in a drupal-esque way. There is no complex logic.
Here is an example of what the page will emulate. http://skimadriver.com/snowreport.php
Depending on the amount of manpower/budget you have available, I would say (high to low): * custom module. Allows you to make the admin UI tailor made for the client. As well as the result for vieuwers. Design your own (highly optimised) tables, simple code, performs a lot better then any general (cck/views) will avver be able to, and gets you 98% where the client wants to get. * Custom modules, only handling the display/ The input UI would be CCK, plus some (unfriendly, scattered) settings and GUI pages. Often clients (think they) don't need fancy input, as long as the output is 100% what they need. This will get you very close there. The input is often a digital version of ductape+rubberbands+paperclips and some jumping hoops. * Views+cck. All ready made, but will never get you 100 where the client wants to be. Often fine enough, but ofteb it gets you less then 60% where the client wants to get. So it may be way out of line. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Op maandag 27 augustus 2007, schreef Mike Bishop:
Hello all, Have a page that has a grid of information that needs to be easily editable and looking for suggestions on how to accomplish it in a drupal-esque way. There is no complex logic.
Here is an example of what the page will emulate. http://skimadriver.com/snowreport.php
Adding to the options below, you could define your own views style plugin that accepts the resulting nodes from the views query and then output your own custom table to make it look exactly right. The advantage being you get all the views query goodness and all you have to do is make sure the data is output the way you want.
Depending on the amount of manpower/budget you have available, I would say (high to low): * custom module. Allows you to make the admin UI tailor made for the client. As well as the result for vieuwers. Design your own (highly optimised) tables, simple code, performs a lot better then any general (cck/views) will avver be able to, and gets you 98% where the client wants to get. * Custom modules, only handling the display/ The input UI would be CCK, plus some (unfriendly, scattered) settings and GUI pages. Often clients (think they) don't need fancy input, as long as the output is 100% what they need. This will get you very close there. The input is often a digital version of ductape+rubberbands+paperclips and some jumping hoops. * Views+cck. All ready made, but will never get you 100 where the client wants to be. Often fine enough, but ofteb it gets you less then 60% where the client wants to get. So it may be way out of line.
Bèr
-- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469
Op dinsdag 28 augustus 2007, schreef Farsheed:
The advantage being you get all the views query goodness and all you have to do is make sure the data is output the way you want.
The disavantage should also be mentioned here: Complexity. A views style plugin is actually (ahum) an abstraction layer, on an abstraction layer, on an abstraction layer and so forth, approximately six levels deep. Drupal, has a DBA to talk to SQL. Views lays on top of that as some kind of databasequery builder, adding complexity to an already complex thing. On top of that lies the Drupal theme layer. But, views style lies on top if /that/ altering the theme. In fact, views has a theme abstraction in itself too. And on top of that, you get the theme layer again. Disclaimer: I am in favour of a simple fifteen-lines PHP function to aggregate data from the DB and present that in the table the way the client wants to see it, over views, cck, theme-over-theme-over-abstraction layers and all that. I just put this other side of the medallion here, so that readers are not blinded by all the CCK/views goodness, but can value a simple few lines of PHP where appropriate :) Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Ok, where is a sample of your fifteen-lines PHP function. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Bèr Kessels Sent: Tuesday, August 28, 2007 3:55 PM To: development@drupal.org Subject: Re: [development] Advice Needed Op dinsdag 28 augustus 2007, schreef Farsheed:
The advantage being you get all the views query goodness and all you have to do is make sure the data is output the way you want.
The disavantage should also be mentioned here: Complexity. A views style plugin is actually (ahum) an abstraction layer, on an abstraction layer, on an abstraction layer and so forth, approximately six levels deep. Drupal, has a DBA to talk to SQL. Views lays on top of that as some kind of databasequery builder, adding complexity to an already complex thing. On top of that lies the Drupal theme layer. But, views style lies on top if /that/ altering the theme. In fact, views has a theme abstraction in itself too. And on top of that, you get the theme layer again. Disclaimer: I am in favour of a simple fifteen-lines PHP function to aggregate data from the DB and present that in the table the way the client wants to see it, over views, cck, theme-over-theme-over-abstraction layers and all that. I just put this other side of the medallion here, so that readers are not blinded by all the CCK/views goodness, but can value a simple few lines of PHP where appropriate :) Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
This module I wrote can be a model for how to accomplish data input/display in a Drupalesque way: http://drupal.org/project/object_driver Not 15 lines, but not complicated. This also had lots of extra goodness (such as hooks) that a dedicated module would not need. Or see (you have to get its code from CVS): http://drupal.org/project/member As before - these modules don't give you any of the power of the node system, but sometimes that 's more than you need. You could even implement hook_search if you need a custom data type to be searchable with Drupal's search module. -Peter On 8/28/07, Walt Daniels <wdlists@optonline.net> wrote:
Ok, where is a sample of your fifteen-lines PHP function.
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Bèr Kessels Sent: Tuesday, August 28, 2007 3:55 PM To: development@drupal.org Subject: Re: [development] Advice Needed
Op dinsdag 28 augustus 2007, schreef Farsheed:
The advantage being you get all the views query goodness and all you have to do is make sure the data is output the way you want.
The disavantage should also be mentioned here: Complexity.
A views style plugin is actually (ahum) an abstraction layer, on an abstraction layer, on an abstraction layer and so forth, approximately six levels deep. Drupal, has a DBA to talk to SQL. Views lays on top of that as some kind of databasequery builder, adding complexity to an already complex thing. On top of that lies the Drupal theme layer. But, views style lies on top if /that/ altering the theme. In fact, views has a theme abstraction in itself too. And on top of that, you get the theme layer again.
Disclaimer: I am in favour of a simple fifteen-lines PHP function to aggregate data from the DB and present that in the table the way the client wants to see it, over views, cck, theme-over-theme-over-abstraction layers and all that. I just put this other side of the medallion here, so that readers are not blinded by all the CCK/views goodness, but can value a simple few lines of PHP where appropriate :)
Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
This is the classic 'argument for assembly'. C, after all, is just an abstraction layer on top of assembly, the efficient native language of the microprocessor. It's also the argument against using a CMS. In some applications it makes sense. In others, it just makes the developer feel 'leet while they scramble around fixing broken queries when the client decides that things need to be sorted by number-of- weekdays-since-tuesday. 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). 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. I've found that for sites that need ongoing maintenance or future enhancements, the speed penalty for using Views is imaginary and the payoff comes in encapsulating those hundred 15-line snippets into a single customizable View Style. Underneath the hood, it's nothing but a theme function: as complex as YOU want to make it, and nothing more. --Jeff On Aug 28, 2007, at 2:55 PM, Bèr Kessels wrote:
Disclaimer: I am in favour of a simple fifteen-lines PHP function to aggregate data from the DB and present that in the table the way the client wants to see it, over views, cck, theme-over-theme-over-abstraction layers and all that. I just put this other side of the medallion here, so that readers are not blinded by all the CCK/views goodness, but can value a simple few lines of PHP where appropriate :)
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
Looking at the sample page, if there really is no complex logic involved (admin enter data, visitor view it), you can sometimes do it "old school" : - either you provide the admin an html template (there is probably a module that copy a prefilled node) they can modify using a wysiwyg editor - either you define statically a new content type with enough fields using cck with a bunch of drop downs to tell if a station is closed or not, a comment text area, some text boxes for the temperature, etc... (I hear the flamethrowers being turned on :-) Philippe On 8/27/07, Mike Bishop <mbishop@adamsonadvertising.com> wrote:
Hello all, Have a page that has a grid of information that needs to be easily editable and looking for suggestions on how to accomplish it in a drupal-esque way. There is no complex logic.
Here is an example of what the page will emulate. http://skimadriver.com/snowreport.php
Thanks!
--
Mike Bishop
We developed a module. And when I say we, you should read that as, the fabulous Will Smith developed a module for me. He comes highly recommended in my book! -- Mike Bishop Digital Mercenary Ask me about Analytics and how they can increase your sales. ADAMSON ADVERTISING P. 314.727.9500 x 1237 M. 314.537.6723 AIM / Y! : theablefew gTalk: theablefew@gmail.com On Aug 31, 2007, at 8:08 AM, Philippe Jadin wrote:
Looking at the sample page, if there really is no complex logic involved (admin enter data, visitor view it), you can sometimes do it "old school" :
- either you provide the admin an html template (there is probably a module that copy a prefilled node) they can modify using a wysiwyg editor - either you define statically a new content type with enough fields using cck with a bunch of drop downs to tell if a station is closed or not, a comment text area, some text boxes for the temperature, etc...
(I hear the flamethrowers being turned on :-)
Philippe
On 8/27/07, Mike Bishop <mbishop@adamsonadvertising.com> wrote:
Hello all, Have a page that has a grid of information that needs to be easily editable and looking for suggestions on how to accomplish it in a drupal- esque way. There is no complex logic.
Here is an example of what the page will emulate. http://skimadriver.com/snowreport.php
Thanks!
--
Mike Bishop
participants (7)
-
Bèr Kessels -
Farsheed -
Jeff Eaton -
Mike Bishop -
Peter Wolanin -
Philippe Jadin -
Walt Daniels