Home
The Toolkit for Online Communities
17516 Community Members, 0 members online, 2204 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : url abstraction : One Message

Forum OpenACS Q&A: Re: url abstraction

Collapse
8: Re: url abstraction (response to 1)
Posted by Tilmann Singer on
Am I right in the assumption that this example is highly hypothetical?

Why would the code need to be able to deal with a case like this:

/bla/forum/12345?forum_id=67890

when all requests of the new form will be like this:

/bla/forum/12345

and all references in the (to avoid) old style like this:

/bla/forum-view?forum_id=12345

Thanks for the note on [ad_conn path_info] - that's right. I'd propably still use it rather than [ad_conn urlv] and treat it with [file split] before because it'll be easier to read when including the message_id, like /bla/forum/12345/54321, but maybe that's just meaningless personal preference.

Collapse
10: Re: url abstraction (response to 8)
Posted by Tom Jackson on

The reason I use [ad_conn urlv] is it contains exactly the information I need, already parsed. Why make a mistake in parsing when the work is already done?

The reason I included the highly hypothetical example is because of the mistake you can make by just appending, blindly to the form. In the case covered, the user is left wondering what the error means. Once a page hits the internet the highly hypothetical becomes the all too common.

Also, there may be other variable you need to add to a form before the internal redirect. This is an example of how to clean up your form so it contains what you want it to contain.

Collapse
11: Re: url abstraction (response to 10)
Posted by Tilmann Singer on
Totally agree with Dave regarding using pretty names instead of object_ids if possible. If you need to generate a string that can be used as url part see the proc util_text_to_url in case you don't know it yet.

About the parameter delete loop: looks like a proc: rp_form_clear would be handy, no? Or should rp_form_put optionally replace existing params instead of appending? Didn't we have that discussion already somewhere?

Using [ad_conn urlv] starts to become tricky when you have possibly more than one element as part of the url information you need, e.g. when you want to both serve http://openacs.org/forums/openacs-general/12345 (the message) and http://openacs.org/forums/openacs-general/ (the forum-view).

Collapse
12: Re: url abstraction (response to 11)
Posted by Tom Jackson on

rp_form_put does what it should. I don't see any reason it should change, but it would be nice to provide a proc to handle the case of clearing, or setting a unique value for a form var.

Without knowing more, I'm not sure exactly what method I would use if I had multiple target pages. I think my example speaks for itself. I'm not trying to write an application page for the forum package, just provide an example for the question asked. I will say, however, that the information in a url path is contained in the sequence and values of what is between the '/' characters. [ad_conn urlv] provides exactly this information.

Here is a more complex example taken from /www/skills/standard/index.vuh on iUnicycle.com:



set urlv [ad_conn urlv]

set path_value [lindex $urlv end]

switch -exact -- "$path_value" {

    riding - mount - transition - stationary {
        set template_name "type"
    }
    standard {
        set template_name "standard"
    }

    default {
        set standard_index [lsearch $urlv "standard"]
        set skill_list [lrange $urlv [expr $standard_index + 1] end]
        if {[llength $skill_list] == 1} {
            set template_name number
        } elseif {[llength $skill_list ] == 2} {
            set template_name letter
        } else {
            set template_name $path_value
        }
    }
}

rp_internal_redirect $template_name