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 at
https://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.
