Skip to content

Instantly share code, notes, and snippets.

package reactive
package web
package widgets
import scala.xml.NodeSeq
import net.liftweb.util.{ CssSel, Helpers, PassThru }
import Helpers._
abstract class TableFormlet[A](val signal: SeqSignal[A]) extends Formlet[Seq[A], NodeSeq => NodeSeq, Nothing] {
@nafg
nafg / Formlet.scala
Created February 27, 2012 06:57
Formlet.scala
package reactive
package web
import javascript.{ JsExp, JsTypes, =|> }
import scala.xml.{ NodeSeq, Text }
import net.liftweb.util.{ CssSel, PassThru }
import net.liftweb.util.Helpers.strToCssBindPromoter
trait FormletRenderer[-R, +Out] {
package reactive
package web
package widgets
import net.liftweb.util.{ CssSel, PassThru }
import net.liftweb.util.Helpers._
import scala.xml.NodeSeq
/**
@nafg
nafg / gist:3031581
Created July 2, 2012 07:03
Extensible data processors
/*
THE OBJECTIVE:
Given some Q[A] (Q might be ScalaQuery's query, A might be the first column of the table),
there should be a function that can return an object that has a Q[B] (B might be the first two columns
of the table), and a way to go from a B to an A (e.g. from (Int, String) to Int). We need to have a
collection of such objects (not sure if List or HList).
The purpose is this:
Suppose for instance I want to develop a very pluggable issue tracker. Its core implementation might
object Test extends App {
case class Item[A, B](get: A => B, apply: B => Unit)
def hlist[A] =
Item((_: A) => 73, println) ::
Item((_: A) => "hello", println) ::
Item((_: A) => false, println) ::
HNil
class Combine[A] extends Poly2 {
@nafg
nafg / PairOps.scala
Created July 8, 2012 04:26
Map and WIP foldLeft for Pairs
trait ~>[F[_], G[_]] {
def apply[T](f: F[T]): G[T]
}
// object ~> {
// class From[F[_]] { type To[G[_]] = ~>[From, To] }
// }
trait Const[C] {
type T[X] = C
@nafg
nafg / gist:3069790
Created July 8, 2012 07:31
CanBuildQuery
// The problem: get the line starting with val q (at the end) to be compile as implicit and inferred as possible
/*
THE IDEA:
Suppose for instance I want to develop a very pluggable issue tracker. Its core implementation might
only support a ticket id and a description. Other extensions might add support for various other fields,
yet those fields might exist in the database on the same table.
Even if not, the number of queries to the database should not need to increase along with the number of
extensions. They should be able to contribute to the definition of the query.
These objects would also be able to render the data. So the second might know how to render a B,
abstract class Foo(config: Config) {
}
class Bar(config: Config) extends Foo(config) {
def doStuff = {
Obj.doStuff(1)
}
}
object Obj {
class Config
abstract class Foo(implicit val config: Config)
class Bar(config: Config) extends Foo()(config) {
def doxxx = Obj.doStuff(1)
}
object Obj {
def doStuff(i: Int)(implicit config: Config) {}
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1342)
at net.liftweb.http.ResourceServerSpec$$anonfun$1$$anonfun$apply$1.apply(ResourceServerSpec.scala:31)
at net.liftweb.http.ResourceServerSpec$$anonfun$1$$anonfun$apply$1.apply(ResourceServerSpec.scala:30)
at org.specs2.specification.Example$$anonfun$apply$1.apply(Fragment.scala:119)
at org.specs2.specification.Example$$anonfun$apply$1.apply(Fragment.scala:119)
at org.specs2.specification.Example.execute(Fragment.scala:102)
at org.specs2.specification.FragmentExecution$$anonfun$1.apply(FragmentExecution.scala:51)
at org.specs2.specification.FragmentExecution$$anonfun$1.apply(FragmentExecution.scala:51)
at org.specs2.execute.ResultExecution$class.execute(ResultExecution.scala:20)