Binding data-xxx attributes via CssSel

[Gustav van der Merwe]

I'm trying to target some data attributes in my template markup via some CssSel. At first I thought it would be a simple matter of template like so:

<div id="specific-id" data-xxx=""> </div>

and snippet CssSel binding like so:

"#specific-id [data-xxx]" #> model.xxx.value

but when I look at the generated page the data attribute is still empty; data-xxx="".

The above code when put into a sample project works fine.

However, for my full project (of which I can not share the source to unfortunately) it does not. I thought it may be that the snippet was set to eagerly evaluate which I tested but made no difference. The rest of the CssSel binders before and after the ones for the data attributes work and all of the are chained properly with &.

Given all of the above, I am at a loss as to why the binding would not work as expected.

Any ideas at all?

Regards,
Gustav van der Merwe

[Richard Dallaway]

Curious. What's the type and value of model.xxx.value? And is this Lift 3 or 2.6?

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gustav van der Merwe]

On 03/24/15 14:26, Richard Dallaway wrote:
> Curious. What's the type and value of model.xxx.value? And is this Lift 3 or 2.6?

Lift 3.0-M5. This actually happens for several fields on the model

Model extends MongoRecord[Model] with ObjectIdPk[Model] {
object xx1 extends StringField(this, 128)
def xx2 = { "calc some string" }
}

This values work in other contexts.

Regards,
Gustav van der Merwe

[Richard Dallaway]

One thing that springs to mind: does the block of bindings you have effect later one? E.g., so that you need to be using andThen rather than &.

[Gustav van der Merwe]

On 03/24/15 14:59, Richard Dallaway wrote:
> One thing that springs to mind: does the block of bindings you have effect later one? E.g., so that you need to be using andThen rather than &.

OMG, yes!

Ok, so, let me get this straight. If a CssSel works on a NodeSeq then any subsequent operations must use andThen rather than &? Does & parallelise rendering such that it will only end up using one of the rendered results rather than merging them?

[Richard Dallaway]

I think of each & applying individually to the original template; and andThen as chaining parts of the bindings together (feeding the result of one into the next).

[Joe Barnes]

This has tripped me up often in the past too.  I generally just blindly use andThen now days because chaining as Richard describes is generally what I intend to happen.

Joe

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

[Antonio Salazar Cardozo]

The specific effect is that a single node will only be visited once by a group of CssSels joined

by &. A node is “visited” when a selector affects it directly (e.g. "node" #> ...) or if its parent is

affected (e.g., "parent" #> or "parent *" #>). Attribute modification won't mark the node visited

(e.g., "node [onclick]" #> ... & "node [onkeypress]" #> ... is fine).

& is optimized to do a single pass through the whole original template to apply the changes

specified by the chained transforms, with the caveat above. andThen means you'll traverse

the template once for the part before andThen, then traverse the full result for the part after

andThen, etc.

Hope that clarifies things a bit. There's a still-incomplete document on CSS selector transforms

in Lift master, and it has a section on this. Let me know if the description there is unclear and

how it might be improved (I realize examples would be a good improvement there).

Thanks,

Antonio