[Lift] Converting a null String to an empty String

2010-03-09 Thread Heiko Seeberger
Hi,

I am pretty sure there is a method somewhere converting a null String to an
empty String. But I have not found it yet ...

Thanks,

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Converting a null String to an empty String

2010-03-09 Thread Heiko Seeberger
On 9 March 2010 16:48, David Pollak feeder.of.the.be...@gmail.com wrote:

 Can you be a little more specific?


Sure ;-)
I am looking for a method like this:
def stringNullTest(s: String): String = if (s != null) s else 

Of course I could roll my own, but if it is already around (e.g. in
StringHelpers) I would use it from there.

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] Re: Converting a null String to an empty String

2010-03-09 Thread Heiko Seeberger
On Tuesday, March 9, 2010, Timothy Perrett timo...@getintheloop.eu wrote:
 how about:
 def stringTest(x: String): String = Box !! x openOr 

Looks great, especially for a one-handed-writer ;-)

Heiko


 Cheers, Tim
 On 9 Mar 2010, at 17:30, Heiko Seeberger wrote:
 On 9 March 2010 16:48, David Pollak feeder.of.the.be...@gmail.com wrote:

 Can you be a little more specific?
 Sure ;-)I am looking for a method like this:def stringNullTest(s: String): 
 String = if (s != null) s else 

 Of course I could roll my own, but if it is already around (e.g. in 
 StringHelpers) I would use it from there.
 Heiko
 Company: weiglewilczek.com http://weiglewilczek.com/
 Blog: heikoseeberger.name http://heikoseeberger.name/
 Follow me: twitter.com/hseeberger
 OSGi on Scala: scalamodules.org http://scalamodules.org/
 Lift, the simply functional web framework: liftweb.net http://liftweb.net/



 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.





 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.


-- 
Heiko Seeberger

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Js normalizations

2010-03-07 Thread Heiko Seeberger
On 7 March 2010 19:37, Marius marius.dan...@gmail.com wrote:


 If you think that this makes sense I'll add a ticket and put it in my
 backlog.


Makes a lot of sense for me. Go for it!

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Re: non snapshot version of lift for scala 2.8

2010-03-04 Thread Heiko Seeberger
On 4 March 2010 15:36, Lukasz Kuczera kuk...@gmail.com wrote:

 I'm developing blog app on 280 and so far no problems yet.


I am doing payed development on Scala 2.8 and it works ;-)

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] Re: Snippets in subpackages?

2010-03-03 Thread Heiko Seeberger
Yep, that would help a lot!

Heiko

On Wednesday, March 3, 2010, David Pollak feeder.of.the.be...@gmail.com wrote:


 On Tue, Mar 2, 2010 at 11:42 PM, Heiko Seeberger 
 heiko.seeber...@googlemail.com wrote:

 On 3 March 2010 00:03, David Pollak feeder.of.the.be...@gmail.com wrote:




 On Tue, Mar 2, 2010 at 1:05 PM, Heiko Seeberger 
 heiko.seeber...@googlemail.com wrote:

 Hi,
 Isn't it possible to put snippets in subpackages of xxx.snippet?Something 
 like lift:snippet type=com.acme.snippet.subpackage.SnippetClass?




 If not, what's the best way to deal with a large number of snippets?
 Explicitly registering the snippet dispatch in LiftRules is the way I'd 
 recommend doing it.  If this is less than 100% optimal for your use case, 
 let's learn more about your use case and see if we have to expand how 
 Snippets are looked up.


 Well, registering quite a lot of snippets is indeed less than 100% optimal.
 OK, I have got a not-so-small website with about 100 templates and snippets. 
 The templates are organized as a tree, e.g. /login/signup/seeker, 
 /login/signup/offerer, etc. There is not a perfect 1:1 relationship between 
 templates and snippets, but for sake of simplicity let's assume so. Hence I 
 would like to organize my snippets in packages according to the templates, 
 e.g. ...snippet.login.signup.Seeker, ...snippet.login.signup.Offerer, etc.

 One of the things I do with page-specific snippets is call them out in 
 SiteMap:
 Loc(..., Snippet(foo, snipetFunc))
 But it might also be interesting to explore a model like Wickets:

 foo/bar/page.html - look in snippets.foo.bar in addition to the normal 
 snippets package... would that help?


 Thank you,
 Heiko
 Company: weiglewilczek.com
 Blog: heikoseeberger.name
 Follow me: twitter.com/hseeberger
 OSGi on Scala: scalamodules.org
 Lift, the simply functional web framework: liftweb.net


 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.


 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics


 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.


-- 
Heiko Seeberger

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Re: Is CometActor the right tool for this job?

2010-03-02 Thread Heiko Seeberger
On 2 March 2010 15:09, ced docpom...@googlemail.com wrote:

 3) How do I get access to the CometActor instance on the page? I need
  to send a message to it from a function bound to e.g. an ajaxSelect

 You need another Actor that dispatches messages to your CometActors.
 Say you have ChartCometActor, then implement something like
 object ChartManager extends Actor {
 ...
 }
 where all your CharCometActors register at creation time. Override
 localSetup() for this. Also override localShutdown() to unregister.
 Your snippet function then sends a message to the ChartManager who's
 responsible for dispatching to all/one actor/s. I use a solution where
 I register the CometActors an a session basis, so I can send a message
 either to all or just one CometActor.


Or use

object ChartServer extends LiftActor with ListenerManager {
  ...
  override def lowPriority = {
case ... = {
  ...
  updateListeners()
}
  }
}

and

class ChartActor extends CometActor with CometListener {

  override def registerWith = ChartServer

  // Only necessary if you do not want to send the message to all comet
actors
  override def shouldUpdate = {
case ...  =  // Decide whether this instance should receive a message
  }
}

Look at http://github.com/weiglewilczek/chatter for a full blown example.

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] Snippets in subpackages?

2010-03-02 Thread Heiko Seeberger
Hi,

Isn't it possible to put snippets in subpackages of xxx.snippet?
Something like lift:snippet
type=com.acme.snippet.subpackage.SnippetClass?

If not, what's the best way to deal with a large number of snippets?

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Snippets in subpackages?

2010-03-02 Thread Heiko Seeberger
On 3 March 2010 00:03, David Pollak feeder.of.the.be...@gmail.com wrote:



 On Tue, Mar 2, 2010 at 1:05 PM, Heiko Seeberger 
 heiko.seeber...@googlemail.com wrote:

 Hi,

 Isn't it possible to put snippets in subpackages of xxx.snippet?
 Something like lift:snippet
 type=com.acme.snippet.subpackage.SnippetClass?

 If not, what's the best way to deal with a large number of snippets?


 Explicitly registering the snippet dispatch in LiftRules is the way I'd
 recommend doing it.  If this is less than 100% optimal for your use case,
 let's learn more about your use case and see if we have to expand how
 Snippets are looked up.


Well, registering quite a lot of snippets is indeed less than 100% optimal.

OK, I have got a not-so-small website with about 100 templates and snippets.
The templates are organized as a tree, e.g. /login/signup/seeker,
/login/signup/offerer, etc. There is not a perfect 1:1 relationship between
templates and snippets, but for sake of simplicity let's assume so. Hence I
would like to organize my snippets in packages according to the templates,
e.g. ...snippet.login.signup.Seeker, ...snippet.login.signup.Offerer, etc.

Thank you,

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Happy 3rd Anniversary to Lift

2010-02-27 Thread Heiko Seeberger
I am proud to be on board and looking forward to the next three years

Heiko

On Saturday, February 27, 2010, David Pollak
feeder.of.the.be...@gmail.com wrote:
 Folks,

 Today is Lift's 3rd Anniversary/Birthday!

 Before I go offline for the weekend, I wanted to give a hearty thanks for the 
 Scala team, the Scala community, the Lift committers, and most importantly 
 the Lift community members new and old for making Lift possible, fun, and 
 challenging.

 Thank you all very, very much for everything each and everyone one of you has 
 done.

 David
 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics


 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.


-- 
Heiko Seeberger

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Logging, part 2

2010-02-25 Thread Heiko Seeberger
On 25 February 2010 10:23, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:


 2) Initialize the logging backend


What needs to be initialized?
Wouldn't auto initialization be nice?

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Reasoning Behind Box

2010-02-25 Thread Heiko Seeberger
Daniel,

I would like to look at this question from a solution oriented
perspective: Certainly you already noticed the third Box subtype Failure and
are aware of its usage. I agree with you, that Option vs Box is confusing
for Lift (and nowadays Goat Rodeo) adopters. As Scala and Lift are still
very young adoption is vital and hence I would like to know, what you
suggest: How could we only use Option *and* get something like Failure? Any
ideas?

Heiko

On 26 February 2010 05:40, Daniel Spiewak djspie...@gmail.com wrote:

 I'm sure this has been discussed before, but I'm curious as to the
 rationale for the Box ADT.  I'm most distressed by the fact that it
 seems to be masquerading as a drop-in Option replacement, and yet the
 mathematical properties of the ADT are widely divergent.  What's more,
 the API is very, very different, leading to a great deal of confusion
 whenever I'm working with code which touches both ADTs (as I often
 do).  Things like `or` vs `orElse`, `open_!` vs `get` and so on are
 very confusing.  The implicit conversion Box[A] = Option[A] doesn't
 help either, since it means I can easily forget and use Option methods
 on Box values, accidentally triggering a conversion.

 The whole `or` vs `orElse` thing is particularly annoying since I
 spend a fair amount of time wading through research which discusses
 the `orElse` function in its abstract monadic sense.  Given the
 standard nature of the name (dating back long before Scala), I'm
 surprised that Box went with something else.

 I'm sure there are good reasons for all of this, I would just like to
 know what they are.  :-)

 Daniel

 --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




-- 
Heiko Seeberger

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Reasoning Behind Box

2010-02-25 Thread Heiko Seeberger
On 26 February 2010 08:09, Naftoli Gugenheim naftoli...@gmail.com wrote:

 Either -- but it's more verbose.
 I'm not so sure David will want to rewrite the entire lift anyway...


Right now, I only would like to listen to Daniel, OK?

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] [urgent] Master is fundamentally broken!!!!!!

2010-02-24 Thread Heiko Seeberger
On 24 February 2010 18:40, David Pollak feeder.of.the.be...@gmail.comwrote:


 In the case of Heiko's issue, it's already been reported by a Japanese user
 of Lift 280_port_refresh.  The 2.8 libraries take an optional parameter for
 character set and default to the platform character set.  We need a ticket
 on this issue with a repro case so we can build a test and build a fix.


Fixed and on review board: http://reviewboard.liftweb.net/r/241/

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Re: Tricky question regarding menus

2010-02-23 Thread Heiko Seeberger
Jeppe,

Thanks for your answer!

