On Sun, Apr 25, 2010 at 8:53 AM, Colin L. [email protected]
wrote:
Or copy it into an @ variable in the controller action to make it
available in the rendered view. But I believe for the OP’s problem he
does not require to use params (or persistence) at all. See my
previous post.
My impression is that the OP is trying to set a variable in one view
(and yes, that’s the wrong place to do it regardless):
app\views\expenses\new.html.erb
and have it show up in another:
“But the “params … true” setting is not conveyed to the
app\views\vendors\show.html.erb page.”
Hence the issue of persistence…
–
Hassan S. ------------------------ [email protected]
twitter: @hassan
On 25 April 2010 17:07, Hassan S. [email protected]
wrote:
app\views\expenses\new.html.erb
and have it show up in another:
“But the “params … true” setting is not conveyed to the
app\views\vendors\show.html.erb page.”
Hence the issue of persistence…
I believe he has been trying to do that, but is that what he needs to
do? Can he not just set the condition variable in the controller
action? With a parameter on the link calling the action if necessary.
Colin
On 25 April 2010 18:44, Hassan S. [email protected]
wrote:
available.
You may be right, I did not read as much into the OPs question as you
have. I assumed that any redirect to show from the create should
include the extra link, rather than specifically a create initiated
from the link you mention. If my interpretatioin is correct then he
can just specify a parameter in the redirect_to :action => ‘show’ in
the create action. If your interpretation is correct (which it may
well be having re-read the original post) then I agree with your
analysis. I would probably put something in the session for this
case.
Over to you Richard - what is your requirement in this regard.
Colin
On Sun, Apr 25, 2010 at 9:40 AM, Colin L. [email protected]
wrote:
I believe he has been trying to do that, but is that what he needs to
do? Can he not just set the condition variable in the controller
action? With a parameter on the link calling the action if necessary.
Not according to the examples provided – there’s a link shown to e.g.
/vendors/new, which would presumably lead to a POST request to a
create action, which would then redirect to a new GET request for
/vendor/:id show - which is where the OP says he wants that value
available.
–
Hassan S. ------------------------ [email protected]
twitter: @hassan
Hi Colin,
In the controller method that is rendering the page that has the
conditional link displayed set a variable
@show_new_expense_page = true
at the point in the code where you know that you wish to show the link.
In the view then just use if @show_new_expense_page on the link display.
===============
Colin
You’re right. I didn’t [fully] understand your advice.
Specifically, I didn’t take note of:
“at the point in the code where you know that you wish to show the
link”.
Now that I do, the short answer is IT WORKS!! But why, when I need
to set a variable in one controller and access a variable of the same
name in a DIFFERENT controller? Following your advice,
I wrote:
-
Set @show_new_expense_page = true in
app\controllers\expenses_controller.rb#new
-
Reference @show_new_expense_page in
app\controllers\vendors_controller.rb#show
This approach works:
when I click “New Expense” link in app\views\expenses\new.html.erb and
then click Create in app\views\expenses\new.html.erb,
I then see the following links displayed:
Edit | Back | New Expense
But, there’s a glitch: I need to reset @show_new_expense_page to
false
after exiting app\views\expenses\new.html.erb by any of the six links
in it:
Home Vendor Expense Edit | Back | New Expense
Failure to employ this reset leads to, e.g.
clicking “New Expense” in app\views\expenses\new.html.erb,
clicking “Vendor” in app\views\expenses\new.html.erb
clicking “Show” on any of the vendors displayed in app\views\vendors
\index.html.erb.
But the following ameliorates this problem::
=== app\controllers\vendors_controller.rb ===
class VendorsController < ApplicationController
[snip]
def index
@vendors = Vendor.all
@show_new_expense_page = false
[snip]
Maybe another navigation will, over time, reveal another weakness.
But armed with this new understanding, acquired from you, will see me
over any such hurdles.
Thanks for continue to urge me to adopt this approach.
Best wishes,
Richard
On 26 April 2010 13:31, RichardOnRails
[email protected] wrote:
Specifically, I didn’t take note of:
false
But the following ameliorates this problem::
over any such hurdles.
Something is still not working as you think it is. An @ variable set
in a controller action only has life into the rendered view from that
action, there should be no need to reset it for another action. I
suggest you use ruby-debug (look at the rails guide on debugging,
google rails guides if necessary) and break into you actions and views
and work out what is going on. Also study the log file to see exactly
what is happening.
I have just seen your next post in reply to Marnen’s suggestion on
testing. I suggest you run for cover.
Colin
Hi Marnen,
Can I suggest that you supplement this with automated tests and version
control?
Absolutely! That’s definitely on my agenda. But this (first) Rails
app is intended to automate a substantial part of burden my son faces
in managing his small business. So, I’m focused on getting “version
1” of this app developed and deployed to prove that “help is on the
way.”
Using BDD and Subversion are my goals, but the learning curve for
effective use is time taken from a delivery date. I just spent more
than a week learning how to introduce navigation subtleties into my
app. I probably left this problem for “version 2” but I was annoyed
that my years of 20th Century computer-consulting skills were
inadequate for the 21st Century Web.
Now that I got a glimpse into handling this navigation problem, I off
to work on the last functionality required before version 1
deployment: authenticated users.
With thanks for your interest in my humble efforts,
Richard
Yes. I think you are totally missing how the Web works 
Funny, but oh so true!
The params hash represents name/value pairs passed from a client
(browser, typically) to your server, either as a GET request’s query
string, or as body parts of a POST request.
This is definitely one of the things I haven’t gotten into my head.
put it in session
I’m ready to add some version of an authenticated user, Authlogic, I
think. That should give me a session as my repository
store it in the DB
Ok, I could script/generate another a model, etc for another table
with CRUD methods.
hidden field in a form.
I see plenty of info on this via Google, which I’ll look into in time.
OK, I see several potential solutions to my problem. I’m going to
suspend this issue until I complete the user’s creation and packaging
a version 1 deliverable.
Many thanks,
Richard
On Apr 25, 11:45 am, Hassan S. [email protected]
RichardOnRails wrote:
Hi Marnen,
Can I suggest that you supplement this with automated tests and version
control?
Absolutely! That’s definitely on my agenda. But this (first) Rails
app is intended to automate a substantial part of burden my son faces
in managing his small business. So, I’m focused on getting “version
1” of this app developed and deployed to prove that “help is on the
way.”
As I’ve said before, you really must implement version control today.
It will take at most an hour or two, and it will make version 1 easier
to develop. Don’t wait another minute.
Using BDD and Subversion are my goals,
Not Subversion, please. Use Git.
but the learning curve for
effective use is time taken from a delivery date.
Wrong! If you take a few minutes to sharpen the saw, you will fell the
tree faster.
I just spent more
than a week learning how to introduce navigation subtleties into my
app. I probably left this problem for “version 2”
Yes, you probably should have.
but I was annoyed
that my years of 20th Century computer-consulting skills were
inadequate for the 21st Century Web.
Don’t let annoyance drive you into decisions that even you know are bad.
Now that I got a glimpse into handling this navigation problem, I off
to work on the last functionality required before version 1
deployment: authenticated users.
Authlogic. Done.
With thanks for your interest in my humble efforts,
Richard
Good luck! It’s always nice to see someone seriously learning.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Something is still not working as you think it is.
You’re right about that, especially the practice of setting @xxx in
one controller and (correctly) referencing it’s value in second
(unrelated by hierarchy) controller. I think that can only work by
meta-programming magic. I’m going to post a question about that at
some future time when I’m not consumed by the need for a deliverable.
… there should be no need to reset it for another action.
I left the conclusion out of my description of the problem, which
stated in full is:
Failure to employ this reset leads to, e.g.
clicking “New Expense” in app\views\expenses\new.html.erb,
clicking “Vendor” in app\views\expenses\new.html.erb
clicking “Show” on any of the vendors displayed in app\views\vendors
\index.html.erb.
leads to three links, “Edit | Back | New Expense” where there should
only be two: “Edit | Back”
Adding the reset clause led to correct behavior in a couple of tests,
I believe. In light of your misgivngs, I thought I should remove all
the params I introduced earlier. Now, the extra link appears again
at times I deem to be inappropriate. So either I was wrong before or
introduced another error.
In any case, I can’t spend any more time on this. As I just posted
Hassan, I’ll get back to this issue after I finish adding
authenticated users and package a “ver. 1” deliverable.
I have just seen your next post in reply to Marnen’s suggestion on
testing. I suggest you run for cover.
I’m a mere needle in a haystack comprised hundreds of millions of
Americans. Finding me to inflict punishment for violating “good
practices” will be inordinately difficult 
Thanks again for you continued contribution to my Rails education. I
hope you don’t find me incorrigible nor ineducable.
Best wishes,
Richard
Hi Hassan,
The “session” concept doesn’t imply “authentication” – it’s a Rails
built-in feature.
I didn’t think that one needed an authenticated user in order to have
a session. But I definitely thought one needed to have a User defined
in order to have session defined. So I was surprised that
“session[:symbol] = value” worked fine.
The app I’m working on will be stored on a server to be accessed by
perhaps 25 to 50 users on desktops connected through a LAN. Since
we’re on the topic, do I have to do any thing special to ensure that
each user has a distinct session inaccessible to all other users?
(I’ll check the Rails’ docs later.)
I am going to add Authlogic gem tomorrow, I think, so that the app can
provide secure user-login. I expect Authlogic will hook-up with the
already-working session mechanism.
Thanks for getting me going on the session approach. I’ve just got to
diagram the flow of control in my app (or maybe jot down a finite
state machine) to figure out where to stick my
session[:show_link]=true/false expressions.
Best wishes,
Richard
On Apr 26, 10:36 am, Hassan S. [email protected]
OK Marnen, your hectoring has overcome me: I got Git working with a
local repository
BTW, if you had mentioned that Linus Torvalds was the founder of
Git, I would have embraced it a lot sooner 
But BDD will have to wait for the addition of one more feature:
authenticated users.
Best wishes,
Richard
RichardOnRails wrote:
OK Marnen, your hectoring has overcome me: I got Git working with a
local repository
Excellent! If you don’t mind one more tip: commit far more often than
you think is necessary. Many little commits are often better than one
big one (unless it’s one conceptual change in the big commit).
BTW, if you had mentioned that Linus Torvalds was the founder of
Git, I would have embraced it a lot sooner 
But BDD will have to wait for the addition of one more feature:
authenticated users.
Understood. That’s admittedly a bit harder to set up. But do do it.
(Cucumber rocks!)
Best wishes,
Richard
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
If you don’t mind one more tip
On the contrary, I very much appreciate your advice. But I’m down
here in my own trench, so I have to operate on a time-table that
meets my current needs. It took me hours to set Git up.)
commit far more often than you think is necessary.
I’m on-board with this one, especially because it’s convenient to add
a descriptor of effect of the update or the status of the app by
virtue of the update… That’s a biggie.
But BDD will have to wait …
Understood … but do do it.
I’ts on my short-list of To-Do’s
Cucumber rocks!
The B’more on Rails local users group just did a nice presentation on
it aimed simultaneously at Cuc-newbies and -vets. It’s short-listed
also, and the presenters are friends, so I got local help should it be
needed.
Again, many thanks for your guidance,
Richard
On Mon, Apr 26, 2010 at 7:05 AM, RichardOnRails
[email protected] wrote:
put it in session
I’m ready to add some version of an authenticated user, Authlogic, I
think. That should give me a session as my repository
The “session” concept doesn’t imply “authentication” – it’s a Rails
built-in feature. And again it’s just a hash.
Set a value:
session[“somevar”] = “somevalue”
Read it anywhere:
session[“somevar”]
That’s all there is to it. (Yes, there is a 4k limit to data stored in
the
default Session::CookieStore – shouldn’t be a problem for you in
this example at least. But the API docs are your friend.)
HTH, and good luck,
Hassan S. ------------------------ [email protected]
twitter: @hassan
RichardOnRails wrote:
If you don’t mind one more tip
On the contrary, I very much appreciate your advice. But I’m down
here in my own trench,
That’s a bad sign right there. If you mean what I think you meant, it
implies that you’re a bit out of touch and probably working somewhat
inefficiently.
so I have to operate on a time-table that
meets my current needs.
Understood, but I’m not sure you fully appreciate how much time good
tools can save you.
It took me hours to set Git up.)
For God’s sakes, why? It should be simple.
commit far more often than you think is necessary.
I’m on-board with this one, especially because it’s convenient to add
a descriptor of effect of the update or the status of the app by
virtue of the update… That’s a biggie.
Yup! Welcome to the wonderful world of version control.
But BDD will have to wait …
Understood … but do do it.
I’ts on my short-list of To-Do’s
Great!
Cucumber rocks!
The B’more on Rails local users group just did a nice presentation on
it aimed simultaneously at Cuc-newbies and -vets. It’s short-listed
also, and the presenters are friends, so I got local help should it be
needed.
Excellent.
Again, many thanks for your guidance,
Richard
You’re welcome.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]