[Lift] Re: MappedLong & null values
It would be nice if there could be a generalized way of specifying optionality for fields.(The first though question is whether the default behavior is consistent -- do all field types equate NULL with their default?) I pasted the names of all the field types (by listing all Mapped*.class files in target/classes/net/liftweb/mapper). For which of them does it make sense to have optionality, which of them do, and would it make sense to have a trait to mix in or some other consistent way to allow nullablility? MappedBinary, MappedBirthYear, MappedBoolean, MappedCountry, MappedDate, MappedDateTime, MappedDecimal, MappedDouble, MappedEmail, MappedEnum, MappedEnumList, MappedFakeClob, MappedForeignKey, MappedGender, MappedInt, MappedIntIndex, MappedLocale, MappedLong, MappedLongForeignKey, MappedLongIndex, MappedPassword, MappedPoliteString, MappedPostalCode, MappedString, MappedStringForeignKey, MappedStringIndex, MappedText, MappedTextarea, MappedTime, MappedTimeZone, MappedUniqueId On Wed, Oct 7, 2009 at 4:36 PM, David Pollak wrote: > > > On Wed, Oct 7, 2009 at 12:55 PM, harryh wrote: > >> >> I have a long field in my database that I want to have a unique index >> (enforced by the database). Sometimes this field will be empty, in >> which case I'd like to set it to NULL. 0 won't work because that >> won't work with the unique index. >> >> MappedLong appears to be converting null to 0 internally. >> Additionally overriding defaultValue for the field and returning null >> does not appear to work. >> >> Is this by design? > > > Yes. > > >> Is it possible that I am misunderstanding something >> here? >> > > I think you're looking for a MappedOptLong which will treat None (or Empty) > as NULL and Some(Long) as the value. > > Please open a ticket and I'll add the code. > >> >> -harryh >> >> >> > > > -- > 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 liftweb@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: Use lift1.0 or 1.1 or 1.x to create a stable and large site(project) ?
I used this command to create my project and was successfully. mvn archetype:generate -U -DarchetypeGroupId=net.liftweb - DarchetypeArtifactId=lift-archetype-blank -DarchetypeVersion=1.1-M6 -DgroupId=demo.helloworld -DartifactId=helloworld2 - Dversion=1.1-M6 If i use the 1.1-SNAPSHOT, some errors occur. [INFO] The desired archetype does not exist (net.liftweb:lift- archetype-blank:1.1-SNAPSHOT) Cheers, Neil On Oct 9, 9:32 pm, David Pollak wrote: > I use Lift 1.1-SNAPSHOT on all the sites I work on (that's currently at 7). > There's rarely breakage on SNAPSHOT. > > > > On Fri, Oct 9, 2009 at 3:01 AM, Neil.Lv wrote: > > > Hi liftweb, > > > Is anyone has used lift to create a stable and large site ? If i > > want to create this site which version that is suit, > > > lift1.0 or higher version. > > > If someone knows the site that develop by lift or has used lift to > > create a site, could you give me some ideas? > > > Thanks very much! > > > Cheers, > > Neil > > -- > 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 liftweb@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: Dynamic SiteMap
Marius- Thanks for your help on this. I guess I'm not sure how this differs from the current conception of the If LocParam. As I understand it, it is checked when determining what to display on the Menu as well as when a User attempts to access the page (or its subdirectory if passing a pair). If this is true, then I think there is no need to reinvent the wheel per se. Assuming I'm right and we can use If's to accomplish this functionality, I can follow up this query with an implementation based question. Specifically, since both of my user types extend MegaProtoUser, I end up with loggedIn_? function that tells if some user is logged in, but is confused about which. So if a user of type 1 logs in and I call UserType2.loggedIn_?, it will also return true. Is there a way to check for this in If statements? Or is it necessary to override loggedIn_? (which I've been trying, but has been pretty slow going so far). Thanks Dave On Oct 11, 12:36 pm, "marius d." wrote: > Yes, a Loc accepts many LocParams ... as I said above If/Unless/Test > would be used in conjunction with CondHidden to also provide > accessibility constraints. > > Here is the definition > > case object CondHidden(test: () => Boolean) extends LocParam > > but we also have case class If(test: () => Boolean, failMsg: FailMsg) > extends LocParam > > So the test function is the same which means that you essentially > implement one function and provide it to both LocParam's. We could > probably combine the two LocParams in a: > > IfHidden(test: () => Boolean, failMsg: FailMsg) // if you have a > better name please let me know :) > > The test function would be called in two cases: > > 1. When rendering the Menu to see is the Menu should be rendered or > not > 2. When try to access the location to as a security check > > I could probably add it this week and point you to my branch to check > it out. If I runt into something weird that I cannot foresee I'll let > you know. > > Would this work for you? > > Other people are welcome to comment as well ... > > Br's, > Marius > > On Oct 11, 7:06 pm, Dave wrote: > > > > > Hi Marius, > > > Thanks for the response. The LocParam is a good idea, but here is the > > attendant problem. No only do I have to hide options A,B,C from user > > type 2, I have to make sure user type 2 does not access those pages/ > > areas. Can I include that in the locParam as well? Right now, I'm > > using an If() val to determine what type of user it is, and then > > funnel accordingly. I assume i can just include both the if (to > > determine access/where to send) and then the conditional hider > > LocParam if necessary. But can I bundle both into a more DRY solution? > > > Thanks, > > > Dave > > > On Oct 11, 2:54 am, "marius d." wrote: > > > > So doesn't what I described about help you? ... a conditional Hidden > > > LocParam? ...thus the SiteMap contains all A, B, C, D, E, F menus but > > > for user type 1 D, E,, F are hidden, and for user type 2 A, B, C are > > > hidden. The decision would done in the function that you provide to > > > CondHidden. > > > > If this helps the new LocParam could be added with not much problems. > > > > If this doesn't work for you, please elaborate. > > > > Br's, > > > Marius > > > > On Oct 11, 2:09 am, Dave wrote: > > > > > Hi all- > > > > > I am interested in a similar question. I have two types of users and > > > > once logged in, I'd like to provide them with distinct menu options. > > > > For instance User type one would have a menu with A / B / C and User > > > > Type Two would have D / E / F. I have tried a variety of approaches > > > > including storing a session variable when the user first logs in, but > > > > because the sitemap is already built, its tough to modify > > > > dynamically. Further, unfortunately, User1.sitemap and User2.sitemap > > > > don't play well together, and only one should be shown at one time > > > > depending on the user type. Not to take away from Markus' question, > > > > but if someone could address this more concrete scenario, it would be > > > > much appreciated. > > > > > Thanks, > > > > Dave > > > > > On Oct 10, 5:09 pm, "marius d." wrote: > > > > > > Well SiteMap is per LiftRules which means it's per application > > > > > runtime. One approach would be to define the entire SiteMap but > > > > > depending on the context using some conditional Hidden LocParam. > > > > > Perhaps something like: > > > > > > case object CondHidden(coond: () => Boolean) extends LocParam > > > > > > This could be used in conjunction with If/Unless/Test LocParam-s to > > > > > also grant access per context (even if the Loc is Hidden) > > > > > > This probably won't suffice if you want each user to have its own > > > > > unique SiteMap. Can you elaborate more on your application > > > > > usecase? ... in what way you want unique SiteMap per user? > > > > > > Other option would be to have in LiftRules something like: > > > > > > val sessionSiteMap: (LiftSession) =
[Lift] Re: Lift UVP's
>From an outsider: Comet/Actors was a big draw for me to Lift. As I learned more, the view-first philosophy began becoming very helpful. In addition, it offers an insanely powerful session state API. It is also secure by default, offering many features that would be a pain to retrofit into a system. The component oriented views/templates and no-single-controller philosophy is also a major win. IMO it, along with Nitrogen may be the only major framework to actually offer true modularization. It was these and other benefits that lured me *despite* its integration with the existing JEE infrastructure. Coming from a functional and c++ background, Lift's association with Java was a detriment in my eyes. I am know that there are others like me, and, depending on the audience, it may need to be addressed. Just my two cents. Good luck with your talk! On Sun, Oct 11, 2009 at 5:37 PM, Timothy Perrett wrote: > > Guys, > > In about a month im speaking at a fairly sizeable event in Belgium and > wanted to ask a few questions about what users see at Lift's unique > value proposition. I did a talk about lift at a bar-camp recently and > whilst they were fairly well received, I think i still assumed too > much information. To that end, I thought by focusing on some of lifts > super cool features in a broad way I would then aim to give people a > better overview / warm fuzzy feeling about Lift in the allotted hour. > > So what are Lift's UVP's? My list looks a little like: > > - OOTB Comet (probably what draws most people to lift) > - View first / code free templating > - Utilisation of existing JEE infrastructure (WARs, JPA etc) > - Non-perscriptive but highly configurable framework > > Then we also have some stuff that we inherit from scala: > > - traits > - concise but type safe code > - etc etc etc > > What do people think? I have an hour to make people feel good about > Lift and hopefully give them enough of a taste to go away and try it > later - am i missing anything blindingly obvious? This isnt a hard and > fast outline of my preso, just trying to kick around some thoughts and > ideas :-) > > Cheers, Tim > > > --~--~-~--~~~---~--~~ 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 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: PayPal Subscriptions
Ryan,
I have pushed the code to master so give it a couple of hours and
Hudson should automatically start pulling those changes into 1.1-
SNAPSHOT JARs for you. Alternatively do a pull and build locally.
Cheers, Tim
On 10 Oct 2009, at 01:38, Timothy Perrett wrote:
>
> Ryan,
>
> Ignore my last email please - i've just tested the change using the
> IPN simulator and it now handles the Cancel message properly by
> passing Empty.
>
> The change is on my branch here:
>
> http://github.com/dpp/liftweb/commit/451dd3cb97e562a063da5cfe046badf1f9d8ad4c
>
> Cheers, Tim
>
> On Oct 10, 1:05 am, Timothy Perrett wrote:
>> Ryan,
>>
>> Looking at it, the strange thing is actually why it compiles now, not
>> why it doesn't compile with the change you suggested.
>>
>> Given:
>>
>> for (info <- buildInfo(resp, r);
>> // stat is going to be a Box[PaypalTransactionStatus.Value] anyway
>> // because of L489.
>> stat <- info.paymentStatus) yield {
>> actions((stat, info, r))
>> true
>>
>> }
>>
>> So, it appears that adding the Box[] to the partial function
>> definition would just make the type exactly right. Im starting to
>> write some mock tests etc as this is going to need testing
>> programatically.
>>
>> More to come soon.
>>
>> Cheers, Tim
>>
>> On Oct 9, 7:03 pm, Ryan Donahue wrote:
>>
>>
>>
>>> Here's a diff showing the changes I made. Notice I added a case
>>> to the
>>> SimplePaypal.actions method that I'd think would fail compilation
>>> but does
>>> not.
>>
>>> On Fri, Oct 9, 2009 at 1:08 PM, Ryan Donahue
>>> wrote:
Well, I am a scala newb, but I know maven all too well. I ran
"mvn clean
install" from the lift-paypal dir to install lift-paypal-1.1-
SNAPSHOT.jar to
my local repo.
>>
To be sure, I changed the signature as follows which does cause
errors:
def actions: PartialFunction[(PayPalInfo, Req), Unit]
>>
Change back to def actions:
PartialFunction[(Box[PaypalTransactionStatus.value], PayPalInfo,
Req), Unit]
and no errors.
>>
On Fri, Oct 9, 2009 at 12:35 PM, Timothy Perrett
wrote:
>>
> Hey Ryan,
>>
> How *exactly* did you locally do the build? If you had done the
> install of your altered lift-paypal then you would certainly get a
> compile error because the signature has changed. The new syntax
> should
> be:
>>
> object MyIPN extends PaypalIPN {
> def actions = {
>case (Full(CompletedPayment), info, req) => // do something
> }
> }
>>
> The only exclusion would be if you had a implicit conversion to
> Box
> PaypalTransactionStatus types that were unboxed.
>>
> Cheers, Tim
>>
> On Oct 9, 3:46 pm, Ryan Donahue wrote:
>> Tim,
>>
>> I locally changed the PaypalIPN.actions method return type to
>> trait PaypalIPN {
>> def actions: PartialFunction[(Box
>> [PaypalTransactionStatus.Value],
>> PayPalInfo, Req), Unit]
>>
>> }
>>
>> Apparently this does not cause any compilation errors for user
>> implementing their own IPN handler as follows
>> object MyIPN extends PaypalIPN {
>> import PaypalTransactionStatus._
>> def actions = {
>> case (CompletedPayment, info, req) => // do something
>> }
>>
>> }
>>
>> This is not good since I assume the result is that the case won't
>> match anymore but we won't have a compilation error to tell us to
>> change our code. Maybe I missed something, I am a scala
>> newbie :)
>>
>> -Ryan
>>
>> On Oct 8, 3:57 pm, Timothy Perrett
>> wrote:
>>
>>> Ok cool, I'll take a look at this tomrrow all being well.
>>
>>> Thanks for the feedback
>>
>>> Cheers, Tim
>>
>>> Sent from my iPhone
>>
>>> On 8 Oct 2009, at 20:43, Ryan Donahue
>>> wrote:
>>
I created the ticket:http://github.com/dpp/liftweb/issues/
#issue/88
>>
I do receive the payment_status field for PDT. I bet in
practice
you will never receive a payment_status value other than
Completed,
>>
because if the payment was not completed PayPal would not
redirect
the user's browser back to your PDT URL. However, I have not
verified this and do check the payment status in my PDT code
anyway
>>
(how could I verify that it will never happen?). So I would
prefer
>>
that both were consistent, but just boxing the IPN payment
status
will be fine too :)
>>
On Thu, Oct 8, 2009 at 2:49 PM, Timothy Perrett
> wrote:
Im not married to the current API, so breaking changes are OK
as
there are only a handful of people using this code right now.
>>
To be honest, this whole situation just underlines the need for
mocking in this module of lift... i've been meaning to do it
since
the beginning but just never got
[Lift] Lift UVP's
Guys, In about a month im speaking at a fairly sizeable event in Belgium and wanted to ask a few questions about what users see at Lift's unique value proposition. I did a talk about lift at a bar-camp recently and whilst they were fairly well received, I think i still assumed too much information. To that end, I thought by focusing on some of lifts super cool features in a broad way I would then aim to give people a better overview / warm fuzzy feeling about Lift in the allotted hour. So what are Lift's UVP's? My list looks a little like: - OOTB Comet (probably what draws most people to lift) - View first / code free templating - Utilisation of existing JEE infrastructure (WARs, JPA etc) - Non-perscriptive but highly configurable framework Then we also have some stuff that we inherit from scala: - traits - concise but type safe code - etc etc etc What do people think? I have an hour to make people feel good about Lift and hopefully give them enough of a taste to go away and try it later - am i missing anything blindingly obvious? This isnt a hard and fast outline of my preso, just trying to kick around some thoughts and ideas :-) Cheers, Tim --~--~-~--~~~---~--~~ 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 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: Script merge similar to head merge?
Interesting feature request. Please open a ticket for it at http://github.com/dpp/liftweb/issues On Sun, Oct 11, 2009 at 3:06 AM, Eros Candelaresi wrote: > Hi group, > > for a project I am working on interactive forms, i.e. fields > appear/disappear/enable/disable based on the user input in other fields. > Everything is heavily JavaScript event based, so I am currently writing a > small library that simplifies the task of binding JS events and composing > event handlers. My library follows a component based approach, so there is a > component for text input fields, for dropdowns, etc. Each component is able > to create its own HTML and JS code. > > And now here is my problem: every component ends up with its own > section in the HTML output (see example below). Although this is not a real > problem it's still rather ugly. One solution could be to have a JS manager > object that collects all JS from the input components and creates one single >