På søndag 19. mai 2013 kl. 17:11:39, skrev Matt Farmer <ma...@frmr.me>:Hey folks,Sorry I haven't been active on here much as of late. I'm hoping now that summer is upon us I'll feel a little bit less like I'm being pulled in a million different directions. (Yeah, right.) Anyway, I opened a pull request earlier this week that adds a new item to SHtml titled onEventIf. It works just like onEvent, with the difference that it prompts the user with a JavaScript confirm dialog before proceeding with the action. I didn't get around to opening a thread on it because it's something we needed for work and I wrote it, pushed it, opened the PR, then back ported it into our work copy of Lift. Had to ship things. Heh. Anyway, that pull request is here: https://github.com/lift/framework/pull/1450It's pretty basic as it is, but I want some feedback on possible improvements to it. I'd love to be able to change the behavior of what this method actually calls on the client using LiftRules, for example. That way you could, presumably, implement your own confirm modals that match the style of your site. Would you guys be interested in that?Anyway, I'd love some feedback on the existing code. As-is I think it's an improvement to SHtml, but am always interested in hearing cases to the contrary before merge. :)I honestly don't think we need this as it's not really complicated to accomplish already:SHtml.onEvent(s => Confirm("Really do stuff?", SHtml.ajaxInvoke(() => Alert("Done it!"))))
--
--
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 a topic in the Google Groups "Lift" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/liftweb/7vvVPmi53Kc/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
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.
Stuff that calls SHtml should be in the utils object. Just off the top of my head.
<a href="#" onclick="callFunction" id="NBSLKJESRLJ">Click Me</a>
<a href="#">Click Me</a>
+ a call to something like S.appendJs(Jq("NBSLKJESRLJ") ~> JsFunc("on","click",AnonFunc(...Extract value and call liftAjax...)
What I always found confusing is that methods that are named quite similar
seem to do rather different things, like, for example,
* ajaxText gives me a new Elem to include in my HTML,
* ajaxForm transforms existing HTML,
* ajaxCall gives me a GUIDJsExp that I need to attach somewhere.
I think that if you want to split the SHtml object, it would make sense to
split the functions according to these three types, similar to
SHtmlElem:
* ajaxButton
* a
* submitButton
* ...
SHtmlModifier:
* ajaxForm
* hrefFunc
* ...
SHtmlFuncs:
* ajaxInvoke
* ajaxCall
* jsonCall
* ...
Thoughts?In re: onEventIf, what I'm hearing is that we don't feel it's essential enough to include in Lift. I disagree, but that's fine. Maybe it's worthy of mentioning in the cookbook?
--
Tim & Co.,Many years ago, Naftoli was banned from the Lift community for harassing me. The culminating event was when he flooded me with demands to look at some code he wrote on a night that I had taken my son to the emergency room and somehow Naftoli thought me reviewing his code was more important than my son's health. You can search the committers mailing list for the phrase "what the f**k is wrong with you" (no stars) to see the exchange.Derek, Indrajit, and others took Naftoli aside and worked with him to help him channel his strong technical skills into something more productive.I agreed to let Naftoli back into the Lift community and the committers with the provision that he must continue to behave reasonably and that provision has always been part of Naftoli's continued participation in the community.About a year ago, Naftoli started a campaign of criticizing the way I handled the community. He was critical of my terse responses to posters and some other things... behaviors that he also engaged in. You can see the exchange between us on the Lift committers list. The end of that exchange I told Naftoli that I simply stop interacting with him and I have not interacted with him until 2 days ago.So, he took his complaints to the public Lift mailing list. About 1/3 of Naftoli's posts were critical of how the Lift community develops software (we code more and use English less than Naftoli thinks we should) and the way that I manage the community (multiple references to the "talent loss because of the way the community is managed.") Numerous people engaged with Naftoli on these issues and these discussions tended to hijack legitimate threads.A couple of asides:
- There's a balance between feedback so we can improve and doing stuff that actually works. Hearing feedback on a topic and working through that feedback is important. But having the same feedback resulting in the same discussions repeatedly is nagging.
- I am no longer the BDFL of this community, but when I resigned as BDFL a fair number of committers asked me to continue to enforce the community standards.
- Lift has its strengths and weaknesses and I think it's pretty clear that Lift is solid (how many sites run in production off SNAPSHOT), the committers respond very quickly to serious defects, Lift's documentation is weak, Lift's APIs are not as clean as they could be which is in tension with being fairly source compatible across versions of Lift and Scala, etc. The ad hoc process that we use to develop code (commit something that's solid, see what people think, tune, enhance or sometimes forget [like wiring]) has led to a ton of innovations (view first, the best comet around, CSS Selector Transforms, etc.) and some mess. Lift is not PostgreSQL (my personal "best blend of features, stability, performance, and documentation"), but it's still the best project in terms of stability (code quality, runtime stability, and API longevity) and build process of anything in the Scala world. Yes, Akka beats Lift in terms of documentation quality. The Scala collections library is excellent, but most of the rest of Scala is either bit-rot or a research project. Lift does have the most responsive and positive community in Scala-land and almost anywhere else.
- I am and we are always looking for ways to improve Lift and our community. However, repeatedly trying to change the Lift methodology and vision by hijacking productive threads with the same requests is not the way to do it.
Naftoli once again hijacked a legitimate thread where we were discussing how to deal with new APIs in the face of some API cruft and the evolution of the way Lift deals with HTML elements with a statement that was simply untrue. Naftoli engaged in nagging or beating a dead horse or diverting attention away from a legitimate discussion to him or some other less than optimal behavior. For me, it was the straw that broke the camel's back. The post in and of itself would have been acceptable if it had been the first post on the subject or the second or the third or maybe even the fourth. But Naftoli is not satisfied with the way we do things in Lift-land... and he never will be, so it's simply better that he's not part of this community.A couple of contexts to put this in: If someone posted 5 times over the course of the year about how Lift's documentation is weak without actually writing any documentation or blog posts, would that person be welcome in the community? If that person hijacked legitimate threads to discuss Lift's weak documentation and diverted community time and attention from making decisions about APIs or even how to write better documentation with posts about how Lift's documentation was weak, how would we react?Naftoli's participation in the Lift community has been provisional since I banned the first time. He engaged in behavior that in aggregate was both disruptive and a repeat of why he was banned originally (nagging). I made the choice to revoke his provisional status and ban him for life.I hope this clarifies things.Thanks,David
I read quite a bit of the posts on this list, and some people's posts interest me more than others'. DPP and Naftoli's posts are some of the ones I enjoy the most, and I've learned much from both of them.I haven't been around for long enough to notice Naftoli's bad behavior that you're referring to. Neither do I interpret his posts to be offensive nor do I feel he's hijacking threads. I do however feel Naftoli is trying to engage discussion around things he cares much about, and API-design seems close to his heart. It seems nobody else are interested in discussing Lift's API-design and prefer the "write the code and see how it works"-methodology. Naftoli doesn't seem very happy about this approach and thinks Lift's quality would be even better if people listened more to what he proposes of methodology-changes. I think he tries to come up with examples of what happens if/when we don't discuss design first when he spots weaknesses in code posted or other places. Maybe this is perceived as thread-hijacking or offensive, but I think this is just a result of Naftoli's frustration of not being heard so he tries to make his point clearer by pointing at examples of what he thinks is sub-optimal API, without much luck of being heard.
My vote is to lift the ban, forget bygones and look forward.
I just read this, I also think it is another side to the story.
Also i think Mr Pollak did not understand the reference to helpers, he called it hijacking and beating a dead horse, probably he thought naftoli was making a call to break down helpers. But I think he was just making an analogy to shtml, there should be consistent approach in lift, which is more if you put onEventIf.
If this is representative maybe all the other times also that Mr Pollak thinks that Naftoli was being argumentative, maybe he was misunderstood, that is what naftoli claims anyway on t the recent pull request thread.It is so sad that we can't have lift on 2.11 because of this.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.