http://qs1969.pair.com?node_id=405795


in reply to Introduction to anonymous arrays and hashes

think in terms of things you already know

Most of the difficulty of your situation goes away when you think in terms of all-purpose simple data containers that you already know well. If you are even bare-bones familiar with either databases, or spreadsheets, or both (as is 90% of the computer literate population?) then the following recipie should be readily understandable. Moreover, it is a "general-purpose" way of looking at your problem: you can apply this recipie to every project you work on for the rest of your life.

the recipie

(if you're in a hurry, skip down to "how does this fit in with your problem" below, and save this for later as a "cheatsheet")

mental inventory of simple data containers

What do I mean by simple data containers? This is a basic term to describe the things that every programmer knows about like the back of their hand and use over and over again without even thinking about it. Here is a sample 'inventory' of simple containers ... (NOTE you can use whatever terminology you want, this is just a generic framework, these are just generic terms).

  • SimpleScalar: aka a "string", can be some value where you dont even care about giving it a name (in perlspeak, the "$_" variable is an example of this)
  • SimpleSequence: an ordered list of zero or more SimpleScalar items, each attached to an index number (0 thru n)
  • SimpleNameValuePair: a SimpleScalar where you *do* care about giving it a name (in perlspeak this would be a hash with a single key-value pair)
  • SimpleRecord: this is one or more SimpleNameValuePair grouped together (in perlspeak, a populated hash with one or more key-value pairs)
  • SimpleTable: this is an ordered sequence of zero or more SimpleRecord items grouped together (one way to do it in perl is an anonymous array where each element is an anonymous hash)
  • SimpleWorkbook: This is a grouping of one or more SimpleTable items where each SimpleTable has a 'name'. An easy visualization: imagine an excel spreadsheet where each little 'tab' holds a SimpleTable.
how does this fit in with perl

When you think in terms of simple data containers, you realize that these containers will handle *a huge percentage* of all your data modeling needs no matter what programming language you use, and no matter what problem domain you are working with. When you translate all of this into perl, you realize that you need to use *references* because some of the simple containers in our inventory cannot be modeled without them.

Here, then, is an example in perl ... 

### SimpleScalar
    $_ = "Homer";

### SimpleSequence
    @aNames = qw(Homer Bart Lisa Maggie);

### SimpleNameValuePair
    %hPerson = (fname => 'Homer');

### SimpleRecord
    %hPerson    = (fname => 'Homer', lname=>'Simpson', age=> 33);

### SimpleTable
    ### NOTE: Here we start to use *references*
    ### because we want to put one kind of 'simple container'
    ### into another kind of 'simple container' ...  whenever
    ### we *nest* simple data containers inside each other,
    ### thats when you have to start thinking about references...

    $oTable = [
        {fname => 'Homer', lname=>'Simpson', age=> 33},
        {fname => 'Bart', lname=>'Simpson', age=> 11},
        {fname => 'Lisa', lname=>'Simpson', age=> 9},
    ];

    ### Now we need to know how to VIEW, ADD, EDIT and DELETE
    ### VIEW Homer
    print "$oTable->[0]{fname}\n----\n";

    ### ADD a new SimpleRecord to the SimpleTable
    push  @{$oTable}, {fname => 'Maggie', lname=>'Simpson', age=> 1};

    ### EDIT a SimpleRecord in the SimpleTable
    $oTable->[0]{fname} = "Marge";
    $oTable->[0]{age}   = 28;

    ### DELETE a SimpleRecord from the SimpleTable
    pop @{$oTable};

    ### Lets VIEW the whole thing!
    use Data::Dumper;
    print Data::Dumper->Dump([$oTable], [qw(SimpleTable)]);
    print "\n----\n";

### SimpleWorkbook
    $oWkbk  = {};
    $oWkbk->{Simpsons}      = $oTable;
    $oWkbk->{Flintstones}   = $oTable1; ### this is blank for now
    $oWkbk->{Jetsons}       = $oTable2; ### this is blank for now

    ### Lets VIEW the whole thing!
    use Data::Dumper;
    print Data::Dumper->Dump([$oWkbk], [qw(SimpleWkbk)]);
    print "\n----\n";

[download]
how does this fit in with your problem

To solve your problem, look at the information you are trying to store and ask yourself, "which simple data container works best for what I am trying to do?"

Since you are working with META tags, my guess is you could get away with either a SimpleTable or a SimpleWorkbook to handle your entire project. There are numerous ways you could arrange this, but for simplicity, here is a bare-bones example of what I mean. 

### option1 put all your meta tags in a single SimpleTable
my  $oMetaTagTable1 = [
    {tag_name => 'description' , tag_content=>'blah blah blah'},
    {tag_name => 'keywords' , tag_content=>'word1;word2;word3'},
    {tag_name => 'author'   , tag_content=>'gurn blansten'},
];


### option2 put all your meta tags in a SimpleWorkbook
    ### where each "worksheet" has the name of the page
    ### where the metatags came from

my  $oWkbk  = {};
    $oWkbk->{index_htm}      = $oMetaTagTable1;
    $oWkbk->{about_us}       = $oMetaTagTable2;
    $oWkbk->{products}       = $oMetaTagTable4;

### option3 thru option999
    ### there are many ways you could approach this
    ### the main thing is, just think in terms of simple
    ### data containers and the problem is more workable

[download]

HTH.

Replies are listed 'Best First'.
Re^2: Introduction to anonymous arrays and hashes
by redspike (Initiate) on Aug 29, 2009 at 23:03 UTC
    Thanks. I think mainly visually, and have in the past found it hard to translate the visual form of structures into programmable structures even though I understand them, but this has put me on the right track. Understanding means being able to apply the model to other data manipulating tasks more easily.
[reply]

In Section Seekers of Perl Wisdom