Hi,
I know this has been discussed somewhat at length (e.g. here
http://groups.google.com/group/liftweb/browse_thread/thread/27aed5f45faf759/a261a2dfe0ae7207?lnk=gst&q=attributes+bind#a261a2dfe0ae7207)
but I still think the default behaviour of -> should be reconsidered if
at all possible. Here's why:
I went through our app fixing small UI annoyances. One is missing tab
index on input fields. I knew this has been working previously.
Template:
<ol><li>
<label for="email">{S.??("email.address")}</label>
<user:email user:tabindex="1"/>
</li><li>
<label for="password">{S.??("password")} (<a
href={lostPasswordPath.mkString("/", "/",
"")}>{S.??("recover.password")}</a>)</label>
<user:password user:tabindex="2"/>
</li>
</ol>
Code:
bind("user", loginXhtml,
"email" -> (FocusOnLoad(<input type="text" name="username" id="email"
class="text"/>)),
"password" -> (<input type="password" class="password" id="password"
name="password"/>),
"submit" -> (<input type="submit" class="submit"
value={S.??("log.in")}/>))
Note the user:tabindex attribute which used to emit a tabindex attribute
in the HTML (this has been changed cf. the conversation above)
I can now change user:tabindex to tabindex and -> to -%> and I get the
tabindex parameter emitted. There are a few problems with this:
1) It doesn't work for the email field since it doesn't bind an Elem but
a NodeSeq (so -%> wouldn't now where to attach the attributes. You could
attach the attributes to the first elem in the NodeSeq (which would work
here), but this doesn't sound like a nice general solution)
2) I have to change my code if I need to introduce attributes on the
rendered elem (ignore the fact that my template code already contains a
class attr :-)
3) To change the email field, I came up with this which seems rather
verbose, but perhaps there's a better way?
"email" -> {_:NodeSeq =>
val n = BindHelpers.currentNode openOr scala.xml.NodeSeq.Empty
(FocusOnLoad(mixinAttributes (<input type="text" name="username"
id="email" class="text"/>)(n).first.asInstanceOf[Elem]))},
Because of 2) I'm tempted to always use -%> in bind. I would like UI
info to be editable by our UI guy without having to change code when
introducing new attributes.
But If I use -%> always, it might as well be the default mode of
operation :-) But maybe I'm the only person with such needs?
Imo, it boils down to the fact that I frequently need to specify
attributes in the markup code but have to either 1) anticipate this up
front in the binding or 2) Change both markup and code when a change is
introduced.
I'm not sure what the best solution is but to me it looks like the
problem that needs solving is where to attach the attributes specified
in the markup?
Before trying to solve this I'm interested in gauging the possibility of
changing this at all :-)
/Jeppe
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