On 23 February 2010 08:47, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:


 I have the same scenario and it works for me. In the parent menu I do this:

  Menu(Loc(parent, List(parent, index), Parent, Loc.EarlyResponse(()
 = Full(RedirectResponse(/subpage

 We're using our own menu snippet and I can't recall if this was one of
 the things we changed :-(


Your solution solves one problem: Clicking the parent leads to the child.
But the other problem still exists: doesMatch_? will not return true for the
parent and hence the parent menu will not be treated special (different
style, no link).

Heiko

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Re: Tricky question regarding menus

2010-02-23 Thread Heiko Seeberger
On 23 February 2010 15:24, Heiko Seeberger
heiko.seeber...@googlemail.comwrote:


 But the other problem still exists: doesMatch_? will not return true for
 the parent and hence the parent menu will not be treated special (different
 style, no link).


Using a custom menu snippet solves the problem. Thanks!

Heiko

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Re: Setting run mode for Lift applications

2010-02-22 Thread Heiko Seeberger
On 22 February 2010 09:20, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:


 The default would still be the current lookup in system properties,
 but you could change this to look at servlet params, hostname, day of
 month etc :-)


Ah, OK.
I agree if and only you will also enable setting the run mode depending on
the beer-level of the deployer ;-)

Heiko

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Re: Setting run mode for Lift applications

2010-02-22 Thread Heiko Seeberger
On 22 February 2010 10:52, Indrajit Raychaudhuri indraj...@gmail.comwrote:

 Given that setting initParams is the usual webapp idiom, should we not
 consider that at all? That would have served the purpose for Petr.

 customRunMode or context.initParam(run.mode) or
 Box.!!(System.getProperty(run.mode))


 with provision for having customRunMode customized heartily.


Looks good!

Heiko

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] Tricky question regarding menus

2010-02-22 Thread Heiko Seeberger
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

2010-02-22 Thread Heiko Seeberger
Hi John ;-)

On 22 February 2010 21:55, David Pollak feeder.of.the.be...@gmail.comwrote:

 Folks,

 Please join me in welcoming John De Goes as a Lift committer.  John burst
 onto the Lift scene a week or so ago with some excellent enhancements to the
 Lift-json stuff and the rest is history.

 Welcome John... looking forward to excellent contributions from you and
 your latest partner in crime, Kris Nuttycombe, a long-time Lift committer.

 Thanks,

 David

 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics

 --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] Re: Tricky question regarding menus

2010-02-22 Thread Heiko Seeberger
Hi,

Sorry for being pushy, but this one is really urgent. Maybe I did not
describe my issue properly, so I will give it another and simpler try:

I want a menu to link to a subpage, i.e. have the same link as one of its
child menus. But the menu shall also be active for every other active
child menu.

Thank you,

Heiko

On 22 February 2010 15:15, Heiko Seeberger
heiko.seeber...@googlemail.comwrote:

 Hi,

 I want to create a menu with the following structure:

 main1 main2 main3...
 sub1a sub1b sub2a sub2b sub3a ...
 page1a1 page1a2 ...

 Now I want some of the main and sub menus not to have their own pages but
 have the same link as certain child pages.

 Example: When the user clicks main1 the page page1a1 is to be shown. Of
 course main1 and sub1a are to be marked as currently selected menu, hence
 Loc.doesMatch_? must return true. If I create the Locs for main1 and sub1a
 with the link to page1a1 (main1/sub1a/paga1a1) then doesMatch_? will not be
 true for all other child pages of main1 and sub1a.

 Is there a simple solution to this? Or do I have to write my own Loc
 implementation?

 Thank you,

 Heiko Seeberger

 Work: weiglewilczek.com
 Blog: heikoseeberger.name
 Follow me: twitter.com/hseeberger
 OSGi on Scala: scalamodules.org
 Lift, the simply functional web framework: liftweb.net


-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Re: Setting run mode for Lift applications

2010-02-21 Thread Heiko Seeberger
Folks,

I really do not understand the value of setting the run mode statically via
code in LiftRules. The run mode should be set externally, right? In order to
use the same artifact (WAR) on a dev or a prod server.

Heiko

On 22 February 2010 08:44, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:

 On Sun, Feb 21, 2010 at 2:19 AM, Timothy Perrett
 timo...@getintheloop.eu wrote:
  The former is a lift idiom that we use for everything configurable...
 Lets look into doing that.
 
  Jeppe: Are you willing to investigate this / take the lead?

 Yes. I've created

 https://www.assembla.com/spaces/liftweb/tickets/362-make-runmode-configurable-in-liftrules

 /Jeppe

 --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] NOT IN subqueries?

2010-02-17 Thread Heiko Seeberger
On 17 February 2010 14:48, David Pollak feeder.of.the.be...@gmail.comwrote:


 On Tue, Feb 16, 2010 at 11:53 PM, Heiko Seeberger 
 heiko.seeber...@googlemail.com wrote:

 Hi,

 Is there a way to create NOT IN subqueries with lift-mapper?


 Nope.  Please open a ticket for 2.0-M3.  I'll get it done next week unless
 you want to do it.


Ticket is there:
http://www.assembla.com/spaces/liftweb/tickets/353-add-notin-queryparam

Heiko

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift]

2010-02-17 Thread Heiko Seeberger
Hi,

Since a week or so I get modified files even when I create a fresh
clone of the repo. These are some js and css files from lift-widgets
and stuff from installer and references. Anyone else experiencing the
same? I guess it could be related to the core.autocrlf configuration
for Git. Mine is set to input and I am working on a Mac.

Any ideas?

Heiko

-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] autocrlf issue?

2010-02-17 Thread Heiko Seeberger
Sorry, forgot the subject ...

On Wednesday, February 17, 2010, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:
 Hi,

 Since a week or so I get modified files even when I create a fresh
 clone of the repo. These are some js and css files from lift-widgets
 and stuff from installer and references. Anyone else experiencing the
 same? I guess it could be related to the core.autocrlf configuration
 for Git. Mine is set to input and I am working on a Mac.

 Any ideas?

 Heiko

 --
 Heiko Seeberger

 Work: weiglewilczek.com
 Blog: heikoseeberger.name
 Follow me: twitter.com/hseeberger
 OSGi on Scala: scalamodules.org
 Lift, the simply functional web framework: liftweb.net


-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] Re: autocrlf issue?

2010-02-17 Thread Heiko Seeberger
Sure, thanks.

On Wednesday, February 17, 2010, Indrajit Raychaudhuri
indraj...@gmail.com wrote:
 Heiko,

 Just remove core.autocrlf settings for now. You can add that back after I 
 update the repo (and send out the notification).

 - Indrajit

 On 17/02/10 8:16 PM, Heiko Seeberger wrote:

 Sorry, forgot the subject ...

 On Wednesday, February 17, 2010, Heiko Seeberger
 heiko.seeber...@googlemail.com  wrote:

 Hi,

 Since a week or so I get modified files even when I create a fresh
 clone of the repo. These are some js and css files from lift-widgets
 and stuff from installer and references. Anyone else experiencing the
 same? I guess it could be related to the core.autocrlf configuration
 for Git. Mine is set to input and I am working on a Mac.

 Any ideas?

 Heiko

 --
 Heiko Seeberger

 Work: weiglewilczek.com
 Blog: heikoseeberger.name
 Follow me: twitter.com/hseeberger
 OSGi on Scala: scalamodules.org
 Lift, the simply functional web framework: liftweb.net





 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.



-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] NOT IN subqueries?

2010-02-16 Thread Heiko Seeberger
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

2010-02-15 Thread Heiko Seeberger
On 14 February 2010 20:10, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:


 Makes sense, and that was actually close to what I had initially: The
 Logger trait was called LiftLogger, but this clashed with the current
 LiftLogger.

 This name (Logger in current code) probably doesn't matter too much as
 it's usually not needed in client code. But AbstractLogger doesn't
 sound very nice :-)


Even if (probably) not needed, we should try to name it the best possible
way. Changing now causes no pain at all, but later ... you know.

Heiko

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] New logging code

2010-02-15 Thread Heiko Seeberger
On 15 February 2010 09:45, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:

  Even if (probably) not needed, we should try to name it the best possible
  way. Changing now causes no pain at all, but later ... you know.

 Agreed. Suggestions?


I already made mine, just to make sure everyone has a chance to see them:
Like *Iterable* and *Iterator* lets call the trait that offers the logging
methods (info, warn, etc.) *Logger* and the trait that gives access to a *
Logger* should be called *Loggable*.

Heiko

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] New logging code

2010-02-14 Thread Heiko Seeberger
On 14 February 2010 14:40, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:

 Hi,

 I've tried to keep it as simple as possible, really just a Scala layer
 on top of the SLF4J api.


I think that's a very good decision!


 Note that no backend (log4j or logback) configuration is included. This
 has to go into lift-util to use runmode etc.

 You can have your choice of a nested logger:

  object MyObj extends Logging {
   logger.info(nested Hello)
  }

 or direct access:

  object MyObj extends Loggable {
   info(direct Hello)
  }

 Thoughts?


I really like to have Logging and Loggable, but I would call them vice versa
and change Logging to Logger. As an example think of Iterable and Iterator.
In general an Xable gives you access to an X. Hence we should have Loggable
with a method logger that returns a Logger and we should have Logger to mix
in all the logging methods. Why change from Logging to Logger? Because we
should call it what it is, not what it does.

Cheers,

Heiko

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] Test whether a Loc is a child of another Loc

2010-02-11 Thread Heiko Seeberger
Hi,

I would like to know what's the easiest way to test whether a Loc is a
child of another Loc. Which means, that the path to the first Loc contains
the path to the second one, e.g. myapp/login and myapp/login/signup.

Thank you!

Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] Re: Test whether a Loc is a child of another Loc

2010-02-11 Thread Heiko Seeberger
On 11 February 2010 19:00, Heiko Seeberger
heiko.seeber...@googlemail.comwrote:

 Hi,

 I would like to know what's the easiest way to test whether a Loc is a
 child of another Loc. Which means, that the path to the first Loc contains
 the path to the second one, e.g. myapp/login and myapp/login/signup.


OK, I came up myself with this simple solution:

loc.link isDefinedAt req

Heiko

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Logging changes

2010-02-11 Thread Heiko Seeberger
On 12 February 2010 05:56, David Pollak feeder.of.the.be...@gmail.comwrote:


 How about a different approach?  How about a new logging system in common
 that takes the best of the existing logging system plus a bunch of
 enhancements?


Are you thinking of something that could also be used standalone, i.e.
outside of Lift? That would be great!

Heiko

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] Question regarding menus

2010-02-10 Thread Heiko Seeberger
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

2010-02-08 Thread Heiko Seeberger
Hi folks,

this time *with* body and hopefully quite understandable: What's the
most clever way to submit a (AJAX)form when ENTER is hit in a
textarea?

Thanks,

Heiko

-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] Are there Maven artifacts for snapshot or milestone releases?

2010-02-07 Thread Heiko Seeberger
-- 
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?

2010-02-07 Thread Heiko Seeberger
Are there Maven *archetypes* for snapshot or milestone releases?

Heiko

