Implementation of onEventIf

[Matt Farmer]

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/1450

It'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. :)

Cheers,

Matt

[Andreas Joseph Krogh]

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!"))))

 

--
Andreas Joseph Krogh <and...@officenet.no>      mob: +47 909 56 963
Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no
Public key: http://home.officenet.no/~andreak/public_key.asc

 

[Andreas Joseph Krogh]

På søndag 19. mai 2013 kl. 17:51:21, skrev Andreas Joseph Krogh <and...@officenet.no>:

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/1450

 

It'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!"))))

 

Note that for [onclick]-events its recommended to use SHtml.ajaxInvoke instead of onEvent as onEvent sends back "this.value" and is ment for form-input elements. Having ajaxInvokeIf, onEventIf, jsonCallIf etc. seems wrong imo.

[Matt Farmer]

So, I mean. Certainly, it's something that's fairly trivial to implement. But do you not feel that it's a common enough use case to justify inclusion into Lift's core?

Show-a-confirm-box-and-do-something-if-the-user-clicks-yes seems like stock behavior that would occur often enough to justify us making a shortcut of some variety for it, yeah?

--

Matt Farmer

Web Developer | Blogger

http://matt.frmr.me | http://farmdawgnation.com

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

[David Pollak]

I'm cool adding a method, but SHtml is already heavily overloaded. How about SUtils or some other object to contain stuff like this?

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/groups/opt_out.
 
 

--

Telegram, Simply Beautiful CMS https://telegr.am

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

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Matt Farmer]

I agree that SHtml is overloaded. But what criteria should we use to distinguish between what belongs in there and what belongs in SUtils? (Or whatever we decide to call it... not really a fan of the SUtils name, tbh... seems vague.)

--

Matt Farmer

Web Developer | Blogger

http://matt.frmr.me | http://farmdawgnation.com

[David Pollak]

Stuff that calls SHtml should be in the utils object. Just off the top of my head.

[Naftoli Gugenheim]

On Sun, May 19, 2013 at 11:49 PM, David Pollak <feeder.of...@gmail.com> wrote:

Stuff that calls SHtml should be in the utils object. Just off the top of my head.

Well there are a lot of things in SHtml already that call (other) things in SHtml. We need a rule that we can be consistent about. People need to be able to find things.

Anyway I thought you like the mega-Helpers approach.

[Matt Farmer]

Yeah, I agree with Naftoli. A class calling other things in the same class doesn't seem like something you'd normally split things out for.

 

--

Matt Farmer

[Diego Medina]

For the most part I'm all for adding things that are useful to people. But here I feel that we don't save that much code from the option that Andreas provided, It looks pretty straight forward

SHtml.onEvent(s => Confirm("Really do stuff?", SHtml.ajaxInvoke(() => Alert("Done it!"))))

Also note that there were some conversations about re-thinking SHtml.* for Lift 3.0, trying to unify some concepts and in short, learn from the experience.

Thanks

  Diego

Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://fmpwizard.telegr.am

[Naftoli Gugenheim]

To be clear, I haven't taken any position on whether it should be in SHtml or not. My point was that good codebase design is an art and cannot be done arbitrarily, ad-hoc. Principle of least surprise. Consistency.

However in truth I think the very fact that we're debating whether we should throw in yet another special-purpose ad-hoc method shows that the abstraction design that we're trying to build on may need to be rethought. Good design does not give rise to tons of special cases, for the following reason. If you plan an API with a short-sighted, limited usage in mind, then it will be concise and easy to use in the concrete use cases you envisioned, and more verbose the more you depart from that. However if when you design an API you penetrate to the essential concepts that you are trying to provide, and how they can work together, then your API will be exponentially more general-purpose usable. I haven't articulated this clearly; it sounds as though I'm begging the question. Anyway scala the language is a tremendous illustration of this.

[Austen Holmes]

Only slightly off topic:

One thought I had when looking at the html generated by SHtml.  I think what would benefit me the most is to allow a common method of attaching server-side events to arbitrary html elements.  

It should allow the method to be attached using inline events:

<a href="#" onclick="callFunction" id="NBSLKJESRLJ">Click Me</a>

or allow it to be attached using a framework:

