Re: [Lift] Customizing meta fields

2010-03-08 Thread Martin Dale Lyness
Again, thank you so much for the help! The head merge feature is perfect for
this situation i described and my next line of though is right inline with
how you describe bind points!

Thanks again!

-- Martin

On Mon, Mar 8, 2010 at 12:47 PM, Ross Mellgren  wrote:

> For your particular example, you can use head merge as Naftoli suggests.
> Head merge is a behavior of Lift templates where any  tags will be
> merged together for the final output, so you put your meta
> name="description" in each of the specific places, any general head stuff
> you want in your surrounding template and they will magically get folded
> together at render time.
>
> For other cases, you have a couple tools at your disposal:
>  - RequestVars -- variables that are local to a particular page request.
> You can use these inside snippets to capture and recover values during
> template processing.
>  - Bind points. In a surrounding template you can use tags like  name="foobar" /> and then define what to put there in the surrounded
> template using the content
>
> And there are more. Hopefully head merging will work for you in this case.
>
> -Ross
>
> On Mar 7, 2010, at 8:25 PM, Martin Dale Lyness wrote:
>
> Thank you Ross, for the very informative response!
>
> Now, I consider SEO to be closer to a designer task than a developer task
> so keeping the power in the design documents would be my best idea. Is there
> anyway to allow individual pages to define blocks that are read into the
> snippets and then injected into the template?
>
> Here is the scenario i'm thinking of:
> 1. A single uniform website template: default.html
> 2. Several HTML files: index.html, product_list.html, product_overview.html
> 3. Each of these HTML files containing  tags referencing
> snippets.
>
> What i would want is for index.html, product_list.html, and
> product_overview.html to all use default.html and various Snippet classes.
> Now for SEO i would want the meta tags in the header of default.html to be
> customized to index.html, product_list.html, and product_overview.html;
> furthermore, product_list and product_overview are dynamic pages so they
> would need further customization based on what the snippets are returning.
>
> Essentially, i would want tags something like:
> This site is totally awesome, better than all our
> competitors   in index.html
> Look at all these products in
> %%category_name%%in product_list.html
> %product_name% - %product_description%
> in product_overview.html
>
> The conceptual road block for me is coming from the controller first
> pattern used in frameworks like Rails. In lift snippets are not really the
> same conceptually. If i use the second proposed method
> (i.e.  wrapping the entire template) i would have a
> battle between snippets used by each page. For example, perhaps i have a
> product overview snippet that sets the meta one way and a login snippet that
> sets it another way (intended for when show standalone in a login.html).
>
> The first solution with using a  to inject a
> snippet at a meta location fits better because it would allow me to create a
> generic function that would attempt to create the keyword and description
> data based on whatever global information is made available to snippets by
> lift (i.e. Request Parameters?). My only problem with using this option is
> it puts all of the text on the developer side forcing the dev team to update
> descriptions and keywords where really the designers should be doing this.
>
> Does anyone have a suggestion on how to put the power in the hands of the
> designers in this type of situation?
>
> -- Martin
>
> On Sun, Mar 7, 2010 at 6:17 PM, Ross Mellgren  wrote:
>
>> To be parsed by the bind, it must be enclosed by
>> ...
>>
>> There is relatively little magic -- Lift goes through your template
>> looking for lift: prefixed tags. For those tags, it will look up a snippet
>> class by using the part before the period (HelloWorld, in the above example)
>> and then look for a method on that snippet class mentioned after the period
>> (hello in the example). If there is no period, the method is assumed to be
>> called "render".
>>
>> Once that method is found, the method is called with the contents of the
>> lift: tag, and the result of the method call is spliced into the XML to
>> replace the lift: tag.
>>
>> bind is a function that does something kind of similar to overall template
>> processing, except you supply some prefix other than lift: (b: in the
>> example) and a limited set of things after the colon that are valid (time
>> and meta_desc in 

Re: [Lift] Customizing meta fields

2010-03-07 Thread Martin Dale Lyness
Thank you Ross, for the very informative response!

Now, I consider SEO to be closer to a designer task than a developer task so
keeping the power in the design documents would be my best idea. Is there
anyway to allow individual pages to define blocks that are read into the
snippets and then injected into the template?

Here is the scenario i'm thinking of:
1. A single uniform website template: default.html
2. Several HTML files: index.html, product_list.html, product_overview.html
3. Each of these HTML files containing  tags referencing snippets.

What i would want is for index.html, product_list.html, and
product_overview.html to all use default.html and various Snippet classes.
Now for SEO i would want the meta tags in the header of default.html to be
customized to index.html, product_list.html, and product_overview.html;
furthermore, product_list and product_overview are dynamic pages so they
would need further customization based on what the snippets are returning.

Essentially, i would want tags something like:
This site is totally awesome, better than all our
competitors   in index.html
Look at all these products in
%%category_name%%in product_list.html
%product_name% - %product_description%
in product_overview.html

The conceptual road block for me is coming from the controller first pattern
used in frameworks like Rails. In lift snippets are not really the same
conceptually. If i use the second proposed method
(i.e.  wrapping the entire template) i would have a
battle between snippets used by each page. For example, perhaps i have a
product overview snippet that sets the meta one way and a login snippet that
sets it another way (intended for when show standalone in a login.html).

The first solution with using a  to inject a
snippet at a meta location fits better because it would allow me to create a
generic function that would attempt to create the keyword and description
data based on whatever global information is made available to snippets by
lift (i.e. Request Parameters?). My only problem with using this option is
it puts all of the text on the developer side forcing the dev team to update
descriptions and keywords where really the designers should be doing this.

Does anyone have a suggestion on how to put the power in the hands of the
designers in this type of situation?

-- Martin

On Sun, Mar 7, 2010 at 6:17 PM, Ross Mellgren  wrote:

> To be parsed by the bind, it must be enclosed by
> ...
>
> There is relatively little magic -- Lift goes through your template looking
> for lift: prefixed tags. For those tags, it will look up a snippet class by
> using the part before the period (HelloWorld, in the above example) and then
> look for a method on that snippet class mentioned after the period (hello in
> the example). If there is no period, the method is assumed to be called
> "render".
>
> Once that method is found, the method is called with the contents of the
> lift: tag, and the result of the method call is spliced into the XML to
> replace the lift: tag.
>
> bind is a function that does something kind of similar to overall template
> processing, except you supply some prefix other than lift: (b: in the
> example) and a limited set of things after the colon that are valid (time
> and meta_desc in the example)
>
> So, you might want something like this instead:
>
> 
>
> class HelloWorld {
>
>def meta_desc(ns: NodeSeq): NodeSeq = Text("test desc")
>
> }
>
> Which will result in this XHTML:
>
> test desc
>
> Or, if you want to keep it in the hello method, you'd then have to move the
>  to the outside of the template:
>
> 
>   ...
>   
> 
> 
>...
>
> 
>
> Hope that helps,
> -Ross
>
>
> On Mar 7, 2010, at 4:38 AM, Martin wrote:
>
> > How would one go about having dynamic description and keyword meta
> > tags in a template? Here is what i've tried:
> >
> > default.html
> > 
> >
> > HelloWorld.scala
> > Helpers.bind("b", in, "time" -> date.map(d => Text(d.toString)),
> > "meta_desc" -> "test desc")
> >
> > I'm using a basic archetype build of 2.0-M3 and it produces an error:
> >
> > This page contains the following errors:
> >
> > error on line 6 at column 28: Namespace prefix b on meta_desc is not
> > defined
> > Below is a rendering of the page up to the first error.
> >
> >
> > It appears to me that the template is not parsed by the Helpers.bind,
> > is this correct?
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Lift" group.
> > To post to this group, send email to lift

[Lift] Customizing meta fields

2010-03-07 Thread Martin
How would one go about having dynamic description and keyword meta
tags in a template? Here is what i've tried:

default.html


HelloWorld.scala
Helpers.bind("b", in, "time" -> date.map(d => Text(d.toString)),
"meta_desc" -> "test desc")

I'm using a basic archetype build of 2.0-M3 and it produces an error:

This page contains the following errors:

error on line 6 at column 28: Namespace prefix b on meta_desc is not
defined
Below is a rendering of the page up to the first error.


It appears to me that the template is not parsed by the Helpers.bind,
is this correct?

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



[Lift] Activity

2010-03-07 Thread Martin
Hey,

First of all, let me take the complete opposite stance observed from
one of the most reason posts from a "Rails Junkie". I'm very excited
to see a framework that takes the good from so many different projects
and houses it under a language that does the same. I find it
refreshing to have the powerful tools developed around Java available
for development in this new Scala language and the Lift framework. No
matter how much one hates the design choices and the verbosity of the
most popular platform in our lifetime, it is only a benefit that we
have access to the years of effort devoted to it. The powerful
compiler behind Scala is my sole reason for preferring it to ports
like JRuby and Groovy.

Now to the point of my query, what is the activity and excitement
levels around lift at this point? I understand that money drives the
world and to make a framework successful one must market like Rails
and make some bank to promote future maintenance and improvements.

I notice the last production quality release was over a year ago; I do
notice there have been much more frequent updates to say the wiki and
the work on the 1.1 milestones. It just seems strange that a minor
release on such a young project would taking such a long time. This is
a completely naive view of what is going on, and this is why i post
this query because I want to be disproven so I can feel comfortable
suggesting the use of this framework for the long term.

Thanks for letting me take some of your time away from more important
things :). I just figured seeing this was a question in my mind,
others thinking about using the framework might have the same
question.