On Sunday, February 7, 2010, Timothy Perrett timo...@getintheloop.eu wrote:
 Would be nice if you could have written an email body - subject only
 emails bug the ass out of me ;-)

 You mean like: http://scala-tools.org/repo-snapshots/net/liftweb/ or
 the hudson builds into nexus?

 Otherwise, you'll have to clarify exactly what your asking (herewith
 the problem with subject-only emails! - grumble grumble grumble)

 Cheers, Tim

 On Feb 7, 4:17 pm, Heiko Seeberger heiko.seeber...@googlemail.com
 wrote:
 --
 Heiko Seeberger

 Work: weiglewilczek.com
 Blog: heikoseeberger.name
 Follow me: twitter.com/hseeberger
 OSGi on Scala: scalamodules.org
 Lift, the simply functional web framework: liftweb.net

 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.



-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Re: Are there Maven artifacts for snapshot or milestone releases?

2010-02-07 Thread Heiko Seeberger
Sorry guys, tonight I seem unable to ask precise questions.

What I would like to know: Is it possible to get snapshot or milestone
archetypes from an archetype catalog? I tried scala-tools.org, but found
only version 1.0 of archetype-basic. Is there another catalog containing 2.0
milestones or snapshots?

Thank you!

Heiko

On 7 February 2010 22:10, David Pollak feeder.of.the.be...@gmail.comwrote:



 On Sun, Feb 7, 2010 at 10:43 AM, Heiko Seeberger 
 heiko.seeber...@googlemail.com wrote:

 Are there Maven *archetypes* for snapshot or milestone releases?


 There are archetypes generated for both snapshot and milestone releases.
 See
 http://scala-tools.org/repo-snapshots/net/liftweb/lift-archetype-basic/



 Heiko

 On Sunday, February 7, 2010, Timothy Perrett timo...@getintheloop.eu
 wrote:
  Would be nice if you could have written an email body - subject only
  emails bug the ass out of me ;-)
 
  You mean like: http://scala-tools.org/repo-snapshots/net/liftweb/ or
  the hudson builds into nexus?
 
  Otherwise, you'll have to clarify exactly what your asking (herewith
  the problem with subject-only emails! - grumble grumble grumble)
 
  Cheers, Tim
 
  On Feb 7, 4:17 pm, Heiko Seeberger heiko.seeber...@googlemail.com
  wrote:
  --
  Heiko Seeberger
 
  Work: weiglewilczek.com
  Blog: heikoseeberger.name
  Follow me: twitter.com/hseeberger
  OSGi on Scala: scalamodules.org
  Lift, the simply functional web framework: liftweb.net
 
  --
  You received this message because you are subscribed to the Google
 Groups Lift group.
  To post to this group, send email to lift...@googlegroups.com.
  To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
  For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.
 
 

 --
 Heiko Seeberger

 Work: weiglewilczek.com
 Blog: heikoseeberger.name
 Follow me: twitter.com/hseeberger
 OSGi on Scala: scalamodules.org
 Lift, the simply functional web framework: liftweb.net

 --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics

 --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Re: OSGi example, what to do to make it run?

2010-02-06 Thread Heiko Seeberger
Philip,

2010/2/6 philip philip14...@gmail.com


 Why do I want to do that? I am making a code generator which generates
 Scala code, I want the user to be able to try out the Scala code. So
 some liftweb method would generate a .scala file and another would
 package it into a OSGi and load the OSGi.


OSGi offers so much more than installing/updating bundles at runtime: There
is dependency management, versioning, services, etc. But you have to pay a
price for all these features = Constraints and complexity.

I do not think you need to pay that price: Just use the embedded Scala
compiler or even the interpreter. Take a look at http://www.simplyscala.com,
they might be doing something similar.

Heiko

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Suggestion to extend Comet (ListenerManager) to selectively update subscribers

2010-02-05 Thread Heiko Seeberger
OK, its on RB (http://reviewboard.liftweb.net/r/206/) = Take a look ...

Heiko

On 5 February 2010 01:07, Timothy Perrett timo...@getintheloop.eu wrote:

 Probally helpful if you share your prototype code?

 Cheers, Tim

 Sent from my iPhone

 On 5 Feb 2010, at 00:05, Heiko Seeberger heiko.seeber...@googlemail.com
 wrote:

 Hi,

 In the current state the ListenerManager will always update all
 subscribers. I have got a use case where only certain subscribers should be
 updated. Therefore I suggest to extend the ListenerManager such that there
 can be an optional partial function that determines which subscribers will
 be updated. This change will not break the current API and will not affect
 the default behavior.

 I have already implemented a prototype solution but would like to know your
 opinion first. So what do you think? Any objections up-front?

 Cheers,

 Heiko

 Work: http://weiglewilczek.comweiglewilczek.com
 Blog: http://heikoseeberger.nameheikoseeberger.name
 Follow me: http://twitter.com/hseebergertwitter.com/hseeberger
 OSGi on Scala: http://scalamodules.orgscalamodules.org
 Lift, the simply functional web framework: http://liftweb.netliftweb.net

 --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.

  --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] OSGi example, what to do to make it run?

2010-02-05 Thread Heiko Seeberger
OK ;-)

This is what I answered to Martin so far:

 I do not know such a tutorial, sorry. OSGi offers hot deployment out of
 the box, hence you do not need any JRebel or so. But by default (according
 to the spec) each bundle must be a JAR, hence you need a full build cycle.
 Eclipse Equinox allows for hosted deployment of usual PDE projects.


Currently Lift's OSGi support is constrained to single bundle (module)
applications. Of course this is already beneficial, because all the
dependencies (including lift-webkit etc.) are deployed as separate modules
and therefore can be updated separately. Also it should be possible to
deploy different Lift apps to one OSGi container.

But on the long run I would like to see real modular Lift applications:
Where one Lift app is made up from several bundles. Maybe some of them are
installed later and contribute to the menus, the mapper etc.

OSGi and JEE integration, namely web app integration, has been quiet for
some time, but recently there seems to be some process. I am not sure
whether the spec will deal with composite web apps: If not, we could pioneer
in this field.

Any ideas or questions?

Heiko

On 5 February 2010 18:18, David Pollak feeder.of.the.be...@gmail.comwrote:



 On Fri, Feb 5, 2010 at 9:06 AM, Heiko Seeberger 
 heiko.seeber...@googlemail.com wrote:

 On 5 February 2010 15:05, Martin Ellis ellis@gmail.com wrote:


 Any offers/suggestions?  (Sorry, I realise the question more about
 OSGI than lift)


 Indeed, let's discuss this off-list ...


 Can you discuss it on-list?  I'd like to learn.


 Heiko

 Work: weiglewilczek.com
 Blog: heikoseeberger.name
 Follow me: twitter.com/hseeberger
 OSGi on Scala: scalamodules.org
 Lift, the simply functional web framework: liftweb.net

 --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics

 --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Potential breakage: Choosing the default Lift logging backend

2010-02-05 Thread Heiko Seeberger
Hi,

On 5 February 2010 22:11, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:


 2) is the cleanest solution since the choice of logging backend is made
 explicit. But this requires people to change their poms in order to get
 any logging.


Let's go for 2) because in real-world projects people will have to adjust
the POM anyway. E.g. for persistence modules or for 3rd party libs.

Heiko

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] Suggestion to extend Comet (ListenerManager) to selectively update subscribers

2010-02-04 Thread Heiko Seeberger
Hi,

In the current state the ListenerManager will always update all subscribers.
I have got a use case where only certain subscribers should be updated.
Therefore I suggest to extend the ListenerManager such that there can be an
optional partial function that determines which subscribers will be updated.
This change will not break the current API and will not affect the default
behavior.

I have already implemented a prototype solution but would like to know your
opinion first. So what do you think? Any objections up-front?

Cheers,

Heiko

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] OSGi example, what to do to make it run?

2010-02-04 Thread Heiko Seeberger
Philip,

Good to see some interest in Lift's OSGi support!

Of course Lift will need a servlet container. Hence you will have to
install one in your OSGi framework, too. The same accounts for all the
dependencies, e.g. the Scala library.

Heiko

On Friday, February 5, 2010, philip philip14...@gmail.com wrote:
 Hi,

 I downloaded the git source and made a OSGi jar package by running the
 maven, now what do I do with it?

 I see its a jar file with the manifest for OSGi, I guess I can load it
 into Apache Felix, but doesn't Liftweb need tomcat or jetty to run? So
 I don't really understand how its going to run.

 Thanks, Philip

 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.



-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] CometActor.fixedRender always below render?

2010-02-03 Thread Heiko Seeberger
Hi,

It looks like the output from fixedRender is always placed below the
one from render. Is there a way to change this?

Heiko

-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



[Lift] Re: CometActor.fixedRender always below render?

2010-02-03 Thread Heiko Seeberger
On Wednesday, February 3, 2010, Marius marius.dan...@gmail.com wrote:
 Technically you could override :

 def toJavaScript(session: LiftSession, displayAll: Boolean): JsCmd

 from CometActor, but you'd probably loose important things that Lift
 does for you there. You could call super but I don't think that it
 would be very helpful.

 Perhaps we should add an easy way to allow this ...

Would be nice, but I can live without :-)

Heiko


 Br's,
 Marius

 On Feb 3, 5:15 pm, Heiko Seeberger heiko.seeber...@googlemail.com
 wrote:
 Hi,

 It looks like the output from fixedRender is always placed below the
 one from render. Is there a way to change this?

 Heiko

 --
 Heiko Seeberger

 Work: weiglewilczek.com
 Blog: heikoseeberger.name
 Follow me: twitter.com/hseeberger
 OSGi on Scala: scalamodules.org
 Lift, the simply functional web framework: liftweb.net

 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.



-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Github issue browser

2010-02-02 Thread Heiko Seeberger
Cool! Did not know there is an API.

Heiko

On Wednesday, February 3, 2010, Naftoli Gugenheim naftoli...@gmail.com wrote:
 If anyone finds github's issue manager too limited, I made a teeny little app 
 that lets you list the issues in a more configurable way. All comments 
 welcome!
 http://github-issues.naftoligug.staxapps.net/index

 You do not need to log in or register. Right now it only browses issues for 
 dpp/liftweb. Use the check boxes on top to filter tickets, click column 
 headers to sort, and click 'more' or 'less' on a ticket to view its 
 description.

 Enjoy!




 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.


-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] New ticketing system

2010-01-28 Thread Heiko Seeberger
On 28 January 2010 15:06, David Pollak feeder.of.the.be...@gmail.comwrote:

I can host an instance.  The big issue as I see it is have a reliable
 maintainer.  In order to use LiftTicket, we need someone who is around most
 of the time (46+ weeks a year), can fix bugs in a few days, has a solid
 Internet connection, etc.  If we can find a reliable maintainer, I'm all for
 moving forward with LiftTicket.


I think this is (too) risky ...

Heiko

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Always log through Slf4j?

2010-01-28 Thread Heiko Seeberger
No more APIs on top of APIs!
slf4j is very OSGi friendly, by the way.
If side effects are minimal, I vote for it.

Heiko

On Thursday, January 28, 2010, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
 Last logging question, I promise!

 I'm about to implement MDC in Lift's logging, but it seems more and more
 layers are introduced.

 So before adding another adapter on top of e.g. Slf4j which is already
 an adapter on top of e.g. logback I thought I would see if there are any
 objections to making Lift always log through Slf4j?

 There wouldn't be any API changes and Log4j could still be the default
 backend, with the config settings as we currently have, only there
 wouldn't be any Log4JLogger.

 On the positive side, Lift's logging is simpler: only interface to Slf4j
 (we would keep the log4j config stuff)

 Downside is two more jars if you're using log4j: slf4j-api 
 slf4j-log4j12

 Thoughts?

 /Jeppe

 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.



