Re: [Lift] Re: non-Lazy evaluation of bind FuncBindParam functions?
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 construct like:
>
> bind("example",xhtml,
>"first_name" -> SHtml.text(user.first_name, user.first_name(_)),
>"last_name" -> SHtml.text(user.last_name, user.last_name(_))
>
> it reminded me of a match with cases and my assumption was that each
> match would only be called if and when the match was found. In reality
> what appears to happen is that the item on the right hand side of the
> "->" is usually evaluated and then placed into a Map with the String
> like "first_name" being the key.
>
> So, if every binding is used in every case there is no big issue here,
> but if you have bindings that aren't all used they will none-the-less
> be evaluated every time you try to bind.
>
> Also every time the bind function is called a new Map appears to be
> generated and indexed in memory which doesn't seem as efficient as it
> could be.
>
> I can't help but wonder whether this could be converted to a form of
> match which would then be built at compile time and re-used and would
> only evaluate those matches that matched.
>
> In the meantime I see that you can convert the code above to:
>
> bind("example",xhtml,
>FuncBindParam("first_name", () => SHtml.text(user.first_name,
> user.first_name(_)),
>FuncBindParam("last_name", () => SHtml.text(user.last_name,
> user.last_name(_))
>
> to get a form of lazy evaluation.
>
>
> On Mar 10, 11:01 am, Stuart Roebuck wrote:
>> I've been trying to figure why some binding is giving me a stack
>> overflow and I've discovered that if you use the BindHelpers.bind
>> method with a set of function BindParams, all the functions are
>> evaluated regardless of whether a match is found.
>>
>> So, for example, if you bind to an empty NodeSeq and have a BindParam
>> which will never match like:
>> "you won't find me here" -> { print("Got here!");
>> NodeSeq.Empty }
>> …you find that the print statement is called.
>>
>> This really surprised me. Is this intentional behaviour as it seems
>> to be a potential source of significant redundant processing?
>>
>> Stuart.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: NodeSeq to JsExp how to?
That's why I factored this as a JQueryNodeSeq, so you can pass anything to
dialog (I've used JQuery, and figured you'd need to pass something in there ;-)
JQueryNodeSeq(ns) ~> JsFunc("dialog", JsObj("autoOpen" -> JsTrue, "width" ->
500, ..., "close" -> AnonFunc(JsVal("this") ~> JsFunc("destroy"
>>> case class JQueryNodeSeq(ns: NodeSeq) extends JsExp with JQueryLeft with
>>> HtmlFixer {
JsExp is the basic trait of the JavaScript DSL. Anything that can go into a
JavaScript expression should have this trait.
JQueryLeft is a trait used by the JQuery portion of the JavaScript DSL to
indicate that you can chain JQuery calls onto this.
HtmlFixer is a trait that provides fixHtml
>>>override def toJsCmd = "jQuery(" + JsStr(fixHtml("NodeSeqDialog",
>>> ns)).toJsCmd + ")"
fixHtml takes the given NodeSeq and does all the appropriate magics to process
lift: tags and then converts the NodeSeq to valid XHTML.
>>> }
And don't forget the security implications!
Hope that helps,
-Ross
On Mar 9, 2010, at 12:30 PM, Stuart Roebuck wrote:
> Thanks for that amazingly quick response!
>
> I only wish I understood the proposed solution! :-)
>
> So (confession time) I simplified things a little, the actual
> JavaScript 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 wrote:
>> 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 = "jQuery(" + JsStr(fixHtml("NodeSeqDialog",
>>> ns)).toJsCmd + ")"
>>> }
>>
>>> Then JQueryNodeSeq(ns) ~> JsFunc("dialog")
>>
>>> -Ross
>>
>>> On Mar 9, 2010, at 12:06 PM, Stuart Roebuck wrote:
>>
>>>> I'm trying to produce a web page with editable content.
>>
>>>> When the user clicks an edit button on a line it uses jQuery to
>>>> display a modal dialog which allows fields of that line to be edited.
>>
>>>> I can easily produce a snippet to produce the lines using the backend
>>>> data and an XHTML template and binding etc.
>>
>>>> However, I also want the template to include the template for the
>>>> dialog. So I want the ajax button callback to send JavaScript to
>>>> instantiate the jQuery UI dialog based on the template and bindings.
>>
>>>> To build this I need to assemble a JsCmd containing the NodeSeq that
>>>> comes from the XHTML sequence and the bindings.
>>
>>>> In short, if this was straight jQuery I would have some JavaScript of
>>>> the form:
>>
>>>> $(theFormNodeSeq).dialog()
>>
>>>> But in my case theFormNodeSeq comes from a NodeSeq that was assembled
>>>> from part of the XHTML template and the bindings and the end result
>>>> needs to be a JsCmd.
>>
>>>> So I'm trying to do something like:
>>
>>>> JsCmds.Run("$(" + theFormNodeSeq.toString + ").dialog()")
>>
>>>> But I need to address escaping issues with the HTML and I also need to
>>>> pre-process any "" commands in theFormNodeSeq.
>>
>>>> Any advice (please)?
>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "Lift" group.
>>>> To post to this group, send email to lift...@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> liftweb+unsubscr...@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 lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] NodeSeq to JsExp how to?
Ah yes, the reason I went through the fixHtml route is because Stuart
specifically mentioned he wanted to process those.
Stuart, you should make sure to properly secure this stuff -- either as an
admin-only thing (understanding that that person has as much rights as you) or
by scrubbing 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 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 = "jQuery(" + JsStr(fixHtml("NodeSeqDialog",
> ns)).toJsCmd + ")"
> }
>
> Ross,
>
> This is good code, but introduces a potential security vulnerability. ;-)
>
> fixHtml runs the NodeSeq through Lift's snippet handler. If you have
> web-user input, a user could type in and cause server-side code
> to be executed.
>
> import net.liftweb.util._
> import Helpers._
>
> Personally, I'd suggest "jQuery(" + AltXML.toXML(nodeSeq, false, true).encJs
> + ")"
>
> Thanks,
>
> David
>
>
> Then JQueryNodeSeq(ns) ~> JsFunc("dialog")
>
> -Ross
>
> On Mar 9, 2010, at 12:06 PM, Stuart Roebuck wrote:
>
> > I'm trying to produce a web page with editable content.
> >
> > When the user clicks an edit button on a line it uses jQuery to
> > display a modal dialog which allows fields of that line to be edited.
> >
> > I can easily produce a snippet to produce the lines using the backend
> > data and an XHTML template and binding etc.
> >
> > However, I also want the template to include the template for the
> > dialog. So I want the ajax button callback to send JavaScript to
> > instantiate the jQuery UI dialog based on the template and bindings.
> >
> > To build this I need to assemble a JsCmd containing the NodeSeq that
> > comes from the XHTML sequence and the bindings.
> >
> > In short, if this was straight jQuery I would have some JavaScript of
> > the form:
> >
> > $(theFormNodeSeq).dialog()
> >
> > But in my case theFormNodeSeq comes from a NodeSeq that was assembled
> > from part of the XHTML template and the bindings and the end result
> > needs to be a JsCmd.
> >
> > So I'm trying to do something like:
> >
> > JsCmds.Run("$(" + theFormNodeSeq.toString + ").dialog()")
> >
> > But I need to address escaping issues with the HTML and I also need to
> > pre-process any "" commands in theFormNodeSeq.
> >
> > Any advice (please)?
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://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 lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
>
>
> --
> 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
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] NodeSeq to JsExp how to?
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 = "jQuery(" + JsStr(fixHtml("NodeSeqDialog",
> ns)).toJsCmd + ")"
> }
>
> Then JQueryNodeSeq(ns) ~> JsFunc("dialog")
>
> -Ross
>
> On Mar 9, 2010, at 12:06 PM, Stuart Roebuck wrote:
>
>> I'm trying to produce a web page with editable content.
>>
>> When the user clicks an edit button on a line it uses jQuery to
>> display a modal dialog which allows fields of that line to be edited.
>>
>> I can easily produce a snippet to produce the lines using the backend
>> data and an XHTML template and binding etc.
>>
>> However, I also want the template to include the template for the
>> dialog. So I want the ajax button callback to send JavaScript to
>> instantiate the jQuery UI dialog based on the template and bindings.
>>
>> To build this I need to assemble a JsCmd containing the NodeSeq that
>> comes from the XHTML sequence and the bindings.
>>
>> In short, if this was straight jQuery I would have some JavaScript of
>> the form:
>>
>> $(theFormNodeSeq).dialog()
>>
>> But in my case theFormNodeSeq comes from a NodeSeq that was assembled
>> from part of the XHTML template and the bindings and the end result
>> needs to be a JsCmd.
>>
>> So I'm trying to do something like:
>>
>> JsCmds.Run("$(" + theFormNodeSeq.toString + ").dialog()")
>>
>> But I need to address escaping issues with the HTML and I also need to
>> pre-process any "" commands in theFormNodeSeq.
>>
>> Any advice (please)?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] NodeSeq to JsExp how to?
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, 2010, at 12:06 PM, Stuart Roebuck wrote:
> I'm trying to produce a web page with editable content.
>
> When the user clicks an edit button on a line it uses jQuery to
> display a modal dialog which allows fields of that line to be edited.
>
> I can easily produce a snippet to produce the lines using the backend
> data and an XHTML template and binding etc.
>
> However, I also want the template to include the template for the
> dialog. So I want the ajax button callback to send JavaScript to
> instantiate the jQuery UI dialog based on the template and bindings.
>
> To build this I need to assemble a JsCmd containing the NodeSeq that
> comes from the XHTML sequence and the bindings.
>
> In short, if this was straight jQuery I would have some JavaScript of
> the form:
>
> $(theFormNodeSeq).dialog()
>
> But in my case theFormNodeSeq comes from a NodeSeq that was assembled
> from part of the XHTML template and the bindings and the end result
> needs to be a JsCmd.
>
> So I'm trying to do something like:
>
> JsCmds.Run("$(" + theFormNodeSeq.toString + ").dialog()")
>
> But I need to address escaping issues with the HTML and I also need to
> pre-process any "" commands in theFormNodeSeq.
>
> Any advice (please)?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: field without mapper and Form validation
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 wrote: >> Le 09/03/2010 10:12, Francois a écrit : >>> >>> Hello guys, >>> >>> >>> I'm often using forms without anything to do persistence and RDBMS >>> related, but I would like to be able to use Fields (StringField, >>> EmailField, my owns, etc), validation, error management, etc. without >>> having everything to manage by hand. >> >> >> After searching more carefully on the mailing list archive, it seems that >> what I'm looking for is something like a mix of one-page wizard with >> Record/Mapper fields integration (or fields that are currently in >> Record/Mapper/Wizard may live in there own package and only manage the >> domain/client part ?) >> >> Relevant threads: >> - http://old.nabble.com/Multipage-wizards-td26504293.html (especially Jeppe >> answer) >> - >> http://old.nabble.com/Lift-Wizard-Fields-incompatible-with-lift-record-fields-tc27230782.html >> >> >> So, I'm going to see how wizards are working, > > Cool, let me know how it works. As you noted, I basically have the > same needs, but haven't started to look into this yet :-) > > I saw the Lift example now includes a one page form (based on > wizards): http://demo.liftweb.net/simple_screen > > /Jeppe > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Trouble with lift-couchdb
So I looked into this as best I could and it seems to be a type inference error
where the compiler is inferring a too-loose type binding for EnumType and
therefore rejecting the assignment to a (supposedly) more specific
Box[TestEnum.Value].
I have no idea how to fix the code so it deduces the correct type or if I've
diagnosed the problem incorrectly; however, you can force the type:
object testEnum extends JSONEnumNameField[Settings, TestEnum.type](this,
TestEnum)
and that seems to make it happy. I tried this with 2.8.0.Beta1 also and it
appears that it also rejects it.
-Ross
On Mar 8, 2010, at 11:05 AM, Craig Blake wrote:
> Writing into the database with the new field type works fine, but I'm running
> into a little hitch trying to access the value. Given the test code (again
> this is in the Github test project,
> g...@github.com:craigwblake/lift-couchdb-test.git):
>
> object TestEnum extends Enumeration { val One = Value( "One")}
>
> object Settings extends Settings with CouchMetaRecord[ Settings]
> class Settings extends CouchRecord[ Settings] {
> def meta = Settings
> object testEnum extends JSONEnumNameField( this, TestEnum)
> }
>
> val settings = Settings.fetch( "id").open_!
> val testEnum: TestEnum.Value = settings.testEnum.valueBox.open_!
>
>
> Results in a compilation error:
>
> [ERROR] /lift-couchdb-test/src/main/scala/test/Testing.scala:24: error:
> 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 this:
>>
>> /** Enum data field for JSON records. Encodes as JString */
>> class JSONEnumNameField[OwnerType <: JSONRecord[OwnerType], EnumType <:
>> Enumeration]
>> (rec: OwnerType, enum: EnumType)(implicit
>> enumValueType: Manifest[EnumType#Value])
>> extends EnumField[OwnerType, EnumType](rec, enum) with JSONField
>> {
>> def this(rec: OwnerType, enum: EnumType, value: EnumType#Value)(implicit
>> enumValueType: Manifest[EnumType#Value]) = {
>> this(rec, enum)
>> set(value)
>> }
>>
>> def this(rec: OwnerType, enum: EnumType, value:
>> Box[EnumType#Value])(implicit enumValueType: Manifest[EnumType#Value]) = {
>> this(rec, enum)
>> setBox(value)
>> }
>>
>> def asJValue: JValue = valueBox.map(v => JString(v.toString)) openOr
>> (JNothing: JValue)
>> def fromJValue(jvalue: JValue): Box[EnumType#Value] = jvalue match {
>> case JNothing|JNull if optional_? => setBox(Empty)
>> case JString(s) => setBox(enum.valueOf(s) ?~ ("Unknown
>> value \"" + s + "\""))
>> case other=> setBox(expectedA("JString", other))
>> }
>> }
>>
>> Let me know if it works for you. If so, I'll start the process of getting it
>> into master as soon as I can.
>>
>> -Ross
>>
>> On Mar 3, 2010, at 8:12 PM, Craig Blake wrote:
>>
>>> Sure, will do. The only thing I think I'll need to figure out is how to
>>> persist an enumeration by name rather than ordinal value, but I imagine
>>> that it should be pretty straight-forward to add a new field type in my app
>>> to handle it.
>>>
>>> Thanks,
>>> Craig
>>>
>>> On Mar 3, 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 don't know why I
>>>>> didn't think to check 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) have a storage
>>>>>
Re: [Lift] Reorganize mapper specs?
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 higher-level behavior. > H2MemoryProvider is incidental--in memory databases are perfect for testing. > So I'd prefer not putting the choice of testing db in the name of a > driver-independent test. > If an ORM is a form of caching then these are cache-related specs. > If David vetoes the change on RB, a name is irrelevant; and depending on his > proposal it may be temporary; but I'm looking for a name that says "More > Mapper Specs except these specs are run on one arbitrary driver rather than > on all of them, because these specs are driver-independent by definition." > Thanks! > > - > Jim Barrows wrote: > > On Mon, Mar 8, 2010 at 1: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 memory db. (Any >> suggestions for a better name?) >> > > ItemsListOnH2MemorySpecs.scala > ItemsListH2MemorySpecs.scala > ItemsList_H2Memory_Specs.scala -- this is probably the most readable and > sets up the pattern for names like > WhatsUnderTest_JDBCDriverSpecificName_Specs > > It's wordy, but if you want everything in the same directory, then that's > what happens. Probably better would be: > > itemsList/ItemsListSpecs.scala > itemsList/H2MemorySpecs.scala > itemsList/JdbcDriverSpecs.scala > > Less wordy, but you have one more directory to traverse to get there. > However if you figure we'll have mysql, sqlserver, oracle, h2 & postgres at > a minimum, I think that this actually easier on the eyes when trying to find > the right jdbc driver specific tests. In addition, we'll probably at some > point end up with version specific test cases as well. That should probably > go in the same file, and use the version as part of the name. > > So the specs name (ItemsList, in this case) is the cross driver tests, with > the driver specific specs test in the same directory. > > > Any other ideas? > > > > >> As for your proposal, are you saying that things like ItemsListSpecs and >> 370, which deal with high-level Mapper API not directly related to the >> database, should ideally be testable on every database vendor? And/or are >> you saying that *all* the tests should be run by default on only one driver >> but have the option to run on all? >> Also, is it possible to run MapperSpecs for all the drivers in parallel, >> and if so would that cause it to finish faster? >> >> Thanks. >> >> - >> David Pollak wrote: >> >> On Sun, Mar 7, 2010 at 12:47 PM, Naftoli Gugenheim >> wrote: >> >>> Based on discussion on Review Board item 247, I want to propose the >>> following change to the organization of Mapper specs. >>> Currently there are four files in >>> framework/lift-persistence/lift-mapper/src/test/scala/net/liftweb/mapper: >>> DBProviders - initalization for each provider to be tested >>> MapperSpecs - the original set of tests. Tested per provider, which makes >>> sense for tests that interact with the database >>> ManyToManySpecs - tests I added with an enhancement to ManyToMany to not >>> choke on broken joins. Only uses DBProviders.H2MemoryProvider. When FK >>> constraints are enabled in H2 this will have to disable them. >>> ItemsListSpecs - tests for a bugfix in ItemsList. Also only uses >>> DBProviders.H2MemoryProvider. >>> >>> Currently MapperSpecs takes about five minutes to run on my laptop. So >> any >>> new test that isn't driver dependent should probably not be tested on all >>> drivers. Thus I'm considering consolidating ItemsListSpecs and >>> ManyToManySpecs into one specs for all H2MemoryProvider-only tests. >>> Then, with two set of tests, one run for each driver and one not, maybe >>> their names should reflect that. >>> It's just a possible idea, but what do people think? Also, if I would go >>> ahead would it need a ticket or just straight to RB? >>> >> >> I agree with the goal of shortening the time it takes to run mapper tests. >> >> I would like there to be a way (not the default, but something that can be >> done with some form of compiler/maven flags) to run all cross-products of >> all tests so we just make 100% sure that things work on all RDBMSs. >> >> Please open a ticket first before putting stuff on RB. >> >> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> liftweb+unsubscr...@googlegroups.com >> >>> >>
Re: [Lift] Customizing meta fields
No problem. Let us know if you have any more questions. -Ross On Mar 8, 2010, at 2:09 PM, Martin Dale Lyness wrote: > Again, thank you so much for the help! The head merge feature is perfect for > this situation i described and my next line of though is right inline with > how you describe bind points! > > Thanks again! > > -- Martin > > On Mon, Mar 8, 2010 at 12:47 PM, Ross Mellgren wrote: > For your particular example, you can use head merge as Naftoli suggests. Head > merge is a behavior of Lift templates where any tags will be merged > together for the final output, so you put your meta name="description" in > each of the specific places, any general head stuff you want in your > surrounding template and they will magically get folded together at render > time. > > For other cases, you have a couple tools at your disposal: > - RequestVars -- variables that are local to a particular page request. You > can use these inside snippets to capture and recover values during template > processing. > - Bind points. In a surrounding template you can use tags like name="foobar" /> and then define what to put there in the surrounded template > using the content > > And there are more. Hopefully head merging will work for you in this case. > > -Ross > > On Mar 7, 2010, at 8:25 PM, Martin Dale Lyness wrote: > >> Thank you Ross, for the very informative response! >> >> Now, I consider SEO to be closer to a designer task than a developer task so >> keeping the power in the design documents would be my best idea. Is there >> anyway to allow individual pages to define blocks that are read into the >> snippets and then injected into the template? >> >> Here is the scenario i'm thinking of: >> 1. A single uniform website template: default.html >> 2. Several HTML files: index.html, product_list.html, product_overview.html >> 3. Each of these HTML files containing tags referencing snippets. >> >> What i would want is for index.html, product_list.html, and >> product_overview.html to all use default.html and various Snippet classes. >> Now for SEO i would want the meta tags in the header of default.html to be >> customized to index.html, product_list.html, and product_overview.html; >> furthermore, product_list and product_overview are dynamic pages so they >> would need further customization based on what the snippets are returning. >> >> Essentially, i would want tags something like: >> This site is totally awesome, better than all our >> competitors in index.html >> Look at all these products in >> %%category_name%%in product_list.html >> %product_name% - %product_description% >>in product_overview.html >> >> The conceptual road block for me is coming from the controller first pattern >> used in frameworks like Rails. In lift snippets are not really the same >> conceptually. If i use the second proposed method (i.e. >> wrapping the entire template) i would have a battle >> between snippets used by each page. For example, perhaps i have a product >> overview snippet that sets the meta one way and a login snippet that sets it >> another way (intended for when show standalone in a login.html). >> >> The first solution with using a to inject a >> snippet at a meta location fits better because it would allow me to create a >> generic function that would attempt to create the keyword and description >> data based on whatever global information is made available to snippets by >> lift (i.e. Request Parameters?). My only problem with using this option is >> it puts all of the text on the developer 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 wrote: >> To be parsed by the bind, it must be enclosed by >> ... >> >> 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, in the above example) and then >> look for a method on that snippet class mentioned after the period (hello in >> the example). If there is no period, the method is assumed to be called >> "render". >> >> Once that method is found, the method is called with the contents of the >
Re: [Lift] Reorganize mapper specs?
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 memory db. (Any suggestions > for a better name?) H2DatabaseMapperSpecs? > As for your proposal, are you saying that things like ItemsListSpecs and 370, > which deal with high-level Mapper API not directly related to the database, > should ideally be testable on every database vendor? And/or are you saying > that *all* the tests should be run by default on only one driver but have the > option to run on all? > Also, is it possible to run MapperSpecs for all the drivers in parallel, and > if so would that cause it to finish faster? > > Thanks. > > - > David Pollak wrote: > > On Sun, Mar 7, 2010 at 12:47 PM, Naftoli Gugenheim > wrote: > >> Based on discussion on Review Board item 247, I want to propose the >> following change to the organization of Mapper specs. >> Currently there are four files in >> framework/lift-persistence/lift-mapper/src/test/scala/net/liftweb/mapper: >> DBProviders - initalization for each provider to be tested >> MapperSpecs - the original set of tests. Tested per provider, which makes >> sense for tests that interact with the database >> ManyToManySpecs - tests I added with an enhancement to ManyToMany to not >> choke on broken joins. Only uses DBProviders.H2MemoryProvider. When FK >> constraints are enabled in H2 this will have to disable them. >> ItemsListSpecs - tests for a bugfix in ItemsList. Also only uses >> DBProviders.H2MemoryProvider. >> >> Currently MapperSpecs takes about five minutes to run on my laptop. So any >> new test that isn't driver dependent should probably not be tested on all >> drivers. Thus I'm considering consolidating ItemsListSpecs and >> ManyToManySpecs into one specs for all H2MemoryProvider-only tests. >> Then, with two set of tests, one run for each driver and one not, maybe >> their names should reflect that. >> It's just a possible idea, but what do people think? Also, if I would go >> ahead would it need a ticket or just straight to RB? >> > > I agree with the goal of shortening the time it takes to run mapper tests. > > I would like there to be a way (not the default, but something that can be > done with some form of compiler/maven flags) to run all cross-products of > all tests so we just make 100% sure that things work on all RDBMSs. > > Please open a ticket first before putting stuff on RB. > > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com >> . >> For more options, visit this group at >> http://groups.google.com/group/liftweb?hl=en. >> >> > > > -- > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Trouble with lift-couchdb
I'll have to look at this in more detail tonight. I took a quick couple hacks
at it and I can honestly say I have no idea what kind of problem the Scala
compiler is trying to tell you about :-/
If you avoid types, they clearly are of the same type and value (e.g.
settings.testEnum.valueBox.open_! == Full(TestEnum.One) -> true)
-Ross
On Mar 8, 2010, at 11:05 AM, Craig Blake wrote:
> Writing into the database with the new field type works fine, but I'm running
> into a little hitch trying to access the value. Given the test code (again
> this is in the Github test project,
> g...@github.com:craigwblake/lift-couchdb-test.git):
>
> object TestEnum extends Enumeration { val One = Value( "One")}
>
> object Settings extends Settings with CouchMetaRecord[ Settings]
> class Settings extends CouchRecord[ Settings] {
> def meta = Settings
> object testEnum extends JSONEnumNameField( this, TestEnum)
> }
>
> val settings = Settings.fetch( "id").open_!
> val testEnum: TestEnum.Value = settings.testEnum.valueBox.open_!
>
>
> Results in a compilation error:
>
> [ERROR] /lift-couchdb-test/src/main/scala/test/Testing.scala:24: error:
> 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 this:
>>
>> /** Enum data field for JSON records. Encodes as JString */
>> class JSONEnumNameField[OwnerType <: JSONRecord[OwnerType], EnumType <:
>> Enumeration]
>> (rec: OwnerType, enum: EnumType)(implicit
>> enumValueType: Manifest[EnumType#Value])
>> extends EnumField[OwnerType, EnumType](rec, enum) with JSONField
>> {
>> def this(rec: OwnerType, enum: EnumType, value: EnumType#Value)(implicit
>> enumValueType: Manifest[EnumType#Value]) = {
>> this(rec, enum)
>> set(value)
>> }
>>
>> def this(rec: OwnerType, enum: EnumType, value:
>> Box[EnumType#Value])(implicit enumValueType: Manifest[EnumType#Value]) = {
>> this(rec, enum)
>> setBox(value)
>> }
>>
>> def asJValue: JValue = valueBox.map(v => JString(v.toString)) openOr
>> (JNothing: JValue)
>> def fromJValue(jvalue: JValue): Box[EnumType#Value] = jvalue match {
>> case JNothing|JNull if optional_? => setBox(Empty)
>> case JString(s) => setBox(enum.valueOf(s) ?~ ("Unknown
>> value \"" + s + "\""))
>> case other=> setBox(expectedA("JString", other))
>> }
>> }
>>
>> Let me know if it works for you. If so, I'll start the process of getting it
>> into master as soon as I can.
>>
>> -Ross
>>
>> On Mar 3, 2010, at 8:12 PM, Craig Blake wrote:
>>
>>> Sure, will do. The only thing I think I'll need to figure out is how to
>>> persist an enumeration by name rather than ordinal value, but I imagine
>>> that it should be pretty straight-forward to add a new field type in my app
>>> to handle it.
>>>
>>> Thanks,
>>> Craig
>>>
>>> On Mar 3, 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 don't know why I
>>>>> didn't think to check 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) have a storage
>>>>>> type of Calendar, and you're trying to assign a Date to them. Try
>>>>>> Calendar.getInstance instead of new Date() and see if that resolves it
>>>>>> for you?
>>>>>>
>>>>
Re: [Lift] Customizing meta fields
For your particular example, you can use head merge as Naftoli suggests. Head
merge is a behavior of Lift templates where any tags will be merged
together for the final output, so you put your meta name="description" in each
of the specific places, any general head stuff you want in your surrounding
template and they will magically get folded together at render time.
For other cases, you have a couple tools at your disposal:
- RequestVars -- variables that are local to a particular page request. You
can use these inside snippets to capture and recover values during template
processing.
- Bind points. In a surrounding template you can use tags like and then define what to put there in the surrounded template
using the content
And there are more. Hopefully head merging will work for you in this case.
-Ross
On Mar 7, 2010, at 8:25 PM, Martin Dale Lyness wrote:
> Thank you Ross, for the very informative response!
>
> Now, I consider SEO to be closer to a designer task than a developer task so
> keeping the power in the design documents would be my best idea. Is there
> anyway to allow individual pages to define blocks that are read into the
> snippets and then injected into the template?
>
> Here is the scenario i'm thinking of:
> 1. A single uniform website template: default.html
> 2. Several HTML files: index.html, product_list.html, product_overview.html
> 3. Each of these HTML files containing tags referencing snippets.
>
> What i would want is for index.html, product_list.html, and
> product_overview.html to all use default.html and various Snippet classes.
> Now for SEO i would want the meta tags in the header of default.html to be
> customized to index.html, product_list.html, and product_overview.html;
> furthermore, product_list and product_overview are dynamic pages so they
> would need further customization based on what the snippets are returning.
>
> Essentially, i would want tags something like:
> This site is totally awesome, better than all our
> competitors in index.html
> Look at all these products in
> %%category_name%%in product_list.html
> %product_name% - %product_description%
> in product_overview.html
>
> The conceptual road block for me is coming from the controller first pattern
> used in frameworks like Rails. In lift snippets are not really the same
> conceptually. If i use the second proposed method (i.e.
> wrapping the entire template) i would have a battle
> between snippets used by each page. For example, perhaps i have a product
> overview snippet that sets the meta one way and a login snippet that sets it
> another way (intended for when show standalone in a login.html).
>
> The first solution with using a to inject a
> snippet at a meta location fits better because it would allow me to create a
> generic function that would attempt to create the keyword and description
> data based on whatever global information is made available to snippets by
> lift (i.e. Request Parameters?). My only problem with using this option is it
> puts all of the text on the developer 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 wrote:
> To be parsed by the bind, it must be enclosed by
> ...
>
> 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, in the above example) and then
> look for a method on that snippet class mentioned after the period (hello in
> the example). If there is no period, the method is assumed to be called
> "render".
>
> Once that method is found, the method is called with the contents of the
> lift: tag, and the result of the method call is spliced into the XML to
> replace the lift: tag.
>
> bind is a function that does something kind of similar to overall template
> processing, except you supply some prefix other than lift: (b: in the
> example) and a limited set of things after the colon that are valid (time and
> meta_desc in the example)
>
> So, you might want something like this instead:
>
>
>
> class HelloWorld {
>
>def meta_desc(ns: NodeSeq): NodeSeq = Text("test desc")
>
> }
>
> Which will result in this XHTML:
>
> test desc
>
> Or, if you want to keep it in the hello method, you'd then have to move the
> to the outside of the template:
>
>
&g
Re: [Lift] Re: BSON support in lift-json
I personally think hybrid approaches make sense for certain designs even if they are a little odd. My thought originally was having a new member of the ADT which is not final which represents "extensions", e.g. JValue \_ JExtension \_ JDate where JExtensions could be ignored or passed through unchanged by most of the stuff, and only special readers/writers would know what to do with them. -Ross On Mar 8, 2010, at 12:45 PM, David Pollak wrote: > > > On Mon, Mar 8, 2010 at 12:50 AM, Joni Freeman wrote: > This is a tricky one. The problem with extending the AST is that the > AST is implemented as an algebraic data type. And by definition it is > not possible to extend such a type. > > Just throwing an idea out and it's likely a bad one. > > I ran into a similar issue with Box and chose to do a hybrid (aka > Frankenstein) ADT/OO paradigm. > > Perhaps it's possible to provide subclasses of certain ADT items (e.g., JDate > extends JInt) such that if you pattern match on a JInt, you get the millis as > long, but if you pattern match against JDate, you get a date extracted if > it's the JDate subclass. > > Once again, it's likely to be a bad idea as it caused a lot of angst in Box > and I'm not sure if the paradigm is one that's worth perpetuating. > > > One way to add BSON support is to create a new AST for it which > includes all extended literals. Then add a few core functions for that > ADT (map, etc.) and maybe a function which can encode BSON as JSON > (bvalue.toJson). Encoding BSON as JSON would give some features for > free, for instance toXml. Anyway, this approach would probably cause > some code duplication between lift-json and lift-bson. > > Converting the JSON AST to an object oriented design would be another > approach. Then adding new AST nodes would not be a problem. But that > would be a huge change to the lib. Probably too big at this phase. > > Since BSON is a superset of JSON we could refactor current lift-json > to be lift-bson and then implement lift-json on top of it. On a > cursory look this feels cleanest but there might 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 wrote: > > 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 > > most familiar. > > > > -Ross > > > > On Mar 5, 2010, at 1:26 PM, Tim Nelson wrote: > > > > > I definitely agree with keeping the BSON code separate or possibly > > > having a strict JSON mode. > > > > > Tim > > > > > On Fri, Mar 5, 2010 at 12:13 PM, Timothy Perrett > > > wrote: > > >> Probably a sub-ordinate module would be preferable... one that builds > > >> on the lift-json stuff and doesn't pollute the "normal" JSON usage. > > > > >> Joni, what are your thoughts? > > > > >> Cheers, Tim > > > > >> On 5 Mar 2010, at 17:59, Tim Nelson wrote: > > > > >>> I finally had the opportunity to look into the couchdb code and I must > > >>> say it is rather impressive. > > > > >>> I would like to utilize the code in JSONRecord.scala in scamongo [1]. > > >>> However, MongoDB uses a variation of JSON they call BSON, which they > > >>> actually just published a spec [2] for, due to interest outside of > > >>> MongoDB. Basically, it adds support for date, ObjectId [3], binary > > >>> data, regular expressions, and code (JavaScript) data types. > > > > >>> My question is, what would it take to add support to lift-json for > > >>> these other data types? Is this even feasible? > > > > >>> Thanks, > > >>> Tim > > > > >>> [1]http://github.com/eltimn/scamongo > > >>> [2]http://bsonspec.org/ > > >>> [3]http://www.mongodb.org/display/DOCS/Object+IDs > > > > >>> -- > > >>> You received this message because you are subscribed to the Google > > >>> Groups "Lift" group. > > >>> To post to this group, send email to lift...@googlegroups.com. > > >>> To unsubscribe from this group, send email to > > >>>
Re: [Lift] Customizing meta fields
To be parsed by the bind, it must be enclosed by
...
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, in the above example) and then look for
a method on that snippet class mentioned after the period (hello in the
example). If there is no period, the method is assumed to be called "render".
Once that method is found, the method is called with the contents of the lift:
tag, and the result of the method call is spliced into the XML to replace the
lift: tag.
bind is a function that does something kind of similar to overall template
processing, except you supply some prefix other than lift: (b: in the example)
and a limited set of things after the colon that are valid (time and meta_desc
in the example)
So, you might want something like this instead:
class HelloWorld {
def meta_desc(ns: NodeSeq): NodeSeq = Text("test desc")
}
Which will result in this XHTML:
test desc
Or, if you want to keep it in the hello method, you'd then have to move the
to the outside of the template:
...
...
Hope that helps,
-Ross
On Mar 7, 2010, at 4:38 AM, Martin wrote:
> How would one go about having dynamic description and keyword meta
> tags in a template? Here is what i've tried:
>
> default.html
>
>
> HelloWorld.scala
> Helpers.bind("b", in, "time" -> date.map(d => Text(d.toString)),
> "meta_desc" -> "test desc")
>
> I'm using a basic archetype build of 2.0-M3 and it produces an error:
>
> This page contains the following errors:
>
> error on line 6 at column 28: Namespace prefix b on meta_desc is not
> defined
> Below is a rendering of the page up to the first error.
>
>
> It appears to me that the template is not parsed by the Helpers.bind,
> is this correct?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] BSON support in lift-json
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 most familiar. -Ross On Mar 5, 2010, at 1:26 PM, Tim Nelson wrote: > I definitely agree with keeping the BSON code separate or possibly > having a strict JSON mode. > > Tim > > On Fri, Mar 5, 2010 at 12:13 PM, Timothy Perrett > wrote: >> Probably a sub-ordinate module would be preferable... one that builds on >> the lift-json stuff and doesn't pollute the "normal" JSON usage. >> >> Joni, what are your thoughts? >> >> Cheers, Tim >> >> On 5 Mar 2010, at 17:59, Tim Nelson wrote: >> >>> I finally had the opportunity to look into the couchdb code and I must >>> say it is rather impressive. >>> >>> I would like to utilize the code in JSONRecord.scala in scamongo [1]. >>> However, MongoDB uses a variation of JSON they call BSON, which they >>> actually just published a spec [2] for, due to interest outside of >>> MongoDB. Basically, it adds support for date, ObjectId [3], binary >>> data, regular expressions, and code (JavaScript) data types. >>> >>> My question is, what would it take to add support to lift-json for >>> these other data types? Is this even feasible? >>> >>> Thanks, >>> Tim >>> >>> >>> [1] http://github.com/eltimn/scamongo >>> [2] http://bsonspec.org/ >>> [3] http://www.mongodb.org/display/DOCS/Object+IDs >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> liftweb+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://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 lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://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 lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Lift security vulnerability
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? > > - > Dano wrote: > > Just saw that Lift 2.0-M3 was released. I looked to see if the > vulnerability was still present in demo.liftweb.net and I am still > able to generate exceptions in the browser when I paste binary > characters in the textfields for the Wizard, Wizard Challenge, and Arc > Challenge examples in the Misc section. > > Don't know if this remaining problem is supposed to be handled by the > application or framework, but thought I would make a post to alert the > group. > > > Dan > > On Feb 24, 11:49 am, Dano wrote: >> The recent scala days conference activity may have cause the updates >> to this thread to escape notice. Just wondering if there is concern >> about the remaining binary character problems I noted in my prior >> post. >> >> Thanks in advance. >> >> Dan >> >> On Feb 22, 1:34 pm, Dano wrote: >> >>> More information on this in case anyone is interested. If you go to >>> theliftdemo website, it appears the issue with characters is mostly >>> addressed except for the "Misc code" section. Specifically, the >>> "Wizard", "Wizard Challenge" and "Arc Challenge #1" examples will >>> generate XML parsing errors. >> >>> For these problems, I am not sure if the issue if the example or the >>> framework. If the issue is with the example, it would be good to know >>> whatLiftapps need to do to avoid getting bitten by binary characters >>> entered into form fields. >> >>> Thanks in advance. >> >>> Dan >> >>> On Feb 17, 11:06 am, Dano wrote: >> Hello, >> I was wondering if the fix for the control characters issue was included in 2.0-M2. I just did a test with ourLiftapplication built with 2.0-M2 and I am still seeing problems (i.e. javascript exceptions - NS_ERROR_INVALID_POINTER). >> Thanks in advance. >> Dan >> On Feb 3, 9:08 am, David Pollak wrote: >> > Thanks for pointing that out. There are other problems as well... I'll > fix > them (in both the Scala andLiftdiffs) >> > On Wed, Feb 3, 2010 at 7:39 AM, Feng Zhang wrote: >> I found that in the fix, \n is changed to \t, while \t to \n. Is this >> desired behavior? >> >> Thank you, >> >> Feng >> >> On Wed, Feb 3, 2010 at 9:20 AM, Indrajit Raychaudhuri >> >> wrote: >> >>> 1. Fix in head/master (2.0-SNAPSHOT) and prepone 2.0-M2. >> >>> 2. Backport in 1.0.x branch and spin 1.0.4. We haven't marked 1.0.x >>> 'unsupported' yet. Forcing apps to move to 2.0-M2 just for this >>> vulnerability fix isn't fun. >> >>> Cheers, Indrajit >> >>> On 03/02/10 3:34 PM, Timothy Perrett wrote: >> +1 >> Fix it in head, no need to back-port; M2 is only around the corner. >> Cheers, Tim >> On 3 Feb 2010, at 09:49, Jeppe Nejsum Madsen wrote: >> David Pollak writes: >> > I'd like to get a sense of how important the community views this >> defect. >> Is it a "backport the fix to every milestone and release yesterday" >> or >> is it >> a "fix it in 2.0-M2" or someplace in between. >> > For me, it's fix it in 2.0-SNAPSHOT >> > /Jeppe >> > -- > You received this message because you are subscribed to the Google > Groups "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > > . > For more options, visit this group at > http://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 lift...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> liftweb+unsubscr...@googlegroups.com>> > >>> . >>> For more options, visit this group at >>> http://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 lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@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 > Follow me:http://twitter.com/dpp > Surf the harmonics > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe f
[Lift] **BREAKING CHANGES** in lift-record
As I mentioned before, I was planning to make some breaking changes to lift-record, and since I got no additional feedback, I've now pushed to master. These changes make some cleanups to method naming and functionality in lift-record, and all code using 2.0-SNAPSHOT will need some changes: - Each MetaRecord implementation must define createRecord. To migrate, add this method to your MetaRecord: def createRecord: MyRecord = new MyRecord - If you previously used Record#fromJSON, you will need to use Record#setFieldsFromJSON instead. - If you previously used MetaRecord#createRecord(json: String), you will need to use MetaRecord#fromJSON instead. - If you previously used MetaRecord#fromJSON(inst, json), you will need to use MetaRecord#setFieldsFromJSON instead. In addition, lift-couchdb has been updated to track these changes: - If you previously used JSONRecord#fromJValue, you will need to use JSONRecord#setFieldsFromJValue instead. - If you previously used JSONMetaRecord#fromJValue(rec, jvalue), you will need to use JSONMetaRecord#setFieldsFromJValue instead. - CouchMetaRecord#create and CouchMetaRecord#createFromJValue have been removed. Use MetaRecord#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 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 that if you used "new MyRecord" then you'd get a > record that was basically functional but some of the extended metadata > (notably field.name) would not be initialized correctly. This is because the > correct way to create a record was MyRecordMeta.createRecord. > > I fixed it so that new MyRecord is equivalent to MyRecordMeta.createRecord, > but Marius pointed out there was more cleaning to do. > > Here are the changes: > - I made the createRecord method on MetaRecord abstract, so that MyRecordMeta > must now implement it. If you are porting over old code, then just do: > def createRecord = new MyRecord > This change is so that record creation must be explicitly specified in case > it is different from new MyRecord (the default implementation) > > - MetaRecord.fromJSON(inst, json) has been renamed to setFieldsFromJSON(inst, > json) > - a new method MetaRecord.setFieldsFromReq(inst, req) has been created to > parallel the new name of fromJSON > - MetaRecord.createRecord(json) has been renamed to fromJSON(json) > - Record.fromJSON has been renamed to setFieldsFromJSON > - Record.setFieldsFromReq has been added -- they just call the meta methods > of the same name. > > These changes at the end make it so that fromSomething(something) are > consistently factory methods that create records from some source (JSON or > Req), and that setFieldsFromSomething(inst, something) is consistently there > for setting the fields from the source. > > Let me know what you think. > > -Ross > > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: SQL error
Sounds proper to me.
-Ross
On Mar 4, 2010, at 4:22 PM, Mads Hartmann Jensen wrote:
> Ah yeah I see, it would be looking for a column named blob_c then, right?
>
> So what do you say - I send out a **Potential breaking change** message that
> states that if 'blob' is not a keyword in your DB 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, 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 Jensen
>>> wrote:
>>> This has already been on reviewboard and comitted to master - should i send
>>> out a breaking change note?
>>>
>>> I'm not sure i get why this is a breaking change though?
>>>
>>>
>>> Not sure if it is. However it's certainly something folks will want to
>>> upgrade to asap.
>>>
>>> Naming columns keywords in SQL is bad.
>>>
>>>
>>>
>>> On 04/03/2010, at 22.07, Jim Barrows wrote:
>>>
>>>> On Thu, Mar 4, 2010 at 1:47 PM, Naftoli Gugenheim
>>>> wrote:
>>>> Is blob a standard reserved word or only on MySQL?
>>>> If the latter this is a potential breaking change.
>>>>
>>>> Blob is not apparently part of the ANSI standard reserved word for SQL. I
>>>> would have sworn it was. However, it is common in Oracle, MS SQL server
>>>> and others. Might as well be standard.
>>>>
>>>>
>>>>
>>>> -
>>>> Mads Hartmann wrote:
>>>>
>>>> Ah! That fixed it, thanks a lot Jeppe ;)
>>>>
>>>> I'm not sure what to say in the ticket though, the column-name blob
>>>> was a bad choise made by me.
>>>>
>>>> On Mar 4, 1:32 pm, Jeppe Nejsum Madsen wrote:
>>>> > On Thu, Mar 4, 2010 at 1:25 PM, Mads Hartmann wrote:
>>>> > > Hello everyone,
>>>> > > I'm not sure if this is a lift problem or it's me. I'm trying to add
>>>> > > the ability to upload images to a project - I'm using the code
>>>> > > explained here:
>>>> > >http://groups.google.com/group/liftweb/browse_thread/thread/b0509263e...
>>>> >
>>>> > > I added two mapper classes:
>>>> > > ---
>>>> > > class ImageInfo extends LongKeyedMapper[ImageInfo] with IdPK {
>>>> > > def getSingleton = ImageInfo
>>>> >
>>>> > > object date extends MappedLong(this) {
>>>> > >override def defaultValue = Helpers.millis
>>>> > > }
>>>> > > object mimeType extends MappedPoliteString(this, 64)
>>>> > > object name extends MappedPoliteString(this, 256) {
>>>> > >override def dbIndexed_? = true
>>>> > >override def defaultValue = ""
>>>> >
>>>> > >private def noSlashes(s: String) : List[FieldError] =
>>>> > > if (s.contains("/"))
>>>> > >List(FieldError(this, Text("Image name
>>>> > > \"" + s + "\" may not
>>>> > > contain \"/\"")))
>>>> > > else
>>>> > >Nil
>>>> >
>>>> > >override def validations =
>>>> > > valMinLen(1, "Image name must not be empty") _ ::
>>>> > > valUnique("Image name must be unique") _ ::
>>>> > > noSlashes _ ::
>>>> > > super.validations
>>>> > > }
>>>> >
>>>> > > object blob extends MappedLongForeignKey(this, ImageBlob)
>>>> >
>>>> > > def deleteWithBlob {
>>>> > >this.blob.obj match {
>>>> > > case Full(x) => x.delete_!
>>>> > > case _ =>
>>>> > >}
>>>> > >this.delete_!
>>>> > > }
>>>> > > }
>>>
Re: [Lift] Re: SQL error
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 Jensen
> wrote:
> This has already been on reviewboard and comitted to master - should i send
> out a breaking change note?
>
> I'm not sure i get why this is a breaking change though?
>
>
> Not sure if it is. However it's certainly something folks will want to
> upgrade to asap.
>
> Naming columns keywords in SQL is bad.
>
>
>
> On 04/03/2010, at 22.07, Jim Barrows wrote:
>
>> On Thu, Mar 4, 2010 at 1:47 PM, Naftoli Gugenheim
>> wrote:
>> Is blob a standard reserved word or only on MySQL?
>> If the latter this is a potential breaking change.
>>
>> Blob is not apparently part of the ANSI standard reserved word for SQL. I
>> would have sworn it was. However, it is common in Oracle, MS SQL server
>> and others. Might as well be standard.
>>
>>
>>
>> -
>> Mads Hartmann wrote:
>>
>> Ah! That fixed it, thanks a lot Jeppe ;)
>>
>> I'm not sure what to say in the ticket though, the column-name blob
>> was a bad choise made by me.
>>
>> On Mar 4, 1:32 pm, Jeppe Nejsum Madsen wrote:
>> > On Thu, Mar 4, 2010 at 1:25 PM, Mads Hartmann wrote:
>> > > Hello everyone,
>> > > I'm not sure if this is a lift problem or it's me. I'm trying to add
>> > > the ability to upload images to a project - I'm using the code
>> > > explained here:
>> > >http://groups.google.com/group/liftweb/browse_thread/thread/b0509263e...
>> >
>> > > I added two mapper classes:
>> > > ---
>> > > class ImageInfo extends LongKeyedMapper[ImageInfo] with IdPK {
>> > > def getSingleton = ImageInfo
>> >
>> > > object date extends MappedLong(this) {
>> > >override def defaultValue = Helpers.millis
>> > > }
>> > > object mimeType extends MappedPoliteString(this, 64)
>> > > object name extends MappedPoliteString(this, 256) {
>> > >override def dbIndexed_? = true
>> > >override def defaultValue = ""
>> >
>> > >private def noSlashes(s: String) : List[FieldError] =
>> > > if (s.contains("/"))
>> > >List(FieldError(this, Text("Image name
>> > > \"" + s + "\" may not
>> > > contain \"/\"")))
>> > > else
>> > >Nil
>> >
>> > >override def validations =
>> > > valMinLen(1, "Image name must not be empty") _ ::
>> > > valUnique("Image name must be unique") _ ::
>> > > noSlashes _ ::
>> > > super.validations
>> > > }
>> >
>> > > object blob extends MappedLongForeignKey(this, ImageBlob)
>> >
>> > > def deleteWithBlob {
>> > >this.blob.obj match {
>> > > case Full(x) => x.delete_!
>> > > case _ =>
>> > >}
>> > >this.delete_!
>> > > }
>> > > }
>> > > -
>> > > and
>> > > --
>> > > class ImageBlob extends LongKeyedMapper[ImageBlob] with IdPK {
>> > > def getSingleton = ImageBlob
>> >
>> > > object image extends MappedBinary(this)
>> > > }
>> > > -
>> >
>> > > The schemifier couldn't create the tables it gave to following
>> > > error ::
>> > > You have an error in your SQL syntax; check the manual that
>> > > corresponds to your MySQL server version for the right syntax to use
>> > > near 'blob BIGINT UNSIGNED) ENGINE = InnoDB' at line 1
>> >
>> > > this is the sql statement it tried to execute
>> >
>> > > CREATE TABLE imageinfo (name VARCHAR(256) , id BIGINT UNSIGNED NOT
>> > > NULL AUTO_INCREMENT UNIQUE KEY , date_c BIGINT , mimetype
>> > > VARCHAR(64) , blob BIGINT UNSIGNED) ENGINE = InnoDB
>> >
>> > I looks like it tries to create a column named blob, afaiks blob is a
>> > reserved word in
>> > MySqlhttp://dev.mysql.com/doc/refman/5.0/en/reserved-words.html
>> >
>> > You could try renaming the field. If this solves the problem, please
>> > file a ticket
>> >
>> > /Jeppe
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://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 lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>>
>>
>>
>> --
>> James A Barrows
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> lif
Re: [Lift] Trouble with lift-couchdb
Okay, type erasure ate your lunch. I have a patched version locally that
apparently works -- your code on my machine gets to "invalid username or
password" accessing Couch, which indicates it got past the previous problem.
I'd love it if you could apply this patch to your local trunk and give it a
quick spin. If it works out for you, I'll get it into master, along with that
new enum field.
-Ross
diff --git
a/framework/lift-persistence/lift-couchdb/src/main/scala/net/liftweb/couchdb/JSONRecord.scala
b/framework/lift-persistence/lift-couchdb/src/main/scala/net/liftweb/couchdb/JSONRecord.scala
index 1d9950b..c65c2fc 100644
---
a/framework/lift-persistence/lift-couchdb/src/main/scala/net/liftweb/couchdb/JSONRecord.scala
+++
b/framework/lift-persistence/lift-couchdb/src/main/scala/net/liftweb/couchdb/JSONRecord.scala
@@ -20,7 +20,7 @@ import _root_.scala.collection.immutable.TreeSet
import _root_.scala.reflect.Manifest
import _root_.scala.xml.NodeSeq
import _root_.net.liftweb.common.{Box, Empty, Failure, Full}
-import Box.box2Iterable
+import Box.{box2Iterable, option2Box}
import _root_.net.liftweb.http.js.{JsExp, JsObj}
import _root_.net.liftweb.json.JsonParser
import _root_.net.liftweb.json.JsonAST.{JArray, JBool, JInt, JDouble, JField,
JNothing, JNull, JObject, JString, JValue}
@@ -307,9 +307,7 @@ class JSONSubRecordArrayField[OwnerType <:
JSONRecord[OwnerType], SubRecordType
/** Specialization of JSONField for field types that use some kind of encoded
string as the JSON type (e.g. binary data, datetimes) */
-private[couchdb] trait JSONEncodedStringFieldMixin extends JSONField {
- self: Field[_, _] =>
-
+private[couchdb] trait JSONEncodedStringFieldMixin[StorageType, OwnerType <:
Record[OwnerType]] extends JSONField with Field[StorageType, OwnerType] {
/** Encode the current value of the field as a JValue */
def encode(value: MyType): String
@@ -340,7 +338,7 @@ private[couchdb] trait JSONStringFieldMixin extends
JSONField {
/** Binary data field for JSON records. Encodes as JString containing base64
conversion of binary data. */
class JSONBinaryField[OwnerType <: JSONRecord[OwnerType]](rec: OwnerType)
- extends BinaryField[OwnerType](rec) with JSONEncodedStringFieldMixin
+ extends BinaryField[OwnerType](rec) with
JSONEncodedStringFieldMixin[Array[Byte], OwnerType]
{
def this(rec: OwnerType, value: Array[Byte]) = { this(rec); set(value) }
def this(rec: OwnerType, value: Box[Array[Byte]]) = { this(rec);
setBox(value) }
@@ -381,7 +379,7 @@ class JSONCountryField[OwnerType <:
JSONRecord[OwnerType]](rec: OwnerType)
/** Date/time data field for JSON records. Encodes as JString containing the
internet formatted datetime */
class JSONDateTimeField[OwnerType <: JSONRecord[OwnerType]](rec: OwnerType)
- extends DateTimeField[OwnerType](rec) with JSONEncodedStringFieldMixin
+ extends DateTimeField[OwnerType](rec) with
JSONEncodedStringFieldMixin[Calendar, OwnerType]
{
def this(rec: OwnerType, value: Calendar) = { this(rec); set(value) }
def this(rec: OwnerType, value: Box[Calendar]) = { this(rec); setBox(value) }
@@ -396,7 +394,7 @@ class JSONDateTimeField[OwnerType <:
JSONRecord[OwnerType]](rec: OwnerType)
/** Decimal data field for JSON records. Encodes as a JString, to preserve
decimal points (JDouble being lossy) */
class JSONDecimalField[OwnerType <: JSONRecord[OwnerType]](rec: OwnerType,
context: MathContext, scale: Int)
- extends DecimalField[OwnerType](rec, context, scale) with
JSONEncodedStringFieldMixin
+ extends DecimalField[OwnerType](rec, context, scale) with
JSONEncodedStringFieldMixin[BigDecimal, OwnerType]
{
def this(rec: OwnerType, value: BigDecimal) = { this(rec,
MathContext.UNLIMITED, value.scale); set(value) }
def this(rec: OwnerType, value: Box[BigDecimal], scale: Int) = { this(rec,
MathContext.UNLIMITED, scale); 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 have to run right now, but I'll look at in ~2-4 hours and hopefully figure
>> it out for you.
>>
>> -Ross
>>
>> On Mar 4, 2010, at 1:28 PM, Craig Blake wrote:
>>
>>> To test further, I've created a simple test project with only one
>>> dependency, lift-couchdb, and this code:
>>>
>>> object Settings extends Settings with CouchMetaRecord[ Settings]
>>> class Settings extends CouchRecord[ Settings] {
>>> def meta = Settings
>>> object updated extends JSONDateTimeField( this)
>>> }
>>>
>>> object Testing {
>>>
>>>
Re: [Lift] Trouble with lift-couchdb
I can reproduce this locally, and offhand looks like a scala compiler bug (this
should never have compiled).
I have to run right now, but I'll look at in ~2-4 hours and hopefully figure it
out for you.
-Ross
On Mar 4, 2010, at 1:28 PM, Craig Blake wrote:
> To test further, I've created a simple test project with only one dependency,
> lift-couchdb, and this code:
>
> object Settings extends Settings with CouchMetaRecord[ Settings]
> class Settings extends CouchRecord[ Settings] {
> def meta = Settings
> object updated extends JSONDateTimeField( this)
> }
>
> object Testing {
>
> def main( args: Array[ String]) {
> import CouchDB.defaultDatabase
> defaultDatabase = new Database( :/( "localhost", 5984) as_! (
> "username", "password"), "database")
>
> val settings = Settings.createRecord
> settings.updated( Calendar.getInstance( TimeZone.getTimeZone(
> "UTC")))
> settings.save
> }
> }
>
> I get the same error:
>
> java.lang.AbstractMethodError:
> test.Settings$updated$.encode(Ljava/lang/Object;)Ljava/lang/String;
>
> I've also put the test code in Github in case anyone might be able to
> reproduce it locally:
>
> g...@github.com:craigwblake/lift-couchdb-test.git
>
>
> Thanks,
> Craig
>
>
> On Mar 3, 2010, at 9:54 PM, Naftoli Gugenheim wrote:
>
>> AbstractMethodError means you need to do a clean build and make sure you
>> don't have multiple scala versions.
>>
>> -
>> Craig Blake wrote:
>>
>> Just took a minor change to compile (didn't like ?~) and I'll let you know
>> how it goes soon. I'm running into one more problem, this time a runtime
>> exception saving a document:
>>
>> java.lang.AbstractMethodError:
>> test.Settings$updated$.encode(Ljava/lang/Object;)Ljava/lang/String;
>> at
>> net.liftweb.couchdb.JSONEncodedStringFieldMixin$$anonfun$asJValue$6.apply(JSONRecord.scala:319)
>> at
>> net.liftweb.couchdb.JSONEncodedStringFieldMixin$$anonfun$asJValue$6.apply(JSONRecord.scala:319)
>> at net.liftweb.common.Full.map(Box.scala:330)
>> 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 <: JSONRecord[OwnerType], EnumType <:
>>> Enumeration]
>>> (rec: OwnerType, enum: EnumType)(implicit
>>> enumValueType: Manifest[EnumType#Value])
>>> extends EnumField[OwnerType, EnumType](rec, enum) with JSONField
>>> {
>>> def this(rec: OwnerType, enum: EnumType, value: EnumType#Value)(implicit
>>> enumValueType: Manifest[EnumType#Value]) = {
>>>this(rec, enum)
>>>set(value)
>>> }
>>>
>>> def this(rec: OwnerType, enum: EnumType, value:
>>> Box[EnumType#Value])(implicit enumValueType: Manifest[EnumType#Value]) = {
>>>this(rec, enum)
>>>setBox(value)
>>> }
>>>
>>> def asJValue: JValue = valueBox.map(v => JString(v.toString)) openOr
>>> (JNothing: JValue)
>>> def fromJValue(jvalue: JValue): Box[EnumType#Value] = jvalue match {
>>> case JNothing|JNull if optional_? => setBox(Empty)
>>> case JString(s) => setBox(enum.valueOf(s) ?~ ("Unknown
>>> value \"" + s + "\""))
>>> case other=> setBox(expectedA("JString", other))
>>> }
>>> }
>>>
>>> Let me know if it works for you. If so, I'll start the process of getting
>>> it into master as soon as I can.
>>>
>>> -Ross
>>>
>>> On Mar 3, 2010, at 8:12 PM, Craig Blake wrote:
>>>
>>>> Sure, will do. The only thing I think I'll need to figure out is how to
>>>> persist an enumeration by name rather than ordinal value, but I imagine
>>>> that it should be pretty straight-forward to add a new field type in my
>>>> app to handle it.
>>>>
>>>> Thanks,
>>>> Craig
>>>>
>>>> On Mar 3, 2010, at 7:45 PM, Ross Mellgren wrote:
>>
Re: [Lift] Response Optimizations too aggressive
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 "production mode" > that is effectively breaking my application's compatibility for IE... > > To get around IE6 deficiencies, I am leveraging JQuery. For example, > if I have a CSS style that uses attribute selectors, like > input[type=checkbox], IE6 ignores them, but I can get JQuery to apply > the style. > > Since this JavaScript applies to IE only, I wrap them in comments > like: > > > > Firefox and Chrome will ignore these, which is perfect, and only IE > will pay attention (and suffer the overhead). > > All was working fine in dev, then came time to roll out to production > and I naturally specified -Drun.mode=production. Surprisingly, > "production mode" has an "optimization" that strips HTML comments from > the output. Generally, I think this is a great idea -- EXCEPT if we > have IE specific comments responding to an IE browser. > > Is there a way to modify the optimization so that IE specific comments > are retained? Alternatively, can I simply disable this optimization > feature so that my IE users are OK? > > How can I find out more about these "production mode optimizations"? > Is there a list? > > I have drilled into Props.scala and I read it very carefully. I think > of my environments as Dev/QA/Prod, but I think this translates best to > Test/Staging/Production in Lift-speak. I am expecting that > "production mode optimizations" are applied to both Staging (aka QA) > as well as Production -- because I need to validate actual production > behavior. > > Note that I am running 2.0-M2. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Trouble with lift-couchdb
Try this:
/** Enum data field for JSON records. Encodes as JString */
class JSONEnumNameField[OwnerType <: JSONRecord[OwnerType], EnumType <:
Enumeration]
(rec: OwnerType, enum: EnumType)(implicit enumValueType:
Manifest[EnumType#Value])
extends EnumField[OwnerType, EnumType](rec, enum) with JSONField
{
def this(rec: OwnerType, enum: EnumType, value: EnumType#Value)(implicit
enumValueType: Manifest[EnumType#Value]) = {
this(rec, enum)
set(value)
}
def this(rec: OwnerType, enum: EnumType, value: Box[EnumType#Value])(implicit
enumValueType: Manifest[EnumType#Value]) = {
this(rec, enum)
setBox(value)
}
def asJValue: JValue = valueBox.map(v => JString(v.toString)) openOr
(JNothing: JValue)
def fromJValue(jvalue: JValue): Box[EnumType#Value] = jvalue match {
case JNothing|JNull if optional_? => setBox(Empty)
case JString(s) => setBox(enum.valueOf(s) ?~ ("Unknown
value \"" + s + "\""))
case other=> setBox(expectedA("JString", other))
}
}
Let me know if it works for you. If so, I'll start the process of getting it
into master as soon as I can.
-Ross
On Mar 3, 2010, at 8:12 PM, Craig Blake wrote:
> Sure, will do. The only thing I think I'll need to figure out is how to
> persist an enumeration by name rather than ordinal value, but I imagine that
> it should be pretty straight-forward to add a new field type in my app to
> handle it.
>
> Thanks,
> Craig
>
> On Mar 3, 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 don't know why I
>>> didn't think to check 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) have a storage type
>>>> of Calendar, and you're trying to assign a Date to them. Try
>>>> Calendar.getInstance instead of new Date() and see if that resolves it for
>>>> you?
>>>>
>>>> -Ross
>>>>
>>>> On Mar 3, 2010, at 4:32 PM, Craig Blake wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am getting familiar with the lift-couchdb module, and trying to put
>>>>> together a sample based on the tests in the module. Trying to create a
>>>>> record, based on this test code:
>>>>>
>>>>> def testRec1: Person = Person.createRecord.name("Alice").age(25)
>>>>>
>>>>> this is what I have:
>>>>>
>>>>> class Account extends CouchRecord[Account] {
>>>>> def meta = Account
>>>>> object created extends JSONDateTimeField(this)
>>>>> }
>>>>> object Account extends Account with CouchMetaRecord[Account]
>>>>>
>>>>> ...
>>>>>
>>>>> val account = Account.createRecord.created(new Date())
>>>>>
>>>>>
>>>>> I get a compilation error:
>>>>>
>>>>> [WARNING] Test.scala:44: error: overloaded method value apply with
>>>>> alternatives ((net.liftweb.common.Box[_12.MyType])test.Account) forSome {
>>>>> val _12: object test.Account#created } ((_13.MyType)test.Account)
>>>>> forSome { val _13: object test.Account#created } cannot be applied to
>>>>> (java.util.Date)
>>>>> [WARNING] val account = Account.createRecord.created( new
>>>>> Date())
>>>>>
>>>>>
>>>>> I'm sure that I am just missing something obvious. Any ideas what?
>>>>>
>>>>> Thanks,
>>>>> Craig
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google Groups
>>>>> "Lift" group.
>>>>> To post to this group, send email to lift...@googlegroups.com.
>>>>> To unsubscribe from this group, send email to
>&
Re: [Lift] Trouble with lift-couchdb
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 don't know why I didn't
> think to check 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) have a storage type of
>> Calendar, and you're trying to assign a Date to them. Try
>> Calendar.getInstance instead of new Date() and see if that resolves it for
>> you?
>>
>> -Ross
>>
>> On Mar 3, 2010, at 4:32 PM, Craig Blake wrote:
>>
>>> Hi,
>>>
>>> I am getting familiar with the lift-couchdb module, and trying to put
>>> together a sample based on the tests in the module. Trying to create a
>>> record, based on this test code:
>>>
>>> def testRec1: Person = Person.createRecord.name("Alice").age(25)
>>>
>>> this is what I have:
>>>
>>> class Account extends CouchRecord[Account] {
>>> def meta = Account
>>> object created extends JSONDateTimeField(this)
>>> }
>>> object Account extends Account with CouchMetaRecord[Account]
>>>
>>> ...
>>>
>>> val account = Account.createRecord.created(new Date())
>>>
>>>
>>> I get a compilation error:
>>>
>>> [WARNING] Test.scala:44: error: overloaded method value apply with
>>> alternatives ((net.liftweb.common.Box[_12.MyType])test.Account) forSome {
>>> val _12: object test.Account#created } ((_13.MyType)test.Account)
>>> forSome { val _13: object test.Account#created } cannot be applied to
>>> (java.util.Date)
>>> [WARNING] val account = Account.createRecord.created( new Date())
>>>
>>>
>>> I'm sure that I am just missing something obvious. Any ideas what?
>>>
>>> Thanks,
>>> Craig
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Lift" group.
>>> To post to this group, send email to lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> liftweb+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://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 lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://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 lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Trouble with lift-couchdb
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 Calendar.getInstance
instead of new Date() and see if that resolves it for you?
-Ross
On Mar 3, 2010, at 4:32 PM, Craig Blake wrote:
> Hi,
>
> I am getting familiar with the lift-couchdb module, and trying to put
> together a sample based on the tests in the module. Trying to create a
> record, based on this test code:
>
> def testRec1: Person = Person.createRecord.name("Alice").age(25)
>
> this is what I have:
>
> class Account extends CouchRecord[Account] {
> def meta = Account
> object created extends JSONDateTimeField(this)
> }
> object Account extends Account with CouchMetaRecord[Account]
>
> ...
>
> val account = Account.createRecord.created(new Date())
>
>
> I get a compilation error:
>
> [WARNING] Test.scala:44: error: overloaded method value apply with
> alternatives ((net.liftweb.common.Box[_12.MyType])test.Account) forSome { val
> _12: object test.Account#created } ((_13.MyType)test.Account) forSome {
> val _13: object test.Account#created } cannot be applied to (java.util.Date)
> [WARNING] val account = Account.createRecord.created( new Date())
>
>
> I'm sure that I am just missing something obvious. Any ideas what?
>
> Thanks,
> Craig
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Snippets in subpackages?
Haha okay okay I'll write it, but you have to review it ;-)
-Ross
On Mar 3, 2010, at 12:37 PM, David Pollak wrote:
>
>
> On Wed, Mar 3, 2010 at 9:30 AM, Heiko Seeberger
> wrote:
> Yep, that would help a lot!
>
>
> Cool. Please open a ticket and assign it to Ross... if he wants, he can
> assign it to me or you. ;-)
>
> Heiko
>
> On Wednesday, March 3, 2010, David Pollak
> wrote:
> >
> >
> > On Tue, Mar 2, 2010 at 11:42 PM, Heiko Seeberger
> > wrote:
> >
> > On 3 March 2010 00:03, David Pollak wrote:
> >
> >
> >
> >
> > On Tue, Mar 2, 2010 at 1:05 PM, Heiko Seeberger
> > wrote:
> >
> > Hi,
> > Isn't it possible to put snippets in subpackages of xxx.snippet?Something
> > like ?
> >
> >
> >
> >
> > If not, what's the best way to deal with a large number of snippets?
> > Explicitly registering the snippet dispatch in LiftRules is the way I'd
> > recommend doing it. If this is less than 100% optimal for your use case,
> > let's learn more about your use case and see if we have to expand how
> > Snippets are looked up.
> >
> >
> > Well, registering quite a lot of snippets is indeed less than 100% optimal.
> > OK, I have got a not-so-small website with about 100 templates and
> > snippets. The templates are organized as a tree, e.g. /login/signup/seeker,
> > /login/signup/offerer, etc. There is not a perfect 1:1 relationship between
> > templates and snippets, but for sake of simplicity let's assume so. Hence I
> > would like to organize my snippets in packages according to the templates,
> > e.g. ...snippet.login.signup.Seeker, ...snippet.login.signup.Offerer, etc.
> >
> > One of the things I do with page-specific snippets is call them out in
> > SiteMap:
> > Loc(..., Snippet("foo", snipetFunc))
> > But it might also be interesting to explore a model like Wickets:
> >
> > foo/bar/page.html -> look in snippets.foo.bar in addition to the normal
> > snippets package... would that help?
> >
> >
> > Thank you,
> > Heiko
> > Company: weiglewilczek.com
> > Blog: heikoseeberger.name
> > Follow me: twitter.com/hseeberger
> > OSGi on Scala: scalamodules.org
> > Lift, the simply functional web framework: liftweb.net
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/liftweb?hl=en.
> >
> >
> > --
> > 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
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/liftweb?hl=en.
> >
>
> --
> Heiko Seeberger
>
> Company: weiglewilczek.com
> Blog: heikoseeberger.name
> Follow me: twitter.com/hseeberger
> OSGi on Scala: scalamodules.org
> Lift, the simply functional web framework: liftweb.net
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
>
>
> --
> 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
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Snippets in subpackages?
On Mar 3, 2010, at 11:25 AM, David Pollak wrote:
> On Tue, Mar 2, 2010 at 11:42 PM, Heiko Seeberger
> wrote:
> On 3 March 2010 00:03, David Pollak wrote:
> On Tue, Mar 2, 2010 at 1:05 PM, Heiko Seeberger
> wrote:
> Hi,
>
> Isn't it possible to put snippets in subpackages of xxx.snippet?
> Something like ?
>
> If not, what's the best way to deal with a large number of snippets?
>
> Explicitly registering the snippet dispatch in LiftRules is the way I'd
> recommend doing it. If this is less than 100% optimal for your use case,
> let's learn more about your use case and see if we have to expand how
> Snippets are looked up.
>
> Well, registering quite a lot of snippets is indeed less than 100% optimal.
>
> OK, I have got a not-so-small website with about 100 templates and snippets.
> The templates are organized as a tree, e.g. /login/signup/seeker,
> /login/signup/offerer, etc. There is not a perfect 1:1 relationship between
> templates and snippets, but for sake of simplicity let's assume so. Hence I
> would like to organize my snippets in packages according to the templates,
> e.g. ...snippet.login.signup.Seeker, ...snippet.login.signup.Offerer, etc.
>
> One of the things I do with page-specific snippets is call them out in
> SiteMap:
>
> Loc(..., Snippet("foo", snipetFunc))
>
> But it might also be interesting to explore a model like Wickets:
>
> foo/bar/page.html -> look in snippets.foo.bar in addition to the normal
> snippets package... would that help?
I have wanted this for a while, I think it would be great.
-Ross
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Cleanups in lift-record **possible breaking changes**
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 that if you used "new MyRecord" then you'd get a record that was basically functional but some of the extended metadata (notably field.name) would not be initialized correctly. This is because the correct way to create a record was MyRecordMeta.createRecord. I fixed it so that new MyRecord is equivalent to MyRecordMeta.createRecord, but Marius pointed out there was more cleaning to do. Here are the changes: - I made the createRecord method on MetaRecord abstract, so that MyRecordMeta must now implement it. If you are porting over old code, then just do: def createRecord = new MyRecord This change is so that record creation must be explicitly specified in case it is different from new MyRecord (the default implementation) - MetaRecord.fromJSON(inst, json) has been renamed to setFieldsFromJSON(inst, json) - a new method MetaRecord.setFieldsFromReq(inst, req) has been created to parallel the new name of fromJSON - MetaRecord.createRecord(json) has been renamed to fromJSON(json) - Record.fromJSON has been renamed to setFieldsFromJSON - Record.setFieldsFromReq has been added -- they just call the meta methods of the same name. These changes at the end make it so that fromSomething(something) are consistently factory methods that create records from some source (JSON or Req), and that setFieldsFromSomething(inst, something) is consistently there for setting the fields from the source. Let me know what you think. -Ross -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] The role of LiftRules
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 configuration. -Ross On Feb 25, 2010, at 10:01 PM, Naftoli Gugenheim wrote: > Hi, I'd like to get some opinions on the following. > You may want to read http://reviewboard.liftweb.net/r/158/. > > I have on Review Board a patch for some date-and-time parsing and formatting > configuration. I put the settings inside a singleton object called > ConversionRules. > The question is, where do these configurations belong? > Marius feels that LiftRules is the place where people look for all > Lift-related configuration. So that the LiftRules code shouldn't become too > monstrous, it makes sense to put the code in ConversionRules and have a val > in LiftRules pointing to ConversionRules. > My opinion is that LiftRules is, at least for the most part, http- > (lift-webkit) related, and should be that way. I would actually prefer to > ConversionRules in lift-util, but it relies on Factory which is in webkit. > Preferably Factory could be moved to lift-util and ConversionRules with it. > Now I suppose pointing LiftRules to ConversionRules is possible even if the > latter is moved to lift-util, so I guess it really boils down to whether it > would be beneficial for ConversionRules to be presented as "side by side" > with LiftRules, or as a member of it. (If the latter, I suppose > ConversionRules could be made private[liftweb] so there's only one path to > it...) > Thoughts? > Thanks! > > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Logging, part 2
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 logging library. -Ross On Feb 25, 2010, at 1:42 PM, Marius wrote: > Why not? LiftRules is about configuring a lift app at startup. > > On 25 feb., 16:56, Naftoli Gugenheim wrote: >> Why should an initLogger method be in LiftRules? >> >> - >> >> Marius wrote: >> >> Then perhaps: >> >> LiftRules.initLogger(Log4J) >> >> On Feb 25, 12:16 pm, Jeppe Nejsum Madsen wrote: >> >>> On Thu, Feb 25, 2010 at 10:32 AM, Marius wrote: I'd opt in for something like: >> LiftRules.logger = Log4J >> >>> Agree this fits the current idioms, but how should this be triggered? >>> The new logging code is in lift-common so cannot call stuff in >>> LiftRules. >> >>> Note we're not talking about Loggers (objects that have warn & info >>> methods) but about configuring the logging system, which needs to be >>> done before Loggers can be used. >> >>> /Jeppe >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@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 lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: bind(): suppress automatic attribute mixin
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 attributes > above: > > val xml = > > should have been: > > val xml = > > The result stays the same (without the prefix): > > > > Sorry for the mistake and the additional mail traffic! > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] RPC from Javascript/JQuery?
-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 role is to filter key presses, only send events
> to the server upon certain key presses.
>
> I guess the easiest way to handle this would be to pass the function created
> by:
> {jsonCall("pressed", JsRaw("event.which")).toJsCmd}
>
> into processKeyPress so that it can invoke it if the event.which is
> the correct type.
>
> Unfortunately, I can't come up with a way to describe this in inline XML.
>
>
>
> leaving out the " causes a parse error.. adding the " cause it to be
> evaulated as a string.
>
> Any ideas?
>
>
>
> On Wed, Feb 24, 2010 at 2:57 PM, David Pollak
> wrote:
>> Rick,
>>
>> Here's a simple example:
>>
>> import net.liftweb._
>> import util._
>> import http._
>> import js._
>> import JsCmds._
>> import JE._
>> import scala.xml.NodeSeq
>>
>> class Evently extends CometActor {
>>
>> // handle an incoming JSON event
>> override def handleJson(in: Any): JsCmd = in match {
>> case JsonCmd("pressed", _, key, _) => SetHtml("info", You pressed
>> {key})
>> case _ => Noop
>> }
>>
>> def render =
>>
>>
>> {
>> Script(jsonInCode) // include the JSON callback
>> }
>>> JsRaw("event.which")).toJsCmd}/>
>>
>> }
>>
>> So, the handleJson message gets called on the server whenever a key is
>> pressed on the client (this example works in non-IE browsers, but that's
>> just 'cause I'm using event.which rather than event.keyCode).
>>
>> Hope this helps.
>>
>> Thanks,
>>
>> David
>>
>>
>> On Wed, Feb 24, 2010 at 8:23 AM, Rick R wrote:
>>>
>>> I have a textarea in which I process onKeyUp and onKeyDown commands.
>>> The handlers for such things are custom javascript.
>>> I would like to invoke functions in a Comet LiftActor /
>>> ListenerManager via these custom javascript functions. Is there
>>> documentation on the recommended way to do so?
>>>
>>> It looks like I will have to define the functions within a render call
>>> and use the SHtml.ajaxCall function, since the destination url is
>>> randomized. I am just wondering what would be the idiomatic way to do
>>> this.
>>>
>>> This is for a chat style app which processes/distributes data by the
>>> keystroke rather than by a line/post command.
>>>
>>>
>>> I'm open to any ideas / alternate suggestions.
>>>
>>> Thanks,
>>> Rick
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Lift" group.
>>> To post to this group, send email to lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> liftweb+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/liftweb?hl=en.
>>>
>>
>>
>>
>> --
>> 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
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://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 lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] [urgent] Master is fundamentally broken!!!!!!
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 > wrote: > > The mental image of you wearing a traffic cone on your head is a pleasing one > David :-D > > > http://twitter.com/dpp/status/9591471689 > > Cheers, Tim > > On 24 Feb 2010, at 20:20, David Pollak wrote: > > > and those that circumvent that process (including me) should wear the cone > > of shame. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > > > -- > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] [urgent] Master is fundamentally broken!!!!!!
I personally think having some mostly uncomplicated web apps (PocketChange style) and some end-to-end tests using those in the repository would be extremely valuable -- shakes out bugs that nobody expected to occur (such as this one) and serves as a known-working example. -Ross On Feb 24, 2010, at 1:51 PM, David Pollak wrote: > On Wed, Feb 24, 2010 at 10:42 AM, Raoul Duke wrote: > On Wed, Feb 24, 2010 at 10:42 AM, Raoul Duke wrote: > > imho a high-level test is way more useful for determining if the > > system is basically working, because it is so end-to-end; no, it > > doesn't tell you precisely what to fix like a unit test would, but the > > code-written-to-code-covered ratio is much better for high-level > > system tests than it is for unit tests. > > in other words: are there any 'professional' Test/QA (note those are > different roles!) people on the Lift team/list? > > Just to be clear, the Lift team has a particularly stellar record of keeping > the master development branch stable. In the instant case, the master branch > was unstable for about 10 hours. The last time the master branch was not > stable was more than 60 days ago and the instability in that case also lasted > for < 12 hours. I deploy most of my projects against master... as apparently > does Tim. I have not participated in a project, commercial or open source, > where the main development branch (call it master, head, edge, etc.) has been > as stable as it is in Lift. > > So, I don't think we need additional QA. I think the existing processes work > just fine. > > > sincerely. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > > > -- > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] [urgent] Master is fundamentally broken!!!!!!
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
> fundamentally broken the markup parser. Yesterday I deploy an
> application to production and today I go to update a small bit of copy
> that marketing want changed and i'm finding that my application is
> broken
>
> With LiftRules.useXhtmlMimeType = false in Boot, I see the following:
>
>
> // <![CDATA[
> jQuery(document).ready(function()
> {liftAjax.lift_successRegisterGC();});
> var lift_page = "F1075228527421HHA";
> // ]]>
>
>
> This is obviously problematic and all my javascript in my application
> is now doing this. Sorry to be grizzly about this, but its totally
> untenable for me to be building apps that work one day and are broken
> the next... I tried reverting to 2.0-M2, but that was giving me errors
> about not being able to boot SessionMaster. If we are changing stuff
> in the core of Lift, we need a good number of eyes (that is, people
> who are ACTIVE committers) on the changes in review board otherwise
> stuff like this happens (certainly, I don't remember getting review
> requests for any of these changes that are now causing me
> problems...)
>
> I have to get this fixed today otherwise im going to be seriously
> flamed.
>
> A very unhappy Tim.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: What is LDAP doing in modules?
Hah maybe if I have some extra moments I'll look at it. I'm preparing for a short trip this weekend so my spare time this week is short. If you didn't have a book to write I'd make you do it! ;-) -Ross On Feb 23, 2010, at 3:40 PM, Timothy Perrett wrote: > Ross my good man, did you just 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), but maybe in >> the short term it should be just mildly split up a bit so that it can be >> used separate of MetaMegaTron? I'm sure there are plenty of people who just >> need authentication and have no intent of using more sophisticated LDAP >> integration. >> >> -Ross >> >> On Feb 23, 2010, at 3:14 PM, Timothy Perrett wrote: >> >>> Seems like the current lift-ldap ought to be gutted and turned into a >>> pure LDAP wrapper for scala. Then we can add a record abstraction and >>> any other abstractions people want. >>> >>> Cheers, Tim >>> >>> On Feb 23, 8:07 pm, Ross Mellgren wrote: >>>> It might turn out that we'll need an actual LDAP record backend at work, >>>> so I may write one in the future ;-) >>>> >>>> -Ross >>>> >>>> On Feb 23, 2010, at 3:00 PM, Timothy Perrett wrote: >>>> >>>> >>>> >>>>> Oh yeah, you are right Ross! >>>>> Doh... in that case, might have to do some refactoring on that module >>>>> to give it a more functional style. >>>> >>>>> Cheers, Tim >>>> >>>>> On Feb 23, 7:15 pm, Ross Mellgren 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, >>>> >>>>>>> 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 be >>>>>>> in persistence? >>>> >>>>>>> Cheers, Tim >>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Lift" group. >>>>>>> To post to this group, send email to lift...@googlegroups.com. >>>>>>> To unsubscribe from this group, send email to >>>>>>> liftweb+unsubscr...@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 lift...@googlegroups.com. >>>>> To unsubscribe from this group, send email to >>>>> liftweb+unsubscr...@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 lift...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> liftweb+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://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 lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://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 lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: What is LDAP doing in modules?
Perhaps eventually (or if someone right now has a strong use), but maybe in the short term it should be just mildly split up a bit so that it can be used separate of MetaMegaTron? I'm sure there are plenty of people who just need authentication and have no intent of using more sophisticated LDAP integration. -Ross On Feb 23, 2010, at 3:14 PM, Timothy Perrett wrote: > Seems like the current lift-ldap ought to be gutted and turned into a > pure LDAP wrapper for scala. Then we can add a record abstraction and > any other abstractions people want. > > Cheers, Tim > > On Feb 23, 8:07 pm, Ross Mellgren wrote: >> It might turn out that we'll need an actual LDAP record backend at work, so >> I may write one in the future ;-) >> >> -Ross >> >> On Feb 23, 2010, at 3:00 PM, Timothy Perrett wrote: >> >> >> >>> Oh yeah, you are right Ross! >>> Doh... in that case, might have to do some refactoring on that module >>> to give it a more functional style. >> >>> Cheers, Tim >> >>> On Feb 23, 7:15 pm, Ross Mellgren 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, >> >>>>> 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 be >>>>> in persistence? >> >>>>> Cheers, Tim >> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "Lift" group. >>>>> To post to this group, send email to lift...@googlegroups.com. >>>>> To unsubscribe from this group, send email to >>>>> liftweb+unsubscr...@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 lift...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> liftweb+unsubscr...@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 lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: What is LDAP doing in modules?
It might turn out that we'll need an actual LDAP record backend at work, so I may write one in the future ;-) -Ross On Feb 23, 2010, at 3:00 PM, Timothy Perrett wrote: > Oh yeah, you are right Ross! > Doh... in that case, might have to do some refactoring on that module > to give it a more functional style. > > Cheers, Tim > > On Feb 23, 7:15 pm, Ross Mellgren 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, >> >>> 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 be >>> in persistence? >> >>> Cheers, Tim >> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> liftweb+unsubscr...@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 lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] What is LDAP doing in modules?
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 be > in persistence? > > Cheers, Tim > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Confused about request scope, session scope
On Feb 22, 2010, at 8:39 PM, Strom wrote: > Thanks for responding Ross. Always helpful. > > On Feb 22, 5:25 pm, Ross Mellgren wrote: >> Session scope is until the LiftSession expires (which is tied to the >> container session) and is longer. > How does one determine the container session scope? Anywhere I can > read up on this basic knowledge? Well the precise details depend on the container, but most containers by default set a cookie called JSESSIONID that is used to maintain the session ID and the cookie last until browser logout. The server-side session data is usually kept alive 20 minutes from the most recent time a request used that session ID, but it's configurable in web.xml, and perhaps overridable in whatever container-specific config is available. >> Request scope is during the "current page" which means the original page >> request and any associated AJAX callbacks and other function bindings. > Does this include redirects to the same page with additional query > parameters? I'm using this to search, and would like to have the query > params so people can bookmark their search. I don't believe it includes these. If you want something bookmarkable, you should explicitly place whatever parameters need to persist in the query string -- function mapping bindings are ephemeral, and even so the session would be expired by the time the bookmark was used. > Thanks again! No problem. -Ross -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Confused about request scope, session scope
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: > This seems like a silly question to me, but what is considered the > scope of a request vs the scope of a session? Which is longer? > > I'm trying to figure how to go about having an object fetched from the > DB in memory so I don't have to fetch from the DB every time someone > submits the form. In my case, I would like to have a search involving > zip code that has some associated info in the DB that I would need for > distance calculations, and I would like to keep that DB object around > until the user clears or changes the zip code field, making the > fetched object obsolete. > > I am considering using sessionmemoize or requestmemoize objects to > suit my needs, but I don't know how long each one would stay around (I > can't think of concrete examples of request vs session...I always > though request happened every time you clicked a link to go somewhere > on a webpage, whereas session is as long as the browser is on the > site). > > I've also considered a stateful snippet, but I don't think that's the > right way to go about it since there is no clear start and finish to > the snippet from where to unregister from. > > Thanks, > Strom > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Welcome John De Goes as a Lift committer
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 rest is history. > > Welcome John... looking forward to excellent contributions from you and your > latest partner in crime, Kris Nuttycombe, a long-time Lift committer. > > Thanks, > > David > > -- > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Documenting the source code / supplementing the API docs
I will do this, and give feed back if it ever becomes too much load. -Ross On Feb 22, 2010, at 12:05 PM, Timothy Perrett wrote: > We are interested in the contribution of course... I think the issue is > mostly about how we take patches for this. Someone on the team would need to > own this and merge your documentation changes into the master (provided DPP > has no objections to this - seeing as its documentation I doubt he has) > > Any takers from the team? > > Cheers, Tim > > On 22 Feb 2010, at 16:14, Stuart Roebuck wrote: > >> Sorry for the slow response—was away for a family weekend! >> >> I have limited knowledge of Lift internals… >> >> However, my view is that it is often easier to document code when you >> don't know it well than when you do, because you soon loose interest >> in documenting things that are obvious to you. What I hope to do is >> document the things that I need to know as I go along on the basis >> that many of these things will also be important to others. It's an >> agile rather than systematic approach if you see what I mean. >> >> I have no ego issues here. It's just a small way of giving to the >> community in a win-win kind of way. If my contributions don't seem >> helpful to anyone else then folk can say and I'm not going to >> disappear in a torrent of abuse :-) >> >> Similarly, I'm not proposing some big project here. I'm talking about >> a drip-drip of updates as I spot things that need documenting—I've got >> plenty other stuff on my plate right now as I'm launching a company >> based on a Lift based product in mid-year. >> >> Enough said… >> >> How do we resolve the documentation standard issue? (Scala 2.8 >> Scaladoc2 or prior) David? >> >> Stuart. >> >> On Feb 19, 4:11 pm, Timothy Perrett wrote: >>> This could work - although, some parts of lift are very non-trivial and >>> require good knowledge of lift internals. Do you have such knowledge or are >>> you just hoping to contribute where you can with helpful information? Both >>> are good, just trying to establish what you had in mind. >>> >>> Lift-util probably has the best docs at the moment, so if we 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 on the content first. >>> >>>> -Ross >>> >>>> On Feb 19, 2010, at 10:53 AM, Stuart Roebuck wrote: >>> >>>>> I've had a bit of a break from Lift and coming back I find myself >>>>> annoyed that I didn't write some notes last time and am having to go >>>>> back to searching through the various bits of documentation to figure >>>>> things out. >>> >>>>> Anyway, after much thought I decided that the best way to write my >>>>> notes would be to supplement the API docs (ie. the Scaladoc >>>>> documentation in the code base). so that I can view context sensitive >>>>> help in my IDE of choice and others can benefit from my labours! >>> >>>>> So, question 1… >>> >>>>> The current API docs are very light on documentation and sometime ago >>>>> I noticed some notice about removing documentation from the code >>>>> base. Is there some policy about not having documentation in the >>>>> code or any thought on whether it should adhere to the Scaladoc 2 >>>>> syntax? >>> >>>>> Question 2… >>> >>>>> This is only really going to work if the process of submitting the >>>>> documentation is reasonably straightforward so… What's the easiest >>>>> possible way of submitting documentation changes to the code base? (if >>>>> indeed this is something the core team would welcome). I was >>>>> thinking of perhaps emailing git patch files to someone in the core >>>>> team who can verify that the comments are right before checking them >>>>> in. Any thoughts? >>> >>>>> If there is a reasonably explainable approach, it could be added as a >>>>> Wiki page to encourage wider parti
Re: [Lift] Versions: Netbeans, Scala and Lift
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 on Scala 2.8.0 Beta 1. I have no idea about NetBeans, though I've heard on the list a couple times that the most recent versions are Scala 2.8 only. Keep in mind that Scala is extremely version sensitive and not backward compatible. Hope that helps, -Ross On Feb 21, 2010, at 4:06 PM, Arie wrote: > I've been going through as many posts as possible to try to establish > how to use Netbeans (on a Mac) with Lift. > > I think I'm correct in saying that Netbeans 6.8 will only work with > Scala 2.8 (beta/snapshot - http://wiki.netbeans.org/Scala68v1), and > that from this (http://old.nabble.com/Lift-1.1-SNAPSHOT-under- > Scala-2.8-with-NetBeans-and-the-Scala-plugin-td25302936.html) Lift 1.1 > will only work with Scala 2.7.5. > > What will Lift 1.0 work with in Netbeans (if it will), and related, > how do I square getting Lift (version 1.0/1.1), to work in Netbeans > 6.8 which seems to require Scala 2.8? > > Will any of these problems be solved by Lift 2.0, and when is 2.0 > scheduled to come out!? > > Thanks. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] CouchDB queryView Enhancements?
Oh, no problem at all; I'm sorry that it's not as well tested as it ought to be though with your help that's rapidly improving. I'm glad you like it! Please continue to share your experience with it -- I'll try to smooth out any wrinkles as fast as I can. Thanks for the well reasoned and described notes and review. -Ross On Feb 20, 2010, at 1:03 PM, Justin Reardon 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/39c475b373d925133b55437aa578cfc18b6a4442 -Ross On Feb 18, 2010, at 4:07 PM, Justin Reardon wrote: From the review board diff it looks like you forgot to actually remove the call to dontReduce (line 221). Perhaps a test case 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 on review board, so if you think the new patch will work for you, I'll push it once it's reviewed. -Ross On Feb 18, 2010, at 12:28 AM, Justin Reardon wrote: Wow you're fast. You probably shouldn't call dontReduce in queryViewDocsFrom, as recent versions of couchdb will return an error if this parameter is applied to a view without a reduce function. This could easily happen in the case of the linked documents feature I mentioned, or in the case of avoiding large objects in an index. Also, include_docs=true will cause an error if reduce=false isn't present when a view does have a reduce function, but at least it's easier to add 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 board: http://reviewboard.liftweb.net/r/216/ Once that's reviewed and pushed to master you'll be able to query those views with the new queryViewDocs function. Let me know if you run over any more missing features that should be added to the integration; I'll try to get them in. -Ross On Feb 17, 2010, at 8:52 PM, Justin Reardon wrote: Hi, I've started working with the CouchRecord support and I've run into a bit of a problem with the queryView function. I've been writing views involving both map and reduce so I could generate statistics on some hierarchical data, and access leaves in one view, by using include_docs. As I discovered when my views returned no results in CouchRecord, its implementation is always using the "value" key in the returned row, whereas my views pulled the document in using the "doc" key. For the present its fairly trivial for me to either split the view into two separate ones or perform a slightly cleverer reduce (I've only been counting totals so far), but it would be more convenient if it were possible to do everything in one view. Also, in CouchDB 0.11 they're adding support for linked documents in views, which will place the resulting documents in the "doc" key. The current implementation makes it impossible to use a linked document view to query. Perhaps there could be a version of queryView that uses the "doc" key to generate the actual record, and provide it and the "value" key as a JValue in a tuple, as that value may be occasionally useful too? Thanks, Justin Reardon -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com . For more options, visit this group at http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com . For more options, visit this group at http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com . For more options, visit this group at http://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 lift...@googlegroups.com. T
Re: [Lift] CouchDB queryView Enhancements?
Pushed to master http://github.com/dpp/liftweb/commit/39c475b373d925133b55437aa578cfc18b6a4442 -Ross On Feb 18, 2010, at 4:07 PM, Justin Reardon wrote: > From the review board diff it looks like you forgot to actually remove the > call to dontReduce (line 221). Perhaps a test case 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 on review board, so if you think the new patch will >> work for you, I'll push it once it's reviewed. >> >> -Ross >> >> On Feb 18, 2010, at 12:28 AM, Justin Reardon wrote: >> >>> Wow you're fast. >>> >>> You probably shouldn't call dontReduce in queryViewDocsFrom, as recent >>> versions of couchdb will return an error if this parameter is applied to a >>> view without a reduce function. This could easily happen in the case of the >>> linked documents feature I mentioned, or in the case of avoiding large >>> objects in an index. Also, include_docs=true will cause an error if >>> reduce=false isn't present when a view does have a reduce function, but at >>> least it's easier to add 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 board: http://reviewboard.liftweb.net/r/216/ >>>> >>>> Once that's reviewed and pushed to master you'll be able to query those >>>> views with the new queryViewDocs function. >>>> >>>> Let me know if you run over any more missing features that should be added >>>> to the integration; I'll try to get them in. >>>> >>>> -Ross >>>> >>>> On Feb 17, 2010, at 8:52 PM, Justin Reardon wrote: >>>> >>>>> Hi, >>>>> >>>>> I've started working with the CouchRecord support and I've run into a bit >>>>> of a problem with the queryView function. I've been writing views >>>>> involving both map and reduce so I could generate statistics on some >>>>> hierarchical data, and access leaves in one view, by using include_docs. >>>>> As I discovered when my views returned no results in CouchRecord, its >>>>> implementation is always using the "value" key in the returned row, >>>>> whereas my views pulled the document in using the "doc" key. >>>>> >>>>> For the present its fairly trivial for me to either split the view into >>>>> two separate ones or perform a slightly cleverer reduce (I've only been >>>>> counting totals so far), but it would be more convenient if it were >>>>> possible to do everything in one view. Also, in CouchDB 0.11 they're >>>>> adding support for linked documents in views, which will place the >>>>> resulting documents in the "doc" key. The current implementation makes it >>>>> impossible to use a linked document view to query. >>>>> >>>>> Perhaps there could be a version of queryView that uses the "doc" key to >>>>> generate the actual record, and provide it and the "value" key as a >>>>> JValue in a tuple, as that value may be occasionally useful too? >>>>> >>>>> Thanks, >>>>> Justin Reardon >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "Lift" group. >>>>> To post to this group, send email to lift...@googlegroups.com. >>>>> To unsubscribe from this group, send email to >>>>> liftweb+unsubscr...@googlegroups.com. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/liftweb?hl=en. >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Lift
Re: [Lift] CouchDB optional fields behaviour
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 this on to avoid pulling in corrupt documents. However, the > current usage of needAllJSONFields does not work with optional fields when > set to true. > > Presently when I create a document with optional fields, leave them empty, > and save, I cannot retrieve the document, because needAllJSONFields requires > those optional fields to be present when reconstructing the document. Being > able to save a document I cannot retrieve seems rather counterintuitive. > While I could just set needAllJSONFields = false, doing so will prevent > checking for the presence of required fields. > > I think the best thing to do is change the fromJValue code so that optional > fields are never included in the recordFieldsNotInJson set. This way > needAllJSONFields can be left true while allowing the user to use optional > fields. > > Thanks, > Justin Reardon > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: serializing and deserializing a json object through Lift-JSON
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 Freeman wrote:
>> Ok, this was yet another bug in serialization code. It is now fixed
>> and should be in next snapshot build. Deserializing null values were
>> not supported. Note a recommended way is to use Option for optional
>> values. This would've worked:
>>
>> case class X(yy: Option[Y])
>> case class Y(ss: String)
>>
>> from(to(X(None)))
>>
>> It makes me a bit sad that both Scala and JSON support null values...
>>
>> Cheers Joni
>>
>> On Feb 20, 8:13 am, Ali wrote:
>>
>>> Thanks for your reply. Actually I was trying to build an exception I
>>> am receiving in our product.
>>
>>> case class X(yy:Y)
>>> case class Y(ss:String)
>>
>>> def from(in:String):X={
>>> implicit val formats = net.liftweb.json.DefaultFormats
>>> import net.liftweb.json.JsonAST._
>>> import net.liftweb.json.Extraction._
>>> import net.liftweb.json.Printer._
>>> net.liftweb.json.Serialization.read[X](in)
>>> }
>>> def to(in:X):String={
>>> implicit val formats = net.liftweb.json.DefaultFormats
>>> import net.liftweb.json.JsonAST._
>>> import net.liftweb.json.Extraction._
>>> import net.liftweb.json.Printer._
>>> compact(render(decompose(in)))
>>> }
>>
>>> val sample = new X(null)
>>> val sample2=from(to(sample))
>>
>>> and I am getting,
>>> net.liftweb.json.MappingException: Did not find value which can
>>> be converted into java.lang.String
>>> at net.liftweb.json.Meta$.fail(Meta.scala:99)
>>> at net.liftweb.json.Extraction$.convert(Extraction.scala:280)
>>> at net.liftweb.json.Extraction$.build$1(Extraction.scala:216)
>>> at net.liftweb.json.Extraction$$anonfun$newInstance
>>> $1$1.apply(Extraction.scala:199)
>>> at net.liftweb.json.Extraction$$anonfun$newInstance
>>> $1$1.apply(Extraction.scala:199)
>>> at scala.List.map(List.scala:812)
>>
>>> I appreciate your comment,
>>
>>> Thanks,
>>> -A
>>
>>> On Feb 20, 12:10 am, Joni Freeman wrote:
>>
Is X perhaps an inner class? Inner class has an implicit reference to
outer instance. Serializing those is not supported.
>>
If so, please move definition of X outside of class.
>>
Cheers Joni
>>
On Feb 20, 12:16 am, Ali wrote:
>>
> Hi,
> I am wondering, could you please let me know what is wrong in the
> following code:
>>
> case class X(vv:String)
> val sample = new X("A")
>>
> implicit val formats = net.liftweb.json.DefaultFormats
> import net.liftweb.json.JsonAST._
> import net.liftweb.json.Extraction._
> import net.liftweb.json.Printer._
>>
> def from(in:String):X=net.liftweb.json.Serialization.read[X](in)
> def to(in:X):String=compact(render(decompose(in)))
>>
> val sample2=from(to(sample))
> sample2 must_== sample
>>
> I am getting java.util.NoSuchElementException: key not found: $outer
>>
> Thanks,
> -A
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] CouchDB optional fields behaviour
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 is in fact true by default. It does seem > safest to have this on to avoid pulling in corrupt documents. However, the > current usage of needAllJSONFields does not work with optional fields when > set to true. > > Presently when I create a document with optional fields, leave them empty, > and save, I cannot retrieve the document, because needAllJSONFields requires > those optional fields to be present when reconstructing the document. Being > able to save a document I cannot retrieve seems rather counterintuitive. > While I could just set needAllJSONFields = false, doing so will prevent > checking for the presence of required fields. > > I think the best thing to do is change the fromJValue code so that optional > fields are never included in the recordFieldsNotInJson set. This way > needAllJSONFields can be left true while allowing the user to use optional > fields. > > Thanks, > Justin Reardon > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Potential breaking changes - lift-record's support for JSON
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 to go ahead and implement that change, but want to get a feel first for if that would cause unacceptable breakage for people or just in general what the opinion on it was. -Ross -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Documenting the source code / supplementing the API docs
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 from Lift and coming back I find myself > annoyed that I didn't write some notes last time and am having to go > back to searching through the various bits of documentation to figure > things out. > > Anyway, after much thought I decided that the best way to write my > notes would be to supplement the API docs (ie. the Scaladoc > documentation in the code base). so that I can view context sensitive > help in my IDE of choice and others can benefit from my labours! > > So, question 1… > > The current API docs are very light on documentation and sometime ago > I noticed some notice about removing documentation from the code > base. Is there some policy about not having documentation in the > code or any thought on whether it should adhere to the Scaladoc 2 > syntax? > > Question 2… > > This is only really going to work if the process of submitting the > documentation is reasonably straightforward so… What's the easiest > possible way of submitting documentation changes to the code base? (if > indeed this is something the core team would welcome). I was > thinking of perhaps emailing git patch files to someone in the core > team who can verify that the comments are right before checking them > in. Any thoughts? > > If there is a reasonably explainable approach, it could be added as a > Wiki page to encourage wider participation. > > Best, > > Stuart. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] CouchDB queryView Enhancements?
Once again unto the breach. http://reviewboard.liftweb.net/r/216/ -Ross On Feb 18, 2010, at 4:07 PM, Justin Reardon wrote: > From the review board diff it looks like you forgot to actually remove the > call to dontReduce (line 221). Perhaps a test case 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 on review board, so if you think the new patch will >> work for you, I'll push it once it's reviewed. >> >> -Ross >> >> On Feb 18, 2010, at 12:28 AM, Justin Reardon wrote: >> >>> Wow you're fast. >>> >>> You probably shouldn't call dontReduce in queryViewDocsFrom, as recent >>> versions of couchdb will return an error if this parameter is applied to a >>> view without a reduce function. This could easily happen in the case of the >>> linked documents feature I mentioned, or in the case of avoiding large >>> objects in an index. Also, include_docs=true will cause an error if >>> reduce=false isn't present when a view does have a reduce function, but at >>> least it's easier to add 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 board: http://reviewboard.liftweb.net/r/216/ >>>> >>>> Once that's reviewed and pushed to master you'll be able to query those >>>> views with the new queryViewDocs function. >>>> >>>> Let me know if you run over any more missing features that should be added >>>> to the integration; I'll try to get them in. >>>> >>>> -Ross >>>> >>>> On Feb 17, 2010, at 8:52 PM, Justin Reardon wrote: >>>> >>>>> Hi, >>>>> >>>>> I've started working with the CouchRecord support and I've run into a bit >>>>> of a problem with the queryView function. I've been writing views >>>>> involving both map and reduce so I could generate statistics on some >>>>> hierarchical data, and access leaves in one view, by using include_docs. >>>>> As I discovered when my views returned no results in CouchRecord, its >>>>> implementation is always using the "value" key in the returned row, >>>>> whereas my views pulled the document in using the "doc" key. >>>>> >>>>> For the present its fairly trivial for me to either split the view into >>>>> two separate ones or perform a slightly cleverer reduce (I've only been >>>>> counting totals so far), but it would be more convenient if it were >>>>> possible to do everything in one view. Also, in CouchDB 0.11 they're >>>>> adding support for linked documents in views, which will place the >>>>> resulting documents in the "doc" key. The current implementation makes it >>>>> impossible to use a linked document view to query. >>>>> >>>>> Perhaps there could be a version of queryView that uses the "doc" key to >>>>> generate the actual record, and provide it and the "value" key as a >>>>> JValue in a tuple, as that value may be occasionally useful too? >>>>> >>>>> Thanks, >>>>> Justin Reardon >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "Lift" group. >>>>> To post to this group, send email to lift...@googlegroups.com. >>>>> To unsubscribe from this group, send email to >>>>> liftweb+unsubscr...@googlegroups.com. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/liftweb?hl=en. >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Lift" group. >>>
Re: [Lift] CouchDB queryView Enhancements?
Updated the patch up on review board, so if you think the new patch will work for you, I'll push it once it's reviewed. -Ross On Feb 18, 2010, at 12:28 AM, Justin Reardon wrote: > Wow you're fast. > > You probably shouldn't call dontReduce in queryViewDocsFrom, as recent > versions of couchdb will return an error if this parameter is applied to a > view without a reduce function. This could easily happen in the case of the > linked documents feature I mentioned, or in the case of avoiding large > objects in an index. Also, include_docs=true will cause an error if > reduce=false isn't present when a view does have a reduce function, but at > least it's easier to add 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 board: http://reviewboard.liftweb.net/r/216/ >> >> Once that's reviewed and pushed to master you'll be able to query those >> views with the new queryViewDocs function. >> >> Let me know if you run over any more missing features that should be added >> to the integration; I'll try to get them in. >> >> -Ross >> >> On Feb 17, 2010, at 8:52 PM, Justin Reardon wrote: >> >>> Hi, >>> >>> I've started working with the CouchRecord support and I've run into a bit >>> of a problem with the queryView function. I've been writing views involving >>> both map and reduce so I could generate statistics on some hierarchical >>> data, and access leaves in one view, by using include_docs. As I discovered >>> when my views returned no results in CouchRecord, its implementation is >>> always using the "value" key in the returned row, whereas my views pulled >>> the document in using the "doc" key. >>> >>> For the present its fairly trivial for me to either split the view into two >>> separate ones or perform a slightly cleverer reduce (I've only been >>> counting totals so far), but it would be more convenient if it were >>> possible to do everything in one view. Also, in CouchDB 0.11 they're adding >>> support for linked documents in views, which will place the resulting >>> documents in the "doc" key. The current implementation makes it impossible >>> to use a linked document view to query. >>> >>> Perhaps there could be a version of queryView that uses the "doc" key to >>> generate the actual record, and provide it and the "value" key as a JValue >>> in a tuple, as that value may be occasionally useful too? >>> >>> Thanks, >>> Justin Reardon >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> liftweb+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://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 lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://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 lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] CouchDB queryView Enhancements?
Sensible. I'll make that change tonight. -Ross On Feb 18, 2010, at 12:28 AM, Justin Reardon wrote: > Wow you're fast. > > You probably shouldn't call dontReduce in queryViewDocsFrom, as recent > versions of couchdb will return an error if this parameter is applied to a > view without a reduce function. This could easily happen in the case of the > linked documents feature I mentioned, or in the case of avoiding large > objects in an index. Also, include_docs=true will cause an error if > reduce=false isn't present when a view does have a reduce function, but at > least it's easier to add 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 board: http://reviewboard.liftweb.net/r/216/ >> >> Once that's reviewed and pushed to master you'll be able to query those >> views with the new queryViewDocs function. >> >> Let me know if you run over any more missing features that should be added >> to the integration; I'll try to get them in. >> >> -Ross >> >> On Feb 17, 2010, at 8:52 PM, Justin Reardon wrote: >> >>> Hi, >>> >>> I've started working with the CouchRecord support and I've run into a bit >>> of a problem with the queryView function. I've been writing views involving >>> both map and reduce so I could generate statistics on some hierarchical >>> data, and access leaves in one view, by using include_docs. As I discovered >>> when my views returned no results in CouchRecord, its implementation is >>> always using the "value" key in the returned row, whereas my views pulled >>> the document in using the "doc" key. >>> >>> For the present its fairly trivial for me to either split the view into two >>> separate ones or perform a slightly cleverer reduce (I've only been >>> counting totals so far), but it would be more convenient if it were >>> possible to do everything in one view. Also, in CouchDB 0.11 they're adding >>> support for linked documents in views, which will place the resulting >>> documents in the "doc" key. The current implementation makes it impossible >>> to use a linked document view to query. >>> >>> Perhaps there could be a version of queryView that uses the "doc" key to >>> generate the actual record, and provide it and the "value" key as a JValue >>> in a tuple, as that value may be occasionally useful too? >>> >>> Thanks, >>> Justin Reardon >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> liftweb+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://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 lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://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 lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] CouchDB queryView Enhancements?
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 those views with the new queryViewDocs function. Let me know if you run over any more missing features that should be added to the integration; I'll try to get them in. -Ross On Feb 17, 2010, at 8:52 PM, Justin Reardon wrote: > Hi, > > I've started working with the CouchRecord support and I've run into a bit of > a problem with the queryView function. I've been writing views involving both > map and reduce so I could generate statistics on some hierarchical data, and > access leaves in one view, by using include_docs. As I discovered when my > views returned no results in CouchRecord, its implementation is always using > the "value" key in the returned row, whereas my views pulled the document in > using the "doc" key. > > For the present its fairly trivial for me to either split the view into two > separate ones or perform a slightly cleverer reduce (I've only been counting > totals so far), but it would be more convenient if it were possible to do > everything in one view. Also, in CouchDB 0.11 they're adding support for > linked documents in views, which will place the resulting documents in the > "doc" key. The current implementation makes it impossible to use a linked > document view to query. > > Perhaps there could be a version of queryView that uses the "doc" key to > generate the actual record, and provide it and the "value" key as a JValue in > a tuple, as that value may be occasionally useful too? > > Thanks, > Justin Reardon > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Port of Lift's demo Pocketchangeapp backed by MongoDB
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 somewhat similar to MongoDB though I haven't used it myself. Maybe you could check it out and see if it fits your needs? -Ross On Feb 17, 2010, at 2:19 PM, Alexander Azarov wrote: I am the author of mongo-scala-driver, it's the library to access MongoDB, document-oriented database. It is a part of a larger project which is using Lift, so I've quickly come to the idea to build a little demo application using mongo-scala-driver and Lift. And finally I decided to migrate Lift book's Pocketchangeapp demo to MongoDB -- I think it makes much more sense to compare persistance techniques using the same app. I saw two alternatives: - Use pure scala objects (POSOs) for domain objects. Thus it would be necessary to provide some equivivalents to the Mapper's methods like toForm, etc. and the whole ProtoUser stuff - Create a Mapper replacement on top of mongo-scala-driver No doubts the second way gives much more in terms of a library and in the best case this would make it possible to easily migrate existing Mapper models to MongoDB backend. But my personal goals were much closer to the first alternative, so it was done this way (however few methods of MetaMapper moved to the port) Features: - Domain objects are more or less clean from persistance stuff, they more like ordinary Scala classes - All the functionality has been retained - I did my best to make the port straightforward -- it will be easier to compare both branches - File upload is done using GridFS, MongoDB's API for storing large binary objects - BigDecimal support is done using custom data type to mongo-scala- driver (it's not supported by MongoDB out of the box) Links: * http://www.mongodb.org/ MongoDB * http://github.com/alaz/mongo-scala-driver mongo-scala-driver * http://www.theliftbook.com/ Pocketchangeapp -- Lift book demo app * http://github.com/alaz/pocketchangeapp Pocketchangeapp backed by mongo-scala-driver and MongoDB -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com . For more options, visit this group at http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [urgent] Broken lift-record
It is definitely the new. I thought that it was always this way because I
observed it (I thought) before I made those changes. I just reproduced your
exact case:
val rec1 = MyMetaRecord.createRecord
val res1 = rec1.foo("zippy").fields.map(_.name)
val rec2 = new MyRecord()
val res2 = rec2.foo("zippy").fields.map(_.name)
{ String.valueOf(res1) } ++ { String.valueOf(res2) }
Result is:
List(foo)
List(null)
So createRecord is doing the introspection. I'll start by reverting out my
change to record and see if that makes the problem go away, to narrow it down.
Do you have IM? We could cycle faster.
-Ross
On Feb 17, 2010, at 1:02 PM, Timothy Perrett wrote:
> The field in question is a subtype of:
>
> sealed abstract class TextADORField[OwnerType <: Record[OwnerType]]
> (rec: OwnerType)
>extends ADORField[OwnerType, String](rec){
> def setFromString(s: String): Box[String] = {
>dirty_?(true)
>Full(set(s))
> }
>
> def setFromAny(in: Any): Box[String] = {
>dirty_?(true)
>in match {
> case seq: Seq[_] if !seq.isEmpty => seq.map(setFromAny)(0)
> case (s: String) :: _ => Full(set(s))
> case null => Full(set(null))
> case s: String => Full(set(s))
> case Some(s: String) => Full(set(s))
> case Full(s: String) => Full(set(s))
> case None | Empty | Failure(_, _, _) => Full(set(null))
> case o => Full(this.set(o.toString))
>}
> }
>
> def defaultValue = ""
> }
>
> As you say, they should both go to setBox... Although, look at this:
>
> scala> Visitor.createRecord.fields.map(_.name)
> res25: List[String] = List(email, last_name, first_name)
>
> scala> new Visitor().fields.map(_.name)
> res27: List[String] = List(null, null, null)
>
> That never used to be the case, you used to be able to call new and
> still get the introspection any ideas?
>
> Cheers, Tim
>
>
> On Feb 17, 5:52 pm, Ross Mellgren 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 should do the actual work. Can you show your
>> setFromString implementation? Are you overriding anything other than
>> setFromAny and setFromString in the set department?
>>
>> -Ross
>>
>> On Feb 17, 2010, at 12:51 PM, Timothy Perrett wrote:
>>
>>
>>
>>> Not a generic one - to reproduce it you would need my custom record
>>> implementation and access to internal work servers (neither of which I
>>> can give out).
>>
>>> I have just realised however 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() ?
>>
>>> Cheers, Tim
>>
>>> On Feb 17, 5:46 pm, Ross Mellgren wrote:
>>>> 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 I have relies on knowing the field
>>>>> name, and for some reason, it appears to not be being set:
>>
>>>>> (where Visitor is an example implementation of my Record):
>>
>>>>> scala> new Visitor().email("dfsfdsf").fields.map(_.name)
>>>>> TRACE - Set the value of 'null' with 'dfsfdsf' and marked as dirty.
>>>>> (true)
>>
>>>>> I added some tracing and I see that the "def name" is always null
>>>>> now... this is a major problem for me. My field apply method looks
>>>>> like:
>>
>>>>> override def apply(in: FieldValueType): OwnerType = if
>>>>> (owner.meta.mutable_?){
>>>>>set(in)
>>>>>dirty_?(true)
>>>>>Log.trace("Set the value of '"+name+"' with '"+in.toString+"' and
>>>>> marked as dirty. ("+dirty_?.toString+")")
>>>>>owner
>>>>> } else {
>>>>>owner.meta.createWithMutableField(owner, this, Box.!!(in))
>>>>> }
>>
>>>>> Im really not sure what h
Re: [Lift] Re: [urgent] Broken lift-record
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 should do the actual work. Can you show your setFromString
implementation? Are you overriding anything other than setFromAny and
setFromString in the set department?
-Ross
On Feb 17, 2010, at 12:51 PM, Timothy Perrett wrote:
> Not a generic one - to reproduce it you would need my custom record
> implementation and access to internal work servers (neither of which I
> can give out).
>
> I have just realised however 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() ?
>
> Cheers, Tim
>
> On Feb 17, 5:46 pm, Ross Mellgren wrote:
>> 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 I have relies on knowing the field
>>> name, and for some reason, it appears to not be being set:
>>
>>> (where Visitor is an example implementation of my Record):
>>
>>> scala> new Visitor().email("dfsfdsf").fields.map(_.name)
>>> TRACE - Set the value of 'null' with 'dfsfdsf' and marked as dirty.
>>> (true)
>>
>>> I added some tracing and I see that the "def name" is always null
>>> now... this is a major problem for me. My field apply method looks
>>> like:
>>
>>> override def apply(in: FieldValueType): OwnerType = if
>>> (owner.meta.mutable_?){
>>>set(in)
>>>dirty_?(true)
>>>Log.trace("Set the value of '"+name+"' with '"+in.toString+"' and
>>> marked as dirty. ("+dirty_?.toString+")")
>>>owner
>>> } else {
>>>owner.meta.createWithMutableField(owner, this, Box.!!(in))
>>> }
>>
>>> Im really not sure what has broken this, but i've not changed my code
>>> other than adding the legacy check to accommodate ross' latest
>>> changes.
>>
>>> I URGENTLY need a fix for this - we have production code relying on
>>> this.
>>
>>> Cheers, Tim
>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Lift" group.
>>> To post to this group, send email to lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> liftweb+unsubscr...@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 lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] [urgent] Broken lift-record
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 I have relies on knowing the field
> name, and for some reason, it appears to not be being set:
>
> (where Visitor is an example implementation of my Record):
>
> scala> new Visitor().email("dfsfdsf").fields.map(_.name)
> TRACE - Set the value of 'null' with 'dfsfdsf' and marked as dirty.
> (true)
>
> I added some tracing and I see that the "def name" is always null
> now... this is a major problem for me. My field apply method looks
> like:
>
> override def apply(in: FieldValueType): OwnerType = if
> (owner.meta.mutable_?){
>set(in)
>dirty_?(true)
>Log.trace("Set the value of '"+name+"' with '"+in.toString+"' and
> marked as dirty. ("+dirty_?.toString+")")
>owner
> } else {
>owner.meta.createWithMutableField(owner, this, Box.!!(in))
> }
>
> Im really not sure what has broken this, but i've not changed my code
> other than adding the legacy check to accommodate ross' latest
> changes.
>
> I URGENTLY need a fix for this - we have production code relying on
> this.
>
> Cheers, Tim
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] autocrlf issue?
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 > wrote: >> Hi, >> >> Since a week or so I get modified files even when I create a fresh >> clone of the repo. These are some js and css files from lift-widgets >> and stuff from installer and references. Anyone else experiencing the >> same? I guess it could be related to the core.autocrlf configuration >> for Git. Mine is set to input and I am working on a Mac. >> >> Any ideas? >> >> Heiko >> >> -- >> Heiko Seeberger >> >> Work: weiglewilczek.com >> Blog: heikoseeberger.name >> Follow me: twitter.com/hseeberger >> OSGi on Scala: scalamodules.org >> Lift, the simply functional web framework: liftweb.net >> > > -- > Heiko Seeberger > > Work: weiglewilczek.com > Blog: heikoseeberger.name > Follow me: twitter.com/hseeberger > OSGi on Scala: scalamodules.org > Lift, the simply functional web framework: liftweb.net > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Problematic Dependencies in lift-couchdb
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/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 >>> wrote: >>> Hi folks, >>> >>> Using the lift-couchdb module, I noticed that the dispatch lift-json module >>> lift-couchdb depends on has a dependency on the 1.1-M6 lift-json module. >>> When using maven this isn't giving me any issues (the package is >>> downloaded, but I guess the classpaths work out to my advantage) However, >>> when I try to build my project in sbt, the compiler is picking up the >>> 1.1-M6 lift-json module instead of 2.0-SNAPSHOT. This is causing >>> compilation failures as I'm using some more recent additions to the >>> lift-json module. >>> >>> I imagine there's something I can add in sbt to make my build work, but in >>> general it seems wrong to have a Lift module that leads to a dependency >>> with older versions of Lift. >>> >>> Yeah... this is a big problem. Please open a ticket and mark it as high >>> priority. >>> >>> >>> Thanks, >>> Justin Reardon >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> liftweb+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/liftweb?hl=en. >>> >>> >>> >>> >>> -- >>> 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 >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> liftweb+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://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 lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://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 lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Problematic Dependencies in lift-couchdb
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 > wrote: > Hi folks, > > Using the lift-couchdb module, I noticed that the dispatch lift-json module > lift-couchdb depends on has a dependency on the 1.1-M6 lift-json module. When > using maven this isn't giving me any issues (the package is downloaded, but I > guess the classpaths work out to my advantage) However, when I try to build > my project in sbt, the compiler is picking up the 1.1-M6 lift-json module > instead of 2.0-SNAPSHOT. This is causing compilation failures as I'm using > some more recent additions to the lift-json module. > > I imagine there's something I can add in sbt to make my build work, but in > general it seems wrong to have a Lift module that leads to a dependency with > older versions of Lift. > > Yeah... this is a big problem. Please open a ticket and mark it as high > priority. > > > Thanks, > Justin Reardon > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > > > -- > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Context path, proxies & Lift
Okay, cool. Figured it couldn't hurt to ask ;-)
-Ross
On Feb 16, 2010, at 11:48 AM, Timothy Perrett wrote:
> Seeing as I don't know what the solution is yet, no. Lol. I'd rather just
> have a 15 min conversation than waste time with a million emails ( I'm very
> busy right now )
>
> Will get jeppe to post working solution when one exists...
>
> Cheers, Tim
>
> Sent from my iPhone
>
> On 16 Feb 2010, at 15:15, Ross Mellgren 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 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 working fine.
>>>
>>> I'm traveling now but will be about later
>>>
>>> Cheers, Tim
>>>
>>> Sent from my iPhone
>>>
>>> On 16 Feb 2010, at 10:01, Jeppe Nejsum Madsen wrote:
>>>
>>>> Hi,
>>>>
>>>> I want to setup a single nginx in front of two independent lift apps
>>>> (see previous thread) but haven't succeeded.
>>>> What I wan't is this:
>>>>
>>>> External url foo.com/index.html goes to jetty:
>>>> localhost:8080/foo/index.html
>>>> External url bar.com/index.html goes to jetty:
>>>> localhost:8080/bar/index.html
>>>>
>>>> So, I'm trying to see if I can get the basic jetty setup going before
>>>> throwing nginx in the mix.
>>>>
>>>> Here are my findings:
>>>>
>>>> With LiftRules.calculateContextPath = () => Empty:
>>>>
>>>> Deploying lift app foo in context foo works fine: ie
>>>> localhost:8080/foo/index.html gives me the app and the app works with
>>>> the localhost:8080/foo prefix
>>>>
>>>> Not surprisingly, setting LiftRules.calculateContextPath = () =>
>>>> Full("/foo") gives same result as above.
>>>>
>>>> Ok, Fine so far. But when nginx is added, a redirect to "/index.html"
>>>> should not go to "/foo/index.html" but to "/index.html"
>>>>
>>>> So I tried:
>>>>
>>>> LiftRules.calculateContextPath = () => Full("/")
>>>>
>>>> But now, hitting localhost:8080/foo/index.html (simulating a request
>>>> from nginx), I just get my raw index.html template without any Lift
>>>> processing as if Lift has ignored the request.
>>>>
>>>> Am I misunderstanding the purpose of calculateContextPath?
>>>>
>>>> How can I make lift run in a non-root context but at the same time,
>>>> when generating URLs, not prepend the context path?
>>>>
>>>> /Jeppe
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "Lift" group.
>>>> To post to this group, send email to lift...@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> liftweb+unsubscr...@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://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 lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> liftweb+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://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 lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://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 lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Lift 2.0 RequestMatcher
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 to Scala 2.7.7 and
Lift 2.0-SNAPSHOT if you want to be on the more stable branch.
That said, DispatchPF is now PartialFunction[Req, () => Box[LiftResponse]], so
you need:
val apiDispatcher: LiftRules.DispatchPF = {
case Req("api"::_::Nil, _, _) => api(r, "index")
}
(This uses Req.unapply, FYI)
Hope that helps,
-Ross
On Feb 16, 2010, at 11:37 AM, Ilya Sterin wrote:
> I'm trying to use Lift 2.0-scala280-SNAPSHOT with Scala 2.8.0.Beta1.
>
> I'm looking to create a RESTful service. I looked at the routing
> examples available and they all seem to utilize something like...
>
>
> val apiDispatcher: LiftRules.DispatchPf = {
> case RequestMatcher(r @ RequestState("api" ::
>_ :: Nil, _) ,_) => api(r, "index")
>}
> LiftRules.statelessDispatchTable = apiDispatcher orElse
> LiftRules.statelessDispatchTable
>
>
> First, the DisipatchPf was renamed to DisipatchPF, this was an easy
> fix, at least it was still there and nested in LiftRules... But I
> don't see RequestMatcher anywhere and compiler complains
>
> error: not found: value RequestMatcher
>
> What has RequestMatcher been replaced with, or am I missing something
> else?
>
> Ilya
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Context path, proxies & Lift
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 working fine.
>
> I'm traveling now but will be about later
>
> Cheers, Tim
>
> Sent from my iPhone
>
> On 16 Feb 2010, at 10:01, Jeppe Nejsum Madsen wrote:
>
>> Hi,
>>
>> I want to setup a single nginx in front of two independent lift apps
>> (see previous thread) but haven't succeeded.
>> What I wan't is this:
>>
>> External url foo.com/index.html goes to jetty: localhost:8080/foo/index.html
>> External url bar.com/index.html goes to jetty: localhost:8080/bar/index.html
>>
>> So, I'm trying to see if I can get the basic jetty setup going before
>> throwing nginx in the mix.
>>
>> Here are my findings:
>>
>> With LiftRules.calculateContextPath = () => Empty:
>>
>> Deploying lift app foo in context foo works fine: ie
>> localhost:8080/foo/index.html gives me the app and the app works with
>> the localhost:8080/foo prefix
>>
>> Not surprisingly, setting LiftRules.calculateContextPath = () =>
>> Full("/foo") gives same result as above.
>>
>> Ok, Fine so far. But when nginx is added, a redirect to "/index.html"
>> should not go to "/foo/index.html" but to "/index.html"
>>
>> So I tried:
>>
>> LiftRules.calculateContextPath = () => Full("/")
>>
>> But now, hitting localhost:8080/foo/index.html (simulating a request
>> from nginx), I just get my raw index.html template without any Lift
>> processing as if Lift has ignored the request.
>>
>> Am I misunderstanding the purpose of calculateContextPath?
>>
>> How can I make lift run in a non-root context but at the same time,
>> when generating URLs, not prepend the context path?
>>
>> /Jeppe
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://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 lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: thread [Image upload and serving example]
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 wrote: > Hello - > > I attempted to "reply" to the thread with subject "Image upload and > serving example" initiated by David Pollack on Nov. 30, 2009 via the > Google Groups UI and inadvertently sent mail directly to David because > there was only a "Reply to author" link, no plain "Reply" link -- > oops. (He politely replied "Please post all questions to the list.") > Please forgive my ignorance, but why didn't that thread have "Reply" > links after each message ? (I see other threads do) > > Anyway, my real question: > Is the code referenced in that original thread -- > http://github.com/dpp/imagine/ > -- code still floating around somewhere ? > > Sorry... I did a purge of my un-used GitHub projects and my hard drive a week > or so back and deleted it. Sorry. :-( > > > Thanks, > - Luke > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > > > -- > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Problematic Dependencies in lift-couchdb
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 > wrote: > Hi folks, > > Using the lift-couchdb module, I noticed that the dispatch lift-json module > lift-couchdb depends on has a dependency on the 1.1-M6 lift-json module. When > using maven this isn't giving me any issues (the package is downloaded, but I > guess the classpaths work out to my advantage) However, when I try to build > my project in sbt, the compiler is picking up the 1.1-M6 lift-json module > instead of 2.0-SNAPSHOT. This is causing compilation failures as I'm using > some more recent additions to the lift-json module. > > I imagine there's something I can add in sbt to make my build work, but in > general it seems wrong to have a Lift module that leads to a dependency with > older versions of Lift. > > Yeah... this is a big problem. Please open a ticket and mark it as high > priority. > > > Thanks, > Justin Reardon > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > > > -- > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Lift Record
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:
>
> Option 1
> class Person extends CouchRecord[Person] with PersonView {
> //..
> }
>
> in my UI layer I can have:
>
> def render (person: PersonView): NodeSeq = ...
This is a pretty slick approach (and I'm ashamed I didn't think of it, since
it's a not uncommon pattern in Haskell ;-), though it'd need a little bit extra
to share validations and so on between the multiple implementations of
PersonView. In this case, I think I'd name my actual record classes to reflect
which domain their bound to.
-Ross
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Lift Record
FWIW, I agree mostly completely, and when I was writing the integration I didn't like the fact that I couldn't make one model object usable for both Couch and an RDBMS (for example). I guess it could be made to support more than one if the persistence-specific stuff was untangled from MetaRecord/Record subclasses and made into mixable traits? -Ross On Feb 15, 2010, at 4:34 AM, Timothy Perrett wrote: > Debasish just posted this: > > http://debasishg.blogspot.com/2010/02/why-i-dont-like-activerecord-for-domain.html > > Interesting feedback especially regarding the current design of > Record... > > Cheers, Tim > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Cached CSS (and Javascript?) issue
It does normally, but not for CSS resources. I just did a quick google and I found one page that said it will send a HEAD for a cached CSS but only when the browser session is restarted. I know that at my work we've had to do the filename hack because nothing else works with IE6. And IE6 may be dying out to some degree, but it's still popular enough (and particularly in certain industries) that it has to be supported for many companies :-/ -Ross On Feb 12, 2010, at 3:51 PM, Alex Black wrote: > 1. Luckily IE6 is dying out :) unless http://saveie6.com/ works > 2. surely even IE6 obeys expires headers or some caching rules? > > On Feb 12, 3:48 pm, Ross Mellgren 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 the enthusiasm, but putting a unique value on the css >>> filenames seems like a hack, surely we can do better? >> >>> Whats supposed to happen is: >>> - browser requests resource (e.g. styles.css) with a conditonal get >>> (if newer than X) >>> - server checks to see if resource is newer than X >>> - if it is new than x then: return resource >>> - if it is not newer than x, then return 304 not modified >> >>> - Alex >> >>> On Feb 12, 2:35 pm, Marius wrote: >>>> On 12 feb., 21:31, Jeppe Nejsum Madsen wrote: >> >>>>> On Fri, Feb 12, 2010 at 8:20 PM, Marius wrote: >>>>>> Jeppe probably we can combine the two proposals. >> >>>>> Yes, that would be natural >> >>>>>> Perhaps something like: >> >>>>>> >> >>>>>> thus Lift could generate: >> >>>>>> >> >>>>>> compound_2434rfe34534.css is a synthetic name that would contain the >>>>>> mycss.css, some_other.css. /classpath/baz.css concatenated. Same thing >>>>>> for JS. This content could potentially be compressed. >> >>>>> One thing that I think will be important (at some point :-) is to do >>>>> combining of individual tags. If a page is constructed from several >>>>> snippets/widgets, each emitting different js files (think jQuery >>>>> plugins) and css files, these need to be combined somehow. This means >>>>> that each page will get it's own unique synthetic css/js file. This >>>>> probably needs to be configurable in some way :-) >> >>>> Yeah that is a slightly different use-case that require more noodling. >>>> But would worth considering in the future. >> >>>>>> I can open a ticket and start looking into this. >> >>>>> Awesome! I'll watch from the sideline! >> >>>>> /Jeppe >> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> liftweb+unsubscr...@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 lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Cached CSS (and Javascript?) issue
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? > > Whats supposed to happen is: > - browser requests resource (e.g. styles.css) with a conditonal get > (if newer than X) > - server checks to see if resource is newer than X > - if it is new than x then: return resource > - if it is not newer than x, then return 304 not modified > > - Alex > > On Feb 12, 2:35 pm, Marius wrote: >> On 12 feb., 21:31, Jeppe Nejsum Madsen wrote: >> >> >> >>> On Fri, Feb 12, 2010 at 8:20 PM, Marius wrote: Jeppe probably we can combine the two proposals. >> >>> Yes, that would be natural >> Perhaps something like: >> >> thus Lift could generate: >> >> compound_2434rfe34534.css is a synthetic name that would contain the mycss.css, some_other.css. /classpath/baz.css concatenated. Same thing for JS. This content could potentially be compressed. >> >>> One thing that I think will be important (at some point :-) is to do >>> combining of individual tags. If a page is constructed from several >>> snippets/widgets, each emitting different js files (think jQuery >>> plugins) and css files, these need to be combined somehow. This means >>> that each page will get it's own unique synthetic css/js file. This >>> probably needs to be configurable in some way :-) >> >> Yeah that is a slightly different use-case that require more noodling. >> But would worth considering in the future. >> >> >> I can open a ticket and start looking into this. >> >>> Awesome! I'll watch from the sideline! >> >>> /Jeppe > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: lift-couchdb pushed to master
Thanks guys. I hope people other than me find it useful :-) I'm working on implementing MetaMegaProtoUser style stuff as mixin traits for Records, though I don't know how far I'll get with my spare time at current levels. Maybe if that excites me enough (and no one has addressed it) I'll move 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 > wrote: > Congratulations Ross. > > +1 > > > Cheers, Tim > > On Feb 12, 5:07 am, Ross Mellgren wrote: > > 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 as > > queries, revisions, storing and so on. > > - A Lift-JSON Record implementation, JSONRecord. > > - An extended JSONRecord that integrates with the JSON-oriented > > integration, CouchRecord. > > > > The best examples of how to use it are currently the unit tests: > > > > http://github.com/dpp/liftweb/tree/master/framework/lift-persistence/... > > > > They cover most of the API. I plan to write some simple documentation at > > some point. > > > > Share and Enjoy, > > -Ross > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > > > -- > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Breaking changes in lift-record 2.0-SNAPSHOT - Optional fields
Originally I had implemented this like you suggest, with separate field types.
Marius reviewed it and preferred it to be baked into the basic field type.
The advantages over that method are:
- Not requiring 2x the number of field types everywhere. For example any
record implementation that extends fields needs double (e.g. DBIntField,
DBOptionalIntField)
- Less code
- Centralizes error handling.
Fields that aren't optional should act mostly the same as they did, modulo
validators and set filters.
Let me know what you'd like described better. I can go into the details of how
it's implemented maybe? Or do you want more examples? I'd be happy to clarify
what the change is.
-Ross
P.S. here's the RB link, in case you'd like to take a look at the older
version, or what have you
http://reviewboard.liftweb.net/r/191/
On Feb 12, 2010, at 12:34 AM, harryh wrote:
> What is the advantage of doing it this way as opposed to having a
> collection of Field types who's value is a Box[Whatever]
> (OptionalStringField, OptionalLongField, etc).
>
> I'm finding the e-mail you sent to the list moderately confusing.
> Maybe it's just that more explanation is needed?
>
> -harryh
>
> On Feb 11, 11:49 pm, Ross Mellgren 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 this:
>>
>> object MyRecord extends Record[MyRecord] {
>> object myNormalField extends StringField(this, 100)
>> object myOptionalField extends StringField(this, 100) {
>> override def optional_? = true
>> override def defaultValueBox = Empty
>> override def defaultValue = "nothin"
>> }
>>
>> }
>>
>> val r: MyRecord
>>
>> r.myNormalField.set("Hello") // as before the change
>> r.myOptionalField.setBox(Empty)
>>
>> r.myNormalField.value == "Hello" // as before
>> r.myNormalField.valueBox == Full("Hello")
>> r.myOptionalField.valueBox == Empty
>> r.myOptionalField.value == "nothin" // because defaultValue was used to give
>> back something
>>
>> As part of this change, the semantics for field errors has changed somewhat
>> -- hopefully, to be more consistent.
>>
>> Previously if you tried to set a field and checkCanWrite_? returned false
>> then an internal flag "valueCouldNotBeSet" on the field will be raised which
>> makes that field generate a validation error when validate is called on the
>> record. In addition, some fields (but not all) would raise the same flag and
>> return Failure or Empty from setFromString or setFromAny upon being given an
>> invalid value.
>>
>> With this change, all types of failure to set now result in the field value
>> becoming a Failure. setFromAny, setFromString, and setBox all return that
>> Failure, while set will return defaultValue (due to its return type.)
>>
>> validators and set filters have had their types changed to Boxed equivalents.
>>
>> And finally, I made consistent the setFromAny methods of all the built-in
>> field types so that they all follow the same contract. For setFromAny it's
>> essentially accept one of MyType, Box[MyType], Option[MyType], or
>> List[MyType] as well as null, with a default to convert an unknown input to
>> string and use setFromString. For setFromString, it is as before, except if
>> the field is optional_? and the empty string is passed in, that's treated as
>> Empty.
>>
>> As I'll mention in another message, I also pushed lift-couchdb to master. I
>> ran the unit tests that I wrote for that, but that doesn't give me full
>> confidence that all the fields are entirely bug free. Similarly I did not
>> test the form generation. If anybody runs into any issues please let me know
>> and I'll fix it as soon as I can. And of course if it causes too much
>> breakage we can revert it back out.
>>
>> -Ross
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] lift-couchdb pushed to master
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 as queries, revisions, storing and so on. - A Lift-JSON Record implementation, JSONRecord. - An extended JSONRecord that integrates with the JSON-oriented integration, CouchRecord. The best examples of how to use it are currently the unit tests: http://github.com/dpp/liftweb/tree/master/framework/lift-persistence/lift-couchdb/src/test/scala/net/liftweb/couchdb/ They cover most of the API. I plan to write some simple documentation at some point. Share and Enjoy, -Ross -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Breaking changes in lift-record 2.0-SNAPSHOT - Optional fields
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 myNormalField extends StringField(this, 100)
object myOptionalField extends StringField(this, 100) {
override def optional_? = true
override def defaultValueBox = Empty
override def defaultValue = "nothin"
}
}
val r: MyRecord
r.myNormalField.set("Hello") // as before the change
r.myOptionalField.setBox(Empty)
r.myNormalField.value == "Hello" // as before
r.myNormalField.valueBox == Full("Hello")
r.myOptionalField.valueBox == Empty
r.myOptionalField.value == "nothin" // because defaultValue was used to give
back something
As part of this change, the semantics for field errors has changed somewhat --
hopefully, to be more consistent.
Previously if you tried to set a field and checkCanWrite_? returned false then
an internal flag "valueCouldNotBeSet" on the field will be raised which makes
that field generate a validation error when validate is called on the record.
In addition, some fields (but not all) would raise the same flag and return
Failure or Empty from setFromString or setFromAny upon being given an invalid
value.
With this change, all types of failure to set now result in the field value
becoming a Failure. setFromAny, setFromString, and setBox all return that
Failure, while set will return defaultValue (due to its return type.)
validators and set filters have had their types changed to Boxed equivalents.
And finally, I made consistent the setFromAny methods of all the built-in field
types so that they all follow the same contract. For setFromAny it's
essentially accept one of MyType, Box[MyType], Option[MyType], or List[MyType]
as well as null, with a default to convert an unknown input to string and use
setFromString. For setFromString, it is as before, except if the field is
optional_? and the empty string is passed in, that's treated as Empty.
As I'll mention in another message, I also pushed lift-couchdb to master. I ran
the unit tests that I wrote for that, but that doesn't give me full confidence
that all the fields are entirely bug free. Similarly I did not test the form
generation. If anybody runs into any issues please let me know and I'll fix it
as soon as I can. And of course if it causes too much breakage we can revert it
back out.
-Ross
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: lifecycle callbacks in record
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 can look into it and > any feedback is welcome. > > Tim aka http://wiki.github.com/eltimn/ > > On Thu, Feb 11, 2010 at 4:17 PM, harryh wrote: >>> Yeah that would be a bit of a problem!! Out of interest, what Record >>> backend are you trying to use? >> >> http://wiki.github.com/eltimn/scamongo/ >> >> Which needs some work (I have a fork on my local machine that I'm >> tinkering with), but mostly seems to be getting the job done. >> >> -harryh >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://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 lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Parsed JSON values do not match with class constructor
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 wrote:
> Thanks I am gonna try and test it.
>
> When is 2.0-M2 going to be released?
>
>
> Yesterday... trying to figure out why it didn't happen. Likely today.
>
> Cheers, GA
>
>
>
> On Feb 11, 2010, at 6:00 PM, Joni Freeman wrote:
>
> > Yes, it is fixed in 2.0-M2.
> >
> > Cheers Joni
> >
> > On Feb 11, 6:54 pm, GA wrote:
> >> That's exactly what I've just found out. :-)
> >>
> >> As a workaround I am forcing the client app to send 0.0.
> >>
> >> are you saying that the bug is fixed in Lift 2.0-M2?
> >>
> >> Thanks for the answer,
> >>
> >> cheers,
> >>
> >> GA
> >>
> >> On Feb 11, 2010, at 5:42 PM, Joni Freeman wrote:
> >>
> >>> Hi,
> >>
> >>> I believe this bug is already fixed in trunk. If I'm right, the
> >>> problem was missing conversion from JInt to float. You could fix it by
> >>> changing these values "passMarkApplied":0,"thresholdApplied":0 to
> >>> "passMarkApplied":0.0,"thresholdApplied":0.0
> >>
> >>> But it would be great if you have time to test with latest snapshot.
> >>> It worked for me at least.
> >>
> >>> Cheers Joni
> >>
> >>> On Feb 11, 6:11 pm, GA wrote:
> Hello guys,
> >>
> I am having a very strange error parsing JSON messages. Everything was
> working perfect until I introduce a new array in the message. It
> supposed to be a very small change, but the system seems to be parsing
> java data types instead of scala data types.
> >>
> This is the error message:
> >>
> net.liftweb.json.MappingException: Parsed JSON values do not match with
> class constructor
> args=129567,248,1,1,0,0, String
> arg
> types=java.lang.Long,java.lang.Long,java.lang.Long,java.lang.Long,scala.BigInt,scala.BigInt,java.lang.String
> constructor=public
> com.tribes.ga.api.FeedAPI$FilterLogging$2(long,long,long,long,float,float,java.lang.String)
> >>
> I do not know how to solve this. There is another array in the same
> structure that works just fine.
> >>
> This is the JSON message coming into the API:
> >>
> {"lastSync":"Thursday, February11,2010",
> "tribeId":1,
> "filterLogging":[{"passMarkApplied":0,"thresholdApplied":0,"entryId":129567,"evaluationDescription":"String","objectFiltered":1,"filterApplied":1,"sourceId":248}],
> "history":7,
> "deviceId":1036,
> "source":248,
> "showNews":true,
> "userId":1049,
> "syncFlag":false,
> "showNewsChanged":false,
> "updatedFeeds":[]}
> >>
> The error is with the array "filter". I am parsing it with the following
> code (this is an extraction of the entire definition):
> >>
> case class FilterLogging(entryId: Long,
> sourceId: Long,
> objectFiltered: Long,
> filterApplied: Long,
> passMarkApplied: Float,
> thresholdApplied: Float,
> evaluationDescription: String
> )
> >>
> case class UpdatedSource(userId: Long,
> deviceId: Long,
> tribeId: Long,
> syncFlag: Boolean,
> lastSync: String,
> history: Int,
> source: Long,
> updatedFeeds: List[UpdatedFeeds],
> filterLogging: List[FilterLogging]
> )
> >>
> val json = parse(req.body.map(bytes => new String(bytes,
> "UTF-8")) openOr "")
> val request: UpdatedSource = json.extract[UpdatedSource]
> >>
> Any ideas?
> >>
> Thanks in advance,
> >>
> GA
> >>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "Lift" group.
> >>> To post to this group, send email to lift...@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> >>> liftweb+unsubscr...@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 lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://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 g
Re: [Lift] Testing local archetypes?
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 wrote: > On Wed, Feb 10, 2010 at 9:21 PM, Naftoli Gugenheim > wrote: >> Don't understand the question. >> mvn test? > > I've modified the archetypes in my local Git repo. How can I create a > new project based on the modified archetypes? > > /Jeppe > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [Lift committers] A Groovy welcome to James Strachan who has joined the Lift committers
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 functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > > -- > You received this message because you are subscribed to the Google Groups > "Lift-committers" group. > To post to this group, send email to lift-committ...@googlegroups.com. > To unsubscribe from this group, send email to > lift-committers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/lift-committers?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: HTTP Reason Phrase
Yeah you're very correct. It's unfortunate, but I think since it's deprecated
in the container we should probably not add support for it. I can't believe
they deprecated it for the reason they did, but there it is.
-Ross
On Feb 7, 2010, at 8:16 AM, Erkki Lindpere wrote:
> Actually, the reason phrase is not a normal HTTP header, but part of
> the status line:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1
>
> Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
>
> Examples:
> HTTP/1.1 200 OK
> HTTP/1.1 404 The user with id 8 does not exist
>
> The only way of setting this in Java Servlets as far as I know is
> through HttpServletResponse.setStatus(int, String), which
> unfortunately is deprecated. A non-deprecated possibility is
> sendError(int, String), but that goes to the container's default error
> page (or the one defined in web.xml, I think) so it's not exactly what
> I would like.
>
> Also, I checked that FireBug actually does display the custom reason
> phrase, but Chrome displays the standard one instead.
>
> Erkki L
>
> On Feb 7, 1:08 pm, Timothy Perrett wrote:
>> If you want to alter the Reason-Phrase, you can already do that - objects
>> like NotFoundResponse are just helpers on InMemoryResponse... nothing
>> stopping you adding your own helpers that set headers with customised reason
>> codes; this should give you what you what. I haven't managed to find an RFC
>> that lists reason-phrase as anything but a particular header in the HTTP
>> response.
>>
>> Moreover, its not the wrong thing to return a plain text response if the
>> request mime was text/plain... indeed, it would be even less helpful if it
>> returned JSON or such. IMHO, the response type should match what was asked
>> for by the caller - i.e. its an implementation issue not a framework level
>> issue.
>>
>> Tim
>>
>> On 6 Feb 2010, at 21:55, Erkki Lindpere wrote:
>>
>>> The NotFoundResponse (and others) puts the custom message into the
>>> request body. That works as well, but to be really lean (mainly for
>>> bragging rights :)) I'd like to remove any unnecessary elements from
>>> the rest api. Most of the error messages are going to be simple one-
>>> line messages (and short sentences). For some errors I might provide a
>>> detailed response and it could go into the body, as XML/JSON/...
>>> That's inconsistent if the other errors have a plain text message in
>>> the body.
>>> So I could either go with structured details for all messages or in
>>> simple cases use the HTTP headers or status line. A custom header
>>> would work, but the status line is standard and also more easily
>>> accessed with some client libraries.
>>
>>> And last but perhaps not least, for debugging purposes, the HTTP
>>> Reason Code should show up better in web developer tools (for example
>>> FireBug, Chrome's tools). My web UI also goes through the REST API so
>>> it would be nice to read error messages right in the listing in
>>> firebug's net panel.
>>
>>> So I'm suggesting that perhaps Lift would like to provide only the
>>> possibility of changing that value in user code. But I completely
>>> understand if it doesn't. Currently it doesn't seem to be supported in
>>> Lift's http.provider package and even in javax.servlet the
>>> setStatus(int, String) method is deprecated (I'm not sure if
>>> sendError(int, String) uses the reason phrase).
>>
>>> Erkki L
>>
>>> On Feb 6, 9:59 pm, Ross Mellgren 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
>>>> - that's always fragile. If you want to give additional machine-readable
>>>> detail, I'd put it in a response header or in the body as a JSON or XML
>>>> field or what have you.
>>
>>>> You can specify custom text there, but you may have to sidestep the usual
>>>> response classes, depending on which one. The one you gave, not found, can
>>>> have the message customized though, just do new NotFoundResponse("the
>>>> message").
>>
>>>> -Ross
>>
>>>> On Feb 6, 2010, at 2:52 PM, Erkki Lindpere wrote:
>>
>>>>> It seems Lift does not support custom HTTP
Re: [Lift] **IMPORTANT** TOTALLY DO CREATE TICKETS ON ASSEMBLA
hah no problem, though if I had realized initially that you had cc'd liftweb on the other thread, I probably wouldn't have ;-) -Ross On Feb 6, 2010, at 3:35 PM, Indrajit Raychaudhuri wrote: > Ross, Thanks for updating the subject line and clarifying even. > > - Indrajit > > On 07/02/10 1:46 AM, 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, Indrajit >>> >>> On 05/02/10 10:49 AM, Naftoli Gugenheim wrote: >>>> Indrajit and I are working on importing tickets into Assembla. The first >>>> ticket on GitHub is #3 and there are now two on Assembla. >>>> So please don't create any Assembla tickets until further notice. >>>> Thanks! >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Lift" group. >>>> To post to this group, send email to liftweb@googlegroups.com >>>> <mailto:liftweb@googlegroups.com>. >>>> To unsubscribe from this group, send email to >>>> liftweb+unsubscr...@googlegroups.com >>>> <mailto:liftweb+unsubscr...@googlegroups.com>. >>>> For more options, visit this group at >>>> http://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 liftweb@googlegroups.com >>> <mailto:liftweb@googlegroups.com>. >>> To unsubscribe from this group, send email to >>> liftweb+unsubscr...@googlegroups.com >>> <mailto:liftweb+unsubscr...@googlegroups.com>. >>> For more options, visit this group at >>> http://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 lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://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 lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] **IMPORTANT** TOTALLY DO CREATE TICKETS ON ASSEMBLA
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 10:49 AM, Naftoli Gugenheim wrote: >> Indrajit and I are working on importing tickets into Assembla. The first >> ticket on GitHub is #3 and there are now two on Assembla. >> So please don't create any Assembla tickets until further notice. >> Thanks! >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Lift" group. >> To post to this group, send email to lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://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 lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] HTTP Reason Phrase
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 - that's always
fragile. If you want to give additional machine-readable detail, I'd put it in
a response header or in the body as a JSON or XML field or what have you.
You can specify custom text there, but you may have to sidestep the usual
response classes, depending on which one. The one you gave, not found, can have
the message customized though, just do new NotFoundResponse("the message").
-Ross
On Feb 6, 2010, at 2:52 PM, Erkki Lindpere wrote:
> It seems Lift does not support custom HTTP Reason Phrases in
> responses. I would like to send error messages in the Reason Phrase
> (along with a vaguely applicable HTTP status code) in a RESTful API
> I'm providing. My understanding of the HTTP spec is that the reason
> phrase is meant to be human readable and does not have to contain the
> recommended messages (i.e. "Not Found").
>
> But maybe it would not be wise to do this? I'm not actually aware of
> any API-s that send error messages in the Reason Phrase.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Map to JsObj
JsObj(map.toSeq: _*) ? -Ross On Feb 5, 2010, at 3:53 PM, Peter Robinett wrote: > I thought it would be something that already exists but I can't for > the life of me find out how to convert a Map to a JsObj. Am I missing > something basic in net.liftweb.http.js? > > Thanks, > Peter > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: S.params disappear?
Looking at the tomcat code, it seems pretty likely this is a Tomcat-specific
issue.
-Ross
On Feb 5, 2010, at 2:01 PM, Naftoli Gugenheim wrote:
> If "any other proxy" includes nginx, then a lot of people!
>
> -
> chas wrote:
>
> CRUD. Yes. Exactly what I'm trying to do, and Tomcat developers are making
> it difficult.
>
> I can say that in Jetty 6, they are definitely passed. I don't know
> whether they are being stripped in Tomcat deliberately (I hope not) or if
> it's a bug. I plan to file a bug report anyway.
>
> I'm running Jetty directly (inside Maven), but my Tomcat container is
> proxied via Apache 2, so it's remotely possible that Apache is stripping
> the params out of the headers. But I doubt it. Still, if someone has Jetty
> behind an Apache proxy (or any other proxy), it would be nice to know...
>
> Chas.
>
>
>> Crud.
>>
>> Can someone do 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 wrote:
>>
>>> Looking at the Tomcat code, this is explicit. From
>>> org.apache.catalina.connector.Request:
>>>
>>> /**
>>>* Parse request parameters.
>>>*/
>>> protected void parseParameters() {
>>> ...
>>> if (!getMethod().equalsIgnoreCase("POST"))
>>> return;
>>> ...
>>> }
>>>
>>> -Ross
>>>
>>> On Feb 5, 2010, at 11:47 AM, Leo Lännenmäki wrote:
>>>
>>>> Hmpf. I have got the Tomcat PUT problem also.
>>>>
>>>> def statefulDispatchTable: LiftRules.DispatchPF = {
>>>> ...
>>>> case r...@req(List("api", "foo"), "", PutRequest) => () =>
>>>> update(req)
>>>> ...
>>>> }
>>>>
>>>> def update(req: Req): LiftResponse = {
>>>> for (name <- req.paramNames) {
>>>> Log.info(name)
>>>> Log.info(req.param(name).openOr("empty"))
>>>> }
>>>> ...
>>>> }
>>>>
>>>>
>>>> On Jetty:
>>>> 209467 [736850...@qtp-566947760-0] INFO lift - param
>>>> 209467 [736850...@qtp-566947760-0] INFO lift - value
>>>> 209476 [736850...@qtp-566947760-0] INFO lift - Service request
>>>> (PUT) /api/foo took 17 Milliseconds
>>>>
>>>> curl -v -X PUT -d "param=value" -b JSESSIONID=v7a6qye5zusv
>>>> http://localhost:8080/api/foo
>>>> * About to connect() to localhost port 8080 (#0)
>>>> * Trying ::1... connected
>>>> * Connected to localhost (::1) port 8080 (#0)
>>>>> PUT /api/foo HTTP/1.1
>>>>> User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
>>> OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
>>>>> Host: localhost:8080
>>>>> Accept: */*
>>>>> Cookie: JSESSIONID=v7a6qye5zusv
>>>>> Content-Length: 49
>>>>> Content-Type: application/x-www-form-urlencoded
>>>>>
>>>> < HTTP/1.1 200 OK
>>>> < Content-Length: 0
>>>> < Content-Type: text/html; charset=utf-8
>>>> < X-Lift-Version: 2.0-M1
>>>> < Server: Jetty(6.1.22)
>>>> <
>>>> * Connection #0 to host localhost left intact
>>>> * Closing connection #0
>>>>
>>>>
>>>>
>>>> On Tomcat:
>>>> 170570 [http-8080-2] INFO lift - Service request (PUT) /api/foo took
>>>> 12 Milliseconds
>>>>
>>>> curl -v -X PUT -d "param=value" -b
>>>> JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
>>> http://localhost:8080/myserver/api/foo
>>>> * About to connect() to localhost port 8080 (#0)
>>>> * Trying ::1... connected
>>>> * Connected to localhost (::1) port 8080 (#0)
>>>>> PUT /api/foo HTTP/1.1
>>>>> User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
>>> OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
>>>>> Host: localhost:8080
>>>>> Accept: */*
>>>>> Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
>>>>> Content-Length: 49
>>>>> Content-Type: application/x-www-form-urlencoded
>>>>>
>>>> < HTTP/1.1 200 OK
>>>> < Server: Apache-Coyote/1.1
>>>> <
Re: [Lift] LiftRules inconsistencies (including FactoryMaker grump)
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 FactoryMaker is used, e.g. stripComments might say: * To strip comments from all resources served by lift: *LiftRules.stripComments.default.set(() => false) * To strip only for a certain request: *... -Ross On Feb 5, 2010, at 1:41 PM, David Pollak wrote: > > > On Fri, Feb 5, 2010 at 7:35 AM, Timothy Perrett > wrote: > Guys, > > I just wanted to have a grumpy moan about FactoryMaker. Now, this must > easily be the most complicated / confusing piece of scala code in > Lift. > > Its totally non-trivial implementation and its levels of miss- > direction (and total lack of examples) make it an utter nightmare to > figure out what one needs to do to use it for pre-assigned vals in > LiftRules. > > This brings me neatly onto my next point: LiftRules and its occasional > use of FactoryMaker, partial functions and mutable vars. I appreciate > that this is partially a legacy thing as many different people within > the team add stuff to LiftRules, however I thought FactoryMaker was > brought in to facilitate object mocking / testing right? Shouldn't it > be the first-order choice for configuration? weather or not that is > the case, why oh why are there no explanations in the comments for > LiftRules where factory maker is used as to how to alter those > configuration options? > > Okay... once the assembla ticket system is up, open a ticket on this and > assign it to me. > > > For example: > >LiftRules.stripComments.default.set(() => false) > > > FactoryMakers allows you to do a number of things: > define functions that calculate a value for a given thing (like should > comments be stripped) > support aggregation into a Factory which can be used for Java-style > dependency injection (you ask the Factory for a thing of type T and it gives > it to you) > supports session, request, and current-thread over-riding of the calculation > function > So, why functions vs. values? Because functions are more flexible than > values... they allow the calculation of values given the current context. > > Why not use call-by-name rather than explicit functions? I've found that > making things explicit functions remove ambiguity. Additionally, there's an > implicit that's supposed to promote a constant (T) to a function... but it > doesn't always get invoked. > > If it's a function, why have session, request, and thread-based functions? > Because you have to know at Boot time what you want the function to look like > in all cases. Kris had some reasonable examples of over-riding the functions > on a test-by-test basis (thread-based). Additionally, it strikes me that you > might want to have a snippet that triggers a change in particular behavior > (request-based) and rather than having to code that behavior into the > function defined in Boot, you change it at the request level (we've got some > examples of stuff that does that already, but making the common pattern into > something that's built into the Factor/FactoryMaker makes sense). > > Are the names and call patterns optimal? No. But given that > Factory/FactoryMaker is little used outside of LiftRules, I'd be up for > breaking changes (as long as they turned into compile-time errors) to make > things better. Tim -- you want to volunteer? > > This is totally non-obvious - if we are going to use stuff like this, > it really out to be in the comments. Stuff like this can seriously > affect Lift's ease of use, and considering the current lack of > documentation we need to be careful about what we are doing here. > > Sorry for the grump, i just felt this was warranted. > > Cheers, Tim > > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > > > -- > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from t
Re: [Lift] OSGi example, what to do to make it run?
On Feb 5, 2010, at 12:18 PM, David Pollak wrote: > On Fri, Feb 5, 2010 at 9:06 AM, Heiko Seeberger > wrote: > On 5 February 2010 15:05, Martin Ellis wrote: > > Any offers/suggestions? (Sorry, I realise the question more about > OSGI than lift) > > Indeed, let's discuss this off-list ... > > > Can you discuss it on-list? I'd like to learn. +1 -Ross -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Single Table Inheritance
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 broken your first message, It's a blank
> message if you view it through the web-interface:
> http://groups.google.com/group/liftweb/browse_thread/thread/e2317e5dbaad4a65
>
> If you have a solution I would love to hear it :)
>
> On Feb 5, 1:52 am, Naftoli Gugenheim wrote:
>> Does my approach not work?
>>
>> -
>>
>> Mads Hartmann wrote:
>>
>> Yeah that helped, my lab and scientist now looks like this:
>>
>> /--- code
>>
>> trait BaseSourceTrait[ T <:BaseSourceTrait[T] ] extends
>> LongKeyedMapper[T] {
>>
>> self: T =>
>>
>> override def primaryKeyField = id
>> object id extends MappedLongIndex(this)
>>
>> object name extends MappedPoliteString(this, 256)
>> object sourceType extends MappedEnum(this,SourceTypes)
>>
>> object SourceTypes extends Enumeration {
>> val Scientist = Value("Scientist")
>> val Lab = Value("Lab")
>> }
>>
>> }
>>
>> class Scientist extends BaseSourceTrait[Scientist] {
>>
>> def getSingleton = Scientist
>>
>> object birth extends MappedInt(this)
>> object death extends MappedInt(this)
>> object nationality extends MappedPoliteString(this, 128)
>>
>> }
>>
>> object Scientist extends Scientist with LongKeyedMetaMapper[Scientist]
>> {
>> override def dbTableName = "Source"
>>
>> }
>>
>> class Lab extends BaseSourceTrait[Lab] {
>>
>> def getSingleton = Lab
>>
>> object institution extends MappedLongForeignKey(this, Institution)
>>
>> }
>>
>> object Lab extends Lab with LongKeyedMetaMapper[Lab] {
>> override def dbTableName = "Source"
>>
>> }
>>
>> /--- code ends
>>
>> My only problem now is that I can't figure out how to implement the
>> following:
>>
>> A Discovery (a mapped class) needs to have a foreign key to the source
>> that made the discovery, this could be either a lab or a scientist, so
>> normally i would have a field with a reference to the super-class of
>> both Scientist and Lab - However, I don't have a super-class, I just
>> have a trait :)
>>
>> I would like to be able to write something like this:
>>
>> /--- code starts again
>>
>> class Discovery extends LongKeyedMapper[Discovery] with IdPK {
>>
>> def getSingleton = Discovery
>>
>> // primatives
>> object description extends MappedDateTime(this)
>> object year extends MappedInt(this)
>> object reference extends MappedPoliteString(this, 128)
>>
>> // relationships
>> object source extends MappedLongForeignKey(this, BaseSourceTrait) //
>> <-- this is what i want.
>>
>> }
>>
>> object Discovery extends Discovery with LongKeyedMetaMapper[Discovery]
>>
>> /--- code ends
>>
>> As always I truely appreciate the help you guys are giving me :)
>>
>> Thanks,
>> Mads Hartmann Jensen
>>
>> On Feb 4, 9:56 pm, David Pollak wrote:
>>
>>
>>
>>
>>
>>> Please take a look at the MegaProtoUser and MegaMetaProtoUser code for
>>> examples of how to create traits that can be mixed into classes.
>>
>>> Does that help?
>>
>>> On Thu, Feb 4, 2010 at 9:58 AM, Mads Hartmann Jensen
>>> wrote:
>>
hello Jeppe,
>>
In my project I've got the following three models: A discovery, a Scientist
and a lab. The Discovery has been invented by someone, this is either a
single scientist or sometimes a lab - This is easily done through
inheritance (would create a superclass named source) but I'm not sure how
to
do this so it maps nicely to the database.
>>
Scientist and Lab only share one attribute so what I'm most interested in
is to be able express that a Discovery has s source that can be either a
lab
or scientist :)
>>
Hope this explains my problem more clearly, thanks for the help
>>
Mads Hartmann
>>
Sent from my iPhone
>>
On 04/02/2010, at 18.17, Jeppe Nejsum Madsen wrote:
>>
Mads Hartmann writes:
>>
> Hello Everyone,
>>
>> I'm currently trying to figure out how to map objects with inheritance
>> using the Mapper framework. I've got a Lab and a Scientist who inherit
>> from Source.
>>
>> As I understand there's no direct way to do inheritance using the
>> Mapper framework so I'm trying to figure out how to implement 'Single
>> Table Inheritance'.
>>
>> Right now I'm trying to create a single trait (Source) for the values
>> that they share called BaseSource and my idea is to mix it in both Lab
>> and Scientist. I would then define the table name of both scienti
Re: [Lift] Re: S.params disappear?
Looking at the Tomcat code, this is explicit. From
org.apache.catalina.connector.Request:
/**
* Parse request parameters.
*/
protected void parseParameters() {
...
if (!getMethod().equalsIgnoreCase("POST"))
return;
...
}
-Ross
On Feb 5, 2010, at 11:47 AM, Leo Lännenmäki wrote:
> Hmpf. I have got the Tomcat PUT problem also.
>
> def statefulDispatchTable: LiftRules.DispatchPF = {
> ...
> case r...@req(List("api", "foo"), "", PutRequest) => () =>
> update(req)
> ...
> }
>
> def update(req: Req): LiftResponse = {
> for (name <- req.paramNames) {
>Log.info(name)
>Log.info(req.param(name).openOr("empty"))
> }
> ...
> }
>
>
> On Jetty:
> 209467 [736850...@qtp-566947760-0] INFO lift - param
> 209467 [736850...@qtp-566947760-0] INFO lift - value
> 209476 [736850...@qtp-566947760-0] INFO lift - Service request
> (PUT) /api/foo took 17 Milliseconds
>
> curl -v -X PUT -d "param=value" -b JSESSIONID=v7a6qye5zusv
> http://localhost:8080/api/foo
> * About to connect() to localhost port 8080 (#0)
> * Trying ::1... connected
> * Connected to localhost (::1) port 8080 (#0)
>> PUT /api/foo HTTP/1.1
>> User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g
>> zlib/1.2.3.3 libidn/1.15
>> Host: localhost:8080
>> Accept: */*
>> Cookie: JSESSIONID=v7a6qye5zusv
>> Content-Length: 49
>> Content-Type: application/x-www-form-urlencoded
>>
> < HTTP/1.1 200 OK
> < Content-Length: 0
> < Content-Type: text/html; charset=utf-8
> < X-Lift-Version: 2.0-M1
> < Server: Jetty(6.1.22)
> <
> * Connection #0 to host localhost left intact
> * Closing connection #0
>
>
>
> On Tomcat:
> 170570 [http-8080-2] INFO lift - Service request (PUT) /api/foo took
> 12 Milliseconds
>
> curl -v -X PUT -d "param=value" -b
> JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
> http://localhost:8080/myserver/api/foo
> * About to connect() to localhost port 8080 (#0)
> * Trying ::1... connected
> * Connected to localhost (::1) port 8080 (#0)
>> PUT /api/foo HTTP/1.1
>> User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g
>> zlib/1.2.3.3 libidn/1.15
>> Host: localhost:8080
>> Accept: */*
>> Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
>> Content-Length: 49
>> Content-Type: application/x-www-form-urlencoded
>>
> < HTTP/1.1 200 OK
> < Server: Apache-Coyote/1.1
> < X-Lift-Version: 2.0-M1
> < Content-Type: text/html;charset=utf-8
> < Content-Length: 0
> < Date: Fri, 05 Feb 2010 16:28:23 GMT
> <
> * Connection #0 to host localhost left intact
> * Closing connection #0
>
>
> On Feb 4, 10:47 pm, David Pollak
> wrote:
>> Sounds to me like a Tomcat issue... I think we're relying on the container
>> to parse the body correctly.
>>
>>
>>
>> On Wed, Feb 3, 2010 at 9:15 PM, wrote:
>>> It's POST vs. PUT. I'm using AJAX, so I can do PUTs.
>>
>>> The two are identical, except:
>>
>>> POST instead of PUT
>>
>>> The POST version includes:
>>
>>> Pragma: no-cache
>>> Cache-Control: no-cache
>>
>>> which the PUT does not. In other words, the headers are identical except
>>> for the above.
>>
>>> In Jetty, no problem. In Tomcat, the params are ignored. They do not show
>>> up in S.params. At all.
>>
>>> I can't imagine that this is a Lift issue, unless Tomcat makes params
>>> available differently for PUTs than for POSTs, but Jetty does not, and I'm
>>> the first guy to do PUTs to Lift on Tomcat. But I've emailed the Tomcat
>>> users list and we'll see if it's something simple. If not, I'll put
>>> something on GitHub.
>>
>>> Chas.
>>
Is it a POST or a GET?
>>
On Wed, Feb 3, 2010 at 11:44 PM, wrote:
>>
> Thanks, David.
>>
> That's a non-trivial exercise for me, so let me chase down another lead
> at
> the moment. If that proves fruitless, I'll bite the bullet and get
> something up on GitHub.
>>
> Chas.
>>
>> Please put together a reproduceable example on GitHub (works in Jetty,
>> doesn't work in Tomcat) and we'll look at it.
>>
>> On Wed, Feb 3, 2010 at 11:48 AM, 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 6 on the server, and
> when
>>> I
>>> do, suddenly it won't work.
>>
>>> The issue is with the S.params. I have a form that submits via an
> Ajax
>>> PUT
>>> request. The params are sent in the header just fine. As I said,
> works
>>> like a charm on Jetty. But when it gets to Tomcat, the entity is
> saved
>>> with blank attributes... i.e., everything worked but the
>>> S.param("whatever") showed up blank. I tested this by doing
>>> S.param("whatever").openOr("Phooey") and, indeed, that attribute was
> set
>>> to "Phooey" on the new entity.
>>
>>> Tomcat issue? Or am I missing something obvious? This form is running
> on
>>> a
>>> subdomain, so that's where I'm looking now (in server.xml).
>>
>>>
Re: [Lift] Re: How to make JsCmds.RedirectTo context path sensitive?
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 those changes. -Ross On Feb 4, 2010, at 5:59 PM, Java1Guy wrote: > I think David's analysis is exactly right: "CometActors do not run in > the scope of any HTTP requests. I'm guessing that > the context path is not getting to the CometActor." > > As the button text I put S.contextPath+"/index" and sure enough, it > shows "/index" - even though the above output shows that to the > "normal" snippet, the context path is set. > > Cheers, Mark > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: How to make JsCmds.RedirectTo context path sensitive?
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 jetty:run, you can use contextPath in pom.xml:
...
...
org.mortbay.jetty
maven-jetty-plugin
/mt
...
...
...
-Ross
On Feb 4, 2010, at 5:31 PM, Java1Guy wrote:
> From mvn jetty:run:
> Here's request map: Full()Here's session map: Full()and finally
> S.contextPath:
> From jetty
> Here's request map: Full(/mt)Here's session map: Full(/mt)and finally
> S.contextPath: /mt
> WTF?
>
> My actor code is:
>bind("f", defaultXml,
>"nakedHomeButton" ->
>SHtml.ajaxButton(
>Text("Home"),
>() => RedirectTo("/index")
>),
>"homeButton" ->
>SHtml.ajaxButton(
>Text("Home"),
>() => RedirectTo(S.hostAndPath+"/index")
>),
>"hiddenButton" ->
>SHtml.ajaxButton(
>Text("Hidden"),
>() => RedirectTo(S.contextPath+"/hidden")
>)
> )
>
> And ALL of them do NOT put in the /mt...
> (FWIW, i'm on Jetty 6.1.20, Scala 2.7.7 and Lift 2.0-M1)
>
> Thanks for looking!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] How to make JsCmds.RedirectTo context path sensitive?
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 should be a simple problem, but I sure can't
> find the answer.
>
> I have a simple CometActor page with an ajaxButton on it. I want the
> button to go to a different page. No problem - except when I deploy
> it into a jetty container where it isn't in the root context, it
> doesn't work!
>
>SHtml.ajaxButton(
>Text("Home"),
>() => RedirectTo("/index")
>),
>
> works fine in "mvn jetty:run" but when deployed it doesn't get the URL
> re-writing facility?
>
> Tried RedirectTo(S.hostAndPath+"/index") - no help.
> and RedirectTo(S.contextPath+"/index") - no help.
>
> I even found some code here which seemed to suggest a fix:
>val loc = (for {
> loc <- SiteMap.findLoc("Login")
> path <- loc.createDefaultPath
>} yield path.text) openOr "/"
> But this doesn't compile in the 2.0-M1 world...
> Shouldn't this be simple?
>
> Thanks in advance,
> Mark
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Mapper objects deserialized from json have all of their fields marked dirty
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 wrote: > I reopened it since I marked it invalid pending the ML discussion. > > Added a comment with the ML discussion. > > Excellent! > > > -Ross > > On Feb 4, 2010, at 3:45 PM, David Pollak wrote: > >> >> >> On Thu, Feb 4, 2010 at 12:41 PM, harryh wrote: >> > - Serializing the dirty-state of each field (e.g., field_name_$dirty: >> > true) >> >> This further increases the size of the serialized objects which is not >> ideal >> >> > - A thread-local flag for the default dirty/clean >> > - A global flag indicating that the fields are marked clean/dirty on >> > deserialization >> >> And these seem no good due to the user of global variables >> >> What about option 4: >> >> - change the deserialize function to take an extra parameter >> indicating whether the fields should be marked dirty or not. >> >> Sure... Please update the ticket: >> https://www.assembla.com/spaces/liftweb/tickets/2-Mapper-objects-deserialized-from-json-have-all-of-their-fields-marked-dirty- >> >> >> ? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/liftweb?hl=en. >> >> >> >> >> -- >> 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 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://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 lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > > -- > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Mapper objects deserialized from json have all of their fields marked dirty
I reopened it since I marked it invalid pending the ML discussion. Added a comment with the ML discussion. -Ross On Feb 4, 2010, at 3:45 PM, David Pollak wrote: > > > On Thu, Feb 4, 2010 at 12:41 PM, harryh wrote: > > - Serializing the dirty-state of each field (e.g., field_name_$dirty: > > true) > > This further increases the size of the serialized objects which is not > ideal > > > - A thread-local flag for the default dirty/clean > > - A global flag indicating that the fields are marked clean/dirty on > > deserialization > > And these seem no good due to the user of global variables > > What about option 4: > > - change the deserialize function to take an extra parameter > indicating whether the fields should be marked dirty or not. > > Sure... Please update the ticket: > https://www.assembla.com/spaces/liftweb/tickets/2-Mapper-objects-deserialized-from-json-have-all-of-their-fields-marked-dirty- > > > ? > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > > > -- > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Mapper objects deserialized from json have all of their fields marked dirty
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 should possibly be some sort of higher level
> mechanism that I can use to indicate that this is the case?
>
> -harryh
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Accessing innerHTML during bind?
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, 2010, at 10:28 AM, Tim Maxwell wrote:
> Hi David,
>
> There really are a lot of paths available with scala/lift, aren't
> there?
>
> After looking at what you wrote, here's what I came up with that works
> well/is functional and compact, in case anyone else is wondering about
> it.
>
> def links(html:NodeSeq): NodeSeq={
>
>Product.findActive.foldLeft(html) {
> (html, prod) => bind("links",html,
>"force_"+prod.product ->{x:NodeSeq => { product="+prod.product}>{x}}}
> )
>}
> }
>
> Product is a JPA entity class, findactive returns a list of products.
>
> If anyone has suggestions, please share.
>
> Cheers,
> Tim
>
> On Feb 3, 5:08 pm, David Pollak wrote:
>> On Wed, Feb 3, 2010 at 12:44 PM, Tim Maxwell wrote:
>>> Hi folks,
>>
>>> I am trying to do binds based on a list of products. The point is to
>>> create links that can be wrapped around existing text or images.
>>> Something like this:
>>
>>> This is the link text our marketing dept.
>>> creates
>>
>>> Here's what I have so far in the snippet related to it:
>>
>>> def links(html:NodeSeq): NodeSeq={
>>
>>>val productBinds:Seq[BindParam] = Product.findActive.flatMap{
>>> prod => List[BindParam] ( TheBindParam( "force_"+prod.product,
>>> SHtml.link("/forced?product="+prod.product, ()=>() , _ ) ) )
>>>}
>>>bind("links" , html, productBinds: _*)
>>
>> It's so cool to see how people stuff in Lift...
>>
>> Within your function, you can get the element that's being bound with:
>>
>> BindHelpers.currentNode: Box[Elem]
>>
>> On the other hand, if you're looking to get the children of the node
>> currently being bound:
>>
>> FuncBindParam("force_"+prod.product, body => > href={"/forced?product="+Helpers.urlEncode(prod.product)}>{body})
>>
>> Hope this helps.
>>
>> Thanks,
>>
>> David
>>
>>
>>
>>
>>
>>> }
>>
>>> Cheers,
>>> Tim
>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Lift" group.
>>> To post to this group, send email to lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> liftweb+unsubscr...@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
>> Follow me:http://twitter.com/dpp
>> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] S.params disappear?
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 6 on the server, and when I
> do, suddenly it won't work.
>
> The issue is with the S.params. I have a form that submits via an Ajax PUT
> request. The params are sent in the header just fine. As I said, works
> like a charm on Jetty. But when it gets to Tomcat, the entity is saved
> with blank attributes... i.e., everything worked but the
> S.param("whatever") showed up blank. I tested this by doing
> S.param("whatever").openOr("Phooey") and, indeed, that attribute was set
> to "Phooey" on the new entity.
>
> Tomcat issue? Or am I missing something obvious? This form is running on a
> subdomain, so that's where I'm looking now (in server.xml).
>
> TIA,
> Chas.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Prevent leaving page if unsaved
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 links!
>
> -
> Timothy Perrett wrote:
>
> Try:
>
> window.onbeforeunload = function(evt){
>var reply= "You have unsaved changes!";
>if(typeof evt == 'undefined'){
> evt = window.event;
>}
>if(evt){
> evt.returnValue = reply;
>}
>return reply;
> }
>
> Cheers, Tim
>
>
> On 2 Feb 2010, at 18:31, Naftoli Gugenheim wrote:
>
>> Hi, in Lift how would one implement functionality similar to in Gmail, that
>> when you try to navigate away from an unsaved email you get a dialog box
>> asking to confirm?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://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 lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Prevent leaving page if unsaved
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, in Lift how would one implement functionality similar to in Gmail, that
> when you try to navigate away from an unsaved email you get a dialog box
> asking to confirm?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] lift-couchdb
Thanks! can you throw a ship it on the issue306 RB request for documentation purposes? Also, if you feel like reviewing issue305 which it depends on while you're there... ;-) -Ross On Jan 31, 2010, at 6:56 AM, Timothy Perrett wrote: Ross, I've just got back from Italy... taken a look at your code and it looks good to me. Go for it :) Cheers, Tim On 25 Jan 2010, at 19:24, David Pollak wrote: Ross, Thanks for this contribution!! I don't have the bandwidth to review it but would encourage folks from the community to take a gander at the code and give you feedback. Thanks, David On Sun, Jan 24, 2010 at 4:06 PM, Ross Mellgren 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 which is a Record implementation that emits/consumes lift-json AST, and CouchRecord extends that with database access - added Optional versions of every basic record field, to represent nullable/optional fields - Uses box much more extensively, rather than exceptions - More tests - Changed the querying from using case class varargs (QueryParam) to using methods on a Queryable trait - Removed use of toJObject and other exception-ful conversions from JValue to JObject - Tests will automatically skip if Couch is not running locally As far as I'm currently aware, the only missing things are: - the unit tests don't exercise every type of JSONField, other than indirectly via the CouchRecord tests - the unit tests don't exercise every one of the Queryable params I'd like to begin the process of getting this into master, so if some folks could review it and comment I would be very appreciative. In particular, I'd like it if some familiar with record could take a gander at the Optional versions I've added and vet them. Barring anyone noticing wrong with it, I'll create some issues and put the changes up on review board in a couple days. The branch: http://github.com/dpp/liftweb/tree/rmm_wip_couch lift-couchdb as a diff: 51724dcd09f68c658ffc025ded14fe7d22f888fb Optional fields in record: 7bb10ac78f83222b2f1f09e986466a0c4edcca64 Comments? Suggestions? Scathing rebuttals? -Ross -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en . -- 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 -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com . For more options, visit this group at http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com . For more options, visit this group at http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
