I know it's not a passed attribute, but I was referring to the fact it's a local variable of sorts. Getting those outside the original tag definition is tricky.
On Nov 15, 11:04 pm, Peter Ehrlich <[email protected]> wrote: > 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.