-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Lift logging improvements

2010-01-27 Thread Heiko Seeberger
+1

On Wednesday, January 27, 2010, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
 Hi,

 I was thinking about some improvements to Lift's logging code:

 1) Make the slf4j logging configurable in the same way as log4j (ie with
 dev, prod logback files)

 2) Add support for MDC to Lift's logging interface (and the log4j 
 slf4j backends)

 3) Add more logging to Lift :-)

 The last part may be a bit controversial, but I find logging statements
 immensely useful when trying to diagnose stuff that doesn't work or
 figure out how stuff works. If separate loggers are created for
 different areas (i.e mapper, comet, ajax, etc) it should be possible to
 turn the needed info on  off without too much information overload.

 Performance wise it shouldn't matter much (famous last words :-) if
 logging is disabled.

 Thoughts?

 /Jeppe

 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.



-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Lift 2.0 on Scala 2.8 update

2010-01-24 Thread Heiko Seeberger
Awesome!

Heiko

On Sunday, January 24, 2010, Indrajit Raychaudhuri indraj...@gmail.com wrote:
 Folks,

 A quick update on Lift 2.0 build on Scala 2.8.

 Scala 2.8 port of Lift is available on the branch 280_port_refresh. This is a 
 'refresh'ed version of 280_port which is fully aligned and sync'ed with the 
 master.

 To ensure minimal delta between the master and 280_port_refresh, the codebase 
 in master has been adjusted considerably to improve Scala 2.8 compatibility. 
 Thus, the master branch continues to be on Scala 2.7.7 but is lot more Scala 
 2.8 friendly now. In fact, most of the modules (and all the examples) build 
 cleanly on both 2.7 and 2.8 without any change.

 Few additional points:

 1. Those interested in playing with this branch can checkout from the 
 280_port_refresh and build locally.

 2. A Hudson job for lift_280_refresh has been setup at 
 http://hudson.scala-tools.org/view/Lift/job/lift-scala280/. For now, it just 
 does internal build. In course of the week, Hudson would be setup to deploy 
 the snapshots as well.

 3. Scala 2.8 is binary incompatible with Scala 2.7. This means the additional 
 scala libraries on which Lift depends also need to provide a Scala 2.8 build. 
 Hopefully, there would be scalajpa and scalamodules-core build available in 
 near term. For now, modules specifically dependent on them have been disabled.

 4. Parts of the code which don't work on Scala 2.8 (broken, incompatible 
 etc.) have been marked with FIXME: 280.

 Cheers, Indrajit

 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.



-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Welcome Jeppe to the Lift committers

2010-01-22 Thread Heiko Seeberger
Howdy!

On Friday, January 22, 2010, David Pollak feeder.of.the.be...@gmail.com wrote:
 Folks,

 Please join me in welcoming Jeppe as a Lift Committer.  He's been helping 
 people on the Lift list and contributing his thoughts to the Lift community 
 for a while... now it's time for him to contribute code to Lift.  
 Hooorraaayyy!

 Thanks,

 David
 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics


 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.


-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

-- 
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Mindless work...

2010-01-21 Thread Heiko Seeberger

 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

2010-01-19 Thread Heiko Seeberger
Hi Mads!

2010/1/19 David Pollak feeder.of.the.be...@gmail.com

 Folks,

 Please join me in welcoming Mads to the Lift committers.

 Thanks,

 David

 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics

 --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




-- 
Heiko Seeberger

Work: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
-- 

You received this message because you are subscribed to the Google Groups "Lift" group.

To post to this group, send email to lift...@googlegroups.com.

To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Re: Lift - GAE Version

2010-01-14 Thread Heiko Seeberger
2010/1/14 __kaveh__ kaveh.shahbaz...@gmail.com

So for cases like many little web
 applications that concurrency is not an issue or for technologies like
 GAE; we should simply fall back to Java?


NO!
Go for Scala + Lift!

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
-- 

You received this message because you are subscribed to the Google Groups "Lift" group.

To post to this group, send email to lift...@googlegroups.com.

To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Re: **IMPORTANT** Lift 2.0 Milestone1 is coming and it's time to test the SNAPSHOT in master

2010-01-11 Thread Heiko Seeberger

 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-01-09 Thread Heiko Seeberger
David,

2010/1/8 David Pollak feeder.of.the.be...@gmail.com

Did you smoke test the lift-examples/example app?


Now I did ;-) Looks good.

The reason I did not before is, that some modules and a lot of tests are
commented out. So was lift-widgets which is a dependency of
lift-examples/example. Now I fixed lift-widgets (there was only one little
adjustment in a test case), added it to the build and then fixed the example
app.

Hence the statement Lift builds against 2.8 is only partially true, because
a lot of things are not included. But I am optimistic that out coverage is
large enough and we won't experience any severe issues when porting the
rest.

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
-- 

You received this message because you are subscribed to the Google Groups "Lift" group.

To post to this group, send email to lift...@googlegroups.com.

To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] 280_port builds against Scala 2.8 Beta1 RC7

2010-01-09 Thread Heiko Seeberger
2010/1/9 David Pollak feeder.of.the.be...@gmail.com


 Yeah... now that 2.8 Beta1 is out, we'll need to finish porting Lift over.


*Once* 2.8 Beta 1 is out: IMHO we are at Beta1 RC7 and it will take another
couple of days until we will see Beta1.
Anyway, I'd be glad to help porting the rest.

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
-- 

You received this message because you are subscribed to the Google Groups "Lift" group.

To post to this group, send email to lift...@googlegroups.com.

To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] 280_port builds against Scala 2.8 Beta1 RC7

2010-01-09 Thread Heiko Seeberger
2010/1/9 Indrajit Raychaudhuri indraj...@gmail.com

How about taking the same strategy as last time (during scala 2.7.5 to
 2.7.7)?
 Use Maven version classifier fot 2.8.0 build and create separate
 hudson job(s) for the purpose.


Yep, let's do that!

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
-- 

You received this message because you are subscribed to the Google Groups "Lift" group.

To post to this group, send email to lift...@googlegroups.com.

To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.



[Lift] 280_port builds against Scala 2.8 Beta1 RC7

2010-01-08 Thread Heiko Seeberger
-- 
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

2010-01-02 Thread Heiko Seeberger

 StreamManager[T] sounds cool to me.


+1

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] Re: WebSockets are Coming

2009-12-23 Thread Heiko Seeberger

 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

2009-12-22 Thread Heiko Seeberger
Martin,

OK, now I got it working (almost) without Maven:

1. step:
Check out 280_port branch from g...@github.com:dpp/liftweb.git

2. step:
cd into liftweb/lift-persistence/lift-mapper and run
mvn dependency:copy-dependencies

3. step:
run the following command
PATH-TO-SCALAC-OR-FSC-2.8-BETA1-RC5 -classpath `find target/dependency
-name *.jar | xargs scala -e 'println(args mkString :)'` -sourcepath
src/main/scala -d target/classes `find src/main/scala -name *.scala`

This will only use Maven to download the dependencies, but you can compile
with scalac or fsc.

Heiko

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




[Lift] Re: [Lift Announce] **Important** Announcing the Lift 2.0 branch

2009-12-21 Thread Heiko Seeberger
Indrajit,

Great to see the next refactoring round!

I got the branch and there are a lot of oddities, e.g.:

   - All the POMs I looked at are still 1.1, not 2.0
   - framework/pom.xml references module lift-archetypes and lift-examples
   - The parent POM is empty

Maybe you did not update the branch on GitHub with your latest changes?

Heiko

2009/12/20 Indrajit Raychaudhuri indraj...@gmail.com

 Okay Folks,

 Lift 2.0 branch has shaped up enough for everybody to play with.
 Checkout the branch irc_wip_lift20 and get going! Just be aware that
 it's still undergoing updated and changes incrementally and there are
 few rough edges.

 Key changes:

 1. The project tree has been restructured according to the proposal
 sent out earlier [1]. To summarize, we now have three top level
 projects (framework, archetypes and examples) each with independent
 build life-cycle. There are other additional infra projects that are
 less to do with the actual code.

 A quick summary of the top-level projects:

 1. Framework:
 The whole of Lift Framework that matter most to most. The usual
 modules (viz., lift-base, lift-persistence and lift-modules) have got
 nested within. Therefore, from now on, building Lift framework would
 mean just that. Doing a git pull or git clone as usual, changing
 to framework directory and running mvn install.

 2. Archetypes:
 The standard distributed archetypes. The archetypes help you get quick
 started with a Lift based project. If you are not into building maven
 archetypes, you can stay clear of this. But a quick probe is welcome.

 3. Examples:
 All the Lift examples are grouped into this project. If you are
 generally interested in learning different techniques from examples
 you don't have to build the whole of Lift anymore. Well that was still
 the case earlier, but now it's even more obvious. And it's true the
 other way round too, if you have to build Lift framework from source,
 you don't have to build the examples along with it. Another point: the
 examples won't be deployed on scala-tools maven repo anymore. Those
 war files up there serve no good purpose.

 Everything now gets neatly tucked into their respective homes :)

 Additional points that you should be aware of:

 A. Availability on scala-tools repository:
 - Components of framework would be available
 - Components of archetypes would be available
 - Components of examples would *not* be available

 B. Availability on scala-tools Maven site:
 Site generated from framework would be the main content of scala-tools
 Maven site. Depending on how things go, we might even have a home of
 it's own at http://dev.liftweb.net. (Separate proposal coming up)

 C. Lift Parent Project Model:
 The top level pom.xml has moved to it's own home at resources/project-
 model. This would stay as a 'flyweight' project (as in boxing, not
 GoF) on it's own that would strictly control the common behavior,
 plugin dependencies, versions etc. for all the top level projects
 (framework, archetypes, examples). This would be deployed on scala-
 tools repository.

 D. Lift Site Skin (WIP):
 I haven't started working on this yet. But the intent is to create a
 project site that is of some real value and serves as placeholder for
 mostly 'auto-generated' docs. See #B above.

 E. Still pending:
 a. Migration to Scala 2.8 branch. Intend to have stable master created
 first with everything working as usual without being caught into Scala
 release cycle. Hopefully, this branch and '280_port' would merge soon!
 b. Higher quality site generation (See #B above, proposal coming up)
 c. Site skin (See #D above)
 d. Hudson integration and better release management. So that certain
 steps in Committer release process [2] become automatic (waiting for
 merge to master and hudson maintenance)
 e. Having a nice README.md at the top level
 f. General spit and polish

 F: To be decided:
 a. Future of lift-core. (Separate mail coming)
 b. Relevance of OtherLicensedWorks.txt (repo distribution of javamail
 is now under CDDL and license automatically reflects in dependency
 page)
 c. Need for remove-trailings.sh (can be replaced by git pre-commit
 hook)


 [1]
 http://groups.google.com/group/liftweb/browse_thread/thread/450a3e741999b5df
 [2] http://wiki.github.com/dpp/liftweb/committer-release-process

 Feedbacks most welcome!

 Cheers, Indrajit




-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] Re: [lift] Building Lift with scala 2.8.0

2009-12-20 Thread Heiko Seeberger

 I could start with 2.7.7 and port it later, but if I can use the 2.8 port,
 and contribute feedback etc, I would like to.


 Feedback would be great: Very welcome!

280_port should build without failures: Could you please tell me exactly,
what is breaking your build?

Heiko



 Channing
 --
 View this message in context:
 http://old.nabble.com/Building-Lift-with-scala-2.8.0-tp26858625p26861997.html
 Sent from the liftweb mailing list archive at Nabble.com.

 --

 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.





-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] [lift] Building Lift with scala 2.8.0

