Removing bind() really messed up a lot of my codebases

169 views
Skip to first unread message

David Pollak

unread,
Apr 25, 2015, 5:24:48 AM4/25/15
to liftweb
Folks,

Removing Helpers.bind() and support for the old XML namespace stuff in Lift really, really, really messed up a *lot* of my old codebases... ones that relied on Wizard, etc.

Is there any migration path or ideas about how to deal with codebases that rely on XML and XML namespace stuff?

Thanks,

David

--
Lift, the simply functional web framework http://liftweb.net

Richard Dallaway

unread,
Apr 25, 2015, 4:43:57 PM4/25/15
to liftweb

Idea: could the XML bind code be turned into a module or standalone library of some kind?


--
--
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

David Pollak

unread,
Apr 26, 2015, 2:50:33 AM4/26/15
to liftweb
I'm not sure why the bind() code went away... I'll do some research into the history when I'm back in the states (Google groups/gmail via VPN from China is suboptimal).

We can just move the APIs someplace else in Lift other than Helpers... it's not taking up that much space.

But having a silent breaking change (Wizard and Screen stuff just not working anymore) is really suboptimal. At the very least, we should have something during the boot phase that looks for common Wizard default templates and throws an exception if they are using the old XML bind tags. Finding out from a production user that stuff simply doesn't work after the security-related upgrade on a Lift 3.0 codebase is wicked, wicked lame.


Peter Brant

unread,
Apr 26, 2015, 7:26:27 AM4/26/15
to lif...@googlegroups.com
Oh, that sucks. So they were using 3.0-M1 before?