-- Martin

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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] reload application.properties

2010-03-01 Thread Martin
Hi

is there any way to reload application.properties file after
boot.scala finishes? I would like to do dynamic localization of
properties on my site, without need to stop/start application.
Mayby there is  much better way to accomplish it.
I would really appreciate any help.

best regards,
Martin

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



Re: [Lift] anybody used OPA?

2010-02-23 Thread Martin Ellis
On 22 February 2010 21:45, Raoul Duke  wrote:
>> This is related to Lift how? It appears to be a framework itself...
>
> i figure people who use Lift are the kinds of people who might have
> their ear to the ground for other approaches to the web problem, and
> might have insight into Competitor X, Y, or Z. i've certainly seen
> people talk about other Java solutions before, admittedly ML is
> further afield, although given Scala, not that much.

I must admit, my initial interest in Scala came from prior use of ML.

I can't answer your question, I'm afraid, but can offer some other
links you might find interesting if you haven't seen them already:

Ur/Web - web application language/framework.
http://impredicative.com/ur/

Yeti - ML-like language on the JVM.
http://wiki.github.com/mth/yeti/

Martin

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, 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 Martin Ellis
On 5 February 2010 05:00, philip  wrote:
> 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.

I've also puzzled over this.  I've figured out that you can point
pax-runner at the hello.composite file.

I'd love to see a tutorial on how experienced OSGI developers set up
their the development environment, and how they work the
edit/compile/redeploy cycle.  It's very obvious for mvn jetty:run
(just wait for the scanner, or use JavaRebel).  It's not so obvious
how people work with OSGI containers.  The best I've figured is to use
the pax assembly: stuff to point at target classes, and run "update
" for each edit/compile cycle - it's a bit clunky.

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

Martin

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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] RC8 candidate for the first 2.8.0 beta

2010-01-21 Thread martin odersky
On Thu, Jan 21, 2010 at 8:37 PM, David Pollak
 wrote:
> Okay... the work-around is checked into the Lift repo.
>
> I say, "Ship RC8 as the beta" and we'll work through this (and likely other)
> issues during the beta period.
>
Sounds good. Thanks! -- Martin

> On Thu, Jan 21, 2010 at 11:36 AM, martin odersky 
> wrote:
>>
>> On Thu, Jan 21, 2010 at 8:31 PM, David Pollak
>>  wrote:
>> > I've written a work-around and am currently testing the code more in
>> > a
>> > few minutes.
>> >
>> If you can make it work, so much the better. To give some info: The
>> original ticket had a vararg parameter of the form List[_]* in a case
>> class. This caused type inference for the synthetic equals method
>> (which uses sameElements for varargs) to fail, because the existential
>> in List[_] made the problem underconstrained. The patch passed the
>> argument type explicitly as the type parameter. In the lift case, it
>> seems that this explicit type parameter violated some type bound, so
>> the type inferencer should have chosen a more general type which would
>> not violate the bound. The easiest fix is probably to just roll back
>> and leave ticket #2867 open until we find a better solution. That's
>> what I have done.
>>
>> Cheers
>>
>>  -- Martin
>
>
>
> --
> 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.




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