2009-12-20 Thread Heiko Seeberger
2009/12/19 Channing Walton channingwal...@mac.com


 I would like to use Lift with scala 2.8.0 but need some helping building
 the
 branches. I've checked out the 280_port branch, but when I set the scala
 version to 2.8.0.Beta1-RC3 in the main pom, Lift doesn't compile.


Hmm, the main POM of the 280_port has already set the scala version ot
2.8.0.Beta1-RC3!
Are you sure you are using 280_port?

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




[Lift] Re: [scala-internals] RC4 candidate for the first 2.8.0 beta

2009-12-20 Thread Heiko Seeberger
Lift built against RC3, but with RC4 we get this error:

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.scala_tools.maven.executions.MainHelper.runMain(MainHelper.java:151)
at
org.scala_tools.maven.executions.MainWithArgsInFile.main(MainWithArgsInFile.java:26)
Caused by: java.lang.AssertionError: assertion failed: type error: can't
convert from REFERENCE(net.liftweb.util.StringHelpers) to
REFERENCE(net.liftweb.util.BasicTypesHelpers) in unit
BasicTypesHelpers.scala
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase.adapt(GenICode.scala:943)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:927)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadLabelArguments(GenICode.scala:990)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:710)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIf(GenICode.scala:363)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:511)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIf(GenICode.scala:363)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:511)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:484)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:850)
at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:130)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97)
at scala.collection.immutable.List.foreach(List.scala:46)
at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87)
at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:152)
at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:106)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97)
at scala.collection.immutable.List.foreach(List.scala:46)
at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87)
at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97)
at scala.collection.immutable.List.foreach(List.scala:46)
at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87)
at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97)
at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:83)
at
scala.tools.nsc.backend.icode.GenICode$ICodePhase.apply(GenICode.scala:79)
at
scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281)
at
scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281)
at scala.tools.nsc.reporters.Reporter.withSource(Reporter.scala:48)
at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:281)
at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259)
at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259)
at scala.collection.Iterator$class.foreach(Iterator.scala:582)
at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:285)
at scala.tools.nsc.Global$GlobalPhase.run(Global.scala:259)
at scala.tools.nsc.backend.icode.GenICode$ICodePhase.run(GenICode.scala:72)
at scala.tools.nsc.Global$Run.compileSources(Global.scala:749)
at scala.tools.nsc.Global$Run.compile(Global.scala:839)
at scala.tools.nsc.Main$.process(Main.scala:109)
at scala.tools.nsc.Main$.main(Main.scala:123)
at scala.tools.nsc.Main.main(Main.scala)
... 6 more

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 

Re: [Lift] Re: Re: [lift] Building Lift with scala 2.8.0

2009-12-20 Thread Heiko Seeberger
2009/12/20 Channing Walton channingwal...@mac.com


 ok here it is. The only thing I changed in the main pom is the scala
 version
 to the 2.8.0 beta rc3


If you are using the latest version of the 280_port branch there is no need
to change the scala version = It is already 2.8 Beta RC4. Maybe you are
using some outdated branch?

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] [lift] Building Lift with scala 2.8.0

2009-12-20 Thread Heiko Seeberger
Your git stuff was quite OK, the Problem was that the branch is
280_port and not vice versa ;-)

Please try it again:

git clone ...
git branch 280_port origin/280_port
git checkout 280_port

Heiko

On Sunday, December 20, 2009, Channing Walton channingwal...@mac.com wrote:

 ah I see the problem - I know nothing about git!

 I original thought that the URL at the top of the github page for port_280
 would get me port_280 which it doesn't.

 I tried following the instructions here:
 http://wiki.github.com/bricoleurs/bricolage/working-with-branches
 But that isn't working for me:

 % git clone git://github.com/dpp/liftweb.git
 ...
 % cd liftweb/
 % git fetch origin
 % git checkout --track -b port_280 origin/port_280
 fatal: git checkout: updating paths is incompatible with switching branches.
 Did you intend to checkout 'origin/port_280' which can not be resolved as
 commit?

 What should I do? (I've trawled gits help pages but I'm not having any luck)

 Channing
 --
 View this message in context: 
 http://old.nabble.com/Building-Lift-with-scala-2.8.0-tp26858625p26862689.html
 Sent from the liftweb mailing list archive at Nabble.com.

 --

 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.




-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] The future of lift-core

2009-12-20 Thread Heiko Seeberger
2009/12/20 Indrajit Raychaudhuri indraj...@gmail.com

 lift-core is a 'meta' project that can be added as a dependency to a
 Lift project to pull in all the Lift modules. This serves as a singular
 configuration point in a Lift based application.

 However, since lift-core downloads all the Lift modules (irrespective of
 whether the project needs it), adding this as the dependency slow  down
 things for a standard project that doesn't need some additional modules.


From a modularity standpoint pulling in all the numerous Lift modules - some
of them very special - is a bad idea.

Further, the name is a misnomer now!


Yes, it is totally misleading.


 The question, therefore is:
 Should we consider deprecating this?


Yes!


 If yes, what should be the time frame for making the move?


Perfect fit for 2.0.

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] Goals for type and method renaming for Lift 2.0 - was: Open discussion on Lift Name Calling practices

2009-12-18 Thread Heiko Seeberger
 of naming?

 Holder is probably the least problematic of these. The only issue I
 have with it is that FooHolder doesn't say anything about why you
 might want to have that particular kind of container (or indeed have a
 container at all) for a Foo. In some sense, every object that contains
 data is a holder - and I don't think StringHolder makes much sense;
 why does FooHolder?

 
   3) Avoid making the name of the return type part of the name of the
   method. The types should tell the story as much as possible, except
 in
   the case where multiple methods varying only in return type would
   exist (illegal overloads)
 
  I'd be interested in understanding what the specific examples are, but
 I'm
  not sure I'm on board with this.  Sometimes getLiftResponse is a lot
 more
  meaningful than get.

 There were a couple of examples of this in S that I thought were
 suspect, but we can address those individually. In general I think
 this suggestion boils down to DRY.

 
   4) Prefer Scala-style accessors and mutators.
 
  I disagree.  This is one where I have tried a lot of different
 accessors and
  mutators and the current crop is the best of breed.  Sure, it's a
 little
  different, but it is much better.

 I'm talking more about the instances where you've got Scala classes
 with setX and getX rather than x  and x_= - S is inconsistent and
 sometimes uses getX, sometimes uses x

 
  In general, the principle goal of this effort must be improving the
  clarity of the Lift API for both new adopters and for maintainers. We
  now have two days before the goal discussion closes. If anyone has
  any additional objectives they'd like to voice before this window
  closes, please do so now. I'd like to hold a vote on the proposals
  above as well as any other objectives folks may have tomorrow, so that
  any -1's can be ironed out before the 15th.
 
  Kris

 --

 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




  --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




[Lift] Make it possible to add LocParams to MetaMegaProtoUser's menus

2009-12-18 Thread Heiko Seeberger
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

2009-12-14 Thread Heiko Seeberger

 5) Avoid using abbreviations


 I disagree.  When coding with a non-IDE, abbreviations make life much
 easier.


 I agree with David, abbreviations are better.  When I'm trying to get
 something out of my head and into code, I don't want things getting in my
 way.  2 things in this scenario get in my way.  1) autocomplete is slow 2)
 typing is slow.

 Here's something else to think about on this issue.  A good typist,
 familiar with their material can type faster then most code completions can
 operate.  In studying data entry folks at UofP, I noticed something about
 the auto-complete functionality that wasn't obvious to me before.  It's not
 how fast the code complete pops up that slow you down.  It's the mental
 shift from typing to reading that takes the most time.  You always have to
 verify that what the auto-complete is going to use is correct.  This almost
 always takes more time then typing it yourself (assuming an expert typist).


My concern is not at all coding speed which mostly is faster than thinking
speed (at least for stupid pea-brains like me). I am concerned about how
intuitive the Lift API, hence how fast folks will be familiar with it.

To be more precise: I like abbreviations for really obvious stuff like
RequestVar (everybody would know VarIABLES). But I do not like ... well I
cannot find an example right now for an abbreviation in Lift that I do not
like = Thus I guess this is more a general principle and Lift behaves quite
well in this regard.

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] Goals for type and method renaming for Lift 2.0 - was: Open discussion on Lift Name Calling practices

2009-12-13 Thread Heiko Seeberger
2009/12/13 Kris Nuttycombe kris.nuttyco...@gmail.com

 To this point, the only goals that have been recommended for this
 effort are those that I've noted below:

  1) Remove ambiguity wherever possible! There are a number of places
  where very similar names are used to refer to utterly different
  things.

  2) As an aide removing ambiguity, consider outlawing or eliminating
  extremely generic names, or else establish a single way in which a
  given name will be used across Lift. Examples are Field, Info, Holder,
  etc.

  3) Avoid making the name of the return type part of the name of the
  method. The types should tell the story as much as possible, except in
  the case where multiple methods varying only in return type would
  exist (illegal overloads)

  4) Prefer Scala-style accessors and mutators.


Thank you Kris for writing up these goals. I would like to add another one:

5) Avoid using abbreviations


 In general, the principle goal of this effort must be improving the
 clarity of the Lift API for both new adopters and for maintainers.


100% agreed!

In order to make Lift even more popular it is essential to ease adoption.
Often folks require better documentation and we all know that the code (the
API) is the first and best source of documentation.

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] Goals for type and method renaming for Lift 2.0 - was: Open discussion on Lift Name Calling practices

2009-12-13 Thread Heiko Seeberger
And here is another one:

6) Use names related to the nature of the thing being named: We should be
able to know what a type is or a method does from reading its name.

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] New Lift release process wiki page

2009-12-10 Thread Heiko Seeberger
2009/12/10 David Pollak feeder.of.the.be...@gmail.com


 On Wed, Dec 9, 2009 at 11:30 PM, Heiko Seeberger 
 heiko.seeber...@googlemail.com wrote:

 David,

 I do not understand the naming convention Lift_x_version. Is this
 something like Lift_x_2.0 or Lift_2.0 or ...?

 git checkout -b Lift_x_version

 Maybe it is possible to find a better symbol, e.g.
 Lift_MAJOR.MINOR[.MICRO][-QUALIFIER] with QUALIFIER something like
 M8? Anyway, could you please write up some examples in the Wiki?


 Lift-1.1-M8


