[Lift] Re: Converting a null String to an empty String
On Tuesday, March 9, 2010, Timothy Perrett 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 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] Converting a null String to an empty String
On 9 March 2010 16:48, David Pollak 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] 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] Js normalizations
On 7 March 2010 19:37, Marius 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 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 wrote:
>
>
> On Tue, Mar 2, 2010 at 11:42 PM, Heiko Seeberger
> wrote:
>
> On 3 March 2010 00:03, David Pollak wrote:
>
>
>
>
> On Tue, Mar 2, 2010 at 1:05 PM, Heiko Seeberger
> wrote:
>
> Hi,
> Isn't it possible to put snippets in subpackages of xxx.snippet?Something
> like ?
>
>
>
>
> If not, what's the best way to deal with a large number of snippets?
> Explicitly registering the snippet dispatch in LiftRules is the way I'd
> recommend doing it. If this is less than 100% optimal for your use case,
> let's learn more about your use case and see if we have to expand how
> Snippets are looked up.
>
>
> Well, registering quite a lot of snippets is indeed less than 100% optimal.
> OK, I have got a not-so-small website with about 100 templates and snippets.
> The templates are organized as a tree, e.g. /login/signup/seeker,
> /login/signup/offerer, etc. There is not a perfect 1:1 relationship between
> templates and snippets, but for sake of simplicity let's assume so. Hence I
> would like to organize my snippets in packages according to the templates,
> e.g. ...snippet.login.signup.Seeker, ...snippet.login.signup.Offerer, etc.
>
> One of the things I do with page-specific snippets is call them out in
> SiteMap:
> Loc(..., Snippet("foo", snipetFunc))
> But it might also be interesting to explore a model like Wickets:
>
> foo/bar/page.html -> look in snippets.foo.bar in addition to the normal
> snippets package... would that help?
>
>
> Thank you,
> Heiko
> Company: weiglewilczek.com
> Blog: heikoseeberger.name
> Follow me: twitter.com/hseeberger
> OSGi on Scala: scalamodules.org
> Lift, the simply functional web framework: liftweb.net
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
--
Heiko Seeberger
Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Snippets in subpackages?
On 3 March 2010 00:03, David Pollak 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 > 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.
[Lift] Snippets in subpackages?
Hi, Isn't it possible to put snippets in subpackages of xxx.snippet? Something like ? If not, what's the best way to deal with a large number of snippets? 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: Is CometActor the right tool for this job?
On 2 March 2010 15:09, ced 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.
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 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] Reasoning Behind Box
On 26 February 2010 08:09, Naftoli Gugenheim 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] 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 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.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 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] [urgent] Master is fundamentally broken!!!!!!
On 24 February 2010 18:40, David Pollak wrote: > > 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
On 23 February 2010 15:24, Heiko Seeberger wrote: > > 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: Tricky question regarding menus
Jeppe,
Thanks for your answer!
On 23 February 2010 08:47, Jeppe Nejsum Madsen 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.
[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 wrote: > 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 wrote: > Folks, > > Please join me in welcoming John De Goes as a Lift committer. John burst > onto the Lift scene a week or so ago with some excellent enhancements to the > Lift-json stuff and the rest is history. > > Welcome John... looking forward to excellent contributions from you and > your latest partner in crime, Kris Nuttycombe, a long-time Lift committer. > > Thanks, > > David > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > -- 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] 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] Re: Setting run mode for Lift applications
On 22 February 2010 10:52, Indrajit Raychaudhuri wrote:
> 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.
Re: [Lift] Re: Setting run mode for Lift applications
On 22 February 2010 09:20, Jeppe Nejsum Madsen 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
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 wrote: > On Sun, Feb 21, 2010 at 2:19 AM, Timothy Perrett > 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.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: autocrlf issue?
Sure, thanks. On Wednesday, February 17, 2010, Indrajit Raychaudhuri 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 > 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] autocrlf issue?
Sorry, forgot the subject ... On Wednesday, February 17, 2010, Heiko Seeberger wrote: > Hi, > > Since a week or so I get modified files even when I create a fresh > clone of the repo. These are some js and css files from lift-widgets > and stuff from installer and references. Anyone else experiencing the > same? I guess it could be related to the core.autocrlf configuration > for Git. Mine is set to input and I am working on a Mac. > > Any ideas? > > Heiko > > -- > Heiko Seeberger > > Work: weiglewilczek.com > Blog: heikoseeberger.name > Follow me: twitter.com/hseeberger > OSGi on Scala: scalamodules.org > Lift, the simply functional web framework: liftweb.net > -- Heiko Seeberger Work: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[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.
Re: [Lift] NOT IN subqueries?
On 17 February 2010 14:48, David Pollak wrote: > > 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] 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 15 February 2010 09:45, Jeppe Nejsum Madsen 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 20:10, Jeppe Nejsum Madsen 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 14 February 2010 14:40, Jeppe Nejsum Madsen 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.
Re: [Lift] Logging changes
On 12 February 2010 05:56, David Pollak wrote: > > > 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] Re: Test whether a Loc is a child of another Loc
On 11 February 2010 19:00, Heiko Seeberger wrote: > 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.
[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] 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.
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 wrote: > > > 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 >> 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 >> > 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. >> >> > > > -- > 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.
[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 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 > 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.
[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.
Re: [Lift] Re: OSGi example, what to do to make it run?
Philip, 2010/2/6 philip > > 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] Potential breakage: Choosing the default Lift logging backend
Hi, On 5 February 2010 22:11, Jeppe Nejsum Madsen 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.
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 wrote: > > > On Fri, Feb 5, 2010 at 9:06 AM, Heiko Seeberger < > heiko.seeber...@googlemail.com> wrote: > >> On 5 February 2010 15:05, Martin Ellis 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.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 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?
On 5 February 2010 15:05, Martin Ellis wrote: > > Any offers/suggestions? (Sorry, I realise the question more about > OSGI than lift) > Indeed, let's discuss this off-list ... 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 wrote: > Probally helpful if you share your prototype code? > > Cheers, Tim > > Sent from my iPhone > > On 5 Feb 2010, at 00:05, Heiko Seeberger > 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.com>weiglewilczek.com > Blog: <http://heikoseeberger.name>heikoseeberger.name > Follow me: <http://twitter.com/hseeberger>twitter.com/hseeberger > OSGi on Scala: <http://scalamodules.org>scalamodules.org > Lift, the simply functional web framework: <http://liftweb.net>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 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 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] 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.
[Lift] Re: CometActor.fixedRender always below render?
On Wednesday, February 3, 2010, Marius 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 > 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.
[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.
Re: [Lift] Github issue browser
Cool! Did not know there is an API. Heiko On Wednesday, February 3, 2010, Naftoli Gugenheim 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] 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 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] New ticketing system
On 28 January 2010 15:06, David Pollak wrote: 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] Lift logging improvements
+1 On Wednesday, January 27, 2010, Jeppe Nejsum Madsen 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] New ticketing system
2010/1/26 David Pollak > Folks, > > We switched to GitHub's ticketing system a bunch of months ago and, well, > it's not making the grade. It's slow. It's limited (no unclosing tickets, > no attachments, weak discussion capaibilities). It doesn't allow easy > planning/prioritization. > > I'd like to switch to something more powerful. Derek was working on > LiftTicket. I'd like to use that, but don't know the state of the project. > Alternatively, we could use Assembla's ticketing system. > > Does anyone have thoughts/input on the issue? > Let's go for Assembla. A ticketing system is ways too important (it just has to work) than we could rely on something under development like LiftTicket. Sorry! 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] Lift 2.0 on Scala 2.8 update
Awesome! Heiko On Sunday, January 24, 2010, Indrajit Raychaudhuri 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 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 > 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.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__ 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
2010/1/9 Indrajit Raychaudhuri 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.
Re: [Lift] 280_port builds against Scala 2.8 Beta1 RC7
2010/1/9 David Pollak > > 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
David, 2010/1/8 David Pollak 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.
[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: [ANN] Lift 1.1-M8
Hi,
What about using *runtime* scope for the database drivers? This is what I am
always changing my POM to. Because IMHO it is just the right thing: No
compilation dependency, but working with *mvn jetty:run* and inclusion in
the WAR.
By the way: The same applies to log4j.
This is a snippet from a "production" app:
net.liftweb
lift-webkit
${lift.version}
net.liftweb
lift-mapper
${lift.version}
log4j
log4j
1.2.14
runtime
com.h2database
h2
1.2.121
runtime
org.scalatest
scalatest
1.0
test
junit
junit
4.5
test
org.mortbay.jetty
jetty
[6.1.22,7)
test
Just my 2 cent ...
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 -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 > 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] The future of lift-core
2009/12/20 Indrajit Raychaudhuri > 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] [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 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] Re: Re: [lift] Building Lift with scala 2.8.0
2009/12/20 Channing Walton > > 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.
[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 liftweb+
Re: [Lift] [lift] Building Lift with scala 2.8.0
2009/12/19 Channing Walton > > 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.
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.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
nutes. >>> > Any class name or object name change that does not meet the above >>> criteria >>> > must be compelling. For example, we changed from Scala Actors to Lift >>> > Actors. This was a substantial amount of breakage, but there were no >>> > alternatives and the Scala Actor memory retention issues were >>> materially >>> > impacting many different sites and we had worked on various attempted >>> > solutions over a 10 month period. If we're going to break without >>> > deprecation and the breakage is going to impact a substantial part of >>> the >>> > Lift community, there must be a compelling reason to make the breakage. >>> > >>> > On Sun, Dec 13, 2009 at 10:49 AM, Kris Nuttycombe >>> > wrote: >>> >> >>> >> 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. >>> > >>> > In general, this is okay, but if there's a FooHolder that holds a Foo, >>> > what's wrong with that kind 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.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 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
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] Goals for type and method renaming for Lift 2.0 - was: Open discussion on Lift Name Calling practices
2009/12/13 Kris Nuttycombe > 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] New Lift release process wiki page
2009/12/10 David Pollak > > 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] 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 > 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.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] Next Lift version will be 2.0
Indrajit, Sorry for the very late reply :-( 2009/12/7 Indrajit Raychaudhuri > 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] Next Lift version will be 2.0
2009/12/7 Josh Suereth > > 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.
[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] Please welcome Jon Hoffman to the Lift committers
Welcome, Jon! 2009/12/3 David Pollak > 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/jobs>But 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.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 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 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 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 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 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
Hi Hannes, 2009/11/29 Hannes > > 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] Sitemap + Menu Names + Change Order
Hannes, 2009/11/29 Hannes > > 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] 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/.
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
> 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
> wrote:
> > File tempdir = (File)
> > config.getServletContext().getAttribute("javax.servlet.context.tempdir")
> >
> > 2009/11/27 jhonig
> >
> >
> >
> > > 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.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.
>
>
>
--
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
> 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.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 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 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] Refactoring Round 2
Excellent proposal! Heiko On Friday, November 27, 2009, Indrajit Raychaudhuri 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//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// > 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//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/ > examples/ > > 4. resources (http://github.com/dpp/liftweb/tree//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// > 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//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.
[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 > 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 > wrote: > >> 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 >> > 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 ..> Trait BinaryCompatability>.. >> > >> > 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=. >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@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.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
Josh, Thank you for your brilliant elaboration of compatibility issues! 2009/11/22 Josh Suereth > 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 .. Trait BinaryCompatability>.. > 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
2009/11/21 Josh Suereth > 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
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] 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 > > > On Wed, Nov 18, 2009 at 10:25 AM, Heiko Seeberger < > heiko.seeber...@googlemail.com> wrote: > >> Jim, >> >> 2009/11/17 Jim Barrows >> >>> >>> 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.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] 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 > > 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.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, 2009/11/17 Jim Barrows > > 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. > So, just because you, or some committee ... > Not a committe, but the developer of the library. > ... 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"? > 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! > That's what I really need to know, > Please accept that other folks might have different needs. 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 > 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=.
