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.