Ah, OK. Thank you.


 You're welcome (encouraged) to update the process.


Sure!
Did it:

create a new branch for the release:
Name it *Lift-VERSION* with *VERSION = MAJOR.MINOR[.MICRO][-QUALIFIER]*,
e.g. *Lift-2.0-M8* or *Lift-2.0.1*

git checkout -b Lift-VERSION


Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] Next Lift version will be 2.0

2009-12-09 Thread Heiko Seeberger
Indrajit,

Sorry for the very late reply :-(

2009/12/7 Indrajit Raychaudhuri indraj...@gmail.com

 Grand stuff!


Thank you!


 Indeed, I was wondering if we could sync this up with the Round 2 of
 Refactoring exercise
 (
 http://groups.google.com/group/liftweb/browse_thread/thread/450a3e741999b5df
 ).
 New structure, new version.


Definitely yes!


 I am working on this refactoring in a private copy and am planning to
 publish the branch once M8 is out (assuming original schedule of 2 weeks
 from 27th Nov). Would this work with you?


+1

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] New Lift release process wiki page

2009-12-09 Thread Heiko Seeberger
David,

I do not understand the naming convention Lift_x_version. Is this
something like Lift_x_2.0 or Lift_2.0 or ...?

git checkout -b Lift_x_version

Maybe it is possible to find a better symbol, e.g.
Lift_MAJOR.MINOR[.MICRO][-QUALIFIER] with QUALIFIER something like
M8? Anyway, could you please write up some examples in the Wiki?

Thanks,

Heiko

2009/12/10 David Pollak feeder.of.the.be...@gmail.com

 http://wiki.github.com/dpp/liftweb/committer-release-process

 Please note the branch vs. tag change in the process.

 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics

 --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




[Lift] Next Lift version will be 2.0

2009-12-07 Thread Heiko Seeberger
Lifters,

Maybe you followed the discussion about the versioning policy for Lift. The
committers finally decided to have a well defined versioning policy which
you can take from here:
http://wiki.github.com/dpp/liftweb/about-versioning-policy.

Following this policy the next Lift version will be 2.0, not 1.1, because
there are numerous changes and enhancements breaking the source
compatibility. As soon as we change the version numbers in the Maven POMs,
we will let you know via the lift-announce mailing list.

Best regards,

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] Next Lift version will be 2.0

2009-12-07 Thread Heiko Seeberger
2009/12/7 Josh Suereth joshua.suer...@gmail.com


 Just curious what the difference between Major and Minor truly is as both
 can break source/binary compatibility?   My feeling here is that sticking to
 strick source-compatibility for minor releases is actually a bonus.


Major changes (e.g. moving/renaming an API class, changing an API method's
signature, etc.) will break source compatibility for sure, i.e. for users
and implementers. Minor changes (e.g. adding an abstract method to an API
trait) will at maximum break source compatibility for implementers. So
from a user's perspective minor changes add new stuff which could be used
but do not break source compatibility, whereas major changes will require
changing the source code.

Examples: Renaming LiftRules to LiftConfig is a major change, adding a
second parameter to LiftRules.parseDate is also a major change. But adding a
second method LiftRules.parseDate is only a minor change (in this case even
binary compatibility should be given).

The other question I have is about deprecations.   What's your plan for
 handling these?   When can deprecated features be removed, etc.   That might
 feed into the source-compatibility issues in minor versions.


This is a good question and I do not have a plan yet ;-) As a first shot I
would say that deprecated features have to survive all minor changes (must
not break source compatibility for users) and maybe one major change. The
latter is the question we have to discuss ...


 I think this is great stuff!  Whatever is decided here will help shape the
 future of the Scala community's versioning, so I hope you don't mind my
 pestering ;)


Don't worry ;-)

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] Please welcome Jon Hoffman to the Lift committers

2009-12-02 Thread Heiko Seeberger
Welcome, Jon!

2009/12/3 David Pollak feeder.of.the.be...@gmail.com

 Folks,

 It may or may not be true that for Jon Hoffman that Martin Odersky
 praises [his] valuable contributions. [He] can read APIs in the 
 dark.http://udorse.com/about/jobsBut Jon's made a valuable contribution to 
 Lift as part of the community.
 Now, he's a committer.

 Please join me in welcoming Jon.  I'm looking forward to his S3-related
 additions to Lift and any other goodies he wants to toss into Lift.

 Jon, welcome and I'm looking forward to the grandeur of your contributions!

 Thanks,

 David

 PS -- Derek please add Jon to the review board.

 PPS -- My wife loves the Udorse jobs page.


 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics

 --
 You received this message because you are subscribed to the Google Groups
 Lift group.

 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] How to get the servlet context

2009-11-30 Thread Heiko Seeberger
All this is brittle, at least special! Please use the temp dir the
servlet context will offer you. Tomcat and Jetty offer one.

Heiko

On Monday, November 30, 2009, jhonig al...@xs4all.nl wrote:
 Marius,

 I tried to create a link from the webapp dir to another location with
 rw-access, but that was not allowed...  My conclusion was that you
 can't have symbolic links to locations outside the war.

 My problem is that there are three different locations that could all
 be interpreted as a root for looking up resources.  I've found
 nothing
 suggesting one over the other, and none of them works.  I assume
 there are more variables involved that I don't even know of.

 Job

 On Nov 30, 10:27 pm, Marius marius.dan...@gmail.com wrote:
 Ok I may be missing something essential from all this thread but why
 not use a folder from the user's home directory? If your app runs say
 under jetty OS user should heve read/write rights to write on the
 home user file-system. Even if not (although I haven't encountered the
 case) those rights can be granted by an admin. So why do you need
 special container allocated locations to write files?

 Br's,
 Marius

 On Nov 30, 11:18 pm, jhonig al...@xs4all.nl wrote:

  Hi Tim, Jeppe, and others who have replied...

  I have spent a few more hours, but there are just too many variables
  and I haven't been able to figure them out.
  I logged the various locations (running under a standalone jetty, not
  mvn jetty:run, and got this:

    INFO - TEMP = /tmp/Jetty_0_0_0_0_8080_tent.
  0.1.SNAPSHOT.warvtra6b
    INFO - REAL = /tmp/Jetty_0_0_0_0_8080_tent.
  0.1.SNAPSHOT.warvtra6b/webapp
    INFO - URL = file:/tmp/Jetty_0_0_0_0_8080_tent.
  0.1.SNAPSHOT.warvtra6b/webapp/WEB-INF/classes/

  I tried to access images, both from the HTML served to my browser and
  from Scala snippets.   I used the
  following paths:

    Images/testimage.jpg
    work/Images/testimage.jpg
    classes/work/Images/testimage.jpg
    WEB-INF/classes/work/Images/testimage.jpg.

  The latter path is what I see in my .war file...   I have no special
  filters.  I tried to add entries to my site map,
  but none of them worked.  About to give up.  Hope somebody will help
  me.

  Job H.

  On Nov 28, 3:14 pm, jhonig al...@xs4all.nl wrote:

   Dear Tim and Heiko,

   I tested a few things under mvn jetty:run...:

     getRealPath gives me ./src/main/webapp
     the temp attribute is set to ./target/work
     and the location is ./target/classes

   While the war contains classes/work which is again different...   I
   didn't manage to get jetty to serve contents from any other directory
   than the first one.

   Didn't try to run it on the standalone jetty, since I still don't know
   how
   to tell jetty to serve contents that is not under the webapp
   directory.
   Probably have to do something with the site map which I don't fully
   understand.

   Guess my main problem is that I don't have any experience in this
   field (jetty/lift) and thought it wouldn't be to difficult to port my
   website
   to lift and enhance it a little on the fly.

   To be continued...

   Job Honig

   On Nov 28, 12:52 am, Timothy Perrett timo...@getintheloop.eu wrote:

Here's a nugget of information for you that will help (as I do 
something similar to what you want in one of my applications):

  val protectionDomain: ProtectionDomain = 
classOf[bootstrap.liftweb.Boot].getProtectionDomain()
  val location: URL = protectionDomain.getCodeSource().getLocation()

Print the value of location, and that will get you headed in the right 
direction ;-) Moreover, if your using jetty, if there is a work 
directory next to where the war file is, jetty will automatically 
expand the war into that work folder... if not, it makes a temp 
directory in the relevant OS temp directory (/var/tmp on *nix OS)

Godspeed.

Tim.

On 27 Nov 2009, at 21:49, Heiko Seeberger wrote:

 Job,

 

-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] Sitemap + Menu Names + Change Order

2009-11-29 Thread Heiko Seeberger
Hannes,

2009/11/29 Hannes hannes.flo...@gmx.li


 I couldn't find anything about how to change a menu name, that is
 generated from CRUDify.


Overwrite CRUDify.createMenuName, etc.


 Furthermore, I want to change the internal order
 of CRUDify menus. I believe that its more natural to use, when the
 create item comes before the list item.


Overwrite CRUDify.menus

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] Sitemap + Menu Names + Change Order

2009-11-29 Thread Heiko Seeberger
Hi Hannes,

2009/11/29 Hannes hannes.flo...@gmx.li


 thanks for the quick and helpful answer!


You're welcome ;-)


 The renaming was quite easy, but what do I've to write inside
 CRUDify.menus?


Please take a look at the source code (CRUDify.scala):
  def menus: List[Menu] =
  List(showAllMenuLoc, createMenuLoc, viewMenuLoc,
   editMenuLoc, deleteMenuLoc).flatMap(x = x)

Overwrite it as you need, e.g. (create and showAll swapped):
  def menus: List[Menu] =
  List(createMenuLoc, showAllMenuLoc, viewMenuLoc,
   editMenuLoc, deleteMenuLoc).flatMap(x = x)

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] Refactoring Round 2

2009-11-27 Thread Heiko Seeberger
Excellent proposal!

Heiko

