I'm pretty sure since you're not directly in the tag definition, you
can't call attributes passed or generate (like options) without using
all_attributes. I might be completely wrong though, I haven't run
into this particular need myself.
<repeat with="&all_parameters[:options]">
...
Your replace on select drops the select wrapper btw so your radio
buttons won't be in a select tag.
If all else, since you're having to set a flag on the input call
anyway, you might just make a new tag that calls the regular input
with your replacement.
<def tag="radio-input">
<input merge>
<select:>
<radio-button-tag repeat="&all_parameters[:options]" /> # not
sure why you passed options &this in your above code. it's available
as 'this' already if it's the current context.
</select:>
</input>
</def>
On Nov 15, 12:37 am, Peter Ehrlich <[email protected]> wrote:
> Hmm, thanks for the great post. I can see I definitely need to delve
> in here and see how the machine works under the hood.
>
> What I'm trying to do right now is to, In good DRY fashion, extend the
> select tag to have an option for radio buttons. Here's the original
> function:
>
> <def tag="input" for="HoboFields::EnumString" attrs="labels, titleize,
> first-option, first-value"><%
> logger.warn "SELECT: #{attributes.inspect}
> ttlize:#{all_attributes.inspect}"
> labels ||= {}
> labels = HashWithIndifferentAccess.new(labels)
> titleize = true if titleize.nil?
> options = this_type.values.map {|v| [labels.fetch(v, titleize ?
> this_type.translated_values[v].titleize :
> this_type.translated_values[v]), v] }
> %>
> <select name="#{param_name_for_this}" merge-attrs param>
> <option value="#{first_value}" unless="&first_option.nil?"><first-
> option/></option>
> <%= options_for_select(options, this) %>
> </select>
> </def>
>
> That being perfectly nice code, it makes some* sense to use it again.
> Here's what's not working for me:
>
> <extend tag="input" for="HoboFields::EnumString" attrs="radio">
> <old-input merge>
> <select: replace>
> <% if radio %>
> <% logger.warn this.inspect %>
> <repeat with="&options">
> <radio-button-tag options="&this"/>
> </repeat>
> <% else %>
> <restore/>
> <% end %>
> </select:>
> </old-input>
> </extend>
>
> Unfortunately, this.inspect comes up as nil and options is not
> defined. Is there something theoretically wrong with what I'm
> trying? I'm quite surprised that 'this' is nil and was hoping that
> the extension would take place in the same scope, with options
> available. Thoughts?
>
> Cheers, Thanks,
> --Peter
>
> On Nov 11, 2:45 pm, Matt Jones <[email protected]> wrote:
>
> > On Nov 11, 2010, at 11:46 AM, Peter Ehrlich wrote:
>
> > > So I have this page, with a bunch of stuff on it. This page has more
> > > stuff on it if an admin views it, and some of the stuff is modified.
>
> > > (Don't just immediately say admin subsite...)
>
> > > The way I'm currently doing this is by having a bunch of conditions
> > > riddled throughout the page. The way I would like to do it, is to
> > > have a section below </show-page> that looks something like this:
>
> > > <extend tag="show-page">
> > > <old-show-page merge>
> > > <if test="@current_user.admin?">
> > > <my-div:>
> > > do stuff
> > > </my-div:>
> > > <append-content:>
> > > Do more stuff
> > > end
>
> > > Nice. DRY. Debuggable and clear. Supported?
>
> > To me, extending tags in view files seems like a Bad Thing. Sort of like if
> > you saw code like this in a controller action:
>
> > def index
> > ...
> > if @some_condition
> > SomeModel.class_eval do
> > include SomeModule
> > end
> > end
> > ...
> > end
>
> > > The only way I can think of getting close is by throwing a bunch of
> > > extend tag definitions inside of a condition in application.dryml. No!
>
> > That wouldn't work anyways, as I don't think anything besides define,
> > include and extend are allowed in taglibs - and would also have issues
> > since application.dryml is only compiled once in production mode, where the
> > ifs wouldn't make any sense...
>
> > Re: the divide between parameter and not-parameter tags - the biggest
> > blocking point is the ability to name parameters implicitly. For instance,
> > these two snippets do different things:
>
> > <form:>
> > <field-list:>
> > <some-field-label:>FOO</some-field-label:>
> > <field-list:>
> > </form:>
>
> > vs.
>
> > <form:>
> > <field-list>
> > <some-field-label:>FOO</some-field-label>
> > <field-list>
> > </form:>
>
> > The top one changes the label of some_field in the existing list, the
> > bottom drops the entire existing contents of the form tag and replaces them
> > with a default field-list with some_field's label changed.
>
> > The other issue with structures like:
>
> > <some-tag>
> > <if test="&something">
> > <some-param:>FOO</some-param:>
> > </if>
> > </some-tag>
>
> > Is that DRYML isn't executed in one "pass"; the tags are expanded to ERB
> > code and parameter-style tags are converted to procs. The resulting ERB is
> > (I believe) cached in production mode, and then executed when a page is
> > rendered. Kristian Mandrup did some pretty neat stuff opening up some of
> > these internals - at least one piece is still up
> > athttps://github.com/kristianmandrup/hobo_dryml_uncovered, which dumps the
> > post-parsing ERB to the filesystem.
>
> > Re: conditionally swapping out page bits. To tidy things up, you could
> > define a tag to encapsulate the condition if it's the same everywhere.
> > Thus, things like:
>
> > <if test="¤t_user.admin?">
> > ...
> > </if>
> > <else>
> > ...
> > </else>
>
> > Could at least be cleaned up to:
>
> > <if-admin>
> > ...
> > </if-admin>
> > <else>
> > ...
> > </else>
>
> > with a tag like:
>
> > <def tag="if-admin">
> > <if test="¤t_user.admin?">
> > <do param="default" />
> > </if>
> > </def>
>
> > (the <if> form is better here than a straight ERB if, as it sets the
> > underlying variable that makes <else> work...)
>
> > Another option that might make sense (depending on the amount of code
> > involved) would be to extend/redefine the show-page tag for this model
> > class in application.dryml and then conditionally render a different file
> > for admins:
>
> > (in the controller)
> > def show
> > hobo_show do
> > render :action => 'admin_show' if current_user.admin?
> > end
> > end
>
> > app/views/model_name/admin_show.dryml could then contain whatever parameter
> > overrides are needed. I'm not sure, however, if this would be more or less
> > readable than the version with inline conditionals - I find that too many
> > parameter calls (especially append- and friends) sometimes make it tough to
> > scan the code and know what will actually get run..
>
> > --Matt Jones
--
You received this message because you are subscribed to the Google Groups "Hobo
Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/hobousers?hl=en.
