Overview | Concept | Licensing | Demo/Download | Installation | Gallery | Last Updates | FAQ

Views

These are the routines that display the results prepared by the shop engine layer. The View layer does not perform much processing, nor is it complex. All the language-specific content is contained here. People with basic Perl skills will be able to make small changes, that will not affect the shop functionality.

You have to understand the basic mechanism:

1. The template has a tag, i.e.:

<cityshop:view:TextTopBar/>

2. The ShopSetup maps this tag to a view:

'TextTopBar' => 'MenuVIEW.pm',

3. The MenuVIEW.pm returns some output, dependent on the passed parameters, in this case "TextTopBar".

That is all there is to it. In some cases you might have extra routines placed in the views, which are called from other libraries - it is pretty much free style, how you want to customize your stuff. You can build your own view, name it CustomMenuVIEW.pm, and generate there your code as you need to.

If you want to disable a certain tag, you just set it in the ShopSetup to 0:

'TextTopBar' => 0,

Methods

The default method in a view is display(). Any other method (or subroutine) you put in there, is your cup of coffee. I split usually the main routine in subroutines, since it is easier to manage. Most of the code in the views is simplified by using the basic engines (the ones in the Library folder), and the shop engines.

The most used shop engine is ShopDBLib.pm. We placed usually the code that gets complicated over there, to keep the view package simple. That way, if you want to build a rather complex form field, there might be a routine in the ShopDBLib ready to do it for you. For example, we will take a look at the OrderFormVIEW.pm.

if you want to build a select box with all the states in the states table, here is the code that is currently used:

 $ShippingState = ShopDBLib::_DisplayStateData($S, {
   -FIELD_NAME => 'SState',
   -FIELD_TYPE => 'select',
   -EMPTY_TITLE => $OrderMsg->{'SelectTheState'}, 
   }, $OX);

You can see how easy it is to handle, since you don't have to do much coding here.
Compare this, with the actual code in the ShopDBLib.pm:

sub _DisplayStateData {
  my ($x, $Display, @Titles, @Values);
  my $S = shift || Carp::croak ("Missing main setup data");
  my $Config = shift;
  my $FX = shift || $S->{-FX};
  my $FName = $Config->{-FIELD_NAME} || '';
  my ($DBData, $DBIx) = DBLib::_read($S, $S->{-DATA_SOURCE}->{'DisplayStates'});
  if (! ref $DBData) {
    my $Val = MainLib::_escapeHTML($FX->{$FName});
    return qq~<input type=text size=4 name="$FName" value="$Val">~;
  }
  my $IxID = $DBIx->{'StateID'};
  my $IxDX = $DBIx->{'StateName'};
# SortArrays($DBData, [$IxDX]); # Enable this if you want to sort the states display
  foreach $x(@$DBData) {
    push @Titles, $x->[$IxDX];
    push @Values, $x->[$IxID];
  }
  $Config->{-VALUES_DATA} = \@Values;
  $Config->{-TITLES_DATA} = \@Titles;
  return _GenerateOutput($S, $Config);
}

While still very compact and understandable, it is sometimes a bit too much for a lot of people.

In the case of the OrderFormVIEW, you can see that the library is calling other views directly, to put together elements of the order form:

  RequireFile($S->{-SHOP_VIEW_PATH}, 'AuthVIEW.pm');
  my $UDisplay = display AuthVIEW($S, 'OrderFormAuth', $Action);

This code does nothing else but blend in the authentication portion on the left of the screen, whether the user is authenticated or not. It displays the default addresses on file, and makes the ordering process easier.

  RequireFile($S->{-SHOP_VIEW_PATH}, 'CartVIEW.pm');
  my $CDisplay = display CartVIEW($S, 'OrderFormCart', $Action);

This code displays the shopping cart at the top of the order form. Note that the parameter $Action is passed to both of them, in this case the called routines will know that they have to deal with an order form process, and can deliver the data formatted appropriately.