The simple way of using FuncBindParam is:
first_name - { (ns: NodeSeq) = SHtml.text(...) }
That will only generate the text if the tag first_name appears.
-Ross
On Mar 10, 2010, at 10:22 AM, Stuart Roebuck wrote:
Okay, so I now understand what is happening a little better.
When I saw a
I think you could use plain Record and MetaRecord to do this.
-Ross
On Mar 9, 2010, at 9:27 AM, Jeppe Nejsum Madsen wrote:
On Tue, Mar 9, 2010 at 3:17 PM, Francois fan...@gmail.com wrote:
Le 09/03/2010 10:12, Francois a écrit :
Hello guys,
I'm often using forms without anything to do
Try this (I haven't tested it, so there could be lurking bugs):
case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft with
HtmlFixer {
override def toJsCmd = jQuery( + JsStr(fixHtml(NodeSeqDialog,
ns)).toJsCmd + )
}
Then JQueryNodeSeq(ns) ~ JsFunc(dialog)
-Ross
On Mar 9,
Whoops, I meant Str(fixHtml(...)) not JsStr(fixHtml(...))
-Ross
On Mar 9, 2010, at 12:14 PM, Ross Mellgren wrote:
Try this (I haven't tested it, so there could be lurking bugs):
case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft with
HtmlFixer {
override def toJsCmd
the XML thoroughly.
-Ross
On Mar 9, 2010, at 12:26 PM, David Pollak wrote:
On Tue, Mar 9, 2010 at 9:14 AM, Ross Mellgren dri...@gmail.com wrote:
Try this (I haven't tested it, so there could be lurking bugs):
case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft with
HtmlFixer
is…
var theDialog = $(…).dialog( { autoOpen: true, width: 500, modal:
true, close: function() { theDialog.destroy; }; } )
How do I assemble this, or is there any documentation / examples you
can point me to.
Thanks very much,
Stuart.
On Mar 9, 5:14 pm, Ross Mellgren dri...@gmail.com
be some performance
penalties for normal JSON processing due to conversions.
To be honest, I'm not yet sure what would be the best approach.
Cheers Joni
On Mar 5, 10:08 pm, Ross Mellgren dri...@gmail.com wrote:
The JSON stuff is mostly just an AST and encoding/decoding from the JSON
wire
side forcing the dev team to update
descriptions and keywords where really the designers should be doing this.
Does anyone have a suggestion on how to put the power in the hands of the
designers in this type of situation?
-- Martin
On Sun, Mar 7, 2010 at 6:17 PM, Ross Mellgren dri
:
type mismatch;
[INFO] found : settings.testEnum.MyType
[INFO] required: test.TestEnum.Value
[INFO] val testEnum: TestEnum.Value =
settings.testEnum.valueBox.open_!
Any ideas?
Thanks,
Craig
On Mar 3, 2010, at 8:39 PM, Ross Mellgren wrote:
Try
On Mar 8, 2010, at 3:00 PM, Naftoli Gugenheim wrote:
I'm not 100% clear on your proposal.
First of all, is what I've done (on RB) in the meantime okay (without a
ticket)? Basically, I renamed ItemsListSpecs to MapperSpecs2 and put the test
for issue 370 there. MapperSpecs2 only uses H2
DriverIndependentSpecs?
-Ross
On Mar 8, 2010, at 3:59 PM, Naftoli Gugenheim wrote:
Currently what I did is combine ItemListSpecs with another test, so I gave it
a more generic name than ItemsList, hence MapperSpecs2. The idea is that some
tests really have zero to do with the vendor, but
: settings.testEnum.MyType
[INFO] required: test.TestEnum.Value
[INFO] val testEnum: TestEnum.Value =
settings.testEnum.valueBox.open_!
Any ideas?
Thanks,
Craig
On Mar 3, 2010, at 8:39 PM, Ross Mellgren wrote:
Try this:
/** Enum data field for JSON records
To be parsed by the bind, it must be enclosed by
lift:HelloWorld.hello.../lift:HelloWorld.hello
There is relatively little magic -- Lift goes through your template looking for
lift: prefixed tags. For those tags, it will look up a snippet class by using
the part before the period (HelloWorld,
The JSON stuff is mostly just an AST and encoding/decoding from the JSON wire
format is almost just an addon. Then, it would be a matter of adding AST
objects for those new things. Could be a use for phantom types ;-)
I'd be interested to hear Joni's view on how it might fit, since he's the
)
at net.liftweb.couchd...
The field is defined as:
object updated extends JSONDateTimeField( this)
Surely something else I missed?
Craig
On Mar 3, 2010, at 8:39 PM, Ross Mellgren wrote:
Try this:
/** Enum data field for JSON records. Encodes as JString */
class JSONEnumNameField[OwnerType
); setBox(value) }
On Mar 4, 2010, at 2:29 PM, Craig Blake wrote:
Great, thanks for taking the time to look into it!
Craig
On Mar 4, 2010, at 2:23 PM, Ross Mellgren wrote:
I can reproduce this locally, and offhand looks like a scala compiler bug
(this should never have compiled).
I
It would be breaking only if somebody were using a database backend where it's
NOT a keyword and also had a mapper field called blob, right?
Seems pretty unlikely, but that's just my opinion.
-Ross
On Mar 4, 2010, at 4:13 PM, Jim Barrows wrote:
On Thu, Mar 4, 2010 at 2:10 PM, Mads Hartmann
and you're currently using
blob as a column name you should change it to blob_c?
On 04/03/2010, at 22.16, Ross Mellgren wrote:
It would be breaking only if somebody were using a database backend where
it's NOT a keyword and also had a mapper field called blob, right?
Seems pretty unlikely
#createRecord and JSONMetaRecord#fromJValue instead.
Let me know if anyone has any problems.
-Ross
On Feb 27, 2010, at 11:53 AM, Ross Mellgren wrote:
Hey all,
So as a result of an infelicity in the way records are initialized that
tripped up Tim a week or two ago, I'm planning on doing some
Check dpp's response as of 8:01
-Ross
On Mar 4, 2010, at 7:49 PM, Naftoli Gugenheim wrote:
What version is the demo running?
-
Danoolearydani...@gmail.com wrote:
Just saw that Lift 2.0-M3 was released. I looked to see if the
vulnerability was still
On Mar 3, 2010, at 11:25 AM, David Pollak wrote:
On Tue, Mar 2, 2010 at 11:42 PM, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:
On 3 March 2010 00:03, David Pollak feeder.of.the.be...@gmail.com wrote:
On Tue, Mar 2, 2010 at 1:05 PM, Heiko Seeberger
heiko.seeber...@googlemail.com
Unfortunately the compiler error is bizarre (due to some of the type shuffling
involved), but the underlying problem you're experiencing is that
DateTimeFields (and therefore JSONDateTimeFields) have a storage type of
Calendar, and you're trying to assign a Date to them. Try
that.
Thanks for the quick answer.
Craig
On Mar 3, 2010, at 4:44 PM, Ross Mellgren wrote:
Unfortunately the compiler error is bizarre (due to some of the type
shuffling involved), but the underlying problem you're experiencing is that
DateTimeFields (and therefore JSONDateTimeFields
, 2010, at 7:45 PM, Ross Mellgren wrote:
It's no problem, as I mentioned the compiler error is practically useless.
Hope you get along well, let me know if you have any other issues.
-Ross
On Mar 3, 2010, at 7:29 PM, Craig Blake wrote:
Yep, that seems to be better. Sorry for the noise, I
There's a FactoryMaker in LiftRules that looks like it may do what you want --
try:
LiftRules.stripComments.default = () = false
-Ross
On Mar 4, 2010, at 1:38 AM, aw wrote:
After fielding calls as to why my UI doesn't look correctly on IE, I
discovered that Lift is doing an optimization in
Hey all,
So as a result of an infelicity in the way records are initialized that tripped
up Tim a week or two ago, I'm planning on doing some cleanup to lift-record. It
is a breaking change, and it was noted that it'd be good to get opinions on
this, so here we are!
The original problem was
The mixin behavior is a bug, and is fixed in 1.1 and 2.0. You should switch to
2.0-SNAPSHOT (or 2.0-M2 if you don't like SNAPSHOTs) unless you have a
compelling reason to stay at 1.0
-Ross
On Feb 25, 2010, at 12:13 PM, jasper wrote:
I have also just realized that I forgot to prefix for the
My concern about putting this in LiftRules is that not all applications that
could benefit from the new logging support will use webkit, since the logging
is in common.
Maybe a bridge method in LiftRules to put it in a convenient place, but I think
the actual work should be exposed nearby the
We were talking in another thread about having something kind of similar to
this where the configuration is held in lift-util (maybe lift-common) but it is
accessible through LiftRules. I think it could be a good idea to do this for
this as well, to help guide people to the right place for this
Tim, you can also pin to certain snapshot dates I believe (-SNAPSHOT versions
are actually -MMDDHHMMSS), if something in the future breaks you.
-Ross
On Feb 24, 2010, at 6:14 AM, Timothy Perrett wrote:
Guys,
I see DPP made a bunch of commits last night. Something in there has
Wow, that is amazing. Now we know what the cone of (process) shame looks like!
-Ross
On Feb 24, 2010, at 3:36 PM, David Pollak wrote:
On Wed, Feb 24, 2010 at 12:29 PM, Timothy Perrett timo...@getintheloop.eu
wrote:
The mental image of you wearing a traffic cone on your head is a
input type=text onkeypress={ processKeyPress(event.which, +
jsonCall(pressed, JsRaw(event.which)).toJsCmd + ) } /
-Ross
On Feb 24, 2010, at 6:38 PM, Rick R wrote:
That works beautifully, thanks.
With regards to using custom javascript functions, I have a function
processKeyPress. It's
There's no record code in there -- it uses mapper in fact.
I think this is just for auth.
-Ross
On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote:
Hey all,
I see the LDAP has finally been committed... what is it doing in
modules? Its a read / write to LDAP based on record... shouldn't it
on that module
to give it a more functional style.
Cheers, Tim
On Feb 23, 7:15 pm, Ross Mellgren dri...@gmail.com wrote:
There's no record code in there -- it uses mapper in fact.
I think this is just for auth.
-Ross
On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote:
Hey all
volunteer? :-D
+1 on the MegaUberRobotTronFromOuterSpace. There is also a fair amount of
Java-ish code in there; it would be nice if that went away sometime too :-)
Cheers, Tim
On 23 Feb 2010, at 20:32, Ross Mellgren wrote:
Perhaps eventually (or if someone right now has a strong use
could emulate
that it would be good.
Cheers, Tim
On 19 Feb 2010, at 15:56, Ross Mellgren wrote:
If you can get an established standard on what the content and format
should be, I can work with you reviewing the patches and applying them.
But, need to get a concordance from the list
re-welcome! All official this time and everything.
-Ross
On Feb 22, 2010, at 3:55 PM, David Pollak wrote:
Folks,
Please join me in welcoming John De Goes as a Lift committer. John burst
onto the Lift scene a week or so ago with some excellent enhancements to the
Lift-json stuff and the
Session scope is until the LiftSession expires (which is tied to the container
session) and is longer.
Request scope is during the current page which means the original page
request and any associated AJAX callbacks and other function bindings.
-Ross
On Feb 22, 2010, at 8:20 PM, Strom wrote:
On Feb 22, 2010, at 8:39 PM, Strom wrote:
Thanks for responding Ross. Always helpful.
On Feb 22, 5:25 pm, Ross Mellgren dri...@gmail.com wrote:
Session scope is until the LiftSession expires (which is tied to the
container session) and is longer.
How does one determine the container
Lift 1.1 and 2.0 are the same code stream by the way, just 1.1 was renamed to
2.0 after 1.1-M8. That said, the most recent versions of 2.0-SNAPSHOT and
1.1-SNAPSHOT run on Scala 2.7.7. The new 2.0-SNAPSHOT branch for Scala 2.8.0
(280_port_refresh, built as 2.0-scala280-SNAPSHOT I believe) runs
Ticket filed: http://www.assembla.com/spaces/liftweb/tickets/359
On review board: http://reviewboard.liftweb.net/r/220/
-Ross
On Feb 20, 2010, at 3:02 AM, Justin Reardon wrote:
Hi,
In JSONMetaRecord, the method needAllJSONFields, has documentation claiming
it is false by default, where it
http://www.assembla.com/spaces/liftweb/tickets/358
It's already been pushed to master so is probably in 2.0-SNAPSHOT.
-Ross
On Feb 20, 2010, at 5:09 AM, Ali wrote:
Hi Joni,
Would you please also post the ticket url so I can track it.
Thank you again,
-A
On Feb 20, 10:39 am, Joni
Pushed to master
e82d7346d7cac7782d7e13c35373a585fc9d14e7
-Ross
On Feb 20, 2010, at 3:02 AM, Justin Reardon wrote:
Hi,
In JSONMetaRecord, the method needAllJSONFields, has documentation claiming
it is false by default, where it is in fact true by default. It does seem
safest to have
that will actually fail if
queryViewDocs were to include the dontReduce call would be good? For example
querying on view people_by_age using queryViewDocs would fail presently if
run against CouchDB 0.10.
Thanks,
Justin Reardon
On 2010-02-18, at 15:45 , Ross Mellgren wrote:
Updated the patch up
and described notes and review.
-Ross
On Feb 20, 2010, at 1:03 PM, Justin Reardon justin.rear...@gmail.com
wrote:
Thanks for the fixes Ross! This library is a really great piece of
work.
On 2010-02-20, at 12:53 , Ross Mellgren wrote:
Pushed to master
http://github.com/dpp/liftweb/commit
If you can get an established standard on what the content and format should
be, I can work with you reviewing the patches and applying them.
But, need to get a concordance from the list on the content first.
-Ross
On Feb 19, 2010, at 10:53 AM, Stuart Roebuck wrote:
I've had a bit of a break
Hi all,
I'm wondering how many people are using lift-record's support for JSON:
Record.fromJSON
Record.asJSON
MetaRecord.createRecord(json)
MetaRecord.fromJSON
MetaRecord.asJSON
Field.asJs
The reason I'm wondering is that the JSON support should really use lift-json,
and I'd like
the dontReduce than to remove it.
Thanks,
Justin Reardon
On 2010-02-17, at 23:46 , Ross Mellgren wrote:
Thanks for the suggestion.
I created a ticket:
http://www.assembla.com/spaces/liftweb/tickets/356-add-ability-to-use-doc-result-of-query--not-just-value
And the change is on review
were to include the dontReduce call would be good? For example
querying on view people_by_age using queryViewDocs would fail presently if
run against CouchDB 0.10.
Thanks,
Justin Reardon
On 2010-02-18, at 15:45 , Ross Mellgren wrote:
Updated the patch up on review board, so if you
Awesome. Let me know if you have other problems or questions with lift-couchdb.
-Ross
On Feb 17, 2010, at 9:53 AM, Justin Reardon wrote:
Much better, thank you.
Cheers,
Justin Reardon
On 2010-02-16, at 23:21 , Ross Mellgren wrote:
Fix pushed to master:
http://github.com/dpp
Did the repo ever get converted for autocrlf? I don't remember seeing the
email. I have my autocrlf left alone and I don't have this issue.
-Ross
On Feb 17, 2010, at 9:46 AM, Heiko Seeberger wrote:
Sorry, forgot the subject ...
On Wednesday, February 17, 2010, Heiko Seeberger
I'm starting to look at this. Do you have a repro case?
-Ross
On Feb 17, 2010, at 12:41 PM, Timothy Perrett wrote:
Guys,
Something strange is happening in Lift Record now - I have production
work that for some reason is now not behaving the way it should. The
custom record implementation
that the name field is present and
correct when the field value is set:
field.setFromString
So it appears that its just a problem with set(param) ?
Cheers, Tim
On Feb 17, 5:46 pm, Ross Mellgren dri...@gmail.com wrote:
I'm starting to look at this. Do you have a repro case?
-Ross
and
still get the introspection any ideas?
Cheers, Tim
On Feb 17, 5:52 pm, Ross Mellgren dri...@gmail.com wrote:
Name should be set by introspect during the record initialization, so I'm
not sure why it would matter. Also, setFromString and set should both
degenerate to setBox, which
There is a persistence-layer-agnostic layer that provides the form
generation support, field validation logic, and common modelling
called Record. It's fairly similar to Mapper except for the lack of a
SQL backend.
I wrote a driver and record integration for CouchDB which I think is
Thanks for the suggestion.
I created a ticket:
http://www.assembla.com/spaces/liftweb/tickets/356-add-ability-to-use-doc-result-of-query--not-just-value
And the change is on review board: http://reviewboard.liftweb.net/r/216/
Once that's reviewed and pushed to master you'll be able to query
Any chance you could have this discussion on-list to increase the general
knowledge about it?
-Ross
On Feb 16, 2010, at 8:50 AM, Timothy Perrett wrote:
Contact me privatly with your IM adress and lets chat about it Jeppe - I'm
doing something similar with helicon (windows proxy) and it's
As a word before giving you a direct answer, you should know that Scala 2.8.0
branch of Lift is not officially supported yet. We obviously invite bugs to fix
and so on, but there are things that could be strangely broken and we won't be
able to support you as well. You might consider switching
jeppe to post working solution when one exists...
Cheers, Tim
Sent from my iPhone
On 16 Feb 2010, at 15:15, Ross Mellgren dri...@gmail.com wrote:
Any chance you could have this discussion on-list to increase the general
knowledge about it?
-Ross
On Feb 16, 2010, at 8:50 AM, Timothy
Fix pushed to master:
http://github.com/dpp/liftweb/commit/8e9e43dfd344256add50179f61524da4f07f47ec
-Ross
On Feb 15, 2010, at 5:40 PM, David Pollak wrote:
On Mon, Feb 15, 2010 at 2:32 PM, Justin Reardon justin.rear...@gmail.com
wrote:
Hi folks,
Using the lift-couchdb module, I
On Feb 15, 2010, at 1:56 PM, Marius wrote:
The author says something like The moment you define a domain
abstraction as being statically dependent on a persistence
implementation, you lose the ability to reuse it in other contexts..
I disagree completly. I can think of a couple of options:
Argh. I'm going to have to reimplement the Dispatch lift-json integration
in-house. Shouldn't take too long at least. Thanks for the catch.
-Ross
On Feb 15, 2010, at 5:40 PM, David Pollak wrote:
On Mon, Feb 15, 2010 at 2:32 PM, Justin Reardon justin.rear...@gmail.com
wrote:
Hi folks,
I have a mild derivative of this code in another test repo I built for someone
else:
http://github.com/Dridus/test-image
Maybe that'll help.
-Ross
On Feb 15, 2010, at 5:19 PM, David Pollak wrote:
On Mon, Feb 15, 2010 at 5:54 AM, Luke Nezda lne...@gmail.com wrote:
Hello -
I attempted
on to CRUDify/CRUDops style stuff for Record too.
-Ross
On Feb 12, 2010, at 11:52 AM, David Pollak wrote:
On Fri, Feb 12, 2010 at 1:26 AM, Timothy Perrett timo...@getintheloop.eu
wrote:
Congratulations Ross.
+1
Cheers, Tim
On Feb 12, 5:07 am, Ross Mellgren dri...@gmail.com
I believe IE6 does not follow the correct process you describe and will always
cache CSS files of the same name.
-Ross
On Feb 12, 2010, at 3:48 PM, Alex Black wrote:
hey guys, I love the enthusiasm, but putting a unique value on the css
filenames seems like a hack, surely we can do better?
expires headers or some caching rules?
On Feb 12, 3:48 pm, Ross Mellgren dri...@gmail.com wrote:
I believe IE6 does not follow the correct process you describe and will
always cache CSS files of the same name.
-Ross
On Feb 12, 2010, at 3:48 PM, Alex Black wrote:
hey guys, I love
It's up on repo-releases, though maybe it is not complete?
-Ross
On Feb 11, 2010, at 12:07 PM, David Pollak wrote:
On Thu, Feb 11, 2010 at 9:05 AM, GA my_li...@me.com wrote:
Thanks I am gonna try and test it.
When is 2.0-M2 going to be released?
Yesterday... trying to figure out
Hey Tim (Nelson),
Have you thought about bringing scamongo in as part of Lift?
-Ross
On Feb 11, 2010, at 5:24 PM, Tim Nelson wrote:
You should note that only the save and delete callbacks have been
implemented, but I haven't tested them.
If you have other requirements, let me know and I
I just committed a change to lift-record in 2.0-SNAPSHOT that will possibly
(probably?) break your build if you use it.
This change makes it possible to have any record field be optional -- that is,
Box[MyType]. You use it like this:
object MyRecord extends Record[MyRecord] {
object
I've just pushed the CouchDB integration using Lift-JSON and Dispatch that I've
talked about on the list a couple times before.
It has a couple pieces:
- A straight JSON integration to CouchDB implemented by providing a family of
extended Request subclasses that model CouchDB operations such
11, 11:49 pm, Ross Mellgren dri...@gmail.com wrote:
I just committed a change to lift-record in 2.0-SNAPSHOT that will possibly
(probably?) break your build if you use it.
This change makes it possible to have any record field be optional -- that
is, Box[MyType]. You use it like
Shouldn't:
cd archetypes; mvn clean install
mvn archetype:generate -DarchetypeGroupId=net.liftweb
-DarchetypeArtifactId=lift-archetype-basic -DarchetypeVersion=2.0-SNAPSHOT
work, since clean install will install in your local repo?
-Ross
On Feb 10, 2010, at 3:22 PM, Jeppe Nejsum Madsen
Welcome!
On Feb 8, 2010, at 12:16 PM, David Pollak wrote:
Folks,
I'm wicked pleased that James Strachan has joined the Lift committers. I'm
looking forward to the cool stuff that James will add to Lift.
Please join me in welcoming James!
Thanks,
David
--
Lift, the simply
phrase).
Erkki L
On Feb 6, 9:59 pm, Ross Mellgren dri...@gmail.com wrote:
I think it would be fine to have different text there, probably better
than having the standard text if you have refined detail. I don't think
it'd be a good idea to conditionalize on the response text in client code
Also, please don't use GitHub for issues any more. Care of Indrajit, here is
the new URL to submit issues:
http://www.assembla.com/spaces/liftweb/tickets
-Ross
On Feb 6, 2010, at 3:12 PM, Indrajit Raychaudhuri wrote:
Go ahead! create tickets in Assembla.
Cheers, Indrajit
On 05/02/10
, Ross Mellgren wrote:
Also, please don't use GitHub for issues any more. Care of Indrajit,
here is the new URL to submit issues:
http://www.assembla.com/spaces/liftweb/tickets
-Ross
On Feb 6, 2010, at 3:12 PM, Indrajit Raychaudhuri wrote:
Go ahead! create tickets in Assembla.
Cheers
This is actually fairly common that messages Naftoli sends are empty, or don't
get threaded onto the original discussion, or formatting comes out funny.
Naftoli, what email client are you using?
-Ross
On Feb 5, 2010, at 1:49 AM, Mads Hartmann wrote:
Hey Naftoli,
I think something might have
On Feb 5, 2010, at 12:18 PM, David Pollak wrote:
On Fri, Feb 5, 2010 at 9:06 AM, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:
On 5 February 2010 15:05, Martin Ellis ellis@gmail.com wrote:
Any offers/suggestions? (Sorry, I realise the question more about
OSGI than lift)
In my experience, I found that the functionality of the FactoryMakers was very
flexible (and I could see the utility of that), but that the documentation was
just plain missing. Maybe more/better documentation on FactoryMaker itself, and
some simple common examples on the places where
a survey of how other JVM web frameworks handle the PUT
inconsistencies on different containers?
On Fri, Feb 5, 2010 at 9:29 AM, Ross Mellgren dri...@gmail.com wrote:
Looking at the Tomcat code, this is explicit. From
org.apache.catalina.connector.Request:
/**
* Parse request
I think this new version will be slower than your original one, as each call to
bind will visit the entire input XHTML. Why not use your original formulation
but instead of TheBindParam, use FuncBindParam (which is the sugar-free version
of body = ... that David describes)?
-Ross
On Feb 4,
How about:
myMappedObject.runSafe {
myMappedObject.allFields.foreach(_.resetDirty)
}
?
-Ross
On Feb 4, 2010, at 2:50 PM, harryh wrote:
At least in my use case this is not idea as I am loading JSON
serialized mapper objects from memcached and the fields are not, in
fact, dirty. There
P.S. Hooray for ticket system that doesn't suck!
-Ross
On Feb 4, 2010, at 3:54 PM, David Pollak wrote:
On Thu, Feb 4, 2010 at 12:47 PM, Ross Mellgren dri...@gmail.com wrote:
I reopened it since I marked it invalid pending the ML discussion.
Added a comment with the ML discussion
RedirectTo should automatically prepend the context path. Could you try writing
a quick snippet that dumps S.request.map(_.contextPath),
S.session.map(_.contextPath) and finally S.contextPath and see what they output?
-Ross
On Feb 4, 2010, at 5:03 PM, Java1Guy wrote:
This sure seems like it
So are you saying that if you run it via jetty:run it doesn't behave properly,
but it does if you run it from jetty outside of mvn?
Or that in both cases it does not behave? I'm not sure exactly what you mean by
from jetty so I think it might be important.
To set your context path from mvn
Yes very well could be. I was part of the email chain when Marius implemented
these changes and I thought that this was why LiftSession has a copy of the
contextPath. Taking a quick glance at the code it should work with that, but
Marius should definitely comment since he's most familiar with
Are you sending Content-Type: application/x-www-form-urlencoded or
multipart/form-data (as appropriate for the body)?
-Ross
On Feb 3, 2010, at 2:48 PM, c...@munat.com wrote:
I have a lift app that works perfectly when I use mvn jetty:run. Then I
package it into a war and load it up in Tomcat
window.onbeforeunload = function() {
if ((emailWizard.htmlTemplateUI.isDirty || emailWizard.textEditorUI.isDirty
|| emailWizard.server.needsSaving) !intentionallyLeavingPage) {
return 'There are unsaved changes.';
}
}
On Feb 2, 2010, at 1:31 PM, Naftoli Gugenheim wrote:
Hi,
That's what the intentionallyLeavingPage variable was in my code snippet.
Submit buttons set this JS variable, so the check is bypassed in that case.
-Ross
On Feb 2, 2010, at 3:32 PM, Naftoli Gugenheim wrote:
One problem -- this script should not be triggered by submit buttons or
stateful
and give you
feedback.
Thanks,
David
On Sun, Jan 24, 2010 at 4:06 PM, Ross Mellgren dri...@gmail.com
wrote:
So I've taken the Couch integration I had previously talked about
and have done quite a bit of work on it:
- Now has a record integration:
- built with two layers -- JSONRecord
lift-mapper's MappedPassword has a method match_?, but PasswordField in
lift-record does not, and I can't see a way around using it since salt_i is
protected, other than subclassing PasswordField.
I think a match_? method should be added to PasswordField, and if folks agree
I'll create a
Looks like you forgot to add form=POST as an attribute to your snippet call.
Without this, the form tag does not get generated.
That is, change lift:Search to lift:Search form=POST and I think it
should start working.
-Ross
On Jan 27, 2010, at 1:24 AM, Strom wrote:
I'm having a hard time
So I've taken the Couch integration I had previously talked about and have done
quite a bit of work on it:
- Now has a record integration:
- built with two layers -- JSONRecord which is a Record implementation that
emits/consumes lift-json AST, and CouchRecord extends that with database
welcome Jeppe!
-Ross
On Jan 22, 2010, at 11:25 AM, David Pollak wrote:
Folks,
Please join me in welcoming Jeppe as a Lift Committer. He's been helping
people on the Lift list and contributing his thoughts to the Lift community
for a while... now it's time for him to contribute code to
It doesn't work is not sufficient to diagnose. What behavior did you get, and
what were you expecting? Were there any errors, log messages, exceptions, etc?
If so, please copy them. Finally, if you have a reproducible test case please
post it to github. I note earlier in the thread that you
most of the rendering done by
JS since rendering everything with ruby slowed down everything for
another few seconds, on lift it works even faster on the client side
since it already does the output-generation in a nip of a second.
Kudos!
On 21 Jan., 01:24, Ross Mellgren dri...@gmail.com
I'm not going to try and explain, but I do recommend you run ab two or more
times in succession and take the average. HotSpot VMs (the java VM) does
selective optimization, so the first run of a benchmark will not be near it's
maximum speed. I'm not saying this will resolve the issue for you,
Scala can't figure out what type of parameter you mean, so you need to annotate
it -- expand - (fooXhtml: NodeSeq) = {... }
Or use a separately named function with a type signature, e.g.
def doTheStuff(ns: NodeSeq): NodeSeq) = { Log.error(ns.toStrnig); span / }
bind(..., expand - doTheStuff
Well, it would help to have the compiler error, but I may have gotten
precedence wrong. Try:
expand - { (fooXhtml: NodeSeq) = ... }
instead
-Ross
On Jan 20, 2010, at 3:51 PM, Franz Bettag wrote:
That doesn't seem to fix the compiler error. :)
On 20 Jan., 21:44, Ross Mellgren dri
On 20 Jan., 21:44, Ross Mellgren dri...@gmail.com wrote:
Scala can't figure out what type of parameter you mean, so you need to
annotate it -- expand - (fooXhtml: NodeSeq) = {... }
Or use a separately named function with a type signature, e.g.
def doTheStuff(ns: NodeSeq): NodeSeq
1 - 100 of 354 matches
Mail list logo