Arc Forumnew | comments | leaders | submitlogin
How do you http redirect in Arc?
1 point by lark 4277 days ago | 17 comments
I would like to make a link where once clicked there will be some processing and the an HTTP redirect to a different, second link. I would like this second link to be what shows up on the top of the browser as the new url.

How can this be done in Arc?



2 points by akkartik 4277 days ago | link

See defopr: https://github.com/nex3/arc/blob/2762cc15fe/lib/srv.arc#L203

You could also define the op for the first url to render a meta refresh tag: https://en.wikipedia.org/wiki/Meta_refresh#Examples

-----

1 point by lark 4277 days ago | link

Thanks, I'll try it.

How would you redirect when executing a closure created with w/link?

-----

2 points by akkartik 4276 days ago | link

There's actually something called w/rlink :)

You might find http://arcfn.com/doc/srv.html useful.

-----

3 points by lark 4274 days ago | link

w/rlink was what I was looking for. Thank you!

-----

1 point by lark 4271 days ago | link

All this redirecting still doesn't get me what I want.

I would like this second link to be what shows up on the top of the browser as the new url. -- but I would also like that page to be initialized with parameters I could express so far only with a closure.

I don't want to pass those parameters to the second link, because then they'll be visible.

So now I need to first save these initialization parameters somewhere (much like saving a closure) and modify the second link to check if there are any scheduled parameters to initialize itself with for a particular user. Some sort of defop-init.

(Am I missing something?)

Down the drain go closures when combined with redirection.

What a hack.

-----

1 point by thaddeus 4271 days ago | link

Why not just pass a session id/key to the second URL* and allow that new page to retrieve the data you don't want exposed?

*or use a hidden field on a form submit.

BTW the limitations you're hitting have nothing to do with Arc or Closures, but rather are just limitations of Browser/HTTP technology (which are by design).

-----

1 point by lark 4271 days ago | link

Great so far. Now... how would you redirect after submitting a form?

  ;; aformh doesn't do it
  (defop prove-it1 req
    (aformh [ (pr "peekaboo") ]
            (pr "do something1 ")
            (submit)
            "/some-fancy-url"))

  ;; Neither does arformh
  (defop prove-it2 req
    (arformh [ (pr "peekaboo") ]
            (pr "do something2 ")
            (submit)
            "/some-fancy-url"))

  (defop some-fancy-url req (pr "Yeii!"))

-----

2 points by lark 4271 days ago | link

The documentation at http://arcfn.com/doc/srv.html reads: "The callback function f must return the redirect target."

The following works:

  (defop arf rq (arform (fn (req) "foo") (prn "Click:") (submit)))
So it is only arform that redirects, not aformh or arformh.

-----

1 point by lark 4271 days ago | link

Well, there is a syntax issue. Using square brackets to express fn fails:

  (defop arf rq (arform [ "foo" ] (prn "Click:") (submit)))

-----

1 point by akkartik 4271 days ago | link

[ ... ] expands to (fn(_) (...))

So [ "foo" ] expands to (fn(_) ("foo")), which fails because you're trying to call a string like a function.

Just use (fn() "foo").

-----

1 point by lark 4270 days ago | link

It might be better if [ "foo" ] expanded to:

  (fn(_) (do "foo"))
rather than

  (fn(_) ("foo"))

EDIT: On second thought, I doubt that's what [ "foo" ] expands to:

[ ... ] expands to (fn(_) (...))

Because you can already write aform submission code that looks like:

  (defop said req
    (aform [ (pr "You entered " (arg _ "foo"))]
      (input "foo") 
     (submit)))
If that's what [ ... ] expands to, aform wouldn't even work so far because it would be trying to call:

  (fn (_) ((pr "You entered.")))
That would be a function call to a function call: (( on the call to pr.

-----

1 point by akkartik 4270 days ago | link

I just ran the following at the repl:

  arc> ([(prn "You entered " _)] 34)
  You entered 34
  Error: "...urces/arc/ac.scm:974:33: arity mismatch;\n the expected number of arguments does not match the given number\n  expected: 1\n  given: 0"
Do you see something different? I think your defop expression is also incorrect. It just happens to have the right side-effect before it runs into the error. You probably have errors at the server -- that aren't visible on the browser.

Edit: I kept having this feeling I'd already pointed this out to you -- and I just found it :) http://arclanguage.org/item?id=16356

-----

1 point by lark 4270 days ago | link

I see the following:

  arc> ([(prn "You entered " _)] 34)
  You entered 34
  Error: "car: expects argument of type <pair>; given ()"
That's good investigation. Note the work described in this thread uses Arc 3.1, not Anarki.

Btw do you mean there's something wrong with defop, or that the example I wrote is incorrect? I had gotten that example from: http://arcfn.com/doc/srv.html

-----

3 points by rocketnia 4270 days ago | link

The examples at arcfn say [do (prn ...) ...] and [w/link (pr ...) ...]. At some point you changed one of these to [ (prn ...)] for your example.

-----

1 point by lark 4269 days ago | link

Thanks. I understand one should write:

  [do (prn "...")]
I support one shouldn't. The do should be implicit.

-----

2 points by Pauan 4269 days ago | link

The reason it does that is so that things like [+ _ 1] work. Under your suggestion, you would have to write [(+ _ 1)] which looks ugly.

Rather than using [(prn ...)] you can just use [prn ...]

---

Incidentally, using Arc/Nu, it's easy to make the square brackets behave the way you want them to:

  (mac square-brackets args
    `(fn (_) (do ,@args)))
I believe Anarki has something similar as well.

-----

1 point by akkartik 4271 days ago | link

I wasn't aware of aformh before, but yes it's not supposed to redirect. But arformh is.

-----