[Lift] Converting a null String to an empty String
Hi, I am pretty sure there is a method somewhere converting a null String to an empty String. But I have not found it yet ... Thanks, 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.
Re: [Lift] Converting a null String to an empty String
On 9 March 2010 16:48, David Pollak feeder.of.the.be...@gmail.com wrote: Can you be a little more specific? Sure ;-) I am looking for a method like this: def stringNullTest(s: String): String = if (s != null) s else Of course I could roll my own, but if it is already around (e.g. in StringHelpers) I would use it from there. 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] Re: Converting a null String to an empty String
On Tuesday, March 9, 2010, Timothy Perrett timo...@getintheloop.eu wrote: how about: def stringTest(x: String): String = Box !! x openOr Looks great, especially for a one-handed-writer ;-) Heiko Cheers, Tim On 9 Mar 2010, at 17:30, Heiko Seeberger wrote: On 9 March 2010 16:48, David Pollak feeder.of.the.be...@gmail.com wrote: Can you be a little more specific? Sure ;-)I am looking for a method like this:def stringNullTest(s: String): String = if (s != null) s else Of course I could roll my own, but if it is already around (e.g. in StringHelpers) I would use it from there. Heiko Company: weiglewilczek.com http://weiglewilczek.com/ Blog: heikoseeberger.name http://heikoseeberger.name/ Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org http://scalamodules.org/ Lift, the simply functional web framework: liftweb.net http://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. -- 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.
Re: [Lift] Js normalizations
On 7 March 2010 19:37, Marius marius.dan...@gmail.com wrote: If you think that this makes sense I'll add a ticket and put it in my backlog. Makes a lot of sense for me. Go for it! 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.
Re: [Lift] Re: non snapshot version of lift for scala 2.8
On 4 March 2010 15:36, Lukasz Kuczera kuk...@gmail.com wrote: I'm developing blog app on 280 and so far no problems yet. I am doing payed development on Scala 2.8 and it works ;-) 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] Re: Snippets in subpackages?
Yep, that would help a lot! Heiko On Wednesday, March 3, 2010, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Mar 2, 2010 at 11:42 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: On 3 March 2010 00:03, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Mar 2, 2010 at 1:05 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Hi, Isn't it possible to put snippets in subpackages of xxx.snippet?Something like lift:snippet type=com.acme.snippet.subpackage.SnippetClass? 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.
Re: [Lift] Re: Is CometActor the right tool for this job?
On 2 March 2010 15:09, ced docpom...@googlemail.com wrote:
3) How do I get access to the CometActor instance on the page? I need
to send a message to it from a function bound to e.g. an ajaxSelect
You need another Actor that dispatches messages to your CometActors.
Say you have ChartCometActor, then implement something like
object ChartManager extends Actor {
...
}
where all your CharCometActors register at creation time. Override
localSetup() for this. Also override localShutdown() to unregister.
Your snippet function then sends a message to the ChartManager who's
responsible for dispatching to all/one actor/s. I use a solution where
I register the CometActors an a session basis, so I can send a message
either to all or just one CometActor.
Or use
object ChartServer extends LiftActor with ListenerManager {
...
override def lowPriority = {
case ... = {
...
updateListeners()
}
}
}
and
class ChartActor extends CometActor with CometListener {
override def registerWith = ChartServer
// Only necessary if you do not want to send the message to all comet
actors
override def shouldUpdate = {
case ... = // Decide whether this instance should receive a message
}
}
Look at http://github.com/weiglewilczek/chatter for a full blown example.
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] Snippets in subpackages?
Hi, Isn't it possible to put snippets in subpackages of xxx.snippet? Something like lift:snippet type=com.acme.snippet.subpackage.SnippetClass? If not, what's the best way to deal with a large number of snippets? 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.
Re: [Lift] Snippets in subpackages?
On 3 March 2010 00:03, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Mar 2, 2010 at 1:05 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Hi, Isn't it possible to put snippets in subpackages of xxx.snippet? Something like lift:snippet type=com.acme.snippet.subpackage.SnippetClass? 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. 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.
Re: [Lift] Happy 3rd Anniversary to Lift
I am proud to be on board and looking forward to the next three years Heiko On Saturday, February 27, 2010, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Today is Lift's 3rd Anniversary/Birthday! Before I go offline for the weekend, I wanted to give a hearty thanks for the Scala team, the Scala community, the Lift committers, and most importantly the Lift community members new and old for making Lift possible, fun, and challenging. Thank you all very, very much for everything each and everyone one of you has done. 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. -- 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.
Re: [Lift] Logging, part 2
On 25 February 2010 10:23, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: 2) Initialize the logging backend What needs to be initialized? Wouldn't auto initialization be nice? 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.
Re: [Lift] Reasoning Behind Box
Daniel, I would like to look at this question from a solution oriented perspective: Certainly you already noticed the third Box subtype Failure and are aware of its usage. I agree with you, that Option vs Box is confusing for Lift (and nowadays Goat Rodeo) adopters. As Scala and Lift are still very young adoption is vital and hence I would like to know, what you suggest: How could we only use Option *and* get something like Failure? Any ideas? Heiko On 26 February 2010 05:40, Daniel Spiewak djspie...@gmail.com wrote: I'm sure this has been discussed before, but I'm curious as to the rationale for the Box ADT. I'm most distressed by the fact that it seems to be masquerading as a drop-in Option replacement, and yet the mathematical properties of the ADT are widely divergent. What's more, the API is very, very different, leading to a great deal of confusion whenever I'm working with code which touches both ADTs (as I often do). Things like `or` vs `orElse`, `open_!` vs `get` and so on are very confusing. The implicit conversion Box[A] = Option[A] doesn't help either, since it means I can easily forget and use Option methods on Box values, accidentally triggering a conversion. The whole `or` vs `orElse` thing is particularly annoying since I spend a fair amount of time wading through research which discusses the `orElse` function in its abstract monadic sense. Given the standard nature of the name (dating back long before Scala), I'm surprised that Box went with something else. I'm sure there are good reasons for all of this, I would just like to know what they are. :-) Daniel -- 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.comliftweb%2bunsubscr...@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.
Re: [Lift] Reasoning Behind Box
On 26 February 2010 08:09, Naftoli Gugenheim naftoli...@gmail.com wrote: Either -- but it's more verbose. I'm not so sure David will want to rewrite the entire lift anyway... Right now, I only would like to listen to Daniel, OK? 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.
Re: [Lift] [urgent] Master is fundamentally broken!!!!!!
On 24 February 2010 18:40, David Pollak feeder.of.the.be...@gmail.comwrote: In the case of Heiko's issue, it's already been reported by a Japanese user of Lift 280_port_refresh. The 2.8 libraries take an optional parameter for character set and default to the platform character set. We need a ticket on this issue with a repro case so we can build a test and build a fix. Fixed and on review board: http://reviewboard.liftweb.net/r/241/ 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.
Re: [Lift] Re: Tricky question regarding menus
Jeppe, Thanks for your answer! On 23 February 2010 08:47, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: I have the same scenario and it works for me. In the parent menu I do this: Menu(Loc(parent, List(parent, index), Parent, Loc.EarlyResponse(() = Full(RedirectResponse(/subpage We're using our own menu snippet and I can't recall if this was one of the things we changed :-( Your solution solves one problem: Clicking the parent leads to the child. But the other problem still exists: doesMatch_? will not return true for the parent and hence the parent menu will not be treated special (different style, no link). Heiko 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.
Re: [Lift] Re: Tricky question regarding menus
On 23 February 2010 15:24, Heiko Seeberger heiko.seeber...@googlemail.comwrote: But the other problem still exists: doesMatch_? will not return true for the parent and hence the parent menu will not be treated special (different style, no link). Using a custom menu snippet solves the problem. Thanks! Heiko 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.
Re: [Lift] Re: Setting run mode for Lift applications
On 22 February 2010 09:20, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: The default would still be the current lookup in system properties, but you could change this to look at servlet params, hostname, day of month etc :-) Ah, OK. I agree if and only you will also enable setting the run mode depending on the beer-level of the deployer ;-) Heiko 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.
Re: [Lift] Re: Setting run mode for Lift applications
On 22 February 2010 10:52, Indrajit Raychaudhuri indraj...@gmail.comwrote: Given that setting initParams is the usual webapp idiom, should we not consider that at all? That would have served the purpose for Petr. customRunMode or context.initParam(run.mode) or Box.!!(System.getProperty(run.mode)) with provision for having customRunMode customized heartily. Looks good! Heiko 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.
[Lift] Tricky question regarding menus
Hi, I want to create a menu with the following structure: main1 main2 main3... sub1a sub1b sub2a sub2b sub3a ... page1a1 page1a2 ... Now I want some of the main and sub menus not to have their own pages but have the same link as certain child pages. Example: When the user clicks main1 the page page1a1 is to be shown. Of course main1 and sub1a are to be marked as currently selected menu, hence Loc.doesMatch_? must return true. If I create the Locs for main1 and sub1a with the link to page1a1 (main1/sub1a/paga1a1) then doesMatch_? will not be true for all other child pages of main1 and sub1a. Is there a simple solution to this? Or do I have to write my own Loc implementation? Thank you, 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.
Re: [Lift] Welcome John De Goes as a Lift committer
Hi John ;-) On 22 February 2010 21:55, David Pollak feeder.of.the.be...@gmail.comwrote: 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- 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.
[Lift] Re: Tricky question regarding menus
Hi, Sorry for being pushy, but this one is really urgent. Maybe I did not describe my issue properly, so I will give it another and simpler try: I want a menu to link to a subpage, i.e. have the same link as one of its child menus. But the menu shall also be active for every other active child menu. Thank you, Heiko On 22 February 2010 15:15, Heiko Seeberger heiko.seeber...@googlemail.comwrote: Hi, I want to create a menu with the following structure: main1 main2 main3... sub1a sub1b sub2a sub2b sub3a ... page1a1 page1a2 ... Now I want some of the main and sub menus not to have their own pages but have the same link as certain child pages. Example: When the user clicks main1 the page page1a1 is to be shown. Of course main1 and sub1a are to be marked as currently selected menu, hence Loc.doesMatch_? must return true. If I create the Locs for main1 and sub1a with the link to page1a1 (main1/sub1a/paga1a1) then doesMatch_? will not be true for all other child pages of main1 and sub1a. Is there a simple solution to this? Or do I have to write my own Loc implementation? Thank you, 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.
Re: [Lift] Re: Setting run mode for Lift applications
Folks, I really do not understand the value of setting the run mode statically via code in LiftRules. The run mode should be set externally, right? In order to use the same artifact (WAR) on a dev or a prod server. Heiko On 22 February 2010 08:44, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: On Sun, Feb 21, 2010 at 2:19 AM, Timothy Perrett timo...@getintheloop.eu wrote: The former is a lift idiom that we use for everything configurable... Lets look into doing that. Jeppe: Are you willing to investigate this / take the lead? Yes. I've created https://www.assembla.com/spaces/liftweb/tickets/362-make-runmode-configurable-in-liftrules /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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- 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.
Re: [Lift] NOT IN subqueries?
On 17 February 2010 14:48, David Pollak feeder.of.the.be...@gmail.comwrote: On Tue, Feb 16, 2010 at 11:53 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Hi, Is there a way to create NOT IN subqueries with lift-mapper? Nope. Please open a ticket for 2.0-M3. I'll get it done next week unless you want to do it. Ticket is there: http://www.assembla.com/spaces/liftweb/tickets/353-add-notin-queryparam Heiko 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.
[Lift]
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 -- 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] autocrlf issue?
Sorry, forgot the subject ... On Wednesday, February 17, 2010, Heiko Seeberger heiko.seeber...@googlemail.com 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.
[Lift] Re: autocrlf issue?
Sure, thanks. On Wednesday, February 17, 2010, Indrajit Raychaudhuri indraj...@gmail.com wrote: Heiko, Just remove core.autocrlf settings for now. You can add that back after I update the repo (and send out the notification). - Indrajit On 17/02/10 8:16 PM, Heiko Seeberger wrote: Sorry, forgot the subject ... On Wednesday, February 17, 2010, Heiko Seeberger heiko.seeber...@googlemail.com 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 -- 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 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.
[Lift] NOT IN subqueries?
Hi, Is there a way to create NOT IN subqueries with lift-mapper? Heiko 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.
Re: [Lift] New logging code
On 14 February 2010 20:10, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Makes sense, and that was actually close to what I had initially: The Logger trait was called LiftLogger, but this clashed with the current LiftLogger. This name (Logger in current code) probably doesn't matter too much as it's usually not needed in client code. But AbstractLogger doesn't sound very nice :-) Even if (probably) not needed, we should try to name it the best possible way. Changing now causes no pain at all, but later ... you know. Heiko 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.
Re: [Lift] New logging code
On 15 February 2010 09:45, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Even if (probably) not needed, we should try to name it the best possible way. Changing now causes no pain at all, but later ... you know. Agreed. Suggestions? I already made mine, just to make sure everyone has a chance to see them: Like *Iterable* and *Iterator* lets call the trait that offers the logging methods (info, warn, etc.) *Logger* and the trait that gives access to a * Logger* should be called *Loggable*. Heiko 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.
Re: [Lift] New logging code
On 14 February 2010 14:40, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
Hi,
I've tried to keep it as simple as possible, really just a Scala layer
on top of the SLF4J api.
I think that's a very good decision!
Note that no backend (log4j or logback) configuration is included. This
has to go into lift-util to use runmode etc.
You can have your choice of a nested logger:
object MyObj extends Logging {
logger.info(nested Hello)
}
or direct access:
object MyObj extends Loggable {
info(direct Hello)
}
Thoughts?
I really like to have Logging and Loggable, but I would call them vice versa
and change Logging to Logger. As an example think of Iterable and Iterator.
In general an Xable gives you access to an X. Hence we should have Loggable
with a method logger that returns a Logger and we should have Logger to mix
in all the logging methods. Why change from Logging to Logger? Because we
should call it what it is, not what it does.
Cheers,
Heiko
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.
[Lift] Test whether a Loc is a child of another Loc
Hi, I would like to know what's the easiest way to test whether a Loc is a child of another Loc. Which means, that the path to the first Loc contains the path to the second one, e.g. myapp/login and myapp/login/signup. Thank you! 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.
[Lift] Re: Test whether a Loc is a child of another Loc
On 11 February 2010 19:00, Heiko Seeberger heiko.seeber...@googlemail.comwrote: Hi, I would like to know what's the easiest way to test whether a Loc is a child of another Loc. Which means, that the path to the first Loc contains the path to the second one, e.g. myapp/login and myapp/login/signup. OK, I came up myself with this simple solution: loc.link isDefinedAt req Heiko 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.
Re: [Lift] Logging changes
On 12 February 2010 05:56, David Pollak feeder.of.the.be...@gmail.comwrote: How about a different approach? How about a new logging system in common that takes the best of the existing logging system plus a bunch of enhancements? Are you thinking of something that could also be used standalone, i.e. outside of Lift? That would be great! Heiko 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.
[Lift] Question regarding menus
Hi, Menu.builder renders the current menu item different than the other menu items and there is the possibility to use a different CSS class. Am I right, that Menu.group does not offer this? If not, are there any other existing possibilities? Thanks, Heiko 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.
[Lift] Submit form on enter in textarea
Hi folks, this time *with* body and hopefully quite understandable: What's the most clever way to submit a (AJAX)form when ENTER is hit in a textarea? Thanks, 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 -- 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] Are there Maven artifacts for snapshot or milestone releases?
-- 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.
[Lift] Re: Are there Maven artifacts for snapshot or milestone releases?
Are there Maven *archetypes* for snapshot or milestone releases? Heiko On Sunday, February 7, 2010, Timothy Perrett timo...@getintheloop.eu wrote: Would be nice if you could have written an email body - subject only emails bug the ass out of me ;-) You mean like: http://scala-tools.org/repo-snapshots/net/liftweb/ or the hudson builds into nexus? Otherwise, you'll have to clarify exactly what your asking (herewith the problem with subject-only emails! - grumble grumble grumble) Cheers, Tim On Feb 7, 4:17 pm, Heiko Seeberger heiko.seeber...@googlemail.com wrote: -- 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. -- 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.
Re: [Lift] Re: Are there Maven artifacts for snapshot or milestone releases?
Sorry guys, tonight I seem unable to ask precise questions. What I would like to know: Is it possible to get snapshot or milestone archetypes from an archetype catalog? I tried scala-tools.org, but found only version 1.0 of archetype-basic. Is there another catalog containing 2.0 milestones or snapshots? Thank you! Heiko On 7 February 2010 22:10, David Pollak feeder.of.the.be...@gmail.comwrote: On Sun, Feb 7, 2010 at 10:43 AM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Are there Maven *archetypes* for snapshot or milestone releases? There are archetypes generated for both snapshot and milestone releases. See http://scala-tools.org/repo-snapshots/net/liftweb/lift-archetype-basic/ Heiko On Sunday, February 7, 2010, Timothy Perrett timo...@getintheloop.eu wrote: Would be nice if you could have written an email body - subject only emails bug the ass out of me ;-) You mean like: http://scala-tools.org/repo-snapshots/net/liftweb/ or the hudson builds into nexus? Otherwise, you'll have to clarify exactly what your asking (herewith the problem with subject-only emails! - grumble grumble grumble) Cheers, Tim On Feb 7, 4:17 pm, Heiko Seeberger heiko.seeber...@googlemail.com wrote: -- 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- 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.comliftweb%2bunsubscr...@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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- 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.
Re: [Lift] Re: OSGi example, what to do to make it run?
Philip, 2010/2/6 philip philip14...@gmail.com Why do I want to do that? I am making a code generator which generates Scala code, I want the user to be able to try out the Scala code. So some liftweb method would generate a .scala file and another would package it into a OSGi and load the OSGi. OSGi offers so much more than installing/updating bundles at runtime: There is dependency management, versioning, services, etc. But you have to pay a price for all these features = Constraints and complexity. I do not think you need to pay that price: Just use the embedded Scala compiler or even the interpreter. Take a look at http://www.simplyscala.com, they might be doing something similar. Heiko 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.
Re: [Lift] Suggestion to extend Comet (ListenerManager) to selectively update subscribers
OK, its on RB (http://reviewboard.liftweb.net/r/206/) = Take a look ... Heiko On 5 February 2010 01:07, Timothy Perrett timo...@getintheloop.eu wrote: Probally helpful if you share your prototype code? Cheers, Tim Sent from my iPhone On 5 Feb 2010, at 00:05, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Hi, In the current state the ListenerManager will always update all subscribers. I have got a use case where only certain subscribers should be updated. Therefore I suggest to extend the ListenerManager such that there can be an optional partial function that determines which subscribers will be updated. This change will not break the current API and will not affect the default behavior. I have already implemented a prototype solution but would like to know your opinion first. So what do you think? Any objections up-front? Cheers, Heiko Work: http://weiglewilczek.comweiglewilczek.com Blog: http://heikoseeberger.nameheikoseeberger.name Follow me: http://twitter.com/hseebergertwitter.com/hseeberger OSGi on Scala: http://scalamodules.orgscalamodules.org Lift, the simply functional web framework: http://liftweb.netliftweb.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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- 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.
Re: [Lift] OSGi example, what to do to make it run?
OK ;-) This is what I answered to Martin so far: I do not know such a tutorial, sorry. OSGi offers hot deployment out of the box, hence you do not need any JRebel or so. But by default (according to the spec) each bundle must be a JAR, hence you need a full build cycle. Eclipse Equinox allows for hosted deployment of usual PDE projects. Currently Lift's OSGi support is constrained to single bundle (module) applications. Of course this is already beneficial, because all the dependencies (including lift-webkit etc.) are deployed as separate modules and therefore can be updated separately. Also it should be possible to deploy different Lift apps to one OSGi container. But on the long run I would like to see real modular Lift applications: Where one Lift app is made up from several bundles. Maybe some of them are installed later and contribute to the menus, the mapper etc. OSGi and JEE integration, namely web app integration, has been quiet for some time, but recently there seems to be some process. I am not sure whether the spec will deal with composite web apps: If not, we could pioneer in this field. Any ideas or questions? Heiko On 5 February 2010 18:18, David Pollak feeder.of.the.be...@gmail.comwrote: On Fri, Feb 5, 2010 at 9:06 AM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: On 5 February 2010 15:05, Martin Ellis ellis@gmail.com wrote: Any offers/suggestions? (Sorry, I realise the question more about OSGI than lift) Indeed, let's discuss this off-list ... Can you discuss it on-list? I'd like to learn. Heiko 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.comliftweb%2bunsubscr...@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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- 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.
Re: [Lift] Potential breakage: Choosing the default Lift logging backend
Hi, On 5 February 2010 22:11, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: 2) is the cleanest solution since the choice of logging backend is made explicit. But this requires people to change their poms in order to get any logging. Let's go for 2) because in real-world projects people will have to adjust the POM anyway. E.g. for persistence modules or for 3rd party libs. Heiko 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.
[Lift] Suggestion to extend Comet (ListenerManager) to selectively update subscribers
Hi, In the current state the ListenerManager will always update all subscribers. I have got a use case where only certain subscribers should be updated. Therefore I suggest to extend the ListenerManager such that there can be an optional partial function that determines which subscribers will be updated. This change will not break the current API and will not affect the default behavior. I have already implemented a prototype solution but would like to know your opinion first. So what do you think? Any objections up-front? Cheers, Heiko 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.
Re: [Lift] OSGi example, what to do to make it run?
Philip, Good to see some interest in Lift's OSGi support! Of course Lift will need a servlet container. Hence you will have to install one in your OSGi framework, too. The same accounts for all the dependencies, e.g. the Scala library. Heiko On Friday, February 5, 2010, philip philip14...@gmail.com wrote: Hi, I downloaded the git source and made a OSGi jar package by running the maven, now what do I do with it? I see its a jar file with the manifest for OSGi, I guess I can load it into Apache Felix, but doesn't Liftweb need tomcat or jetty to run? So I don't really understand how its going to run. Thanks, Philip -- 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 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.
[Lift] CometActor.fixedRender always below render?
Hi, It looks like the output from fixedRender is always placed below the one from render. Is there a way to change this? 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 -- 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: CometActor.fixedRender always below render?
On Wednesday, February 3, 2010, Marius marius.dan...@gmail.com wrote: Technically you could override : def toJavaScript(session: LiftSession, displayAll: Boolean): JsCmd from CometActor, but you'd probably loose important things that Lift does for you there. You could call super but I don't think that it would be very helpful. Perhaps we should add an easy way to allow this ... Would be nice, but I can live without :-) Heiko Br's, Marius On Feb 3, 5:15 pm, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Hi, It looks like the output from fixedRender is always placed below the one from render. Is there a way to change this? 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 -- 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 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.
Re: [Lift] Github issue browser
Cool! Did not know there is an API. Heiko On Wednesday, February 3, 2010, Naftoli Gugenheim naftoli...@gmail.com wrote: If anyone finds github's issue manager too limited, I made a teeny little app that lets you list the issues in a more configurable way. All comments welcome! http://github-issues.naftoligug.staxapps.net/index You do not need to log in or register. Right now it only browses issues for dpp/liftweb. Use the check boxes on top to filter tickets, click column headers to sort, and click 'more' or 'less' on a ticket to view its description. Enjoy! -- 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 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.
Re: [Lift] New ticketing system
On 28 January 2010 15:06, David Pollak feeder.of.the.be...@gmail.comwrote: I can host an instance. The big issue as I see it is have a reliable maintainer. In order to use LiftTicket, we need someone who is around most of the time (46+ weeks a year), can fix bugs in a few days, has a solid Internet connection, etc. If we can find a reliable maintainer, I'm all for moving forward with LiftTicket. I think this is (too) risky ... Heiko 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.
Re: [Lift] Always log through Slf4j?
No more APIs on top of APIs! slf4j is very OSGi friendly, by the way. If side effects are minimal, I vote for it. Heiko On Thursday, January 28, 2010, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Last logging question, I promise! I'm about to implement MDC in Lift's logging, but it seems more and more layers are introduced. So before adding another adapter on top of e.g. Slf4j which is already an adapter on top of e.g. logback I thought I would see if there are any objections to making Lift always log through Slf4j? There wouldn't be any API changes and Log4j could still be the default backend, with the config settings as we currently have, only there wouldn't be any Log4JLogger. On the positive side, Lift's logging is simpler: only interface to Slf4j (we would keep the log4j config stuff) Downside is two more jars if you're using log4j: slf4j-api slf4j-log4j12 Thoughts? /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. -- 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.
Re: [Lift] Lift logging improvements
+1 On Wednesday, January 27, 2010, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Hi, I was thinking about some improvements to Lift's logging code: 1) Make the slf4j logging configurable in the same way as log4j (ie with dev, prod logback files) 2) Add support for MDC to Lift's logging interface (and the log4j slf4j backends) 3) Add more logging to Lift :-) The last part may be a bit controversial, but I find logging statements immensely useful when trying to diagnose stuff that doesn't work or figure out how stuff works. If separate loggers are created for different areas (i.e mapper, comet, ajax, etc) it should be possible to turn the needed info on off without too much information overload. Performance wise it shouldn't matter much (famous last words :-) if logging is disabled. Thoughts? /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. -- 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.
Re: [Lift] Lift 2.0 on Scala 2.8 update
Awesome! Heiko On Sunday, January 24, 2010, Indrajit Raychaudhuri indraj...@gmail.com wrote: Folks, A quick update on Lift 2.0 build on Scala 2.8. Scala 2.8 port of Lift is available on the branch 280_port_refresh. This is a 'refresh'ed version of 280_port which is fully aligned and sync'ed with the master. To ensure minimal delta between the master and 280_port_refresh, the codebase in master has been adjusted considerably to improve Scala 2.8 compatibility. Thus, the master branch continues to be on Scala 2.7.7 but is lot more Scala 2.8 friendly now. In fact, most of the modules (and all the examples) build cleanly on both 2.7 and 2.8 without any change. Few additional points: 1. Those interested in playing with this branch can checkout from the 280_port_refresh and build locally. 2. A Hudson job for lift_280_refresh has been setup at http://hudson.scala-tools.org/view/Lift/job/lift-scala280/. For now, it just does internal build. In course of the week, Hudson would be setup to deploy the snapshots as well. 3. Scala 2.8 is binary incompatible with Scala 2.7. This means the additional scala libraries on which Lift depends also need to provide a Scala 2.8 build. Hopefully, there would be scalajpa and scalamodules-core build available in near term. For now, modules specifically dependent on them have been disabled. 4. Parts of the code which don't work on Scala 2.8 (broken, incompatible etc.) have been marked with FIXME: 280. Cheers, Indrajit -- 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 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.
Re: [Lift] Welcome Jeppe to the Lift committers
Howdy! On Friday, January 22, 2010, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Please join me in welcoming Jeppe as a Lift Committer. He's been helping people on the Lift list and contributing his thoughts to the Lift community for a while... now it's time for him to contribute code to Lift. Hooorraaayyy! 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. -- 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.
Re: [Lift] Mindless work...
I have time to do the mindless work of doing the port tonight (my brain will explode if it has to think, but mindless is okay). Sorry for the delay, but my night already started when you were having lunch ;-) - Heiko -- how far along is the stuff in issue 292? Is this code on the irc_issue_292 branch? Can I work on this branch tonight? Good question: Indrajit told me to relax, because he was already working on that. Let's ask him! David (who is very serious about making Lift on Scala 2.8 very successful) Very good! Heiko 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.
Re: [Lift] Welcome Mads Hartmann Jensen to the Lift Committers
Hi Mads! 2010/1/19 David Pollak feeder.of.the.be...@gmail.com Folks, Please join me in welcoming Mads to the Lift committers. 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- 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.
Re: [Lift] Re: Lift - GAE Version
2010/1/14 __kaveh__ kaveh.shahbaz...@gmail.com So for cases like many little web applications that concurrency is not an issue or for technologies like GAE; we should simply fall back to Java? NO! Go for Scala + Lift! Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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: **IMPORTANT** Lift 2.0 Milestone1 is coming and it's time to test the SNAPSHOT in master
Or will Lift support only ONE Scala version? Yes, Lift 2.0 will be for Scala 2.8 only. Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] 280_port builds against Scala 2.8 Beta1 RC7
David, 2010/1/8 David Pollak feeder.of.the.be...@gmail.com Did you smoke test the lift-examples/example app? Now I did ;-) Looks good. The reason I did not before is, that some modules and a lot of tests are commented out. So was lift-widgets which is a dependency of lift-examples/example. Now I fixed lift-widgets (there was only one little adjustment in a test case), added it to the build and then fixed the example app. Hence the statement Lift builds against 2.8 is only partially true, because a lot of things are not included. But I am optimistic that out coverage is large enough and we won't experience any severe issues when porting the rest. Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] 280_port builds against Scala 2.8 Beta1 RC7
2010/1/9 David Pollak feeder.of.the.be...@gmail.com Yeah... now that 2.8 Beta1 is out, we'll need to finish porting Lift over. *Once* 2.8 Beta 1 is out: IMHO we are at Beta1 RC7 and it will take another couple of days until we will see Beta1. Anyway, I'd be glad to help porting the rest. Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] 280_port builds against Scala 2.8 Beta1 RC7
2010/1/9 Indrajit Raychaudhuri indraj...@gmail.com How about taking the same strategy as last time (during scala 2.7.5 to 2.7.7)? Use Maven version classifier fot 2.8.0 build and create separate hudson job(s) for the purpose. Yep, let's do that! Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] 280_port builds against Scala 2.8 Beta1 RC7
-- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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: Minor breaking changes -- LiftRules.getResourceAsStream and LiftRules.finder
StreamManager[T] sounds cool to me. +1 Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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: WebSockets are Coming
I could start an experimental branch for all this. Yeah, go for it, man, go for it! Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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: [scala-internals] RC5 candidate for the first 2.8.0 beta
Martin, OK, now I got it working (almost) without Maven: 1. step: Check out 280_port branch from g...@github.com:dpp/liftweb.git 2. step: cd into liftweb/lift-persistence/lift-mapper and run mvn dependency:copy-dependencies 3. step: run the following command PATH-TO-SCALAC-OR-FSC-2.8-BETA1-RC5 -classpath `find target/dependency -name *.jar | xargs scala -e 'println(args mkString :)'` -sourcepath src/main/scala -d target/classes `find src/main/scala -name *.scala` This will only use Maven to download the dependencies, but you can compile with scalac or fsc. Heiko -- 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 Announce] **Important** Announcing the Lift 2.0 branch
Indrajit, Great to see the next refactoring round! I got the branch and there are a lot of oddities, e.g.: - All the POMs I looked at are still 1.1, not 2.0 - framework/pom.xml references module lift-archetypes and lift-examples - The parent POM is empty Maybe you did not update the branch on GitHub with your latest changes? Heiko 2009/12/20 Indrajit Raychaudhuri indraj...@gmail.com Okay Folks, Lift 2.0 branch has shaped up enough for everybody to play with. Checkout the branch irc_wip_lift20 and get going! Just be aware that it's still undergoing updated and changes incrementally and there are few rough edges. Key changes: 1. The project tree has been restructured according to the proposal sent out earlier [1]. To summarize, we now have three top level projects (framework, archetypes and examples) each with independent build life-cycle. There are other additional infra projects that are less to do with the actual code. A quick summary of the top-level projects: 1. Framework: The whole of Lift Framework that matter most to most. The usual modules (viz., lift-base, lift-persistence and lift-modules) have got nested within. Therefore, from now on, building Lift framework would mean just that. Doing a git pull or git clone as usual, changing to framework directory and running mvn install. 2. Archetypes: The standard distributed archetypes. The archetypes help you get quick started with a Lift based project. If you are not into building maven archetypes, you can stay clear of this. But a quick probe is welcome. 3. Examples: All the Lift examples are grouped into this project. If you are generally interested in learning different techniques from examples you don't have to build the whole of Lift anymore. Well that was still the case earlier, but now it's even more obvious. And it's true the other way round too, if you have to build Lift framework from source, you don't have to build the examples along with it. Another point: the examples won't be deployed on scala-tools maven repo anymore. Those war files up there serve no good purpose. Everything now gets neatly tucked into their respective homes :) Additional points that you should be aware of: A. Availability on scala-tools repository: - Components of framework would be available - Components of archetypes would be available - Components of examples would *not* be available B. Availability on scala-tools Maven site: Site generated from framework would be the main content of scala-tools Maven site. Depending on how things go, we might even have a home of it's own at http://dev.liftweb.net. (Separate proposal coming up) C. Lift Parent Project Model: The top level pom.xml has moved to it's own home at resources/project- model. This would stay as a 'flyweight' project (as in boxing, not GoF) on it's own that would strictly control the common behavior, plugin dependencies, versions etc. for all the top level projects (framework, archetypes, examples). This would be deployed on scala- tools repository. D. Lift Site Skin (WIP): I haven't started working on this yet. But the intent is to create a project site that is of some real value and serves as placeholder for mostly 'auto-generated' docs. See #B above. E. Still pending: a. Migration to Scala 2.8 branch. Intend to have stable master created first with everything working as usual without being caught into Scala release cycle. Hopefully, this branch and '280_port' would merge soon! b. Higher quality site generation (See #B above, proposal coming up) c. Site skin (See #D above) d. Hudson integration and better release management. So that certain steps in Committer release process [2] become automatic (waiting for merge to master and hudson maintenance) e. Having a nice README.md at the top level f. General spit and polish F: To be decided: a. Future of lift-core. (Separate mail coming) b. Relevance of OtherLicensedWorks.txt (repo distribution of javamail is now under CDDL and license automatically reflects in dependency page) c. Need for remove-trailings.sh (can be replaced by git pre-commit hook) [1] http://groups.google.com/group/liftweb/browse_thread/thread/450a3e741999b5df [2] http://wiki.github.com/dpp/liftweb/committer-release-process Feedbacks most welcome! Cheers, Indrajit -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Building Lift with scala 2.8.0
I could start with 2.7.7 and port it later, but if I can use the 2.8 port, and contribute feedback etc, I would like to. Feedback would be great: Very welcome! 280_port should build without failures: Could you please tell me exactly, what is breaking your build? Heiko Channing -- View this message in context: http://old.nabble.com/Building-Lift-with-scala-2.8.0-tp26858625p26861997.html Sent from the liftweb mailing list archive at Nabble.com. -- 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Building Lift with scala 2.8.0
2009/12/19 Channing Walton channingwal...@mac.com I would like to use Lift with scala 2.8.0 but need some helping building the branches. I've checked out the 280_port branch, but when I set the scala version to 2.8.0.Beta1-RC3 in the main pom, Lift doesn't compile. Hmm, the main POM of the 280_port has already set the scala version ot 2.8.0.Beta1-RC3! Are you sure you are using 280_port? Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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: [scala-internals] RC4 candidate for the first 2.8.0 beta
Lift built against RC3, but with RC4 we get this error: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.scala_tools.maven.executions.MainHelper.runMain(MainHelper.java:151) at org.scala_tools.maven.executions.MainWithArgsInFile.main(MainWithArgsInFile.java:26) Caused by: java.lang.AssertionError: assertion failed: type error: can't convert from REFERENCE(net.liftweb.util.StringHelpers) to REFERENCE(net.liftweb.util.BasicTypesHelpers) in unit BasicTypesHelpers.scala at scala.tools.nsc.backend.icode.GenICode$ICodePhase.adapt(GenICode.scala:943) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:927) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadLabelArguments(GenICode.scala:990) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:710) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIf(GenICode.scala:363) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:511) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIf(GenICode.scala:363) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:511) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:484) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:850) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:130) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:152) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:106) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:83) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.apply(GenICode.scala:79) at scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281) at scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281) at scala.tools.nsc.reporters.Reporter.withSource(Reporter.scala:48) at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:281) at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259) at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259) at scala.collection.Iterator$class.foreach(Iterator.scala:582) at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:285) at scala.tools.nsc.Global$GlobalPhase.run(Global.scala:259) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.run(GenICode.scala:72) at scala.tools.nsc.Global$Run.compileSources(Global.scala:749) at scala.tools.nsc.Global$Run.compile(Global.scala:839) at scala.tools.nsc.Main$.process(Main.scala:109) at scala.tools.nsc.Main$.main(Main.scala:123) at scala.tools.nsc.Main.main(Main.scala) ... 6 more Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Re: Re: [lift] Building Lift with scala 2.8.0
2009/12/20 Channing Walton channingwal...@mac.com ok here it is. The only thing I changed in the main pom is the scala version to the 2.8.0 beta rc3 If you are using the latest version of the 280_port branch there is no need to change the scala version = It is already 2.8 Beta RC4. Maybe you are using some outdated branch? Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Building Lift with scala 2.8.0
Your git stuff was quite OK, the Problem was that the branch is 280_port and not vice versa ;-) Please try it again: git clone ... git branch 280_port origin/280_port git checkout 280_port Heiko On Sunday, December 20, 2009, Channing Walton channingwal...@mac.com wrote: ah I see the problem - I know nothing about git! I original thought that the URL at the top of the github page for port_280 would get me port_280 which it doesn't. I tried following the instructions here: http://wiki.github.com/bricoleurs/bricolage/working-with-branches But that isn't working for me: % git clone git://github.com/dpp/liftweb.git ... % cd liftweb/ % git fetch origin % git checkout --track -b port_280 origin/port_280 fatal: git checkout: updating paths is incompatible with switching branches. Did you intend to checkout 'origin/port_280' which can not be resolved as commit? What should I do? (I've trawled gits help pages but I'm not having any luck) Channing -- View this message in context: http://old.nabble.com/Building-Lift-with-scala-2.8.0-tp26858625p26862689.html Sent from the liftweb mailing list archive at Nabble.com. -- 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 My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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 future of lift-core
2009/12/20 Indrajit Raychaudhuri indraj...@gmail.com lift-core is a 'meta' project that can be added as a dependency to a Lift project to pull in all the Lift modules. This serves as a singular configuration point in a Lift based application. However, since lift-core downloads all the Lift modules (irrespective of whether the project needs it), adding this as the dependency slow down things for a standard project that doesn't need some additional modules. From a modularity standpoint pulling in all the numerous Lift modules - some of them very special - is a bad idea. Further, the name is a misnomer now! Yes, it is totally misleading. The question, therefore is: Should we consider deprecating this? Yes! If yes, what should be the time frame for making the move? Perfect fit for 2.0. Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Goals for type and method renaming for Lift 2.0 - was: Open discussion on Lift Name Calling practices
of naming? Holder is probably the least problematic of these. The only issue I have with it is that FooHolder doesn't say anything about why you might want to have that particular kind of container (or indeed have a container at all) for a Foo. In some sense, every object that contains data is a holder - and I don't think StringHolder makes much sense; why does FooHolder? 3) Avoid making the name of the return type part of the name of the method. The types should tell the story as much as possible, except in the case where multiple methods varying only in return type would exist (illegal overloads) I'd be interested in understanding what the specific examples are, but I'm not sure I'm on board with this. Sometimes getLiftResponse is a lot more meaningful than get. There were a couple of examples of this in S that I thought were suspect, but we can address those individually. In general I think this suggestion boils down to DRY. 4) Prefer Scala-style accessors and mutators. I disagree. This is one where I have tried a lot of different accessors and mutators and the current crop is the best of breed. Sure, it's a little different, but it is much better. I'm talking more about the instances where you've got Scala classes with setX and getX rather than x and x_= - S is inconsistent and sometimes uses getX, sometimes uses x In general, the principle goal of this effort must be improving the clarity of the Lift API for both new adopters and for maintainers. We now have two days before the goal discussion closes. If anyone has any additional objectives they'd like to voice before this window closes, please do so now. I'd like to hold a vote on the proposals above as well as any other objectives folks may have tomorrow, so that any -1's can be ironed out before the 15th. Kris -- 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.comliftweb%2bunsubscr...@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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Make it possible to add LocParams to MetaMegaProtoUser's menus
Hi, I created an issue (#251) to Make it possible to add LocParams to MetaMegaProtoUser's menus: The various user related menus are created by methods xxxMenuLoc (e.g. loginMenuLoc) which give us no flexibility to add LocParams. Why would there be a need for that? E.g. for adding a LocGroup in order to customize menu display. The idea is that there are additional methods that are called from xxxMenuLoc in order to populate the LocParams. The default implementation will add a LocGroup(user). Before implementing that I would like to ask for you opinion. Thank you, Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Goals for type and method renaming for Lift 2.0 - was: Open discussion on Lift Name Calling practices
5) Avoid using abbreviations I disagree. When coding with a non-IDE, abbreviations make life much easier. I agree with David, abbreviations are better. When I'm trying to get something out of my head and into code, I don't want things getting in my way. 2 things in this scenario get in my way. 1) autocomplete is slow 2) typing is slow. Here's something else to think about on this issue. A good typist, familiar with their material can type faster then most code completions can operate. In studying data entry folks at UofP, I noticed something about the auto-complete functionality that wasn't obvious to me before. It's not how fast the code complete pops up that slow you down. It's the mental shift from typing to reading that takes the most time. You always have to verify that what the auto-complete is going to use is correct. This almost always takes more time then typing it yourself (assuming an expert typist). My concern is not at all coding speed which mostly is faster than thinking speed (at least for stupid pea-brains like me). I am concerned about how intuitive the Lift API, hence how fast folks will be familiar with it. To be more precise: I like abbreviations for really obvious stuff like RequestVar (everybody would know VarIABLES). But I do not like ... well I cannot find an example right now for an abbreviation in Lift that I do not like = Thus I guess this is more a general principle and Lift behaves quite well in this regard. Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Goals for type and method renaming for Lift 2.0 - was: Open discussion on Lift Name Calling practices
2009/12/13 Kris Nuttycombe kris.nuttyco...@gmail.com To this point, the only goals that have been recommended for this effort are those that I've noted below: 1) Remove ambiguity wherever possible! There are a number of places where very similar names are used to refer to utterly different things. 2) As an aide removing ambiguity, consider outlawing or eliminating extremely generic names, or else establish a single way in which a given name will be used across Lift. Examples are Field, Info, Holder, etc. 3) Avoid making the name of the return type part of the name of the method. The types should tell the story as much as possible, except in the case where multiple methods varying only in return type would exist (illegal overloads) 4) Prefer Scala-style accessors and mutators. Thank you Kris for writing up these goals. I would like to add another one: 5) Avoid using abbreviations In general, the principle goal of this effort must be improving the clarity of the Lift API for both new adopters and for maintainers. 100% agreed! In order to make Lift even more popular it is essential to ease adoption. Often folks require better documentation and we all know that the code (the API) is the first and best source of documentation. Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Goals for type and method renaming for Lift 2.0 - was: Open discussion on Lift Name Calling practices
And here is another one: 6) Use names related to the nature of the thing being named: We should be able to know what a type is or a method does from reading its name. Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] New Lift release process wiki page
2009/12/10 David Pollak feeder.of.the.be...@gmail.com On Wed, Dec 9, 2009 at 11:30 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: David, I do not understand the naming convention Lift_x_version. Is this something like Lift_x_2.0 or Lift_2.0 or ...? git checkout -b Lift_x_version Maybe it is possible to find a better symbol, e.g. Lift_MAJOR.MINOR[.MICRO][-QUALIFIER] with QUALIFIER something like M8? Anyway, could you please write up some examples in the Wiki? Lift-1.1-M8 Ah, OK. Thank you. You're welcome (encouraged) to update the process. Sure! Did it: create a new branch for the release: Name it *Lift-VERSION* with *VERSION = MAJOR.MINOR[.MICRO][-QUALIFIER]*, e.g. *Lift-2.0-M8* or *Lift-2.0.1* git checkout -b Lift-VERSION Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Next Lift version will be 2.0
Indrajit, Sorry for the very late reply :-( 2009/12/7 Indrajit Raychaudhuri indraj...@gmail.com Grand stuff! Thank you! Indeed, I was wondering if we could sync this up with the Round 2 of Refactoring exercise ( http://groups.google.com/group/liftweb/browse_thread/thread/450a3e741999b5df ). New structure, new version. Definitely yes! I am working on this refactoring in a private copy and am planning to publish the branch once M8 is out (assuming original schedule of 2 weeks from 27th Nov). Would this work with you? +1 Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] New Lift release process wiki page
David, I do not understand the naming convention Lift_x_version. Is this something like Lift_x_2.0 or Lift_2.0 or ...? git checkout -b Lift_x_version Maybe it is possible to find a better symbol, e.g. Lift_MAJOR.MINOR[.MICRO][-QUALIFIER] with QUALIFIER something like M8? Anyway, could you please write up some examples in the Wiki? Thanks, Heiko 2009/12/10 David Pollak feeder.of.the.be...@gmail.com http://wiki.github.com/dpp/liftweb/committer-release-process Please note the branch vs. tag change in the process. -- 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Next Lift version will be 2.0
Lifters, Maybe you followed the discussion about the versioning policy for Lift. The committers finally decided to have a well defined versioning policy which you can take from here: http://wiki.github.com/dpp/liftweb/about-versioning-policy. Following this policy the next Lift version will be 2.0, not 1.1, because there are numerous changes and enhancements breaking the source compatibility. As soon as we change the version numbers in the Maven POMs, we will let you know via the lift-announce mailing list. Best regards, Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Next Lift version will be 2.0
2009/12/7 Josh Suereth joshua.suer...@gmail.com Just curious what the difference between Major and Minor truly is as both can break source/binary compatibility? My feeling here is that sticking to strick source-compatibility for minor releases is actually a bonus. Major changes (e.g. moving/renaming an API class, changing an API method's signature, etc.) will break source compatibility for sure, i.e. for users and implementers. Minor changes (e.g. adding an abstract method to an API trait) will at maximum break source compatibility for implementers. So from a user's perspective minor changes add new stuff which could be used but do not break source compatibility, whereas major changes will require changing the source code. Examples: Renaming LiftRules to LiftConfig is a major change, adding a second parameter to LiftRules.parseDate is also a major change. But adding a second method LiftRules.parseDate is only a minor change (in this case even binary compatibility should be given). The other question I have is about deprecations. What's your plan for handling these? When can deprecated features be removed, etc. That might feed into the source-compatibility issues in minor versions. This is a good question and I do not have a plan yet ;-) As a first shot I would say that deprecated features have to survive all minor changes (must not break source compatibility for users) and maybe one major change. The latter is the question we have to discuss ... I think this is great stuff! Whatever is decided here will help shape the future of the Scala community's versioning, so I hope you don't mind my pestering ;) Don't worry ;-) Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Please welcome Jon Hoffman to the Lift committers
Welcome, Jon! 2009/12/3 David Pollak feeder.of.the.be...@gmail.com Folks, It may or may not be true that for Jon Hoffman that Martin Odersky praises [his] valuable contributions. [He] can read APIs in the dark.http://udorse.com/about/jobsBut Jon's made a valuable contribution to Lift as part of the community. Now, he's a committer. Please join me in welcoming Jon. I'm looking forward to his S3-related additions to Lift and any other goodies he wants to toss into Lift. Jon, welcome and I'm looking forward to the grandeur of your contributions! Thanks, David PS -- Derek please add Jon to the review board. PPS -- My wife loves the Udorse jobs page. -- 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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 get the servlet context
All this is brittle, at least special! Please use the temp dir the servlet context will offer you. Tomcat and Jetty offer one. Heiko On Monday, November 30, 2009, jhonig al...@xs4all.nl wrote: Marius, I tried to create a link from the webapp dir to another location with rw-access, but that was not allowed... My conclusion was that you can't have symbolic links to locations outside the war. My problem is that there are three different locations that could all be interpreted as a root for looking up resources. I've found nothing suggesting one over the other, and none of them works. I assume there are more variables involved that I don't even know of. Job On Nov 30, 10:27 pm, Marius marius.dan...@gmail.com wrote: Ok I may be missing something essential from all this thread but why not use a folder from the user's home directory? If your app runs say under jetty OS user should heve read/write rights to write on the home user file-system. Even if not (although I haven't encountered the case) those rights can be granted by an admin. So why do you need special container allocated locations to write files? Br's, Marius On Nov 30, 11:18 pm, jhonig al...@xs4all.nl wrote: Hi Tim, Jeppe, and others who have replied... I have spent a few more hours, but there are just too many variables and I haven't been able to figure them out. I logged the various locations (running under a standalone jetty, not mvn jetty:run, and got this: INFO - TEMP = /tmp/Jetty_0_0_0_0_8080_tent. 0.1.SNAPSHOT.warvtra6b INFO - REAL = /tmp/Jetty_0_0_0_0_8080_tent. 0.1.SNAPSHOT.warvtra6b/webapp INFO - URL = file:/tmp/Jetty_0_0_0_0_8080_tent. 0.1.SNAPSHOT.warvtra6b/webapp/WEB-INF/classes/ I tried to access images, both from the HTML served to my browser and from Scala snippets. I used the following paths: Images/testimage.jpg work/Images/testimage.jpg classes/work/Images/testimage.jpg WEB-INF/classes/work/Images/testimage.jpg. The latter path is what I see in my .war file... I have no special filters. I tried to add entries to my site map, but none of them worked. About to give up. Hope somebody will help me. Job H. On Nov 28, 3:14 pm, jhonig al...@xs4all.nl wrote: Dear Tim and Heiko, I tested a few things under mvn jetty:run...: getRealPath gives me ./src/main/webapp the temp attribute is set to ./target/work and the location is ./target/classes While the war contains classes/work which is again different... I didn't manage to get jetty to serve contents from any other directory than the first one. Didn't try to run it on the standalone jetty, since I still don't know how to tell jetty to serve contents that is not under the webapp directory. Probably have to do something with the site map which I don't fully understand. Guess my main problem is that I don't have any experience in this field (jetty/lift) and thought it wouldn't be to difficult to port my website to lift and enhance it a little on the fly. To be continued... Job Honig On Nov 28, 12:52 am, Timothy Perrett timo...@getintheloop.eu wrote: Here's a nugget of information for you that will help (as I do something similar to what you want in one of my applications): val protectionDomain: ProtectionDomain = classOf[bootstrap.liftweb.Boot].getProtectionDomain() val location: URL = protectionDomain.getCodeSource().getLocation() Print the value of location, and that will get you headed in the right direction ;-) Moreover, if your using jetty, if there is a work directory next to where the war file is, jetty will automatically expand the war into that work folder... if not, it makes a temp directory in the relevant OS temp directory (/var/tmp on *nix OS) Godspeed. Tim. On 27 Nov 2009, at 21:49, Heiko Seeberger wrote: Job, -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Sitemap + Menu Names + Change Order
Hannes, 2009/11/29 Hannes hannes.flo...@gmx.li I couldn't find anything about how to change a menu name, that is generated from CRUDify. Overwrite CRUDify.createMenuName, etc. Furthermore, I want to change the internal order of CRUDify menus. I believe that its more natural to use, when the create item comes before the list item. Overwrite CRUDify.menus Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Sitemap + Menu Names + Change Order
Hi Hannes, 2009/11/29 Hannes hannes.flo...@gmx.li thanks for the quick and helpful answer! You're welcome ;-) The renaming was quite easy, but what do I've to write inside CRUDify.menus? Please take a look at the source code (CRUDify.scala): def menus: List[Menu] = List(showAllMenuLoc, createMenuLoc, viewMenuLoc, editMenuLoc, deleteMenuLoc).flatMap(x = x) Overwrite it as you need, e.g. (create and showAll swapped): def menus: List[Menu] = List(createMenuLoc, showAllMenuLoc, viewMenuLoc, editMenuLoc, deleteMenuLoc).flatMap(x = x) Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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] Refactoring Round 2
Excellent proposal! Heiko On Friday, November 27, 2009, Indrajit Raychaudhuri indraj...@gmail.com wrote: Folks, In continuation to the refactoring initiative and following up on the discussion that we had on the last committers call, here we have the next round of broad based project structure refactoring proposal. This is themed around the idea of splitting the build system into separate smaller 'projects' with clearly demarcated responsibilities between them. In the way, these projects can have independent life-cycles on their own without coming in the way of each other (but still continue to have a dependency hierarchy). Here are the set of projects to begin with: 1. framework (http://github.com/dpp/liftweb/tree/branch/framework): The regular Lift as we have today (minus lift-archetype, lift- examples, lift-misc). Thus we would have: framwork/pom.xml framwork/lift-base framwork/lift-persistence framwork/lift-modules 2. archetypes (http://github.com/dpp/liftweb/tree/branch/ archetypes): The lift-archetypes from Liftweb. archetypes/pom.xml archetypes/lift-archetype-blank archetypes/lift-archetype-basic archetypes/lift-archetype-jpa-blank-single archetypes/lift-archetype-jpa-blank archetypes/lift-archetype-jpa-basic 3. examples (http://github.com/dpp/liftweb/tree/branch/examples): The lift-archetypes from Liftweb. The big uptake for archetypes and examples is the reduction of build time for building full Lift. Individuals building Lift might not always be interested in building non ancillary packages like lift-archetypes and lift-examples. examples/pom.xml examples/example1 examples/example2 4. resources (http://github.com/dpp/liftweb/tree/branch/resources: 4a. project-parent: A pure POM based project to be canonically used by all Lift family of projects (liftweb, lift-archetype, lift-examples etc.). Lot of what has gone in liftweb/pom.xml should get moved here. Obviously, this would contain the most generic configuration that holds true for all projects of Lift (#1, #2, #3). 4b. site-skin: Lift specific site skin instead of relying on org.scala- tools.skins:scala-skin-simple 5. references (http://github.com/dpp/liftweb/tree/branch/ references): Lift documentations and presentations. These don't need to show up in the project hierarchy in the IDE. 6. installer (http://github.com/dpp/liftweb/tree/branch/installer): The usual lift-installer that is tucked inside lift-misc. Again, these are unnecessarily showing up in the project hierarchy in the IDE. I am floating the idea beforehand and would be keen to have input from committers, the pros and cons and any other general feedback before proceeding. Thoughts would be very welcome :) Cheers, Indrajit -- 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 My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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 get the servlet context
According to the Servlet spec each webapp has got a private temporary
directory. I cannot remember exactly how to get this, maybe
ServletContext.getTmpDir(). Please take a look at the spec.
Heiko
On Friday, November 27, 2009, jhonig al...@xs4all.nl wrote:
Thanks Ross, I will try this! Is there a generic way to get to a
kind
of sandbox directory where snippets can read/write files?
Job
On Nov 27, 5:12 pm, Ross Mellgren dri...@gmail.com wrote:
A way you can get the Servlet context is like this:
LiftRules.context match {
case context: HTTPServletContext = // do something with
context.ctx which is the javax.servlet.ServletContext
case _ = // do something when the context is not a servlet
context, perhaps log an error
}
The reason you need the match is because Lift can run on non-servlet
web containers, so Lift does not guarantee there is a Servlet context
in scope.
Hope that helps,
-Ross
On Nov 27, 2009, at 10:51 AM, jhonig wrote:
LS,
After Ross' kind invitation to post any other questions I might have,
I'll start with
this one:
The web application I am developing needs a scratch directory to white
scaled
images to. I first try to use a subdir of /tmp and put a symbolic
link in place to
access that directory from my project's context. However, this got me
an
error message (something about an aliased resource), so after some
searching
around I decided the best way is to create a directory inside WEF-INF
and
access it through getServletContext ().getRealPath (/...).
From the APIdocs I found out that an instance of a ServiceContext is
passed
to HTTPServletContext, but I haven't been able to find if that is the
instance I
need, or how to get an instance of HTTPServletContext...
Note: I am currently able to read/write temporary finds when running
through
mvn getty:run, but I need a solution that still works when I deploy a
war with
an existing jetty server.
Thanks for any hints!
Job Honig
--
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.
--
Heiko Seeberger
My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
--
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 get the servlet context
File tempdir = (File) config.getServletContext().getAttribute(javax.servlet.context.tempdir) 2009/11/27 jhonig al...@xs4all.nl Dear Heiko, According to the Servlet spec each webapp has got a private temporary directory. I cannot remember exactly how to get this, maybe ServletContext.getTmpDir(). Please take a look at the spec. I started reading the spec, but didn't find it yet. ServletContext doesn't have any obvious way to get to a temporary dir, but I assumed I could create one. Would probably need to tweak a security policy to be able to write to it, but that would be the next step. Job H. -- 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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 get the servlet context
Job, This directory is managed by the servlet container and as far as I know there is little you can do to configure the location. If you use Tomcat you are able to specify CATALINA_BASE and it will be somewhere beneath that directory, I believe it is work/Catalina/localhost/WABAPP-NAME. Regarding serving images from there: Depending on the configuration of the servlet container WARs are not unpacked, hence there is no standard way to bring these images into your webapp. I think you will not be able to have the servlet container serve these images directly. But it should be easy to write a ServletFilter or something that will do it for you. Heiko 2009/11/27 jhonig al...@xs4all.nl Heiko, In the meantime, I found that solution as well... I tried it, and the default seems to be a work directory in target. I guess I can set another value for the attribute if I manage to convince jetty to do that for me. What I forgot to mention is that the directory is to contain images that are to be served by jetty... So it means the directory should be logically under webapp, but not in the war (of course). If I use a link from inside the war to some regular file system location, I'll probably run into the same problem as before. Any idea how to do this? Job H. On Nov 27, 6:56 pm, Heiko Seeberger heiko.seeber...@googlemail.com wrote: File tempdir = (File) config.getServletContext().getAttribute(javax.servlet.context.tempdir) 2009/11/27 jhonig al...@xs4all.nl Dear Heiko, According to the Servlet spec each webapp has got a private temporary directory. I cannot remember exactly how to get this, maybe ServletContext.getTmpDir(). Please take a look at the spec. I started reading the spec, but didn't find it yet. ServletContext doesn't have any obvious way to get to a temporary dir, but I assumed I could create one. Would probably need to tweak a security policy to be able to write to it, but that would be the next step. Job H. -- 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.comliftweb%2bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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: Call it Lift 2.0
Please let's not widen this discussion into something else but the question which versioning policy we are to apply. Building some kind of compatibility layer could be done regardless of the next Lift version number. Do we have a consensus, that there are several substantial changes breaking source and binary compatibility? And do we have a consensus, that this is something which requires increasing the major version number? Heiko 2009/11/23 Josh Suereth joshua.suer...@gmail.com The real question is could you still keep source compatibility if you made use of some interesting implict and @deprecated annotations? I believe those are acceptable. - Josh On Mon, Nov 23, 2009 at 6:05 AM, Timothy Perrett timo...@getintheloop.euwrote: Interesting - this is something i've not actually thought about: If we were to compile a list of all the breaking changes in 1.1, perhaps that would give some focus to this discussion... as josh points out, there are most likely quite a few now and 1.0 - 1.1 is a fairly short jump. Loc and LocParam Actor - LiftActor Full,Box etc have moved packages JSON parsing alterations and changes in JsExp Im probably missing a number of others, but we are talking about some fairly significant breaks here, right? Cheers, Tim On 23 Nov 2009, at 07:09, Heiko Seeberger wrote: Josh, Thank you for your brilliant elaboration of compatibility issues! 2009/11/22 Josh Suereth joshua.suer...@gmail.com The real question is, with all these breaking changes in lift 1.1, has any attempt been made at source-compatability? If not, I would argue a bigger version jump than 1.1. The current Lift is not source compatible with 1.0.x, just consider Box moved from ...util to ...common. Hence you would go for 2.0, right? Also, there is the possibility of taking the version system and adding a functionality milestone version at the begginning. In this case, you can use that number for marketting purposes (e.g. Lift goes 1.0!). Your version number would then be Marketing.SourceCompatability.All but Trait BinaryCompatability.Binary Compatibility. I am all against using versioning policy for marketing! Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=. -- 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=. -- 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=. -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- Heiko Seeberger Managing Director Technology Besuchen Sie unser Eclipse Demo Camp am 26.11. in Stuttgart http://wiki.eclipse.org/Eclipse_DemoCamps_November_2009/Stuttgart Weigle Wilczek GmbH Martinstraße 42-44 73728 Esslingen Deutschland T (+49) 711 46050250 F (+49) 711 45999829 www.weiglewilczek.com Geschäftsführer / Managing Directors: Dr. Jörn Weigle, Dr. Stephan Wilczek, Heiko Seeberger Sitz der Gesellschaft / Domicile: Esslingen a. N. Amtsgericht / Register Court: Stuttgart, HRB 214442 USt-Ident.-Nr. / VAT ID: DE 213 472 880 -- 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=.
[Lift] Re: Call it Lift 2.0
2009/11/21 Josh Suereth joshua.suer...@gmail.com I think eclipse and maven might be two of the only projects following that convention (besides others in the eclipse ecosystem). I think that Spring also follows the recommended OSGi versioning policy, but to be sure I will check with some of the Spring folks. And what about Java EE? Just remember 2.0-2.1 (small refinements and additions) and then 3.0 (very very breaking stuff). The question in my mind is what is the popular version number convention in the Scala ecosystem. As far as I can tell, e.g. from the 2.8 or 3.0 discussion on scala-internals, not many folks from Scala world are interested or trustful in versioning policies. So why not make Lift the thought leader in this regard? Heiko -- 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=.
[Lift] Re: Call it Lift 2.0
Josh, Thank you for your brilliant elaboration of compatibility issues! 2009/11/22 Josh Suereth joshua.suer...@gmail.com The real question is, with all these breaking changes in lift 1.1, has any attempt been made at source-compatability? If not, I would argue a bigger version jump than 1.1. The current Lift is not source compatible with 1.0.x, just consider Box moved from ...util to ...common. Hence you would go for 2.0, right? Also, there is the possibility of taking the version system and adding a functionality milestone version at the begginning. In this case, you can use that number for marketting purposes (e.g. Lift goes 1.0!). Your version number would then be Marketing.SourceCompatability.All but Trait BinaryCompatability.Binary Compatibility. I am all against using versioning policy for marketing! Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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=.
[Lift] Re: Call it Lift 2.0
Hi, Heiko, can you find the stated version number policies of 3 or 4 other well regarded open source projects? That will allow us to synthesize the best of what others have done into a coherent policy for Lift. Take a look at the recommended OSGi version policy: http://www.aqute.biz/Code/XBnd Then take a look at Eclipse (pretty well known, eh?): http://wiki.eclipse.org/index.php/Version_Numbering Both use a major increment (1.x - 2) to show breaking changes in API, a minor increment (1.1.x - 1.2) to show non-breaking changes in API and a micro increment to show internal (no class name changes, no method signature changes, ...) changes (e.g. bug fixes in the implementation). -- 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=.
[Lift] Re: Call it Lift 2.0
Folks, I would like to bring this version discussion to an end. I would prefer 2.0 but, I am also cool with 1.1. If there are still unheard arguments for 2.0, please speak out now. For me it is important that there is a version policy in place, such that everyone knows what's the difference between a change to 1.1 or to 1.0.2. As we probably will stick to Lift 1.1, IMHO the version policy has to be: Increasing the major or minor version number means breaking changes, increasing the micro version number keeps the API stable.. Opinions? Heiko -- 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=.
Re: [Lift] Lift Scala style.
Hi, As now is the time to improve names, I suggest to change the Actor names in lift-common: SimpleActor - Receiver SimplestActor - DefaultReceiver TypedActor - Actor GenericActor - BaseActor SimplestGenericActor - DefaultActor Heiko 2009/11/16 Kris Nuttycombe kris.nuttyco...@gmail.com Hi, all, This is just a starting point for debate with a hope of eventual consensus on something that's ultimately somewhat trivial matter. Since style is currently a topic of discussion on the main scala-users list, I thought it an appropriate time to bring it up. Lift is one of the most prominent, perhaps the most prominent Scala applications in current existence, and as such I think it has a significant role to play in exemplifying good Scala style. At the same time, Lift has also been developed over the course of its' developers familiarization with the language, and so it displays some occasional stylistic warts. At the same time, major changes coming with Scala 2.8, particularly named default parameters, may be something we want to take advantage of in ways that may have a substantial effect on usability of our APIs. I guess my general question is, how does the Lift community want to deal with the stylistic warts and naming inconsistencies, and how do we want to go about integrating some of these new features? In some cases, we may be able to use a strategy of giving some operations new names and deprecating the old, but in others this might lead to some really hacky looking APIs since we've already got good names, and changing their signatures might break a lot of code. Also, what are the big warts on Lift that ought to be resolved by renames or named/default parameters? Two naming issues that have come up recently in Lift internal discussions follow: First, Alex Boisvert suggested that S.init be renamed to S.doWith to have more consistency with Req and LiftSession. At least internally, I think that the consensus was that this wasn't necessarily appropriate. Second, I suggested the deprecation of the pattern of using apply() on AnyVar to provide setter functionality, since to me using something that looks like function application to do a mutation seems ill-conceived. My initial suggestion was to piggyback our functionality on the update() rewriting that is done by Scala, but on further reflection and David's feedback I realized that this would be even uglier since you'd have to use myRequestVar() = foo. So, what would folks think about defining the symbolic method := on both AnyVal and within the Mapper framework instead, with the goal of eventual deprecation of the apply style? Thirdly, I would like to propose that any marker traits (i.e. traits that declare no methods) within Lift either be sealed, or have the relevant methods tailored to the shared functionality they represent added (or both.) Match errors can be nasty, and sealing the traits (providing an extension point for users if need be) can help the compiler help us to eliminate that class of errors. Fourth, in compiling the Lift source I see far more warnings related to type erasure in match statements than I'm strictly comfortable with. My personal plan is to start working through these and eliminating them where possible, but in general I think that we as a community should start running all of our builds with all warnings enabled, and strive to eliminate them. The Scala type system can be complicated, but in my experience it is virtually always possible to avoid such warnings (and type unsafety!) with a bit of extra thought. The less we subvert the type system, the less likely we are to have unexpected errors. Kris --~--~-~--~~~---~--~~ 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.comliftweb%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~--- -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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=.
Re: [Lift] Re: Call it Lift 2.0
Jim, Let's stop this discussion (I won't convince you and you wont't convince me) and start doing something more valuable: Are you in town for a couple of beers? Heiko 2009/11/18 Jim Barrows jim.barr...@gmail.com On Wed, Nov 18, 2009 at 10:25 AM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Jim, 2009/11/17 Jim Barrows jim.barr...@gmail.com The behavior of a method, it's implementation is part of the contract I have with the library. Behavior yes, as long as agreed part of the contract. Implementation no. Implementation is not behavior? So, just because you, or some committee ... Not a committe, but the developer of the library. I don't care who. Somebody, who isn't me, is deciding whether the impact to me is is minor (ie 0.0.1), major (ie 0.1.0), or catastrophic (ie 1.0.0). ... think that the change is minor, I still have to thoroughly test everything that uses your library. Did you hear me saying Don't test your app when a required library changes its version? Yes, actually your attempting to use a scheme to tell me what I need to test. If you agree that with every change, I need to test those changes, then why complicate everybody's lives with number schemes? Because whether a someone uses the OSGI complex scheme of numbers, or Ubuntus year.month scheme, it still means I have to read the change list, and test the things that changed. As to your As Lift also is to support OSGi (already some support in place) it would be beneficial to stick to this version policy comment. I counter with Lift works on Ubuntu it would be beneficial to stick to this version policy and of course Lift runs on scala it would be beneficial to stick to this version policy, or better yet Lift runs on the Java VM it would be beneficial to stick to this version policy. All three of my arguments have far more to do with Lift running then OSGI does. If you are not interested in OSGi or Lift's OSGi support, then just ignore it. As far as I know neither Ubuntu, nor Scala, nor the JVM care about Lift's version number or version strategy. But OSGi does! You miss my point. My point was that the argument you make is useless. That's what I really need to know, Please accept that other folks might have different needs. You cut the context. However Everyone needs to know that things changed. And they need to know what changed. The OSGI scheme attempts to tell the developer how severe the change is, without knowing how the developer is using the library. That's useless. -- 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 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=. -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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=.
Re: [Lift] foursquare.com now basically all on Lift
Very very cool! Heiko 2009/11/17 harryh har...@gmail.com I've been a bit coy about it on the list, but three months ago when I joined the team at foursquare.com I made the final decision that we would port our webservers to Scala/Lift. It took about 3 months, but foursquare.com is now basically running only on Lift(1). This includes the website, a mobile website (m.foursquare.com) and a simple (but growing!) REST api (api.foursquare.com). I'd like the send a huge thank you to dpp and the rest of the Lift team. You've built a really great framework here, and I look forward to using it and seeing it grow for many years to come. An additional thanks goes out to all those who have answered my many random questions over the past couple of months. For those who haven't yet found out about foursquare, you can read more about it here: http://foursquare.com/learn_more Anyways, that's about enough self promotion, but I did want to officially let the community know about what I hope will be a fairly high profile site that is using Lift. -harryh (1) Haven't quite ported feeds.foursquare.com, and there is a legacy PHP based REST api that will live on for a bit longer as it supports current versions of our iPhone app. -- 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=. -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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=.
Re: [Lift] Re: Call it Lift 2.0
2009/11/17 Naftoli Gugenheim naftoli...@gmail.com But it's up to DPP because it's his project. Of course David kicked off Lift and he is managing the project actively. Yet there is also a huge Lift community. Hence I do not agree calling Lift his project. And even though I do not agree with every decision, I think that it is very beneficial for Lift to have a decision maker like him. Just look at the figures: There are 30+ committers and 1500+ members in this list. Ain't that successful? Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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=.
[Lift] Call it Lift 2.0
Hi, There has been a large amount of new stuff and also some breaking changes since Lift 1.0. As an OSGi guy I suggest we call the next version Lift 2.0, because increasing the major version number will show the world that there are breaking changes and/or cool new features. At least, this is how versions are used in OSGi land. OK, I know that Sun follows another version strategy (keeping the major version fixed to 1 forever) and the Scala folks also seem to be stick to 2.x (quite a lot people would like 2.8 to be 3.0), but IMHO this is no reason for Lift to follow the same mislead strategy. So what do you think? Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [Lift] Re: Call it Lift 2.0
I think version numbers are idiotic, and created by the marketing department, and not engineers. I strongly disagree: An appropriate version strategy is not at all about marketing but expresses valuable information. In OSGi increasing the major version means breaking changes in the API, increasing the minor version means nonbreaking changes in the API and increasing the micro version means no changes to the API but only changes of the implementation. Further these versions are used to declare dependencies between modules (OSGi bundles) which results in a high degree of trust that different modules work seamlessly together. As Lift also is to support OSGi (already some support in place) it would be beneficial to stick to this version policy. I think a 2.0 needs more time with a 2.0 mindset. Once 2.0 is on the table there may be more redesign involved. I disagree: Versions should not express a mindset but information about (non)breaking API changes. That's all, no magic, no marketing, no mindset. Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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=.
Re: [Lift] Re: Call it Lift 2.0
2009/11/17 David Pollak feeder.of.the.be...@gmail.com The current Lift is not a major change to Lift 1.0, it's a minor progression and a lot of tuning of the developer experience. There are breaking changes to the API which in the version policy suggested by me (the OSGi way) means increasing the major version number. OK, of course we need not stick to this particular version policy, but it would be beneficial to have one. What about: Increasing the minor version number (e.g. 1.0 - 1.1) means breaking changes to the API. Increasing the micro version number (e.g. 1.1.0 - 1.1.1) means *no* breaking changes to the API. Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- 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=.
