How to approach this problem, or should I ignore it?

jedikaiti has asked for the wisdom of the Perl Monks concerning the following question:

OK, Monks, I have more of a conceptual question this time. I have a whole mess of data in a big ol' nested HoHoH (and the occasional array, too). Format like what's below:

%cmdData = (
     'command_1' => {
          'subfields' => [],
          'description' => 'descriptive text',
          'safety' => 'SAFE',
          'opcode' => 'code_1'
                    },
     'command_2' => {
          'subfields' => [
               {
                  '_size' => 32,
                   'state_conversions' => [],
                   'subfield_name' => 'sub_1',
                   '_fsw_type' => 'UINT32',
               },
               {
                  '_size' => 32,
                   'state_conversions' => [],
                   'subfield_name' => 'sub_2',
                   '_fsw_type' => 'UINT32',
               },
                          ],
          'description' => 'descriptive text',
          'safety' => 'SAFE',
          'opcode' => 'code_2'
                    }
     'command_3' => {
          'subfields' => [
               {
                  '_size' => 16,
                   'state_conversions' => [],
                   'subfield_name' => 'sub_3',
                   '_fsw_type' => 'UINT16',
               },
               {
                  '_size' => 32,
                   'state_conversions' => [],
                   'subfield_name' => 'sub_4',
                   '_fsw_type' => 'UINT32',
               },
               {
                  '_size' => 8,
                   'state_conversions' => [],
                   'subfield_name' => 'sub_4',
                   '_fsw_type' => 'UINT8',
               },
                          ],
          'description' => 'descriptive text',
          'safety' => 'SAFE',
          'opcode' => 'code_3'
                    }
)
[download]

I have some code that, right now, goes through this data and, for each command, comes up with an HTML table like this (example for command 3 in the data above):

opcode subfield(s)

code_1 sub_1 sub_2 sub_3

99% of the time, this is fine. But there's a couple of commands that have a LOT of subfields - like 20 of them - and that just doesn't fit well.

What I am trying to determine is if there's a relatively easy way to break the big ones down into multiple tables. Like put the first 5 subfields in the first table, cut it off, then put the next 5 into another table, and so on. If this is going to be a PITA, or just take forever to code up, then I have my boss' OK to ignore the problem - we're talking about < 5 commands out of close to 300 that this applies to.

The existing code just uses a foreach to iterate through (and sort) the commands, an if/else to check for the existence of subfields, and if there are subfields, a for to iterate through those.

So, what do you guys think? Any brilliant insights? Should I leave the sleeping puppies alone, or can you think of a simple/quick way to handle this?

Thanks!

Kaiti
Swiss Army Nerd

Comment on How to approach this problem, or should I ignore it? Download Code

Replies are listed 'Best First'.
Re: How to approach this problem, or should I ignore it? by jethro (Monsignor) on Apr 07, 2010 at 17:54 UTC
I hope your script is well designed with subroutines to do the difficult tasks ;-). In that case you probably have a subroutine to generate a row of the html table. Then you just need to insert the following code (adapted to your circumstances, $x has a different name in your script): `$opcode=$x->{opcode}; while (@{$x->{subfields}}) { @params= splice(@{$x->{subfields}},0,5); generate_html_row($opcode,@params); $opcode=''; }` [download] Beware, this changes your datastructure. if you can't have that, make a copy of `@{$x->{subfields}}` and loop over the copy If you don't have that subroutine it should be easy to extract the relevant code and make it one. Ok, you could do the same inline, but readability is much better with subroutines for distinct tasks	[reply] [d/l] [select]
Re^2: How to approach this problem, or should I ignore it? by jedikaiti (Hermit) on Apr 08, 2010 at 16:05 UTC
Thanks, jethro! Kaiti Swiss Army Nerd	[reply]
Re: How to approach this problem, or should I ignore it? by rubasov (Friar) on Apr 07, 2010 at 21:04 UTC
Here's my stab at it: #! /usr/bin/perl use strict; use warnings; use Text::Template; use List::MoreUtils qw( natatime ); my %cmd_data = ( ... ); our $max_sf_cols = 5; my $template = Text::Template->new( TYPE => 'FILEHANDLE', SOURCE => \* +DATA ) or die "Couldn't construct template: $Text::Template::ERROR"; for my $cmd ( sort keys %cmd_data ) { local our $opcode = $cmd_data{$cmd}{opcode}; my @sf_names; push @sf_names, $_->{subfield_name} for @{ $cmd_data{$cmd}{subfields} }; @sf_names = qw( none ) if not @sf_names; my $it = natatime $max_sf_cols, @sf_names; print $template->fill_in() while local our @sf_cols = $it->(); } __DATA__ <p> <table border="1"> <thead> <tr> <th>opcode</th> <th colspan="{ $max_sf_cols }" align="center">subfield(s)</th> </tr> </thead> <tbody> <tr> <td>{ $opcode }</td> { $OUT .= "<td>$_</td>" for @sf_cols } </tr> </tbody> </table> </p> [download] Probably the most interesting part of it is the List::MoreUtils::natatime (n at a time) function. This almost does the same as jethro's splice, but without changing your data structure. It gives you an iterator sub, and every time you call that iterator sub it gives you the next five items from an array. You can use this in your existing code without bothering much with the other parts. The templating is just an extra. You can see the template in the `DATA` section, where every `{ perl code }` section will be replaced by the value of its last statement, or with the value of `$OUT` if you appended something to it. Notice the scoping of the variables used both in the template and in the main code. They are not lexicals, because you cannot see lexicals of the main code in the templating code fragments. I'm not dealing much with HTML templating, so I'm sure there are better ways to do this, but I hope this helps.	[reply] [d/l] [select]
Re^2: How to approach this problem, or should I ignore it? by jedikaiti (Hermit) on Apr 08, 2010 at 16:20 UTC
Excellent! Many thanks, rubasov! Kaiti Swiss Army Nerd	[reply]
How to approach these titles ... by LanX (Saint) on Apr 07, 2010 at 17:57 UTC
... or should I ignore them? Cheers Rolf	[reply]
Re: How to approach these titles ... by Argel (Prior) on Apr 07, 2010 at 20:43 UTC
There is only one problem -- commands that generate an excessive number of subfields -- so I am not sure what your post is referring to. Could you elaborate? Elda Taluta; Sarks Sark; Ark Arks	[reply]
Re^2: How to approach these titles ... by LanX (Saint) on Apr 07, 2010 at 20:56 UTC
> Could you elaborate? sure ... IMHO titles should reflect the subject of the post. Not only of courtesy ... if a poster can't phrase his problem, it's questionable if he's able to understand the replies and merits the energy spend to explain. But you have a point, in the future I should simply silently ignore these kinds of posts! :) Update: it was just a too obvious pun I couldn't resist. ;) Cheers Rolf	[reply]


Think about Loose Coupling
	PerlMonks