2010-01-21 Thread martin odersky
On Thu, Jan 21, 2010 at 8:31 PM, David Pollak
 wrote:
> I've written a work-around and am currently testing the code more in a
> few minutes.
>
If you can make it work, so much the better. To give some info: The
original ticket had a vararg parameter of the form List[_]* in a case
class. This caused type inference for the synthetic equals method
(which uses sameElements for varargs) to fail, because the existential
in List[_] made the problem underconstrained. The patch passed the
argument type explicitly as the type parameter. In the lift case, it
seems that this explicit type parameter violated some type bound, so
the type inferencer should have chosen a more general type which would
not violate the bound. The easiest fix is probably to just roll back
and leave ticket #2867 open until we find a better solution. That's
what I have done.

Cheers

 -- Martin
-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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] RC8 candidate for the first 2.8.0 beta

2010-01-21 Thread martin odersky
(Un)fortunately I have an idea what the problem is. It's probably my
fix for #2867. I have now rolled back that fix in r20629. Can you
check again whether it works with that revision (should be in the
nightly tomorrow)? If it does we might be able to make an exception to
our RC = final rule, because this one just rolls back a non-critical
patch, so I fail to see how this could affect anything but the
original ticket.

Cheers

 -- Martin
-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, 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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 7:12 PM, Paul Phillips  wrote:
> On Tue, Dec 22, 2009 at 05:45:52PM +0100, martin odersky wrote:
>> But I need to know how to build lift with a 2.8.0 compiler. Or
>> alternatively, if a kind soul can send me a lift 2.8.0 tarball with
>> all the classfiles in there I can take it from there.
>
> FYI until you have git you can always download a tarball snapshot of the
> current head at github.  There's a "download" link here:
>
>  http://github.com/dpp/liftweb
>
> Except you need the 280_port branch, so here:
>
>  http://github.com/dpp/liftweb/tree/280_port
>
> And that download link goes here:
>
> http://github.com/dpp/liftweb/tarball/12d1bf0697c9c792c8c91416989a0ef7e287b156
>
> Assuming that gets the files it should, typing "mvn install" will try to
> build with 2.80 Beta1 RC3.  To use RC5 edit pom.xml with this diff:
>
> -    2.8.0.Beta1-RC3
> +    2.8.0.Beta1-RC5
>
> Instructions from earlier in this thread should get you to the point
> where you can build with the local compiler.
>
yes I got that working. The problem was that the download at 280_port
was not 280_port but (I guess) 280_dev. That got me stuck for a while,
but we sorted it out eventually.

Cheers

 -- Martin

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, 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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 6:48 PM, martin odersky  wrote:
> I found someone who could download the repository with git. So trying
> again now.

... and it builds with RC3. Great! So now I have something to work with ...

Cheers

 -- Martin

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, 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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
I found someone who could download the repository with git. So trying
again now.

 -- Martin

On Tue, Dec 22, 2009 at 6:36 PM, martin odersky  wrote:
> On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri
>  wrote:
>>
>> On 22/12/09 10:44 PM, martin odersky wrote:
>>>
>>> On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
>>>   wrote:
>>>>
>>>> Martin,
>>>>
>>>> I think the jetty version is incorrect in the pom.xml in test:sample.
>>>>
>>>> It should be:
>>>>
>>>>        org.mortbay.jetty
>>>>        jetty
>>>>        [6.1.6,7.0)
>>>>
>>> ... and, which test:sample are you referring to?
>>>
>>> Thanks
>>>
>>>  -- Martin
>>
>> The test:sample:war:0.1 artifact for which it fails. By your question, I
>> realize that you are encountering this during archetype generation. It's
>> completely unnecessary.
>>
>> edit the top level pom.xml and remove all the modules other than lift-base,
>> lift-persistence and lift-modules for now. They are really all that you
>> need.
>>
>> The modules section in your top level pom.xml should have just this.
>>
>>  
>>    lift-base
>>    lift-persistence
>>    lift-modules
>>    
>>    
>>
>>    
>>    
>>  
>>
>> - Indrajit
>>
>>
> OK, that will help, I hope.
>
> But I still have no luck. When I download from
>
>  http://github.com/dpp/liftweb/tree/280_port
>
> I get something that's different than the layout on the webpage.
> Subdirectories in dpp-liftweb-12d1bf0/
> are flatter than what I see on the webpage. When I compile with 2.8 it
> dies because it wants jcl.Conversions which sure does not exist
> anymore. So it seems to me that versions are mixed up? I really need a
> tarball or zip with the right lift to test against!
>
>  -- Martin
>

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, 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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri
 wrote:
>
> On 22/12/09 10:44 PM, martin odersky wrote:
>>
>> On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
>>   wrote:
>>>
>>> Martin,
>>>
>>> I think the jetty version is incorrect in the pom.xml in test:sample.
>>>
>>> It should be:
>>>
>>>        org.mortbay.jetty
>>>        jetty
>>>        [6.1.6,7.0)
>>>
>> ... and, which test:sample are you referring to?
>>
>> Thanks
>>
>>  -- Martin
>
> The test:sample:war:0.1 artifact for which it fails. By your question, I
> realize that you are encountering this during archetype generation. It's
> completely unnecessary.
>
> edit the top level pom.xml and remove all the modules other than lift-base,
> lift-persistence and lift-modules for now. They are really all that you
> need.
>
> The modules section in your top level pom.xml should have just this.
>
>  
>    lift-base
>    lift-persistence
>    lift-modules
>    
>    
>
>    
>    
>  
>
> - Indrajit
>
>
OK, that will help, I hope.

But I still have no luck. When I download from

  http://github.com/dpp/liftweb/tree/280_port

