[ANN] Lift 1.1-M8
David Pollak
Lift is an expressive and elegant framework for writing web applications.
Lift stresses the importance of security, maintainability, scalability
and performance while allowing for high levels of developer productivity.
Lift is a Scala web framework.
Changes in this version include:
New features:
o Added new built-in <lift:html5> snippet that sets HTML5 DOCTYPE on the XHTML response
o Add ability to call JS code after AJAX form submit Issue: 148.
o Add AJAX editable field generator to SHtml, add AjaxEditableField to Mapper. Issue: 181.
Fixed Bugs:
o JqJsCmds.ModalDialog now takes JsObj argument to work with BlockUI v2.x Issue: 218.
o Fixed typo in DerbyDriver.integerIndexColumnType: IDENITY -> IDENTITY
o Fixed Mapper to use DriverType.columnTypeMap everywhere Issue: 211.
o Fixed Mapper logging to properly log inserts, updates and deletes Issue: 210.
o Breaking Changes:
1) LocParam
LocParam has been made a sealed trait to facilitate pattern matching within the Lift codebase and has had a contravariant type parameter added to its type to facilitate typesafe interactions with Loc[T]. The new trait is hence LocParam[-T]. As LocParam is now a sealed trait, I have added an extension point for user-specified LocParam subtypes as UserLocParam[-T] extends LocParam[T]. Since the new type parameter is contravariant, LocParam subclasses that are applicable for any Loc[T] have the type LocParam[Any], and a type alias AnyLocParam has been added for this type.
The Loc.checkProtected method now enforces type consistency between the evaluated Link[T] and the list of LocParam[T] which are used to evaluate whether the link is accessible given the specified parameters.
2) Renames
Previously, the "Param" suffix was used for two unrelated purposes within Loc: first, to refer to the type parameter of the Loc, and secondly for the LocParam configuration. This overloading made the code and the API somewhat difficult to read, so the first usage has been removed resulting in the following renames:
ParamType => T
NullLocParams => //removed, Unit is sufficient!
Loc.defaultParams => Loc.defaultValue
Loc.forceParam => Loc.overrideValue
Loc.foundParam => Loc.requestValue
Loc.additionalKidParams => Loc.childValues
After this change, all instances of the "param" name within Loc should refer to something having to do with LocParam instances.
Non-Breaking Additions:
case class IfValue[T](test: Box[T] => Boolean, failMsg: FailMsg) extends LocParam[T]
case class UnlessValue[T](test: Box[T] => Boolean, failMsg: FailMsg) extends LocParam[T]
case class TestValueAccess[T](func: Box[T] => Box[LiftResponse]) extends LocParam[T]
If you are using a non-Unit typed Loc, you can use these LocParam instances to enforce access rules at the value level.
case class ValueTemplate[T](template: Box[T] => NodeSeq) extends LocParam[T] //per-value template selection
DataLoc[T] subclass of Loc was added to facilitate the use of the new more typeful LocParam subtypes.
A few changes to Link:
Since Link.createLink creates a Box[Text] (and not a clickable link) a couple of methods were added to create the intermediate, unboxed
values in order that subclasses can more easily manipulate the resulting path:
Link.pathList(value: T): List[String] // added to facilitate creation of value-aware paths by subclasses.
Link.createPath(value: T): String //creates the String representation of the path that is subsequently turned into XML and boxed by Link.createLink Issue: 139.
o Allowing page fragments wrapped by <lift:lazy-load> node to be processed and loaded asynchronously. Issue: 56.
o Updated documentation for Msgs Issue: 153.
o XmlResponse(...) now accepts optional HTTP status code, mime type and cookies. Issue: 177.
o SQL Server Alter Table Fails Issue: 14.
o Typo in Req.scala Issue: 170.
o Snapshot jars contains several Box.class files Issue: 166.
o Fix scala:doc and vscaladoc configuration along with provision for module specific configuration for packageLinkDefs. Issue: 180.
o Upgrade Lift archetypes to use the new archetype metadata format. Enhance/fix archetype integration tests during build. Issue: 161.
o Enhance archetype metadata not to depend on ext.vm and allow one to set Lift version (-DliftVersion) or Scala version (-DscalaVersion) during archetype:generate. Issue: 227.
o Fixed SQL Server drivers to use version-appropriate unicode columns for text. Issue: 16.
Changes:
o Update hibernate-entitymanager to 3.4.0.GA. Issue: 156. Thanks to econoplas.
o Adjust javax.mail version range to avoid issues when Sun's repo is used and
honor javax.activation being transitively pulled up my javax.mail. Issue: 168. Thanks to awhitford.
o Enforce Maven version 2.1.0 or higher, but lower than 3.0. Issue: 203.
Have fun!
-Lift Web Framework team
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
harryh
Welcome M8!
Randinn
On Dec 15, 6:57 am, harryh <har...@gmail.com> wrote:
> Huzzah!
> Welcome M8!
Oleg G.
planned?
Timothy Perrett
This is currently on the 2_8_0 branch and will be in Lift 2.0 (Scala 2.8 keeps being put back)
Cheers, Tim
On 15 Dec 2009, at 10:57, Oleg G. wrote:
> I'm wondering about scala 2.8 compatibility, is it in or when is it
> planned?
>
>
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
>
>
>
Jim McBeath
least for some of the libraries (for example,
<http://scala-tools.org/repo-releases/net/liftweb/lift-util/1.1-M8/>).
Are these perhaps located somewhere else now? Or do they typically
get added a bit later?
--
Jim
On Mon, Dec 14, 2009 at 11:37:02AM -0800, David Pollak wrote:
> Date: Mon, 14 Dec 2009 11:37:02 -0800
> From: David Pollak <feeder.of...@gmail.com>
> To: liftweb <lif...@googlegroups.com>
> Subject: [Lift] [ANN] Lift 1.1-M8
DMB
the hard way. If anyone knows a workaround on how to make Netbeans 6.8
work with Lift, do share.
Naftoli Gugenheim
-------------------------------------
Xuefeng Wu
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
--
Scala中文社区: http://groups.google.com/group/scalacn
joseph hirn
more related to the archetype.
Still in the M8 archetype, h2 db is dependency of the project rather
than a dependency of Jetty. It is better to have jetty declare the h2
dep because it keeps the sample app database independent. Even if you
are programming directly to H2 API it is better to mark provided and
have it be provided at runtime by the system or container. The bigger
issue I'm experiencing is that it makes Jetty also unable to survive
hot changes to class files for me. If I change a file and compile
while jetty is running I get this error:
-------------------------------------------------------------------------------------------------------------
org.h2.jdbc.JdbcSQLException: Database may be already in use: Locked
by another process. Possible solutions: close all other connection(s);
use the server mode [90020-121]
$mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500)
Java version: 1.6.0_16
Java home: C:\Java\jdk1.6.0_16\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
-------------------------------------------------------------------------------------------------------------
This is probably because the application is spinning up the database
and Jetty is unable to clean it out entirely due to it being outside
the scope of a normal web application (I assume is spawns some of its
own threads).
By moving the dependency inside of Jetty like this I no longer have
the issue. I've used Jetty+Maven alot and have had to do this with
other api's, specifically Tibco RVD:
[----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------]
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<configuration>
<contextPath>/</contextPath>
<scanIntervalSeconds>5</scanIntervalSeconds>
</configuration>
<dependencies>
<dependency>
<groupId>com.h2database</groupId>
<artifactId>h2</artifactId>
<version>1.2.121</version>
</dependency>
</dependencies>
</plugin>
[------------------------------------------------------------------------------------------------------------------------------------------------------------]
On Dec 16, 6:36 am, Xuefeng Wu <ben...@gmail.com> wrote:
> anyone will add the source.jar?
>
>
>
> On Wed, Dec 16, 2009 at 3:33 AM, Jim McBeath <goo...@j.jimmc.org> wrote:
> > It looks like the source jars are missing from the M8 repository, at
> > least for some of the libraries (for example,
> > <http://scala-tools.org/repo-releases/net/liftweb/lift-util/1.1-M8/>).
>
> > Are these perhaps located somewhere else now? Or do they typically
> > get added a bit later?
>
> > --
> > Jim
>
> > On Mon, Dec 14, 2009 at 11:37:02AM -0800, David Pollak wrote:
> > > Date: Mon, 14 Dec 2009 11:37:02 -0800
> > > From: David Pollak <feeder.of.the.be...@gmail.com>
> > > To: liftweb <lif...@googlegroups.com>
> > > Subject: [Lift] [ANN] Lift 1.1-M8
>
> > > The Lift Web Framework team is pleased to announce the lift-1.1-M8
> > release!
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lif...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>
Indrajit Raychaudhuri
I assume your concern is same as the one that you had mentioned here:
http://github.com/dpp/liftweb/issues/246/find.
While this is a genuine case for the scenario you described, marking db
driver as 'provided' has the side effect of not being included with the
generated war (because the container would be expected to provide this).
This is fine if the application is deployed on a container using
container managed persistence. However, if you are expecting the db
driver to be loaded by the same classloader (context classloader) as the
application you would be expected to provide it as part of the war (and
therefore not in 'provided' scope).
Cheers, Indrajit
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
joseph hirn
opened 246 for and sorry for beating a dead horse.
The thing is that in most cases, you do want to container to provide
the db driver. It's bad practice to create a war file with dependence
on a specific database, let alone a specific version of the database
(1.2.121 of h2 in this case) as it limits the reusability of that
warfile. I say most cases meaning most production cases, but if this
is a simple example for development purposes, surely having hot
redeploy for rapid development is of high value. Spending an hour on
my first day with Liftweb figuring out why Jetty couldn't handle a
restart was disgruntling. I still haven't even gotten around to
learning the cool stuff in Lift because of the derailing. I recently
spoke with another colleague who had the same issue but he just blamed
it on Maven so you're off the hook =P
If you are 100% intent on providing the h2 jarfile inside of the
warfile then you could configure maven-war-plugin to include the
dependency only in the warfile rather than compilation class scope so
it will not affect jetty:run (it would still affect jetty:run-war). I
could quickly provide the xml to do this if you deem it worthwhile,
although I would recommend against it.
Ultimately I'm just trying to help people who are getting started like
myself. Thanks for your time and thoughts in response.
David Pollak
Thanks for the response Indrajit. Yes this is the same issue I had
opened 246 for and sorry for beating a dead horse.
The thing is that in most cases, you do want to container to provide
the db driver.
If this is the case that you want, then you can change the pom.xml file that is generated by the archetype.
On the other hand, this is the default configuration that works just fine when doing mvn jetty:run. On the other hand, of you do mvn jetty:run and have H2 marked as provided, the app doesn't run.
So, this is not a defect. This is the way things should be. If you want a different configuration, by all means, change up your pom.xml file.
joseph hirn
It's true that if you only have the dependency marked as provided then
yes, it won't run. I am not advocating the use of using <scope>
provided. That is only if you are programming to the h2 interfaces
directly which you aren't and shouldn't be doing. I am advocating that
you do not include h2 as an application dependency, but rather a
dependency of the runtime environment which in this case is jetty.
If you put the dependency inside of jetty and remove it from the
project dependencies, it will run and survive restarts without issue.
I see this post from today describing the same symptom I experience:
http://groups.google.com/group/liftweb/browse_thread/thread/dd2f48174c9916ef#
I respectfully assert that this is an issue and that most people will
not know to change up their pom file to correct the issue. Since the
archetype is the gateway to learning the framework, it can be and is a
stumbling block to those looking for a quick start into liftweb
hacking.
On Dec 29, 6:00 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
> > <liftweb%2Bunsu...@googlegroups.com<liftweb%252Buns...@googlegroups.com>
>
> > > >>> .
> > > >>> For more options, visit this group at
> > > >>>http://groups.google.com/group/liftweb?hl=en.
>
> > > >> --
> > > >> Scala中文社区: http://groups.google.com/group/scalacn
>
> > > > --
>
> > > > You received this message because you are subscribed to the Google
> > Groups "Lift" group.
> > > > To post to this group, send email to lif...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>
> > .
> > > > For more options, visit this group athttp://
> > groups.google.com/group/liftweb?hl=en.
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lif...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
Heiko Seeberger
My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
joseph hirn
I just tried runtime scope and I get the same exception when
recompiling a Scala file with jetty still running. Do you experience
the same?
org.h2.jdbc.JdbcSQLException: Database may be already in use: Locked
by another process. Possible solutions: close all other connection(s);
use the server mode [90020-121]
For production, when you are taking your warfile and deploying it
somewhere runtime may be suitable but for development, having Jetty be
able to hot redeploy is critical, at least to me. I can change it to
taste sure, but most people aren't experts in maven let alone maven-
jetty-plugin.
On Dec 31, 1:10 am, Heiko Seeberger <heiko.seeber...@googlemail.com>
wrote:
> Hi,
>
> What about using *runtime* scope for the database drivers? This is what I am
> always changing my POM to. Because IMHO it is just the right thing: No
> compilation dependency, but working with *mvn jetty:run* and inclusion in
David Pollak
Hello David.
It's true that if you only have the dependency marked as provided then
yes, it won't run. I am not advocating the use of using <scope>
provided. That is only if you are programming to the h2 interfaces
directly which you aren't and shouldn't be doing. I am advocating that
you do not include h2 as an application dependency, but rather a
dependency of the runtime environment which in this case is jetty.
If you put the dependency inside of jetty and remove it from the
project dependencies, it will run and survive restarts without issue.
I see this post from today describing the same symptom I experience:
http://groups.google.com/group/liftweb/browse_thread/thread/dd2f48174c9916ef#
I respectfully assert that this is an issue and that most people will
not know to change up their pom file to correct the issue.
Let me be clear... badgering me about in issue is not "respectful." You opened a ticket and I closed it. You posted to this list and I explained why we were not going to adopt your solution. You posted twice this morning about this issue including a post about "not being taken seriously."
I have described my criteria for the default archetypes: they must work correctly with "mvn jetty:run" from the command line without any other modifications. Your proposal does not meet this criteria and I have rejected it. This is not for lack of "taking you seriously." It is because I and the other Lift committers have been working with newbies and Lift for almost three years, we've been through thousands of newbie getting started questions and we've tuned Lift to make Lift easy to get started with. This means not having to set up a container as part of getting started.
It is a developers choice as to how to configure their pom.xml file, but the default Lift archetype will allow the Lift app to start up correctly with mvn jetty:run or as dropped into an unmodified container. If you want something different, there's nothing about Lift that requires that the DB JAR file be specified in the pom.xml file and you are welcome to and encouraged to change it up to suit your needs.
So, why is the H2/Jetty restart issue coming up today? I think the reasons are as follows:
- Up until recently, Derby was the default DB for the Lift archetypes. We changed to H2 because by all measures, H2 is better.
- Most developers do not rely on Jetty's code reloading features. They use JRebel or they kill and manually restart their Jetty instance.
David
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
--
joseph hirn
have a warfile that you can drop into an unmodified container. I
assumed it would be to get a development environment setup as quickly
as possible and since jetty:run is the prescribed method of getting
started, I thought it might help to recommend an alternative pom
configuration. There are other methods to create a war you can drop
into an unmodified container which will not break jetty:run. I've
never touched JRebel because Jetty is fantastic standalone for hot
redeploy provided it is configured properly.
I also now see from other posts that you intend to change the h2
connection string so that Jetty can hot redeploy. You've never
responded to me with that as a solution, only that the pom has no
problems. That is why I felt like my issue was a non-issue and not
being taken into serious consideration.
So I'm sorry for getting off on the wrong foot with you David. I don't
take for granted your efforts on the framework or the work you've put
into making jetty easy for beginners. I was only trying to help out
and for some people I have.
On Dec 31, 12:10 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
> On Wed, Dec 30, 2009 at 9:39 PM, joseph hirn <joseph.h...@gmail.com> wrote:
> > Hello David.
>
> > It's true that if you only have the dependency marked as provided then
> > yes, it won't run. I am not advocating the use of using <scope>
> > provided. That is only if you are programming to the h2 interfaces
> > directly which you aren't and shouldn't be doing. I am advocating that
> > you do not include h2 as an application dependency, but rather a
> > dependency of the runtime environment which in this case is jetty.
>
> > If you put the dependency inside of jetty and remove it from the
> > project dependencies, it will run and survive restarts without issue.
>
> > I see this post from today describing the same symptom I experience:
>
> >http://groups.google.com/group/liftweb/browse_thread/thread/dd2f48174...
>
> > I respectfully assert that this is an issue and that most people will
> > not know to change up their pom file to correct the issue.
>
> Let me be clear... badgering me about in issue is not "respectful." You
> opened a ticket and I closed it. You posted to this list and I explained
> why we were not going to adopt your solution. You posted twice this morning
> about this issue including a post about "not being taken seriously."
>
> I have described my criteria for the default archetypes: they must work
> correctly with "mvn jetty:run" from the command line without any other
> modifications. Your proposal does not meet this criteria and I have
> rejected it. This is not for lack of "taking you seriously." It is because
> I and the other Lift committers have been working with newbies and Lift for
> almost three years, we've been through thousands of newbie getting started
> questions and we've tuned Lift to make Lift easy to get started with. This
> means not having to set up a container as part of getting started.
>
> It is a developers choice as to how to configure their pom.xml file, but the
> default Lift archetype will allow the Lift app to start up correctly with
> mvn jetty:run or as dropped into an unmodified container. If you want
> something different, there's nothing about Lift that requires that the DB
> JAR file be specified in the pom.xml file and you are welcome to and
> encouraged to change it up to suit your needs.
>
> So, why is the H2/Jetty restart issue coming up today? I think the reasons
> are as follows:
>
> - Up until recently, Derby was the default DB for the Lift archetypes.
> We changed to H2 because by all measures, H2 is better.
> - Most developers do not rely on Jetty's code reloading features. They
> ...
>
> read more »