Maypole::Manual::BugSpy Maypole::Manual::BugSpy is the Maypole iBuySpy portal.
Download

Maypole::Manual::BugSpy Ranking & Summary

Maypole::Manual::BugSpy Tags

Perl module Maypole manual Maypole manual Maypole iBuySpy iBuySpy

Maypole::Manual::BugSpy Description

Maypole::Manual::BugSpy is the Maypole iBuySpy portal. Maypole::Manual::BugSpy is the Maypole iBuySpy portal.Developer commentsI think it's good fun to compare Maypole against other frameworks, so here's how to build the ASP.NET tutorial site in Maypole.We begin with a lengthy process of planning and investigating the sources. Of prime interest is the database schema and the initial data, which we convert to a MySQL database. Converting MS SQL to MySQL is not fun. I shall spare you the gore. Especially the bit where the default insert IDs didn't match up between the tables.The ibsportal database has a number of tables which describe how the portal should look, and some tables which describe the data that should appear on it. The portal is defined in terms of a set of modules; each module takes some data from somewhere, and specifies a template to be used to format the data. This is quite different from how Maypole normally operates, so we have a choice as to whether we're going to completely copy this design, or use a more "natural" implementation in terms of having the portal display defined as a template itself, with all the modules specified right there in Template Toolkit code rather than picked up from the database. This would be much faster, since you get one shot of rendering instead of having to process each module's template independently. The thing is, I feel like showing off precisely how flexible Maypole is, so we'll do it the hard way.The first thing we need to do is get the database into some sort of useful shape, and work out the relationships between the tables. This of course requires half a day of playing with GraphViz, Omnigraffle and mysql, but ended up with something like this:This leads naturally to the following driver code: package Portal; use Maypole::Application; Portal->setup("dbi:mysql:ibsportal"); use Class::DBI::Loader::Relationship; Portal->config->loader->relationship($_) for ( "A module has a definition", "A module has settings", "A tab has modules", "A portal has tabs", "A role has a portal", "A definition has a portal", "A module has announcements", "A module has contacts", "A module has discussions", "A module has events", "A module has htmltexts", "A module has links", "A module has documents", "A user has roles via userrole" ); 1;As you can see, a portal is made up of a number of different tabs; the tabs contain modules, but they're separated into different panes, so a module knows whether it belongs on the left pane, the right pane or the center. A module also knows where it appears in the pane.We'll begin by mocking up the portal view in plain text, like so: use Portal; my $portal = Portal::Portal->retrieve(2); for my $tab ($portal->tabs) { print $tab,"n"; for my $pane (qw(LeftPane ContentPane RightPane)) { print "t$pane:n"; for (sort { $a->module_order $b->module_order } $tab->modules(pane => $pane)) { print "tt$_:t", $_->definition,"n"; } } print "n"; }This dumps out the tabs of our portal, along with the modules in each tab and their types; this lets us check that we've got the database set up properly. If we have, it should produce something like this: Home LeftPane: Quick link: Quicklink ContentPane: Welcome to the IBuySpy Portal: Html Document News and Features: announcement Upcoming event: event RightPane: This Week's Special: Html Document Top Movers: XML/XSL ...Now we want to get the front page up; for the moment, we'll just have it display the module names and their definitions like our text mock-up, and we'll flesh out the actual modules later.But before we do that, we'll write a front-end URL handler method, to allow us to ape the ASP file names. Why do we want to make a Maypole site look like it's running .aspx files? Because we can! - and because I want to show we don't necessarily have to follow the Maypole tradition of having our URLs look like /table/action/id/arguments. our %pages = ( "DesktopDefault.aspx" => { action => "view", table => "tab" }, "MobileDefault.aspx" => { action => "view_mobile", table => "tab" }, ); sub parse_path { my $self = shift; $self->path("DesktopDefault.aspx") unless $self->path; return $self->SUPER::parse_path if not exists $pages{$self->path}; my $page = $pages{$self->path} ; $self->action($page->{action}); $self->table($page->{table}); my %query = $self->ar->args; $self->args( ); } 1;Here we're overriding the parse_path method which takes the path slot from the request and populates the table, action and args slots. If the user has asked for a page we don't know about, we ask the usual Maypole path handling method to give it a try; this will become important later on. We turn the default page, DesktopDefault.aspx, into the equivalent of /tab/view/1 unless another tabid or ItemID is given in the query parameters; this allows us to use the ASP.NET-style DesktopDefault.aspx?tabid=3 to select a tab.Now we have to create our tab/view template; the majority of this is copied from the DesktopDefault.aspx source, but our panes look like this: < td id="LeftPane" Width="170" > < /td > < td width="1" > < td id="ContentPane" Width="*" > < /td > < td id="RightPane" Width="230" > < /td > < td width="10" > < /td >The pane macro has to be the Template Toolkit analogue of the Perl code we used for our mock-up: [% MACRO pane(panename) BLOCK; FOR module = tab.modules("pane", panename); "< P >"; module; " - "; module.definition; "< /P >"; END; END;Now, the way that the iBuySpy portal works is that each module has a definition, and each definition contains a path to a template: $module->definition->DesktopSrc returns a path name for an ascx component file. All we need to do is convert those files from ASP to the Template Toolkit, and have Maypole process each component for each module, right? Requirements: · Perl

Maypole::Manual::BugSpy Related Software