[ic] Internal bounce

[Ethan Rowe]

Paul Jordan wrote:
>> users-bounces at icdevgroup.org] On Behalf Of Brian J. Miller
>> Bill Carr wrote:
>>     
>>> Hi,
>>>
>>> I don't know what or how to call this.
>>>
>>> I would like to do something similar to the [bounce] tag without
>>> issuing a redirect to the client. I would like to just say, "Hey
>>> Interchange start over with this other page instead and give that
>>>       
>> over
>>     
>>> to the client." Is there a way to do that? I'm trying to make search
>>> engine friendly URLs.
>>>
>>> Is there a way in interchange to have a URL like /product/yellow-
>>>       
>> tail-
>>     
>>> shiraz and then have a page called 'product' that knows about
>>>       
>> 'yellow-
>>     
>>> tail-shiraz' and can do what it needs to do?
>>>
>>>
>>> Bill Carr
>>> bill at bottlenose-wine.com
>>>       
>> Sounds like an Action Map to me.
>>
>> http://www.icdevgroup.org/xmldocs/confs/ActionMap.html
>>
>> --
>> Brian J. Miller
>>     
>
>
> hmmm, I'd still be interested to know what someone from End Point would
> say....
>
> 8-)
>
> Paul
>   

I'm going to go out on a limb and say "actionmap".

It should be mentioned that if you use a global (Interchange-level) 
actionmap rather than a catalog level one (or a global sub registered as 
a catalog-level actionmap), you can tell the dispatch routine to 
actually redo the actionmap phase.  This can be handy.  It can also be 
dangerous and lead to infinite loops if you're not careful.  Anyway, to 
engage in this delightfulness, do the following in your actionmap code 
if rerunning is desirable:

    $Vend::FinalPath = 'new/catalog-relative/path/to/parse';
    $Vend::RedoAction = 1;


This isn't typically useful, unless you use actionmaps all over the 
place (which I have, encourage, and rigorously applaud).

Actionmaps are a marvelous way of achieving MVC-style separation of 
concerns: put your business logic in 'em, and then have your template 
pages and the ITL therein be strictly about presentation concerns.

Take it a step farther, and put all your actionmap routines in a custom 
Perl module.  Now you can have them call each other and have your 
business logic be internally reusable, clean, etc.  Depending on the 
design of the routines, you could presumably validate some subset of 
them with unit tests.  Unit tests!

They are also nice for SEO.

They are also nice for RESTful design, since they let you craft URLs 
where parameters are expressed as part of the URI path (instead of 
GET/POST variables with an opaque path like "process" -- which is also 
an actionmap).

If you get into using actionmaps, it is helpful to implement 
routines/usertags that generate actionmap URL paths for you based on the 
parameters you want passed to the actionmap.  If you don't do this, then 
you end up scattering the logic for building such URLs all over your 
app.  Which is !$cool.

By the way, people at End Point like actionmaps.  In case you were 
wondering.

Thanks.
- Ethan

-- 
Ethan Rowe
End Point Corporation
ethan at endpoint.com