Okay, I wrote an implicit + operator combo that scraps most of the boilerplate.

Snippet code:

  def howdy(in: NodeSeq): NodeSeq =
      bind("foobar", in, "foobaz" -%%> FocusOnLoad(<input type="text" 
name="username" id="email" class="text" input:attrs="" />))

(input:attrs="" is the magic)

Template code:

        <lift:helloWorld.howdy>
            <foobar:foobaz input:class="monkey" />
        </lift:helloWorld.howdy>

Output:
            <input id="email" name="username" type="text" class="text monkey" 
/><script type="text/javascript">
// <![CDATA[
jQuery(document).ready(function() {document.getElementById("email").focus();});
// ]]>
</script>

The -%%> operator will scan all the nodes on the right hand side looking for a 
special prefix:attrs attribute, which it will replace with all the prefixed 
attributes from the template that start with the prefix, combining style and 
class attributes as before. This gives you the same flexibility as %% 
currentPrefixedAttrs with somewhat less typing (and more magic), plus you can 
attach attributes to different nodes:

  def howdy(in: NodeSeq): NodeSeq =
      bind("foobar", in, "foobaz" -%%> (<input type="text" name="username" 
id="email" class="text" username:attrs="" />
                                        <input type="text" name="password" 
id="email" class="text" password:attrs="" />))

Note that I wrote it to scan only shallowly -- if you have a nested output it 
will only look at the outermost elements. A recursive version would probably be 
trivial.

I posted the entire code to git so you can take a look -- 
http://www.github.com/dridus/test-bindparams

The heart of the code is 
http://github.com/Dridus/test-bindparams/blob/master/src/main/scala/test/lib/BindParamExtensions.scala

-Ross

On Nov 28, 2009, at 9:24 AM, Jeppe Nejsum Madsen wrote:

> Ross Mellgren <dri...@gmail.com> writes:
> 
>> I'm not sure if this addresses your points, but I figured I'd throw  
>> out what I've been doing in case it helps.
> 
> It's always nice to see how others approach a problem!
> 
>> I don't use -%>, but I do use something similar along with another  
>> implicit so I can place the attrs in exactly the right place, and it  
>> automagically combines class and style attributes correctly. Some  
>> example code:
>> 
>> bind("user", loginXhtml",
>>      "email" -> (FocusOnLoad(<input type="Text" name="username"  
>> id="email" class="text" /> %% currentPrefixedAttrs("input")),
>>      ...)
> 
> Much cleaner than my version :-)
> 
>> I think personally that the default behavior of bind is correct and  
>> least surprising, since (at least for me and the applications I have)  
>> it's very common that a single bound tag does not map one to one to a  
>> result elem.
> 
> I don't think I disagree that the current bind is very clean and easy to
> understand. I guess the bind use cases can be divided in two:
> 
> 1) The bound element is (conceptually) replaced with a single element
> e.g an input field. I think the example above falls in this category
> even if it outputs several elements (ie input, script etc)
> 
> 2) The bound element is replaced with a more complex NodeSeq.
> 
> The current bind works fine for 2), but 1) I think can be made
> easier. Your approach is a step in the right direction, but I still feel
> there's too much boilerplate. Basically it should be natural to always
> use this approach whenever a single element is (conceptually)
> output. That way it's easy to add/change attributes in the template
> afterwards without changing the bind code.....
> 
> /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.
> 
> 

--

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.


Reply via email to