GET requests are managed through regular links. To get a dynamic link to a content object with optional query string parameters set, use:
my $url = $c->link(%query_params);
The content object's show() method can check for these query string parameters when deciding what to show. For example, blogs by default show an index of current posts, but this will return a dynamic link to the archives:
$blog->link(archive=>1);
In v3 POSTs were all handled by plug-in modules. In v4, content classes can optionally accept posts directly, with no special plugin. Post methods should process normal interactions with the content from the website front-end, for example:
These posts can therefore be handled without any plug-in modules. Administrator interactions, such as content configuration, should not be run through the post() method. Deal with those in the conventional way in the module's control panel.
Post data is processed by the object's post() method. You can post direct to the post() method using:
http://website.ca/cgi/ex.cgi/post/path/to/content
but that is mostly useful for background and AJAX posts, since it is not in a page context, and will not do well at generating contextual links and content expansion. If you want to do a regular form post that returns a full page, then your show method should handle the post, using a method like
if ($c->allow_post()) {
$out .= $c->post();
}
The allow_post() method in turn should perform all necessary checks that the post is permissible. It is important that it check that the URL is targeting your content object directly:
return 0 if (! $c->url_is_me); # do not allow posts to us at other URLs
That is because content can sometimes be embedded elsewhere (such as a sidebar preview on a different page), and we only want this content responding to posts at its "home" url.