I get something that's different than the layout on the webpage.
Subdirectories in dpp-liftweb-12d1bf0/
are flatter than what I see on the webpage. When I compile with 2.8 it
dies because it wants jcl.Conversions which sure does not exist
anymore. So it seems to me that versions are mixed up? I really need a
tarball or zip with the right lift to test against!

 -- Martin

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, 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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
 wrote:
> Martin,
>
> I think the jetty version is incorrect in the pom.xml in test:sample.
>
> It should be:
>
>        org.mortbay.jetty
>        jetty
>        [6.1.6,7.0)
>
... and, which test:sample are you referring to?

Thanks

 -- Martin

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, 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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
 wrote:
> Martin,
>
> I think the jetty version is incorrect in the pom.xml in test:sample.
>
> It should be:
>
>        org.mortbay.jetty
>        jetty
>        [6.1.6,7.0)
>
> See if that works.
>
But even then I only get a 2.7.7 build, which is not what I need?

 -- Martin

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, 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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
I just verified that it did indeed use 2.7.7, because the generated
classfiles still have version 4.1.

My new strategy is to build with the last working RC3, and then
recompile just the failing file with the current compiler and all lift
classes on the classpath. That should work.

But I need to know how to build lift with a 2.8.0 compiler. Or
alternatively, if a kind soul can send me a lift 2.8.0 tarball with
all the classfiles in there I can take it from there.

Thanks

 -- Martin

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, 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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread martin odersky
Thanks for all the help. I tried to do

mvn clean
mvn install

After upgrading to maven 2.2.1, I got somewhere. It compiled a bunch
of packages including lift-mapper, so it seems it did not in fact take
RC6 as its compiler?

But then it stopped due to a build error here.

Any idea what I need to do to solve this?

Thanks

 -- martin



[INFO] [INFO] 

[INFO] [ERROR] BUILD ERROR
[INFO] [INFO] 

[INFO] [INFO] Failed to resolve artifact.
[INFO]
[INFO] Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19,
6.1.20, 6.1.21, 6.1.22] to match range [6.1.6,6.1.6]
[INFO]   org.mortbay.jetty:jetty:jar:null
[INFO]
[INFO] from the specified remote repositories:
[INFO]   scala-tools.org (http://scala-tools.org/repo-releases),
[INFO]   central (http://repo1.maven.org/maven2),
[INFO]   scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots)
[INFO]
[INFO] Path to dependency:
[INFO]  1) test:sample:war:0.1
[INFO]
[INFO]
[INFO]
[INFO] [INFO] 

[INFO] [INFO] Trace
[INFO] org.apache.maven.lifecycle.LifecycleExecutionException:
Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19, 6.1.20,
6.1.21, 6.1.22] to match range [6.1.6,6.1.6]
[INFO]   org.mortbay.jetty:jetty:jar:null
[INFO]
[INFO] from the specified remote repositories:
[INFO]   scala-tools.org (http://scala-tools.org/repo-releases),
[INFO]   central (http://repo1.maven.org/maven2),
[INFO]   scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots)
[INFO]
[INFO] Path to dependency:
[INFO]  1) test:sample:war:0.1
[INFO]
[INFO]
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:711)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
[INFO]  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
[INFO]  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
[INFO]  at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
[INFO]  at 
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
[INFO]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO]  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO]  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO]  at java.lang.reflect.Method.invoke(Method.java:597)
[INFO]  at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[INFO]  at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
[INFO]  at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
[INFO]  at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] Caused by:
org.apache.maven.artifact.versioning.OverConstrainedVersionException:
Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19, 6.1.20,
6.1.21, 6.1.22] to match range [6.1.6,6.1.6]
[INFO]   org.mortbay.jetty:jetty:jar:null
[INFO]
[INFO] from the specified remote repositories:
[INFO]   scala-tools.org (http://scala-tools.org/repo-releases),
[INFO]   central (http://repo1.maven.org/maven2),
[INFO]   scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots)
[INFO]
[INFO] Path to dependency:
[INFO]  1) test:sample:war:0.1
[INFO]
[INFO]
[INFO]  at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:374)
[INFO]  at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74)
[INFO]  at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:316)
[INFO]  at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:304)
[INFO]  at 
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1499)
[INFO]  at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:442)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
[INFO]  ... 17 more
[INFO] [INFO] 

[INFO] [INFO] Total time: 6 seconds
[INFO] [INFO] Finished at: Tue Dec 22 17:26:55 CET 2009
[INFO] [INFO] Final Memory: 12M/12

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

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 3:41 PM, Heiko Seeberger
 wrote:
> Martin,
> OK, now I got it working (almost) without Maven:
> 1. step:
> Check out 280_port branch from ...@github.com:dpp/liftweb.git
> 2. step:
> cd into liftweb/lift-persistence/lift-mapper and run
> mvn dependency:copy-dependencies
> 3. step:
> run the following command
>  -classpath `find target/dependency
> -name *.jar | xargs scala -e 'println(args mkString ":")'` -sourcepath
> src/main/scala -d target/classes `find src/main/scala -name *.scala`
> This will only use Maven to download the dependencies, but you can compile
> with scalac or fsc.

Great! Can you provide me with a tarball or zip of the lift sources? I
don't have git installed here yet.

Thanks

 -- Martin

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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 martin odersky
On Tue, Dec 22, 2009 at 2:35 PM, Josh Suereth  wrote:
> For curiousities sake, if you're building using fsc, are you running scalac
> via an exploded classpath (i.e. not a JAR file?).  If so, I'll try to come
> up with a longer-term solution for this.

Yes, exactly. My usual setup is that my output directory is the first
item on the classpath. So any files I recompile get chosen first.

>
> If we allowed you to do the following:
>
> mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P local-scala
> -Dscala.local.classpath=classfiledir
>
> would that be sufficient?  We could also have this do conditional
> computation in the future.

Does that mean that the scala compiler would then be run out of
classfiledir? Yes, that could work.