<a href="#">Click Me</a>
+  a call to something like S.appendJs(Jq("NBSLKJESRLJ") ~> JsFunc("on","click",AnonFunc(...Extract value and call liftAjax...)

I think making it configurable in LiftRules would be of great benefit.  This way you could configure the application to use jQuery events, Dojo events, some custom event mechanism you have created in-house, etc.

Although I haven't looked at it too much, round-trips in lift 3.0 may be a possible alternative.

-Austen

[Tobias Pfeiffer]

Hi,

(Sorry, this is not exactly related to the original question of whether to
include onEventIf.)

Am Montag, 20. Mai 2013, 15:50:14 schrieb Naftoli Gugenheim:
> Well there are a lot of things in SHtml already that call (other) things
> in SHtml. We need a rule that we can be consistent about. People need to
> be able to find things.

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

SHtmlModifier:
* ajaxForm
* hrefFunc
* ...

SHtmlFuncs:
* ajaxInvoke
* ajaxCall
* jsonCall
* ...

Just my 2 cent,
Tobias

[David Pollak]

Naftoli,

I think it's time for you to leave this community. The vast majority of your posts are simply critical of this community and our approach to software development, but without really offering anything better. If you don't like Lift, the way Lift has evolved, our development methodologies, our community ethos or the way that I manage the community, then leave.

In terms of Scala being well thought out... look at Scala Actors... they sucked for so long and so badly that they were dumped in favor of another actor library that Martin pissed on in public when it was introduced. Or perhaps look at the ad-hoc nature of Option/Try vs. Lift's Box. And look at Lift's Actors and Futures... both by far cleaner and better thought out than Scala or Akka actors or futures (Lift's had fail-fast Futures for 3+ years... far longer than the other libraries.)

In terms of your complaints about how I have managed the community... go back and look at how Martin and Jon Harrop mixed it up over type inference and Jon's Scala book or more recently how Martin reacted to Paul Snively's observations about how Java developers come up the Scala learning curve. I will always find ways to improve how I manage community... but painting a "David does a crappy job of managing the Lift community, but the Scala community is oh so wonderfully managed" picture is just factually wrong.

I am not interested in a discussion on this issue. I am only interested in seeing you leave the Lift community. It can be voluntary or not. Your choice.

David

[Matt Farmer]

Reply below quote.

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

SHtmlModifier:
 * ajaxForm
 * hrefFunc
 * ...

SHtmlFuncs:
 * ajaxInvoke
 * ajaxCall
 * jsonCall
 * ...

I think see your logic here. It still doesn't jive with me though. I mean, I think everything we have in SHtml fits the definition we set out for it in the documentation.

> The SHtml object defines a suite of XHTML element generator methods to simplify the creation of markup, particularly with forms and AJAX.

 

Maybe it's time to entertain splitting things along an ajax/non ajax line? I think part of what bugs me about the above mentioned approach is that I as an engineer would have to remember where various things are - and under that organization would likely need all three classes imported into a particular file to make things work. However, if we split things into SHtmlElem for all of the static form controls, SHtmlAjaxElem for all of the ajax form controls, and SHtmlAjax for all of the ajax event binders (ajaxInvoke, etc) we may be able to provide some clear distinctions.

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?

[Naftoli Gugenheim]

Okay, that's an interesting approach. I like it. Not sure about the names though. For one thing, once we're changing the name we don't have to have "SHtml" in the name; let's try to think of names from scratch. Although, what about objects inside SHtml, like SHtml.Elems, etc.?

[Naftoli Gugenheim]

Okay that division also makes sense. To tell the truth I'm not the most heavy user of SHtml so I can't weigh your approach against Tobias'. Perhaps we should take a step back, and sort of systematically catalogue all the methods in SHtml, so that we can get a better idea of possible division lines?

Or, is there anyone on this list that opposes rethinking the architecture of SHtml?

 

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?

--

[Andreas Joseph Krogh]

I'm fine with SHtml the way it is, it provides lots of usefull functions to generate form and ajax-stuff I need.

[Tim Nelson]

I would just like to say that I don't feel Naftoli deserves to be kicked out of this community. I believe his intentions were only to help improve Lift.

Also, should this be something that should be discussed with other committers first?

Tim

[Derek Chen-Becker]

I think this might be a bit harsh. While Naftoli may disagree with design decisions, etc on the list, I think that that's a part of the overall discussion. I can't recall him ever saying something along the lines of "Lift sucks"; I genuinely believe he's trying to improve it. There have been plenty of times where I've said I think something is wrong although I don't necessarily have a better idea.

Derek

[Kristof Jozsa]

David, did we also receive the post on which you are reacting like that? I would assume that generally asking someone to leave a community is something about personal behaviour which despite all warnings, repeatedly breaks the community's own rules. Here Naftoli has been voted as the most awesome member of the community twice during the years, last time a few months ago.. I just don't get this case at all, it would be useful to see what you feel wrong here.

thanks,
K

[Tyler Weir]

I'm going to agree with Tim, Derek and Kristof.

While I often think he could be more tactful, he's not abusive and has contributed to many discussions.

I would vote to remove the ban on his participation.

[Lukasz Kuczera]

+1 I don't see anything offending in Naftoli post, OTOH I see lot of acid in DPP's. 

If you throw away Naftoli then please also throw away me.

[David Pollak]

Tim,

Let's take this to the committer's mailing list.

Thanks,

David

[Vasya Novikov]

* The topic seems really strange.. If nafg will be un-banned -- please write it publicly.

[Tim Nelson]

David,

I think the issue regarding Naftoli should probably stay on the public list, since that's where it started. But, you can post wherever you feel most comfortable.

Regarding voting on these things, yes that should probably be discussed on the committer's list as it relates to committer processes.

Tim

[David Pollak]

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

[Andreas Joseph Krogh]

På torsdag 23. mai 2013 kl. 17:35:35, skrev David Pollak <feeder.of...@gmail.com>:

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.

 

Thanks.

[Tim Nelson]

David,

Thanks for responding. I didn't know about the past history with Naftoli. All I can say is if he was asked to modify his behavior and he didn't, then it would be justified to ban him. What I did see I didn't think warranted it, but I'll admit that I don't know enough of the the details to make an informed opinion on the matter. So, I'll have to trust your judgment on this.

Regarding enforcing community policy, I vaguely remember folks asking you to continue enforcing them, now that you mention it. There have been a few cases where it was pretty obvious the person didn't belong in the community and I have no problem with you taking control of those situations. I will make one suggestion; next time you're considering banning someone, maybe just post something on the committer list so we can have a quick discussion and not have to do it afterward. In this case Naftoli is a pretty active member of the community and I was a little surprised to see him banned.

Thanks,

Tim

[Antonio Salazar Cardozo]

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.

You are correct that there's a preference for write code and see how it works. It's a bigger preference for David, I think, but it also happens that David is still contributing more code that any other committer at the moment, so that makes sense.

The problem here isn't whether or not problem areas of the API have been identified. They have, and indeed we've had discussions about SHtml.* before. The problem is we consistently get platitudes and methodology instead of concrete suggestions. Methodology is nice and all, but the best way to show your methodology works is to apply it and show us the results. That has happened very few times, and having constant questioning occur without any actual concrete suggestions is an excellent example of non-constructive criticism—which is very taxing to the receiver, because it's a lot harder to discuss “you should have a great API that you've thought through all the way” than it is to discuss “here's an API that I've thought through all the way and I think is better”. The latter is constructive. The former is armchair quarterbacking and serves for nothing other than generating more emails and discussion rather than serious progress. 

Abstract discussion has its place as an expository exercise, but less so as an exercise in criticism. As one example, in the thread at https://groups.google.com/forum/?fromgroups#!searchin/liftweb/antonio$20naftoli%7Csort:date/liftweb/m63kJ7Sq9v0/Rg2ENLBNLJcJ , the Lift CometActor abstraction was criticized as (essentially) not layered enough, but despite my expressing confusion as to what the specific change being suggested was, we continued to discuss at a high level—in essence, about software engineering, not Lift. An interesting discussion, but stemming as it did from essentially an opening argument that CometActor was improperly designed, it didn't lead anywhere particularly useful or supportive of that argument.

  

My vote is to lift the ban, forget bygones and look forward. 

I did not know the history either, but as a courtesy to David I looked up the previous interactions (I realize not everyone has access to the committers list, but I think it's the least the committers can do to look that up if they weren't around when it happened). I support his decision fully in this case, even though I don't hold any grudges against Naftoli as a person. This was not a sudden action by any stretch of the imagination.

As a side note, I'm curious to see where other discussions around Lift's API design have come up that others haven't participated in. I'm generally quite interested in it, for example, and try to engage on the matter when possible.

Thanks,

Antonio

[Dylan Halperin]

This ban also comes as a surprise to me. Obviously I cannot know all of the details (and I don't think I can access the committer's list), but I think that Naftoli makes a good addition to the community. I disagree with the mentality of "if you don't like it then leave." I'd like to think that if there's something you dislike, you'd be able to help change it for the better, which is what I think Naftoli is trying to do. I would cast a vote to lift the ban as well.

[Vasya Novikov]

I must say I'm 100% not comfortable with banning a man who wrote
http://scalareactive.org/

In your exact case, I think moderators may be impolite, but right in a
general sense. I mean, this really isn't constructive:

> I have the *feeling* that Lift Comet integration isn't complete

People usually like to solve problems, or propose interesting ideas. Or
implement the ideas.) But "just discussing" takes time and may not take
anywhere.

So, my personal opinion is that something's definitely wrong with
banning people that write libraries for Lift. But one has to be
conscious about the goals of his topics, too. For example, if you need
an embedded language -- you don't just criticize Scala.


On 2014-04-08 03:47, Alois Cochard wrote:
> Hey everyone,
>
> Years ago Naftoli asked me about Lift and what I thought about it, I
> told him not to use it, because of my experience with the community manager:
> https://groups.google.com/d/msg/liftweb/2TXcd4cmszY/uiQG6-SjlcIJ
>
> It's very ironic what happen today... but in a sad way.
> I just wanted to say that it's not an isolated case and that this whole
> approach imposed on the community refrained a lot of people from joining
> the boat.
>
> Just my 2 cents

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

> <http://home.officenet.no/%7Eandreak/public_key.asc>

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

> <mailto:liftweb+u...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Matt Farmer]

Folks,

To say that this thread has gone off the rails is putting it mildly. This thread is nearly a year old, and to be frank, further discussion of Naftoli here isn't really doing anything except continuing to stir the pot. I would like to leave this thread open for discussion on the onEventIf implementation if folks still have comments relevant to the original discussion. If you feel the need to further discuss your thoughts on Naftoli's removal from the community, I encourage you to write a blog post, but it should not continue here.

Cheers,

On Saturday, April 12, 2014 9:37:25 PM UTC-4, ti com wrote:

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.