accessing data types and if statements

[hobo_hippy]

I'm modifying a card;

<def tag="card" for="User">
<card class="user" param="default" merge>
<header: param>
<h4 param="heading"><a><name/></a></h4>
<a action="new" if="@user.administrator==true" to="&model"
param="new-link"/>
</header:>
</card>
</def>

I'd like the if statement to only let the button be visible if the
user is the administrator:

<a action="new" if="@user.administrator==true" to="&model" param="new-
link"/>

i also tried

<a action="new" if="@user.administrator" to="&model" param="new-link"/
>

since user.administrator is a boolean anyway. Either way, I get:

compile error
app/views/taglibs/application.dryml:20: syntax error
output_buffer.concat " "; concat((if !
(this.@user.administrator==true).blank?; (__tmp_1 = call_tag_parameter
(:a, {:action => "new", :to => (model)}, {},
all_parameters, :new_link); Hobo::Dryml.last_if = true; __tmp_1) else
(Hobo::Dryml.last_if = false; ''); end)) ; output_buffer.concat "\n"

I suppose I'm still unfamiliar with the data nomenclature. I'm sure
this is a quick fix so if anyone could shout out some help, I'd
appreciate it.

THANKS!

[Montgomery Kosma]

Maybe I've missed something, but I don't see the if="test" syntax in
the taglibs help at http://cookbook.hobocentral.net/api_tag_defs/a ...

Have you tried one of these approaches?

<if test="&@user.administrator">
<a action="new" ...>
</if>

or

<%= if @user.administrator %>
<a action="new" ...>
<%= end %>

Frankly, I'm not sure either of these is correct, so I look forward to
hearing what happens for you. I've been smacking my own head over
conditionals in dryml, finding that it is very unpredictable what will
and will not work.

On Jun 15, 5:26 pm, hobo_hippy <87bee...@gmail.com> wrote:
> I'm modifying a card;
>
> <def tag="card" for="User">
>   <card class="user" param="default" merge>
>     <header: param>
>       <h4 param="heading"><a><name/></a></h4>
>       <a action="new" if="@user.administrator==true" to="&model"
> param="new-link"/>
>     </header:>
>   </card>
> </def>
>
> I'd like the if statement to only let the button be visible if the
> user is the administrator:
>
> <a action="new" if="@user.administrator==true" to="&model" param="new-
> link"/>
>
> i also tried
>
> <a action="new" if="@user.administrator" to="&model" param="new-link"/
>
>
>
> since user.administrator is a boolean anyway. Either way, I get:
>
> compile error
> app/views/taglibs/application.dryml:20: syntax error
> output_buffer.concat "      ";  concat((if !

> (th...@user.administrator==true).blank?; (__tmp_1 = call_tag_parameter

[Bryan Larsen]

Try if="&@user.administrator" or if="#{@user.administrator}"

You want to tell Hobo that the part inside the quotes is ruby code.
Both mechanisms do this.

Now there are some attributes where only ruby code makes sense, so the
& can be omitted, but that often gives slightly different results. In
this case, Hobo is assuming that you are providing a method name
instead. So if="administrator" should also work for you.

if="&this.administrator" would be more idiomatic Hobo than
if="&@user.administrator", although they would both work. The former
is code that could be reused on other types of objects -- the latter
only would work on User's.

cheers,
Bryan

[hobo_hippy]

Great success! if="@this.administrator" works perfectly, not to
mention looks pretty clean.

I'm getting too used to saying this, but Thanks Bryan!

[hobo_hippy]

Ok, new situation. Now I'm working inside the main-nav definition. The
line of interest is:

<nav-item if="&acting_user.user" with="&Blog">Company Blog</nav-item>

I figure I can't use "this" because it would refer to the nav-item,
not the user? I'm don't completely understand the polymorphic rules as
far as how "this" would inherit some thing. Anyways, I tried all of
these:

acting_user == user
acting_user.user
acting_user.user?
&acting_user == user
&acting_user.user
&acting_user.user?
@acting_user == user
@acting_user.user
@acting_user.user?

no to avail. I get either compile errors, nil errors, or no method
errors. is what I'm trying to do even allowed? I could've sworn I've
gotten this to work in the past - that is, I want a menu Item only to
be visible to logged in users.

[hobo_hippy]

wait, wait, I'm an idiot. this works just fine:

<nav-item if="&@User" with="&Blog">Company Blog</nav-item>



simple simple simple :)

[hobo_hippy]

ACK!

nope, I spoke too soon. that just hides it. How do I modify that to
make the statement true if whoever is logged in is a User? That way
only users will see the menu item...

[magicseth]

You should try this:

<nav-item if="&logged_in?">

current_user could potentially be a guest if they have not logged.

[Bryan Larsen]

current_user is what you're looking for. The difference between
current_user (used in the view) and acting_user (used in the models) is
a common source of confusion.

Why are they different? You'd have to ask Tom, but I can imagine
scenarios where they might actually be different values.

cheers,
Bryan

[Tom Locke]

> current_user is what you're looking for. The difference between
> current_user (used in the view) and acting_user (used in the models)
> is
> a common source of confusion.
>
> Why are they different? You'd have to ask Tom, but I can imagine
> scenarios where they might actually be different values.

Consider me asked : )

Although it is a common source of confusion, it's actually fairly
important to understand the difference between the two concepts, or
you're at risk of messing up your nice MVC separation. current_user
only makes sense in conjunction with the idea of a "current session",
which only exists in the view and controller layers. That's why in
'normal' Rails apps you just can't get at that information from the
model.

But it struck me that "this model-level action is happening on behalf
some specific user" is such a fundamental aspect of the kind of apps
we right, that it was a good idea to support this in the model layer.
As Bryan says, it's not _necessarily_ the current_user from the
session. Rather, it's the user who is performing this action - the
acting_user.

Sometimes a common source of confusion is a good thing, because what's
actually going on is a common misconception, and the confusion is an
opportunity to straighten things out.

Tom

[hobo_hippy]

I gotta wrap my head around that for a bit.


Thanks Tom!