Cheers

 -- Martin

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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 martin odersky
On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth  wrote:
> I think staying in maven would require the least amount of typing, but the
> most amount of time as you'd have to publish local snapshots of Scala 2.8.0
> to use them in the lift build.  I remember how annoying this is ;).   Also
> note that deploying maven requires a full scala build, but if needed I can
> make a short-cut that will just publish the "quick" libraries.  This would
> help immensely in testing trunk against projects, but is not very helpful
> otherwise.  Would this be desirable?
>
> What was already suggested (runing mvn dependency:copy-dependencies) is very
> viable.   However, if lift-mapper relies on lift-util, you'll have to
> rebuild one before you rebuild the other if you're somehow changing the ABI.
>
> If you still wanted to use maven, I recommend using the reactor plugin.   If
> you identify the project that is failing you can run:
>
> mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper
>
> Where "net.liftweb:lift-mapper" is the groupId:artifactId containing the
> failing module.  This will only build the lift-mapper module and other
> modules on which lift-mapper depends (i.e. if lift-mapper needs lift-util
> (and only lift-util) just those two will be built.
>
> I have a local VM where I was setting up a scala nightly build that would
> feed maven.  Perhaps when I finish I'll make a write-up on how to do this,
> or have some kind of template/script you can use to do it by hand.
>
> - Josh
>
Hi Josh,

The problem is not so much building individual maven modules, but
building them with experimental compilers. I need to be able to put a
println into scalac, rebuild that (takes 10sec with fsc) and then
recompile the offending maven part with that compiler. That's why I
need a version of lift that can be compiled without maven. It need not
be perfect, for instance one can probably throw out all the tests. But
I need to be able to use lift as a rapid experimentation tool for the
scala compiler itself.

Unfortunately, LAMP is pretty much shutting down for the holidays
right now. So any outside help that you can give is appreciated.
Ideally: I get the right lift version as a tarball, together with all
jars that it needs. Then, instructions what to compile in what order
(I can probably figure them out in a pinch, but if someone knows that
already, it would help).

Thanks

 -- Martin

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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-21 Thread martin odersky
On Sun, Dec 20, 2009 at 12:39 PM, martin odersky  wrote:
> Thanks for letting us know. This looks like something stirred up by
> the change in erasure. We'll investigate Monday what it is.
>
> Cheers
>
>  -- Martin
>
I could reproduce the fault and think I found the underlying problem:
There was a problem with the erasure of self types  and it looks like
this problem was unmasked by my previous, unrelated change to erasure.
I'll think about a fix now.

Cheers

 -- Martin

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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 martin odersky
Thanks for letting us know. This looks like something stirred up by
the change in erasure. We'll investigate Monday what it is.

Cheers

 -- Martin

On Sun, Dec 20, 2009 at 11:43 AM, Heiko Seeberger
 wrote:
> 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

[Lift] Re: Problems downloading dependencies, can't get started

2009-11-14 Thread Nate Martin

Fantastic, that worked great!

Mentioning this tip in the tutorial might be a good idea.

Thanks!

On Nov 14, 4:37 pm, "Jim Barrows"  wrote:
> Nate there is a directory in your home directory called ".m2".  Delete that 
> and retry.
> If that doesn't work, and nobody else jumps in, its an issue with maven.  I'm 
> mobile abd be more helpful I'm afraid.
> Sent on the Now Network™ from my Sprint® BlackBerry
>
>
>
> -Original Message-
> From: Nate Martin 
> Date: Sat, 14 Nov 2009 16:32:19
> To: Lift
> Subject: [Lift] Problems downloading dependencies, can't get started
>
> Hi-
>
> I was very intrigued with Lift, so I tried to work my way through the
> Hello World tutorial. Unfortunately, I can't seem to get that to work.
>
> I'm running on Snow Leopard. I installed Lift with the installer
> downloaded from the Lift web site (version 1.0.1). When I first ran
> "mvn jetty:run" it tried to download a bunch of dependencies.
> Unfortunately, I was in china on a business trip when this happened,
> and because of my spotty internet connection, I don't think all the
> dependencies downloaded, and I couldn't launch the hello world
> tutorial.
>
> Now, I'm back in the states, but I can't figure out how to get Maven
> to retry downloading the dependencies. All that happens when I type
> "mvn jetty:run" is:
>
> [INFO] Copying 0 resource
> [WARNING] POM for 'backport-util-concurrent:backport-util-
> concurrent:pom:3.0:runtime' is invalid.
>
> Its dependencies (if any) will NOT be available to the current build.
> [INFO]
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] Error configuring: net.sf.alchim:yuicompressor-maven-plugin.
> Reason: A required class was missing during mojo configuration: org/
> mozilla/javascript/ErrorReporter
> [INFO]
> 
> [INFO] For more information, run Maven with the -e switch
>
> Can anyone give me some advice on fixing this?
>
> Thanks,
> Nate

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



[Lift] Problems downloading dependencies, can't get started

2009-11-14 Thread Nate Martin

Hi-

I was very intrigued with Lift, so I tried to work my way through the
Hello World tutorial. Unfortunately, I can't seem to get that to work.

I'm running on Snow Leopard. I installed Lift with the installer
downloaded from the Lift web site (version 1.0.1). When I first ran
"mvn jetty:run" it tried to download a bunch of dependencies.
Unfortunately, I was in china on a business trip when this happened,
and because of my spotty internet connection, I don't think all the
dependencies downloaded, and I couldn't launch the hello world
tutorial.

Now, I'm back in the states, but I can't figure out how to get Maven
to retry downloading the dependencies. All that happens when I type
"mvn jetty:run" is:

[INFO] Copying 0 resource
[WARNING] POM for 'backport-util-concurrent:backport-util-
concurrent:pom:3.0:runtime' is invalid.

Its dependencies (if any) will NOT be available to the current build.
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error configuring: net.sf.alchim:yuicompressor-maven-plugin.
Reason: A required class was missing during mojo configuration: org/
mozilla/javascript/ErrorReporter
[INFO]

[INFO] For more information, run Maven with the -e switch


Can anyone give me some advice on fixing this?

Thanks,
Nate

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



[Lift] Re: Removing Scala Actors from Lift

2009-10-02 Thread martin

Hi Jonas,

On Sep 30, 8:05 pm, Jonas Bonér  wrote:
> Hi Martin and Philipp.
>
> Thanks for your email. What you are saying sounds great. I love Scala
> Actors and I know its an important thing that brings people over to
> Scala.
>
> I hope that I didn't offend you. You have done amazing things with and
> for Scala. I really respect you guys.
>
> But I saw and felt the need for something like Akka and went away and build 
> it.
>
I think you have done a great thing with Akka, and I'm very glad you
did it! That's precisely the strength of Scala that experts can build
great libraries and high-level domain specific languages on it. I
really like where you are taking Akka, and I hope it will be very
succesfull.

As I wrote before, we are not at all defensive about our own actor
library. I think Scala actors are very useful for lots of people who
need easy and performant support for concurrent programs. If you need
to take it further (such as remoting, supervising, persistence), there
might be other more complete systems like Akka that can pick up there
and provide these things. We at EPFL simply do not have the
contributor base to do that ourselves, and that's also not our
mission, I think. We need to concentrate on core language, tools, and
some core libraries (if there's nobody else doing those). So I see
Akka as a very important upgrade path from simple multicore
concurrency to robust distributed systems. And I hope that other
people will do the same in other areas, such as I/O, serialization,
graphics, and so on.
If we can collaborate on those, great, but if people find it easier to
do their own thing, that's also perfectly fine.

The only thing I am asking is to avoid confusion to outside people. Be
clear what role you API serves, how it is different from others. Avoid
using the same name for different things.

Cheers

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



[Lift] Re: Removing Scala Actors from Lift

2009-09-30 Thread martin

About actors in Scala 2.8:

 . they have been refactored substantially compared to what's in the
   2.7.x branch
 . Philipp has sent mails about this to scala-internals (05/31)
 . Philipp has invited DPP to look at the refactorings in 2.8 (07/21)
to which
   he responded positively.
 . The ForkJoinPool in 2.8 is completely different from FJTask in
   2.7.5; it's the version that's going into JDK7. It has been
   battle-tested and should not suffer from any memory leaks.

The reason why Scala actors use the FJ framework is performance, in
particular on multi-core hardware. So we do not think it's a good idea
to go back to java.util.concurrent, except maybe for applications with
very specialized demands.

We think the main problem was that lift depends on Scala 2.7.x, and
that the actor refactorings have not gone into the 2.7.x branch. The
result is that people have not noticed the changes. For example, most
of the issues that Erik raises in his blog post no longer apply to
Scala 2.8. Initially we wanted 2.8 to be out by now, but it's taken
much longer than we have foreseen, because some of the problems were
harder than initially thought. We are sorry to have left the 2.7
branch relatively unattended for so long. It's difficult for us,
though, to provide the resources to support two diverging branches in
parallel. More community support with backports etc could help.

To fix the concrete issue at hand, we replaced FJTask with (a backport
of) java.util.concurrent.ThreadPoolExecutor in the Scala 2.7.x branch,
to be released as 2.7.7. That takes care of the memory leaks in
FJTask.

Now to the larger picture. We are not at all wedded to Scala actors
here; after all it's just a library. If there are others which fulfill
some needs better, great! But we have to be honest to avoid confusion.
One of the main differences between Scala actors and lift actors and
Akka seems to be that only Scala actors provide nested receives, so
only Scala actors really let you avoid an inversion of control. This
is a feature which complicates the implementation considerably, and
that's what all our main results are about. You might not care about
this particular feature in your code, and consequently you might
choose a different abstraction. But calling that abstraction simply
`actors' causes unnecessary confusion, in our opinion. And that's not
good for the goal of convincing people that actors are a useful
concurrency abstraction. So, nothing against lift actors and Akka, but
we need to be precise about the tradeoffs. Maybe call them `flat
actors' or something like that.

Martin and Philipp

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



[Lift] Re: automaticly generated forms and submit button naming

2009-09-28 Thread Martin

Hi,

Ross, thank you for your help. This code works perfectly for me. I
heaven't noticed I could group many elements in one lift tag.

I changed somethings in your code. Maybe it's not worth mentioning but
if someone has similar problems it can help a little.
I corrected only to things: changed parameters order in one bind and
added some code to other.
Result is here:

def newPlace(ns: NodeSeq, place : Place): NodeSeq = {
def bindFields(innerNs: NodeSeq): NodeSeq = {
var s : String = "test"
signupFields.
map(fi => getSingleton.getActualBaseField(place, fi)).
flatMap(f => {
f.toForm.toList.map(form => {
bind("field",
innerNs,
"displayName" -
> f.displayName,
"form"-
> form)(1);
})
})
}

def handleSubmit(): Any = {
}

bind("place", ns,
 "fields" -> { (ns: NodeSeq) => bindFields(ns) },
 "submit" -> { (ns: NodeSeq) => SHtml.submit("Submit new
place", handleSubmit _) })
}

Still I don't get why I need to get second element from bind result
(which is NodeSeq) and pass it to .toForm.toList.map(...).
When I first compiled this code i got type mismatch error:
 found   : scala.xml.NodeSeq
 required: scala.xml.Node

So I picked up first non empty element from the result by using bind
(...)(1) and it works in my scenario. Maybe I will catch it later ;)

Again this code works perfectly for me. Great thanks Ross!

- Martin




On 24 Wrz, 16:15, Ross Mellgren  wrote:
> It sounds like you probably want { SHtml.submit("Title of submit  
> button", () => actionToTakeWhenButtonIsUsedToSubmitForm) }
>
> By the way, what you have there doesn't seem to be following the usual  
> lift pattern of binding snippets, is there a reason that you prefer  
> this to:
>
> template:
>
> 
>      Place details
>      
>          
>              
>                  
>                  
>              
>          
>      
>      
> 
>
> Snippet:
>
> def newPlace(ns: NodeSeq): NodeSeq = {
>      val place = /* make a new place somehow */
>
>      def bindFields(ns: NodeSeq): NodeSeq =
>          signupFields.
>              map(fi => getSingleton.getActualBaseField(place, fi)).
>              flatMap(f => {
>                  f.toForm.toList.map(form => {
>                      bind(ns, "field",
>                           "displayName" -> f.displayName,
>                           "form"        -> form)
>                  })
>              })
>
>      def handleSubmit(): Any = /* do something with place */
>
>      bind("place", ns,
>           "fields" -> { (ns: NodeSeq) => bindFields(ns) },
>           "submit" -> { (ns: NodeSeq) => SHtml.submit("Submit new  
> Place", handleSubmit _) })
>
> }
>
> This way lets you see most of the HTML in one place (the template). I  
> inlined localForm, but there's no particular reason that it needs to  
> be local (other than it closes on place, but you could just pass that  
> in)
>
> -Ross
>
> On Sep 24, 2009, at 6:55 AM, Martin wrote:
>
>
>
> > Hi all,
>
> > I've got a following problem. When I create a form form automaticly..
> > similar to the User login/register example I encontered a problem I'm
> > not posible to cope with.
>
> > Firstly I have 'written' a function (using Copy&Paste method) which
> > creates a form fields list based on my class properties:
>
> >    private def localForm(place: Place, ignorePassword: Boolean):
> > NodeSeq = {
> >        signupFields.
> >        map(fi => getSingleton.getActualBaseField(place, fi)).
> >        filter(f => !ignorePassword || (f match {
> >                    case f: MappedPassword[Place] => false
> >                    case _ => true
> >                })).
> >        flatMap(f =>
> >            f.toForm.toList.map(form => {f.displayName} > label> {form}) )
> >    }
>
> > Next, I wrote some code to return a complete form to the snippet:
>
> >    def newPlace(place: Place) =
> >    
> >        Place details
> >        
> >            {
> >                localForm(place, false)
> >            }
> >        
> >        <_WHAT_SHOULD_I_WRITE_HERE_:s

[Lift] automaticly generated forms and submit button naming

2009-09-24 Thread Martin

Hi all,

I've got a following problem. When I create a form form automaticly..
similar to the User login/register example I encontered a problem I'm
not posible to cope with.

Firstly I have 'written' a function (using Copy&Paste method) which
creates a form fields list based on my class properties:

private def localForm(place: Place, ignorePassword: Boolean):
NodeSeq = {
signupFields.
map(fi => getSingleton.getActualBaseField(place, fi)).
filter(f => !ignorePassword || (f match {
case f: MappedPassword[Place] => false
case _ => true
})).
flatMap(f =>
f.toForm.toList.map(form => {f.displayName} {form}) )
}

Next, I wrote some code to return a complete form to the snippet:


def newPlace(place: Place) =

Place details

{
localForm(place, false)
}

<_WHAT_SHOULD_I_WRITE_HERE_:submit />



My question is... what do I write in _WHAT_SHOULD_I_WRITE_HERE_ ?
Or better.. how/where to define this value?

In a user login/register example there is submit defined like this:


Placing there name of the owner class didn't work.
I know I could use bind but as far as I know next I should create a
complete snippet with all the fields by hand.. and I would to avoid
it.

I was digging for solution in a Lift Book and on group as well, but
without success.
Help!

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



[Lift] Re: New Lift Actor code

2009-05-23 Thread Martin Ellis

On Sat, May 23, 2009 at 6:19 AM, David Pollak
 wrote:
> I am happy to share the Lift Actor code with EPFL and if it makes it into
> the Scala distribution as SimpleActors or something similar, I'm totally
> cool with that.  I'm not interested in owning or maintaining an Actor
> library.  I am however, dedicated to making sure that Lift apps can run in
> production for months (or even years) without retaining memory or having
> other problems that can impact the stability of applications.

The cool thing about this is that it provides solid evidence that Scala -
as a language - does satisfy the aim of being be a scalable language.

I'm referring to the fact that Scala actors are not part of the core language.
They're just a library that can be replaced with a different library, which can
also to provide the 'feel' of native language support for objects of that type.
It's such a fundamental part of the language design that Programming in
Scala talks about it in Chapter 1, Section 1.

It's timely that you sent the email so soon after the link to the Guy Steele
"Growing a Language" OOPSLA presentation (of which I am still in awe)
went around on twitter.
http://video.google.com/videoplay?docid=-8860158196198824415

I guess this demonstrates that Scala provides the features for growth that
Steele says are needed for languages to be successful in the long term,
and that he would have liked Java to have.  Awesome.

Nice, clear explanation, by the way.  Should avoid any any NIH allegations on
the diggs and reddits of the world ;o)

Martin

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



[Lift] Why XML tags, not attributes, for lift markup?

2009-05-19 Thread Martin Ellis

Hi,

I was wondering why lift markup uses XML elements to reference
snippets, rather than using namespaced attributes in the way that (I
think) Wicket and Tapestry do?  Or like Plone's TAL, which is the
first place I saw such a thing.

The reason I ask is this: I'm sure I've read somewhere that David P
has used these frameworks before (the Java ones, at least)... so it
seems most unlikely that such a design was never considered.  Perhaps
it was just an arbitrary choice?  Or was there something more to it
than that?

I hope this question doesn't sound like criticism - I'm just curious. :o)

Martin

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



[Lift] Re: problems logging

2009-05-19 Thread Martin Ellis

> On May 17, 10:33 pm, Timothy Perrett  wrote:
>> Can you verify the log4j.xml file is being read?
>>

On Mon, May 18, 2009 at 9:38 PM, Channing Walton  wrote:
> Not sure how I can tell.

Specifying -Dlog4j.debug on the command line should prompt log4j to tell you
what it's doing.

Martin

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



[Lift] Re: Progress on JPADemo and JTA

2008-10-10 Thread Martin Ellis

On Fri, Oct 10, 2008 at 10:37 PM, Derek Chen-Becker
<[EMAIL PROTECTED]> wrote:
> OK, I think I know how to create a new branch, but being a Git newb I really
> don't want to nuke anything. Do I just do a "git branch  name>" in my local repo?

I think you want: git checkout -b branchName

git branch on it's own won't switch to the new branch.

Martin

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: expired sessions and log in

2008-10-05 Thread Martin Ellis

On Sun, Oct 5, 2008 at 7:28 PM, Charles F. Munat <[EMAIL PROTECTED]> wrote:
>
> I'm working on an app in which users may spend significant time editing
> a form before submitting it. It's possible during this time that their
> session could time out. My concern is that they might submit a long
> edit, discover that their session has timed out, log in, and lose the
> edit. (They can probably back up and resubmit, but these are not very
> savvy users.)
>
> I'd like it to remember their update, hold it until they log back in,
> then send them a prompt to ask if they want to:
>
> a) complete the update,
> b) cancel the update,
> c) return to the edit form (with their recent edits included, though not
> yet saved).
>
> Any ideas for how to go about this?

I guess it's still true that:

  "The best way to deal with the particular situation (browser
  open, don't want the session to disappear), is to put a hidden
  CometActor on the page that does nothing other than keep
  the session alive." - David Pollack
  
http://groups.google.com/group/liftweb/browse_thread/thread/e98f2f75cc4461e4/10a16b586e879b11


Martin

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Caching JPA entities and JPA vs Hibernate

2008-10-01 Thread Martin Ellis

On Tue, Sep 30, 2008 at 11:54 PM, Tim Perrett <[EMAIL PROTECTED]> wrote:

> Having an issue with ehcache.xml being picked up. The docs say that it
> need to be on the classpath - I've tried having it in META-INF, WEB-
> INF/classes/META-INF but yet nothing seems to work. It never gets
> picked up...?
>
> Where can i stick it so that its forced to be read?

IIRC, it needs to be at the top of the classpath, not under META-INF.

Martin

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Many to many in Lift mapper

2008-09-20 Thread Martin Ellis

On Sat, Sep 20, 2008 at 10:01 PM, Charles F. Munat <[EMAIL PROTECTED]> wrote:
> I can't find any examples of a many-to-many relationship using Lift's
> mapper. Am I missing one? How does one map two classes in a many-to-many
> bidirectional relationship?

Using the HasManyThrough class:

http://liftweb.net/index.php/HowTo_setup_composite_keys

Martin

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: One further: JPA + JTA + Lift

2008-09-10 Thread Martin Ellis

On Wed, Sep 10, 2008 at 4:27 PM, Kris Nuttycombe
<[EMAIL PROTECTED]> wrote:
> The only question I have is thread safety - it doesn't seem
> like I should really be using a variable on the singleton to store the
> transaction; should I instead be creating a separate RequestVar to
> hold it?

It is thread safe to use a singleton - in fact, it's what Sun do in
the code that accompanies the Java EE Tutorial...

web/books/src/main/java/com/sun/books/listeners/ContextListener.java:

public final class ContextListener implements ServletContextListener {
@PersistenceUnit
private EntityManagerFactory emf;
private ServletContext context = null;
@Resource
private UserTransaction utx;

public void contextInitialized(ServletContextEvent event) {
context = event.getServletContext();

try {
context.setAttribute("emf", emf);
Globals.UTX = utx;


... where Globals is defined as:

public class Globals {
public static UserTransaction UTX;
}


Hence, using val instead of def should be fine.

The begin() and commit() javadoc on UserTransaction:
"Create a new transaction and associate it with the current thread."
"Complete the transaction associated with the current thread. When
this method completes, the thread is no longer associated with a
transaction."

The transaction is associated with the thread that called begin()
'internally', so there's no need to associate it with a thread
manually.

See also:
http://java.sun.com/javaee/5/docs/tutorial/doc/bnafo.html

Martin

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: JPA w/Scala

2008-09-08 Thread Martin Ellis

Hi Tim,

On Mon, Sep 8, 2008 at 12:29 PM, Tim Perrett wrote:
>
> Just been doing some more debugging on this - it appears that the
> correct values are being passed through and are assigned to an entity
> instance, but they blow up when trying to do the em.merge(author)
> call.
>
> The stack trace I get is:

You didn't post the full stack trace (or at least, it didn't show up
in gmail), but there are only two places I can see merge being called:

(Authors)
  def add (xhtml : NodeSeq) : NodeSeq = {
def doAdd () = {
  if (author.name.length == 0) {
error("emptyAuthor", "The author's name cannot be blank")
  } else {
Model.merge(author)
redirectTo("list.html")
  }
}

and (Books) 

  def add (xhtml : NodeSeq) : NodeSeq = {
def doAdd () = {
  Model.merge(book)
  redirectTo("list.html")
}


The above looks slightly fishy, but I'm afraid I don't have time right
now to try the project to check.

If you want to add something, shouldn't you be calling persist rather
than merge?
I'd expect to see merge being used in a method called doUpdate() or whatever...
... or can you really get away with calling merge when something's not
in the DB yet?

Just a thought.

Regards
Martin

>
> ### AUTHOR
> [EMAIL PROTECTED]
> ### AUTHOR ID
> 0
> ### AUTHOR NAME
> sdfsdssdfs
> DEBUG - opened session at timestamp: 12208732519
> DEBUG - begin
> DEBUG - opening JDBC connection
> DEBUG - total checked-out connections: 0
> DEBUG - using pooled JDBC connection, pool size: 0
> DEBUG - current autocommit status: true
> DEBUG - disabling autocommit
> DEBUG - after transaction begin
> DEBUG - id unsaved-value: 0
> DEBUG - transient instance of: com.foo.jpaweb.model.Author
> DEBUG - merging transient instance
> DEBUG - saving [com.foo.jpaweb.model.Author#]
> DEBUG - executing insertions
> DEBUG - Wrapped collection in role: com.foo.jpaweb.model.Author.books
> DEBUG - executing identity-insert immediately
> DEBUG - Inserting entity: com.foo.jpaweb.model.Author (native id)
> DEBUG - about to open PreparedStatement (open PreparedStatements: 0,
> globally: 0)
> DEBUG - insert into authors (name, id) values (?, ?)
> Hibernate: insert into authors (name, id) values (?, ?)
> DEBUG - preparing statement
> DEBUG - Dehydrating entity: [com.foo.jpaweb.model.Author#]
> DEBUG - binding 'sdfsdssdfs' to parameter: 1
> DEBUG - about to close PreparedStatement (open PreparedStatements: 1,
> globally: 1)
> DEBUG - closing statement
> DEBUG - could not insert: [com.foo.jpaweb.model.Author] [insert into
> authors (name, id) values (?, ?)]
> java.sql.SQLException: Parameter #2 has not been set.
>at
> net.sourceforge.jtds.jdbc.ConnectionJDBC2.prepareSQL(ConnectionJDBC2.java:
> 613)

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---