I think you've misunderstood my post. As you can see, options is not something passed in as an attribute but rather and options for the select menu, generated by the original tag.
Also, I definitely don't want radio buttons inside my select tag, thanks. How does this actually work? I may take a look on Kristian Mandrup's work to shed some light on this issue, given some free time here.. ;-) --Peter On Nov 15, 9:01 pm, kevinpfromnm <[email protected]> wrote: > 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.