On Friday, November 27, 2009, Indrajit Raychaudhuri indraj...@gmail.com wrote:
 Folks,

 In continuation to the refactoring initiative and following up on the
 discussion that we had on the last committers call, here we have the
 next round of broad based project structure refactoring proposal. This
 is themed around the idea of splitting the build system into separate
 smaller 'projects' with clearly demarcated responsibilities between
 them. In the way, these projects can have independent life-cycles on
 their own without coming in the way of each other (but still continue
 to have a dependency hierarchy).

 Here are the set of projects to begin with:

 1. framework (http://github.com/dpp/liftweb/tree/branch/framework):
 The regular Lift as we have today (minus lift-archetype, lift-
 examples, lift-misc).
 Thus we would have:
 framwork/pom.xml
 framwork/lift-base
 framwork/lift-persistence
 framwork/lift-modules


 2. archetypes (http://github.com/dpp/liftweb/tree/branch/
 archetypes):
 The lift-archetypes from Liftweb.
 archetypes/pom.xml
 archetypes/lift-archetype-blank
 archetypes/lift-archetype-basic
 archetypes/lift-archetype-jpa-blank-single
 archetypes/lift-archetype-jpa-blank
 archetypes/lift-archetype-jpa-basic


 3. examples (http://github.com/dpp/liftweb/tree/branch/examples):
 The lift-archetypes from Liftweb. The big uptake for archetypes and
 examples is the reduction of build time for building full Lift.
 Individuals building Lift might not always be interested in building
 non ancillary packages like lift-archetypes and lift-examples.
 examples/pom.xml
 examples/example1
 examples/example2

 4. resources (http://github.com/dpp/liftweb/tree/branch/resources:

 4a. project-parent: A pure POM based project to be canonically used by
 all Lift family of projects (liftweb, lift-archetype, lift-examples
 etc.). Lot of what has gone in liftweb/pom.xml should get moved here.
 Obviously, this would contain the most generic configuration that
 holds true for all projects of Lift (#1, #2, #3).

 4b. site-skin: Lift specific site skin instead of relying on org.scala-
 tools.skins:scala-skin-simple

 5. references (http://github.com/dpp/liftweb/tree/branch/
 references):
 Lift documentations and presentations. These don't need to show up in
 the project hierarchy in the IDE.

 6. installer (http://github.com/dpp/liftweb/tree/branch/installer):
 The usual lift-installer that is tucked inside lift-misc. Again, these
 are unnecessarily showing up in the project hierarchy in the IDE.

 I am floating the idea beforehand and would be keen to have input from
 committers, the pros and cons and any other general feedback before
 proceeding.

 Thoughts would be very welcome :)

 Cheers, Indrajit

 --

 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.




-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] How to get the servlet context

2009-11-27 Thread Heiko Seeberger
According to the Servlet spec each webapp has got a private temporary
directory. I cannot remember exactly how to get this, maybe
ServletContext.getTmpDir(). Please take a look at the spec.

Heiko

On Friday, November 27, 2009, jhonig al...@xs4all.nl wrote:
 Thanks Ross, I will try this!   Is there a generic way to get to a
 kind
 of sandbox directory where snippets can read/write files?

 Job

 On Nov 27, 5:12 pm, Ross Mellgren dri...@gmail.com wrote:
 A way you can get the Servlet context is like this:

 LiftRules.context match {
      case context: HTTPServletContext = // do something with
 context.ctx which is the javax.servlet.ServletContext
      case _ = // do something when the context is not a servlet
 context, perhaps log an error

 }

 The reason you need the match is because Lift can run on non-servlet
 web containers, so Lift does not guarantee there is a Servlet context
 in scope.

 Hope that helps,

 -Ross

 On Nov 27, 2009, at 10:51 AM, jhonig wrote:

  LS,

  After Ross' kind invitation to post any other questions I might have,
  I'll start with
  this one:

  The web application I am developing needs a scratch directory to white
  scaled
  images to.  I first try to use a subdir of /tmp and put a symbolic
  link in place to
  access that directory from my project's context.  However, this got me
  an
  error message (something about an aliased resource), so after some
  searching
  around I decided the best way is to create a directory inside WEF-INF
  and
  access it through getServletContext ().getRealPath (/...).

  From the APIdocs I found out that an instance of a ServiceContext is
  passed
  to HTTPServletContext, but I haven't been able to find if that is the
  instance I
  need, or how to get an instance of HTTPServletContext...

  Note: I am currently able to read/write temporary finds when running
  through
  mvn getty:run, but I need a solution that still works when I deploy a
  war with
  an existing jetty server.

  Thanks for any hints!

  Job Honig

  --

  You received this message because you are subscribed to the Google
  Groups Lift group.
  To post to this group, send email to lift...@googlegroups.com.
  To unsubscribe from this group, send email to 
  liftweb+unsubscr...@googlegroups.com
  .
  For more options, visit this group 
  athttp://groups.google.com/group/liftweb?hl=en
  .

 --

 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.




-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] Re: How to get the servlet context

2009-11-27 Thread Heiko Seeberger
File tempdir = (File)
config.getServletContext().getAttribute(javax.servlet.context.tempdir)


2009/11/27 jhonig al...@xs4all.nl

 Dear Heiko,

  According to the Servlet spec each webapp has got a private temporary
  directory. I cannot remember exactly how to get this, maybe
  ServletContext.getTmpDir(). Please take a look at the spec.

 I started reading the spec, but didn't find it yet.  ServletContext
 doesn't
 have any obvious way to get to a temporary dir, but I assumed I could
 create one.  Would probably need to tweak a security policy to be able
 to write to it, but that would be the next step.

 Job H.

 --

 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.





-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




Re: [Lift] Re: How to get the servlet context

2009-11-27 Thread Heiko Seeberger
Job,

This directory is managed by the servlet container and as far as I know
there is little you can do to configure the location. If you use Tomcat you
are able to specify CATALINA_BASE and it will be somewhere beneath that
directory, I believe it is work/Catalina/localhost/WABAPP-NAME.

Regarding serving images from there: Depending on the configuration of the
servlet container WARs are not unpacked, hence there is no standard way to
bring these images into your webapp. I think you will not be able to have
the servlet container serve these images directly. But it should be easy to
write a ServletFilter or something that will do it for you.

Heiko

2009/11/27 jhonig al...@xs4all.nl

 Heiko,

 In the meantime, I found that solution as well...   I tried it, and
 the default seems to
 be a work directory in target.  I guess I can set another value
 for the attribute
 if I manage to convince jetty to do that for me.   What I forgot to
 mention is that
 the directory is to contain images that are to be served by jetty...
 So it means
 the directory should be logically under webapp, but not in the war (of
 course).

 If I use a link from inside the war to some regular file system
 location, I'll
 probably run into the same problem as before.  Any idea how to do
 this?

 Job H.

 On Nov 27, 6:56 pm, Heiko Seeberger heiko.seeber...@googlemail.com
 wrote:
  File tempdir = (File)
  config.getServletContext().getAttribute(javax.servlet.context.tempdir)
 
  2009/11/27 jhonig al...@xs4all.nl
 
 
 
   Dear Heiko,
 
According to the Servlet spec each webapp has got a private temporary
directory. I cannot remember exactly how to get this, maybe
ServletContext.getTmpDir(). Please take a look at the spec.
 
   I started reading the spec, but didn't find it yet.  ServletContext
   doesn't
   have any obvious way to get to a temporary dir, but I assumed I could
   create one.  Would probably need to tweak a security policy to be able
   to write to it, but that would be the next step.
 
   Job H.
 
   --
 
   You received this message because you are subscribed to the Google
 Groups
   Lift group.
   To post to this group, send email to lift...@googlegroups.com.
   To unsubscribe from this group, send email to
   liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com
 
   .
   For more options, visit this group at
  http://groups.google.com/group/liftweb?hl=en.
 
  --
  Heiko Seeberger
 
  My job: weiglewilczek.com
  My blog: heikoseeberger.name
  Follow me: twitter.com/hseeberger
  OSGi on Scala: scalamodules.org
  Lift, the simply functional web framework: liftweb.net

 --

 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.





-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.




[Lift] Re: Call it Lift 2.0

2009-11-23 Thread Heiko Seeberger
Please let's not widen this discussion into something else but the question
which versioning policy we are to apply. Building some kind of
compatibility layer could be done regardless of the next Lift version
number.

Do we have a consensus, that there are several substantial changes breaking
source and binary compatibility? And do we have a consensus, that this is
something which requires increasing the major version number?

Heiko

2009/11/23 Josh Suereth joshua.suer...@gmail.com

 The real question is could you still keep source compatibility if you made
 use of some interesting implict and @deprecated annotations?   I believe
 those are acceptable.

 - Josh


 On Mon, Nov 23, 2009 at 6:05 AM, Timothy Perrett 
 timo...@getintheloop.euwrote:

 Interesting - this is something i've not actually thought about: If we
 were to compile a list of all the breaking changes in 1.1, perhaps that
 would give some focus to this discussion... as josh points out, there are
 most likely quite a few now and 1.0 - 1.1 is a fairly short jump.

 Loc and LocParam
 Actor - LiftActor
 Full,Box etc have moved packages
 JSON parsing alterations and changes in JsExp

 Im probably missing a number of others, but we are talking about some
 fairly significant breaks here, right?

 Cheers, Tim

 On 23 Nov 2009, at 07:09, Heiko Seeberger wrote:

  Josh,
 
  Thank you for your brilliant elaboration of compatibility issues!
 
  2009/11/22 Josh Suereth joshua.suer...@gmail.com
  The real question is, with all these breaking changes in lift 1.1, has
 any attempt been made at source-compatability?   If not, I would argue a
 bigger version jump than 1.1.
 
  The current Lift is not source compatible with 1.0.x, just consider Box
 moved from ...util to ...common.
  Hence you would go for 2.0, right?
 
  Also, there is the possibility of taking the version system and adding a
 functionality milestone version at the begginning.  In this case, you can
 use that number for marketting purposes (e.g. Lift goes 1.0!).   Your
 version number would then be   Marketing.SourceCompatability.All but
 Trait BinaryCompatability.Binary Compatibility.
 
  I am all against using versioning policy for marketing!
 
  Heiko Seeberger
 
  My job: weiglewilczek.com
  My blog: heikoseeberger.name
  Follow me: twitter.com/hseeberger
  OSGi on Scala: scalamodules.org
  Lift, the simply functional web framework: liftweb.net
 
 
  --
 
  You received this message because you are subscribed to the Google
 Groups Lift group.
  To post to this group, send email to lift...@googlegroups.com.
  To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
  For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=.

 --

 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=.



  --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=.




-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net



-- 
Heiko Seeberger
Managing Director Technology

Besuchen Sie unser Eclipse Demo Camp am 26.11. in Stuttgart
http://wiki.eclipse.org/Eclipse_DemoCamps_November_2009/Stuttgart

Weigle Wilczek GmbH
Martinstraße 42-44
73728 Esslingen
Deutschland

T (+49) 711 46050250
F (+49) 711 45999829
www.weiglewilczek.com

Geschäftsführer / Managing Directors: Dr. Jörn Weigle, Dr. Stephan Wilczek,
Heiko Seeberger
Sitz der Gesellschaft / Domicile: Esslingen a. N.
Amtsgericht / Register Court: Stuttgart, HRB 214442
USt-Ident.-Nr. / VAT ID: DE 213 472 880

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=.




[Lift] Re: Call it Lift 2.0

2009-11-22 Thread Heiko Seeberger
2009/11/21 Josh Suereth joshua.suer...@gmail.com

 I think eclipse and maven might be two of the only projects following that
 convention (besides others in the eclipse ecosystem).


I think that Spring also follows the recommended OSGi versioning policy, but
to be sure I will check with some of the Spring folks. And what about Java
EE? Just remember 2.0-2.1 (small refinements and additions) and then 3.0
(very very breaking stuff).


 The question in my mind is what is the popular version number convention in
 the Scala ecosystem.


As far as I can tell, e.g. from the 2.8 or 3.0 discussion on
scala-internals, not many folks from Scala world are interested or trustful
in versioning policies. So why not make Lift the thought leader in this
regard?

Heiko

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=.




[Lift] Re: Call it Lift 2.0

2009-11-22 Thread Heiko Seeberger
Josh,

Thank you for your brilliant elaboration of compatibility issues!

2009/11/22 Josh Suereth joshua.suer...@gmail.com

 The real question is, with all these breaking changes in lift 1.1, has any
 attempt been made at source-compatability?   If not, I would argue a bigger
 version jump than 1.1.


The current Lift is not source compatible with 1.0.x, just consider Box
moved from ...util to ...common.
Hence you would go for 2.0, right?


 Also, there is the possibility of taking the version system and adding a
 functionality milestone version at the begginning.  In this case, you can
 use that number for marketting purposes (e.g. Lift goes 1.0!).   Your
 version number would then be   Marketing.SourceCompatability.All but
 Trait BinaryCompatability.Binary Compatibility.


I am all against using versioning policy for marketing!

Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=.




[Lift] Re: Call it Lift 2.0

2009-11-21 Thread Heiko Seeberger
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

2009-11-20 Thread Heiko Seeberger
Folks,

I would like to bring this version discussion to an end.

I would prefer 2.0 but, I am also cool with 1.1. If there are still unheard
arguments for 2.0, please speak out now.

For me it is important that there is a version policy in place, such that
everyone knows what's the difference between a change to 1.1 or to 1.0.2. As
we probably will stick to Lift 1.1, IMHO the version policy has to be:
Increasing the major or minor version number means breaking changes,
increasing the micro version number keeps the API stable.. Opinions?

Heiko

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=.




Re: [Lift] Lift Scala style.

2009-11-18 Thread Heiko Seeberger
Hi,

As now is the time to improve names, I suggest to change the Actor names
in lift-common:

SimpleActor - Receiver
SimplestActor - DefaultReceiver
TypedActor - Actor
GenericActor - BaseActor
SimplestGenericActor - DefaultActor

Heiko

2009/11/16 Kris Nuttycombe kris.nuttyco...@gmail.com


 Hi, all,

 This is just a starting point for debate with a hope of eventual
 consensus on something that's ultimately somewhat trivial matter.
 Since style is currently a topic of discussion on the main scala-users
 list, I thought it an appropriate time to bring it up.

 Lift is one of the most prominent, perhaps the most prominent Scala
 applications in current existence, and as such I think it has a
 significant role to play in exemplifying good Scala style. At the same
 time, Lift has also been developed over the course of its' developers
 familiarization with the language, and so it displays some occasional
 stylistic warts. At the same time, major changes coming with Scala
 2.8, particularly named  default parameters, may be something we want
 to take advantage of in ways that may have a substantial effect on
 usability of our APIs.

 I guess my general question is, how does the Lift community want to
 deal with the stylistic warts and naming inconsistencies, and how do
 we want to go about integrating some of these new features? In some
 cases, we may be able to use a strategy of giving some operations new
 names and deprecating the old, but in others this might lead to some
 really hacky looking APIs since we've already got good names, and
 changing their signatures might break a lot of code. Also, what are
 the big warts on Lift that ought to be resolved by renames or
 named/default parameters?

 Two naming issues that have come up recently in Lift internal
 discussions follow:

 First, Alex Boisvert suggested that S.init be renamed to S.doWith to
 have more consistency with Req and LiftSession. At least internally, I
 think that the consensus was that this wasn't necessarily appropriate.

 Second, I suggested the deprecation of the pattern of using apply() on
 AnyVar to provide setter functionality, since to me using something
 that looks like function application to do a mutation seems
 ill-conceived. My initial suggestion was to piggyback our
 functionality on the update() rewriting that is done by Scala, but on
 further reflection and David's feedback I realized that this would be
 even uglier since you'd have to use myRequestVar() = foo. So, what
 would folks think about defining the symbolic method := on both
 AnyVal and within the Mapper framework instead, with the goal of
 eventual deprecation of the apply style?

 Thirdly, I would like to propose that any marker traits (i.e. traits
 that declare no methods) within Lift either be sealed, or have the
 relevant methods tailored to the shared functionality they represent
 added (or both.) Match errors can be nasty, and sealing the traits
 (providing an extension point for users if need be) can help the
 compiler help us to eliminate that class of errors.

 Fourth, in compiling the Lift source I see far more warnings related
 to type erasure in match statements than I'm strictly comfortable
 with. My personal plan is to start working through these and
 eliminating them where possible, but in general I think that we as a
 community should start running all of our builds with all warnings
 enabled, and strive to eliminate them. The Scala type system can be
 complicated, but in my experience it is virtually always possible to
 avoid such warnings (and type unsafety!) with a bit of extra thought.
 The less we subvert the type system, the less likely we are to have
 unexpected errors.

 Kris

 --~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to liftweb@googlegroups.com
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en
 -~--~~~~--~~--~--~---




-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=.




Re: [Lift] Re: Call it Lift 2.0

2009-11-18 Thread Heiko Seeberger
Jim,

Let's stop this discussion (I won't convince you and you wont't convince me)
and start doing something more valuable: Are you in town for a couple of
beers?

Heiko

2009/11/18 Jim Barrows jim.barr...@gmail.com



 On Wed, Nov 18, 2009 at 10:25 AM, Heiko Seeberger 
 heiko.seeber...@googlemail.com wrote:

 Jim,

 2009/11/17 Jim Barrows jim.barr...@gmail.com


 The behavior of a method, it's implementation is part of the contract I
 have with the library.


 Behavior yes, as long as agreed part of the contract. Implementation no.


 Implementation is not behavior?




 So, just because you, or some committee ...


 Not a committe, but the developer of the library.


 I don't care who.  Somebody, who isn't me, is deciding whether the impact
 to me is is minor (ie 0.0.1), major (ie 0.1.0), or catastrophic (ie 1.0.0).



 ... think that the change is minor, I still have to thoroughly test
 everything that uses your library.


 Did you hear me saying Don't test your app when a required library
 changes its version?


 Yes, actually your attempting to use a scheme to tell me what I need to
 test.  If you agree that with every change, I need to test those changes,
 then why complicate everybody's lives with number schemes?  Because whether
 a someone uses the OSGI complex scheme of numbers, or Ubuntus year.month
 scheme, it still means I have to read the change list, and test the things
 that changed.




 As to your As Lift also is to support OSGi (already some support in
 place) it would be beneficial to stick to this version policy comment.  I
 counter with Lift works on Ubuntu it would be beneficial to stick to this
 version policy and of course Lift runs on scala  it would be beneficial to
 stick to this version policy, or better yet Lift runs  on the Java VM it
 would be beneficial to stick to this version policy.  All three of my
 arguments have far more to do with Lift running then OSGI does.


 If you are not interested in OSGi or Lift's OSGi support, then just ignore
 it. As far as I know neither Ubuntu, nor Scala, nor the JVM care about
 Lift's version number or version strategy. But OSGi does!


 You miss my point.  My point was that the argument you make is useless.




 That's what I really need to know,


 Please accept that other folks might have different needs.


 You cut the context.  However Everyone needs to know that things
 changed.  And they need to know what changed.  The OSGI scheme attempts to
 tell the developer how severe the change is, without knowing how the
 developer is using the library.  That's useless.
 --
 James A Barrows

  --
 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=.




-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=.




Re: [Lift] foursquare.com now basically all on Lift

2009-11-17 Thread Heiko Seeberger
Very very cool!

Heiko

2009/11/17 harryh har...@gmail.com

 I've been a bit coy about it on the list, but three months ago when I
 joined the team at foursquare.com I made the final decision that we
 would port our webservers to Scala/Lift.  It took about 3 months, but
 foursquare.com is now basically running only on Lift(1).  This
 includes the website, a mobile website (m.foursquare.com) and a simple
 (but growing!) REST api (api.foursquare.com).

 I'd like the send a huge thank you to dpp and the rest of the Lift
 team. You've built a really great framework here, and I look forward
 to using it and seeing it grow for many years to come. An additional
 thanks goes out to all those who have answered my many random
 questions over the past couple of months.

 For those who haven't yet found out about foursquare, you can read
 more about it here: http://foursquare.com/learn_more

 Anyways, that's about enough self promotion, but I did want to
 officially let the community know about what I hope will be a fairly
 high profile site that is using Lift.

 -harryh

 (1) Haven't quite ported feeds.foursquare.com, and there is a legacy
 PHP based REST api that will live on for a bit longer as it supports
 current versions of our iPhone app.

 --

 You received this message because you are subscribed to the Google Groups
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to
 liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=.





-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=.




Re: [Lift] Re: Call it Lift 2.0

2009-11-17 Thread Heiko Seeberger
2009/11/17 Naftoli Gugenheim naftoli...@gmail.com

 But it's up to DPP because it's his project.


Of course David kicked off Lift and he is managing the project actively.
Yet there is also a huge Lift community. Hence I do not agree calling Lift
his project.

And even though I do not agree with every decision, I think that it is very
beneficial for Lift to have a decision maker like him. Just look at the
figures: There are 30+ committers and 1500+ members in this list. Ain't that
successful?

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=.




[Lift] Call it Lift 2.0

2009-11-16 Thread Heiko Seeberger
Hi,

There has been a large amount of new stuff and also some breaking changes
since Lift 1.0. As an OSGi guy I suggest we call the next version Lift 2.0,
because increasing the major version number will show the world that there
are breaking changes and/or cool new features. At least, this is how
versions are used in OSGi land. OK, I know that Sun follows another version
strategy (keeping the major version fixed to 1 forever) and the Scala folks
also seem to be stick to 2.x (quite a lot people would like 2.8 to be 3.0),
but IMHO this is no reason for Lift to follow the same mislead strategy. So
what do you think?

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



Re: [Lift] Re: Call it Lift 2.0

2009-11-16 Thread Heiko Seeberger

 I think version numbers are idiotic, and created by the marketing
 department, and not engineers.


I strongly disagree: An appropriate version strategy is not at all about
marketing but expresses valuable information. In OSGi increasing the major
version means breaking changes in the API, increasing the minor version
means nonbreaking changes in the API and increasing the micro version means
no changes to the API but only changes of the implementation. Further these
versions are used to declare dependencies between modules (OSGi bundles)
which results in a high degree of trust that different modules work
seamlessly together. As Lift also is to support OSGi (already some support
in place) it would be beneficial to stick to this version policy.

I think a 2.0 needs more time with a 2.0 mindset.

Once 2.0 is on the table there may be more redesign involved.


I disagree: Versions should not express a mindset but information about
(non)breaking API changes. That's all, no magic, no marketing, no mindset.

Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=.




Re: [Lift] Re: Call it Lift 2.0

2009-11-16 Thread Heiko Seeberger
2009/11/17 David Pollak feeder.of.the.be...@gmail.com

 The current Lift is not a major change to Lift 1.0, it's a minor
 progression and a lot of tuning of the developer experience.


There are breaking changes to the API which in the version policy suggested
by me (the OSGi way) means increasing the major version number. OK, of
course we need not stick to this particular version policy, but it would be
beneficial to have one. What about: Increasing the minor version number
(e.g. 1.0 - 1.1) means breaking changes to the API. Increasing the micro
version number (e.g. 1.1.0 - 1.1.1) means *no* breaking changes to the API.

Heiko

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--

You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=.




  1   2   3   >