Removing bind() was discussed on the mailing list, the PR (#1568) was out there for a couple of months before it was merged, and this was mentioned in the 3.0-M2 release notes. I can definitely understand the frustration with being suddenly confronted with it though.

Pushing a 3.0-M1-1 with the security fixes might be the best solution for now. I don't think there should be any issues with putting the bind() code into a module for people that still need it. Some defensive checking at boot and in LiftScreen/Wizard sounds like a good idea too. I'll take a look at that.

Pete


Antonio Salazar Cardozo

unread,
Apr 26, 2015, 2:17:35 PM4/26/15
to lif...@googlegroups.com
On Sunday, April 26, 2015 at 2:50:33 AM UTC-4, David Pollak wrote:
We can just move the APIs someplace else in Lift other than Helpers... it's not taking up that much space.

Absolutely down to move this to a module (whether external or still managed in Lift's core build pipeline
doesn't really matter to me), but having two completely different approaches for template management in
the core framework is more confusing than useful, IMO. Obviously we want to make sure everything that's
there still works—and migration away from them is a big part of why we made a stable M0/M1 release that
preceded those changes. More on the interaction of that with the security patches below.
 
But having a silent breaking change (Wizard and Screen stuff just not working anymore) is really suboptimal.

I think it's just wizard that suffers from this. We communicated that LiftScreen switched to CSS selectors,
and I believe this is a compilation-breaking change for people who were using LiftScreen internally. I did not,
however, realize that wizard was built in such a way that it relied on BindHelpers without failing
loudly in client code when BindHelpers was removed. Looks like this was a bit thing we missed when we
made the CSS LiftScreen the main implementation, and even though a lot of those changes were open on
Github for a while and existed on the snapshot before going into a milestone build, I suspect no one who
uses wizard was on snapshot to find the breakage.

At the very least, we should have something during the boot phase that looks for common Wizard default templates and throws an exception if they are using the old XML bind tags. Finding out from a production user that stuff simply doesn't work after the security-related upgrade on a Lift 3.0 codebase is wicked, wicked lame.

That's fair, and I suppose it's the big hunking drawback for how long our Lift 3 release cycle has gone—
production apps on a really old build of a next major version that's only halfway through removing the
things that are deprecated in the previous major version.

I wouldn't be at all opposed to making an M1-1 build that included our XML patches over the M1 build.
Being on the hook for security patches to M1 until we've got all the proper migration pieces in place for
the Lift 3 final release seems pretty reasonable.
Thanks,
Antonio

Peter Brant

unread,
Apr 27, 2015, 5:06:53 AM4/27/15
to lif...@googlegroups.com
Nah, LiftScreen and Wizard are in the same boat. The Scala-side API didn't change. There are a number of additional features, but the previous one-size-fits-all template still works as before. Users of CssBoundScreen would have gotten a compilation error though (with the fix being just removing the reference to it).

Short of renaming them entirely, I'm not sure there really is anything we can do besides check this at runtime.

Pete

--

Antonio Salazar Cardozo

unread,
Apr 27, 2015, 2:01:13 PM4/27/15
to lif...@googlegroups.com
Ah, I see. Yes, that's definitely troublesome. 100% agree on doing some heuristics on the template and
throwing up a flag if it looks like you may be using an incompatible one.

Perhaps there's a way to do fairly straightforward rewriting of a template from the old style to one compatible
with CSS transforms?
Thanks,
Antonio
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

David Pollak

unread,
Apr 27, 2015, 4:25:35 PM4/27/15
to liftweb
Responding to the collection of posts...

Thank you all for taking the time to address this issue!

I appreciate the discussion and PR process. But in the future, when silently breaking changes are introduced, the changes should be accompanied by some form of active detection of old patterns... basically, if the compiler isn't going to alert the developer, Lift itself should. There will hopefully be very few "upgrade this minute" events in the future, but when there are, if things have changed out from under the developer, there should be some hint prior to production.

In terms of supporting only one templating mechanism, I'm in favor of this. There are, however, non-templating cased where I've used bind(). It's a useful mechanism for re-writing namespaced XML. Yes, the world is moving to JSON, but XML is still around. As a utility, given the number of lines of code, it should not be removed from Lift. I'm all for removing the methods from Helpers and shuttling them off to net.liftweb.util.XmlUtilities or somesuch.  In the instant case, I just copied the code from an old version of Lift into my codebase and Bob's your Uncle. But for others, Lift provides a lot of tools to a developer that's building server-side code. Removing a couple of K of class files from the Lift JAR doesn't seem to my mind warranted.

No need to build a 3.0-M1-1. I can fix the template.

Thanks!

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

For more options, visit https://groups.google.com/d/optout.

--
--
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+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Lift, the simply functional web framework http://liftweb.net

Peter Brant

unread,
Apr 27, 2015, 6:25:09 PM4/27/15
to lif...@googlegroups.com
Yeah, I thought of rewriting the template too. I think it probably qualifies as too clever though. The main potential issue is that the (customizable) class names used by Wizard/LiftScreen by default might already be used which could lead to a deeply confusing result.

Renaming the class names to force a compilation error may not be a horrible idea (even if that also comes with some substantial negatives).

Pete

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

For more options, visit https://groups.google.com/d/optout.

--
--
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+u...@googlegroups.com.

David Pollak

unread,
Apr 27, 2015, 7:51:02 PM4/27/15
to liftweb
So... there's another legacy bind() issue that I just hit...

If any of the *Xhtml methods in ProtoUser return old, bound XML rather than the new stuff, the forms silently don't work.

Fixing that issue now...
Lift, the simply functional web framework http://liftweb.net

David Pollak

unread,
Apr 27, 2015, 7:52:32 PM4/27/15
to liftweb
And I'm not sure why, but some of the menu items in the app are no longer showing up... I'll dig into that one next.

Sigh.

David Pollak

unread,
Apr 27, 2015, 7:56:15 PM4/27/15
to liftweb
And the password reset stuff in ProtoUser is broken because the way the form in bound is incorrect. I'll submit a patch tomorrow.

Antonio Salazar Cardozo

unread,
Apr 28, 2015, 10:49:59 AM4/28/15
to lif...@googlegroups.com
Agreed on silent failure needing active warnings—two things on that front:
 - There are parts of the code base that don't have clear knowledge from committers who were
   active when we made the change, so it's not surprising that some things slipped :/ I would have
   pushed for some sort of warning for sure… If I'd been familiar enough with screen and wizard to
   know it was necessary.
 - We're catching these before 3.0 goes final, which I consider to be a Good Thing™. Hurray!

Any thoughts on how we could have done a the big shift away from bind in the core
codebase in a better way, given the familiarity constraints of the folks who were active
at the time? Seems like a good opportunity to learn some lessons :)
Thanks,
Antonio
Antonio
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.

--
--
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.

--
--
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.
--
Lift, the simply functional web framework http://liftweb.net




--
Lift, the simply functional web framework http://liftweb.net

David Pollak

unread,
Apr 28, 2015, 1:38:32 PM4/28/15
to liftweb
One I already discussed... have something in the Boot process to look for well known templates and test them for XML binding and throw during Boot process if there are XML artifacts floating around. Maybe this is done in dev and test mode, but not in production.

In terms of the embedded templates in User, wrapping each call that asks for the template with XML testing in dev/test mode.

Also, having an up-to-date sample project or 7 things project against 3.0-SNAPSHOT and running through a smoke test of basic functions against one or both before a major change where the person doing the change knows there could be silent breakage.

Finally, at the meta/macro level... keeping in mind that Scala coders rely on the compiler for many of the "tests" of code correctness. With this in mind, where there are breaking changes that will not be picked up by the compiler, working on a strategy for making sure the Lift developers get other notifications/alerts/hints about code correctness in the face of the breaking changes will continue to align Lift with the mindset of the kind of developers who use Lift/Scala.

More concretely, if there's a PR with a silent breaking change, the developer should flag the PR as such and include a strategy for alerting developers of the silent breaking change outside of the mailing list/PR process.

Antonio

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

For more options, visit https://groups.google.com/d/optout.

--
--
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+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
--
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+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
--
Lift, the simply functional web framework http://liftweb.net




--
Lift, the simply functional web framework http://liftweb.net




--
Lift, the simply functional web framework http://liftweb.net

--
--
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+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

ti com

unread,
Jul 8, 2015, 2:01:54 PM7/8/15
to liftweb
On Sun, Apr 26, 2015 at 2:17 PM, Antonio Salazar Cardozo <savedf...@gmail.com> wrote:
On Sunday, April 26, 2015 at 2:50:33 AM UTC-4, David Pollak wrote:
We can just move the APIs someplace else in Lift other than Helpers... it's not taking up that much space.

Absolutely down to move this to a module (whether external or still managed in Lift's core build pipeline
doesn't really matter to me), but having two completely different approaches for template management in
the core framework is more confusing than useful, IMO. Obviously we want to make sure everything that's
there still works—and migration away from them is a big part of why we made a stable M0/M1 release that
preceded those changes. More on the interaction of that with the security patches below.
 
But having a silent breaking change (Wizard and Screen stuff just not working anymore) is really suboptimal.

I think it's just wizard that suffers from this. We communicated that LiftScreen switched to CSS selectors,
and I believe this is a compilation-breaking change for people who were using LiftScreen internally. I did not,
however, realize that wizard was built in such a way that it relied on BindHelpers without failing
loudly in client code when BindHelpers was removed. Looks like this was a bit thing we missed when we
made the CSS LiftScreen the main implementation, and even though a lot of those changes were open on
Github for a while and existed on the snapshot before going into a milestone build, I suspect no one who
uses wizard was on snapshot to find the breakage.

At the very least, we should have something during the boot phase that looks for common Wizard default templates and throws an exception if they are using the old XML bind tags. Finding out from a production user that stuff simply doesn't work after the security-related upgrade on a Lift 3.0 codebase is wicked, wicked lame.

That's fair, and I suppose it's the big hunking drawback for how long our Lift 3 release cycle has gone—
production apps on a really old build of a next major version that's only halfway through removing the
things that are deprecated in the previous major version.

i wonder if it would be an improvement, if feature releases would be for a fixed set of changes from day one, any other breaking changes go into a future version, then you have shorter releases and you can break changes, but people don't get caught off guard because from day one everyone knows that version X is going to have change Y

 

I wouldn't be at all opposed to making an M1-1 build that included our XML patches over the M1 build.
Being on the hook for security patches to M1 until we've got all the proper migration pieces in place for
the Lift 3 final release seems pretty reasonable.
Thanks,
Antonio

--
Reply all
Reply to author
Forward
0 new messages