URL after {render_other, ..... }

31 views
Skip to first unread message

Graeme Defty

unread,
Feb 2, 2012, 1:41:42 AM2/2/12
to chica...@googlegroups.com
I am not sure if this question even makes sense so bear with me . . .

When I do a render_other, the URL that shows in the browser is not that related to the rendered screen, but the one related to the action which gave rise to the render.

For example, say I am on a page with URL .../player/list/team-123 which shows all the players in a particular team. Beside each player I have a 'delete' link which allows him to be removed from the team.

I click the link for .../player/delete/player-789

and then in the delete function there is some validation error (maybe that player is the captain so cant be deleted).

Now I want to get back to the player/list screen with an error message shoeing, but since we are in the delete function, i need to do a render_other.

I do the render_other (providing my error message as a variable) and the team list shows up again beautifully looking the same as before with the addition of my error message on it  BUT  the URL at the top, instead of .../player/list/team-123 as before is now showing .../player/delete/player-789.

This has no effect on the processing AFAICS but looks a bit confusing from the user's POV.

SO . . .
1) is it possible to make the URL match the displayed screen? (Or is it controlled by the browser?)
2) is there some reason NOT to do this?
3) am I missing something?  (maybe a "better way"?)

Thanks,

g



Jose Luis Gordo Romero

unread,
Feb 2, 2012, 3:02:11 AM2/2/12
to chica...@googlegroups.com
HI Graeme,

Looks like you need to make a redirect to the player list. And for pass the error msg between requests (you make's 302 in the middle), you can use the boss_flash module (this stores the error msg in the session and automatically put it in the view after the redirect).

In the controller (player/delete) after you hit the error:

boss_flash:add(SessionID, notice, "I can't delete this player because..."),
{redirect, ...} <- Player list

When the user goes to player lists, the rendered template will have a boss_flash erlydtl var filled (a list of flash messages):

{% for flash in boss_flash %} {{ flash.method }} - {{ flash.title }} - {{ flash.message }} {% endfor %}

I hope that is what you need :)

--
Jose Luis Gordo Romero



2012/2/2 Graeme Defty <graeme...@gmail.com>

Graeme Defty

unread,
Feb 2, 2012, 4:21:47 AM2/2/12
to chica...@googlegroups.com
Jose,

Yes, I wanted to redirect but did not know how to pass the message. I missed the flash feature.

Sadly I do not yet use boss sessions. I built my own login/user-tracking mechanism at the start (my application was written before boss had sessions) and I have not converted to use sessions yet.

I do notice that my screens have a session id cookie, so i am guessing I have sessions even though I have done nothing specific to cause them, so maybe I can use them only for this and keep my own mechanism in parallel for now. I will give it a go.

Also, I will not use the flash message directly in the view as I already have an error mechanism which is all through my screens (actually only in the skeleton - lol) but will pull the data from flash in the player:list('GET',....) function and use it to populate the screen fields.

Anyway, thanks for the pointer.

g

_______________________________________________

Graeme Defty

unread,
Feb 3, 2012, 3:59:14 AM2/3/12
to chica...@googlegroups.com
I know you will not be surprised, but I am happy to report that it works like a charm!

In the end I used a session variable - flash did a little more than I wanted.

One obvious suggestion I would make is that remove_session_data/2 would be better returning {ok, Data} rather than just 'ok'. That would save having to do get_session_data/2 immediately followed by remove_session_data. (This is similar to boss_flash:get_and_clear - maybe to save breaking existing code a new get_and_remove would be better?)

Otherwise, very nice facility.

Thanks again for the help,

g
___________________________________
Reply all
Reply to author
Forward
0 new messages