Re: [cgiapp] Navigation Templates and Run Mode

[B10m <suppressed>]

* Mark Fuller <suppressed> [2005-10-19 18:04:14-0700]
> 
> Within an area of the site (which is equivalent to a distinct cgiapp object)
> there usually are sub-areas which are equivalent to run modes for a single
> cgiapp object. The sub areas are depicted in a sub-navigation pane. I don't
> put the run mode in the sub navigation. Instead, each link has ?subarea=new
> (or ?subarea=archived, or ?subarea=upcoming). It is the setup method for a
> cgiapp object that translates this to a "rm=<num>" pair of values so they
> relate to a method in the cgiapp object.

Aren't you just basically doing the same stuff here? If I get this
right, you now have links like:

http://domain.tld/app/runmode?subarea=new
http://domain.tld/app/runmode?subarea=archived
http://domain.tld/app/runmode?subarea=upcoming

> I don't know if this is considered good or bad by cgiapp users. But,
> personally I liked it because 1) it replaces the cryptic "rm=" with
> something more informative if the user happens to look at the URL. 

I strongly diagree here. Your URLs above, to me, are more cryptic
than say:

http://domain.tld/app/new
http://domain.tld/app/archived
http://domain.tld/app/upcoming

Where your subareas now became runmodes. If you don't like to use
the PATH_INFO to base the runmode on, and find 'rm' too cryptic,
look at the POD[1]. You might want something like:

$self->mode_param('subarea');

> 2) It keeps the run mode values out of the templates by
> abstracting their actual value into something logical. And, 

Why is this more 'logical' compared to the examples I gave you?
Still you'd have to tell your templates to set the 'subarea' param.

> 3) it eliminates the use of an rm (or subarea) parameter for
> default (initial entry) views.

And it eliminates the need for CGI::Application, IMHO. There's also 
$self->start_mode('mode1'); This would set the 'initial entry' view.

Let's look at a quick example:
You have a site with a basic main section, a user section (needs
authentication) and a news section (fresh, archived, deleted).
Basically you want to provide everybody news, and users the ability
to set preferences or whatever.

Following your logic, you'd make one CGI instance, with three
runmodes: main (default), user and news, right? What if you'd split
it up to three CGI files. That way, you'd have no subareas, but FQRM
(Fully Qualified RunModes ;-) Your URLs would look like this:

http://domain.tld/main/
http://domain.tld/main/aboutus
http://domain.tld/main/contact

http://domain.tld/users/login
http://domain.tld/users/logout
http://domain.tld/users/preferences

http://domain.tld/news/fresh
http://domain.tld/news/archived
http://domain.tld/news/deleted

To me, this is a little more logical than using cryptic 'subarea'
params ;-)


 1. http://search.cpan.org/~markstos/CGI-Application-4.04/lib/CGI/Application.pm

-- 
B10m
   'Google is Evil'
   -rw-rw-rw-  1 satan demons  0 Jun 06 06:06 google

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed