[Lift] Netbeans 6.8 issues with Lift
Hello guys,
I have upgraded my Netbeans from 6.7 to 6.8 and the very same Lift code started
to report some errors. The code compiles correctly from the command line, but
it reports error in the GUI. One of the errors is the following:
This method:
def dispatch: LiftRules.DispatchPF = {
case r...@req(api :: feed:: getNewSources :: Nil, , PutRequest)
=
() = getNewSources(r)
case r...@req(api :: feed:: getNewFeedsPerSource :: Nil, ,
PutRequest) =
() = getNewFeedsPerSource(r)
case r...@req(api :: feed :: setNewSource :: Nil, , PutRequest)
=
() = setNewSource(r)
case r...@req(api :: feed :: setNewFeedEntries :: Nil, ,
PutRequest) =
() = setNewFeedEntries(r)
}
Reports:
missing parameter type for expanded function
As I say, the code complies and run perfectly from Maven in the command line.
Does anybody have similar issues with Netbeans 6.8?
Thanks in advance,
GA
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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 is awesome (with reservations)
Hello, I would like to hear more about, how you get lift. I am new to lift too and trying to get a better and clearer viewpoint. Maybe it can help others to. If you can summarize it in a few sentences. This would be really great. with best regards On 25 Dez., 01:05, Erkki Lindpere vill...@gmail.com wrote: It took me a long time to get lift. For about a year I looked at examples from time to time and tried out some basic stuff, but it just didn't click. I found the structure to be too messy. I still do actually. It seems that the documentation is also not well structured enough for getting started and I had to look at examples and Lift's source to understand how things work (thanks for putting sources in the Maven repo BTW, I wish everyone would do that). After experimenting with Lift for about two days I think I get the basic idea and I've come to a better understanding about lift's structure by looking at the sources, I can now ignore the parts I don't like (Mapper being one, I use JPA instead) and use the parts that I do. The way the X(HT)ML processing, type-safe JavaScript/jQuery, Ajax and Comet work is just brilliant! PS. I'm working (on my spare time for now) on an Ajax Comet heavy application that will hopefully also have a lot of runtime customization ability through OSGi. I haven't gotten to the OSGi part yet, because there's the hurdle of OSGifying all the jars I use and I want to get a good understanding of Lift before I start making things dynamic. But do you have any recommendations for OSGi framework/web container combinations to use with Lift? I have tried SpringSource dmServer (with the SpringSource tooling), but I don't like it much... Maybe plain Equinox + Jetty with the ScalaModules library would be a good combo? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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 is awesome (with reservations)
It would be really good for us as a team to know what it is you *dont* get? Is it conceptual? code? If we can understand what is daunting for newbies that would really be helpful. Cheers, Tim On Dec 25, 2:51 pm, greekscala hellectro...@gmail.com wrote: Hello, I would like to hear more about, how you get lift. I am new to lift too and trying to get a better and clearer viewpoint. Maybe it can help others to. If you can summarize it in a few sentences. This would be really great. with best regards On 25 Dez., 01:05, Erkki Lindpere vill...@gmail.com wrote: It took me a long time to get lift. For about a year I looked at examples from time to time and tried out some basic stuff, but it just didn't click. I found the structure to be too messy. I still do actually. It seems that the documentation is also not well structured enough for getting started and I had to look at examples and Lift's source to understand how things work (thanks for putting sources in the Maven repo BTW, I wish everyone would do that). After experimenting with Lift for about two days I think I get the basic idea and I've come to a better understanding about lift's structure by looking at the sources, I can now ignore the parts I don't like (Mapper being one, I use JPA instead) and use the parts that I do. The way the X(HT)ML processing, type-safe JavaScript/jQuery, Ajax and Comet work is just brilliant! PS. I'm working (on my spare time for now) on an Ajax Comet heavy application that will hopefully also have a lot of runtime customization ability through OSGi. I haven't gotten to the OSGi part yet, because there's the hurdle of OSGifying all the jars I use and I want to get a good understanding of Lift before I start making things dynamic. But do you have any recommendations for OSGi framework/web container combinations to use with Lift? I have tried SpringSource dmServer (with the SpringSource tooling), but I don't like it much... Maybe plain Equinox + Jetty with the ScalaModules library would be a good combo? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Netbeans 6.8 issues with Lift
That would be because the 6.8 plugin uses scala 2.8 which we do not support.
See some of the recent threads on the mailing list.
Cheers, Tim
On 25 Dec 2009, at 12:38, GA wrote:
Hello guys,
I have upgraded my Netbeans from 6.7 to 6.8 and the very same Lift code
started to report some errors. The code compiles correctly from the command
line, but it reports error in the GUI. One of the errors is the following:
This method:
def dispatch: LiftRules.DispatchPF = {
case r...@req(api :: feed:: getNewSources :: Nil, ,
PutRequest) =
() = getNewSources(r)
case r...@req(api :: feed:: getNewFeedsPerSource :: Nil, ,
PutRequest) =
() = getNewFeedsPerSource(r)
case r...@req(api :: feed :: setNewSource :: Nil, ,
PutRequest) =
() = setNewSource(r)
case r...@req(api :: feed :: setNewFeedEntries :: Nil, ,
PutRequest) =
() = setNewFeedEntries(r)
}
Reports:
missing parameter type for expanded function
As I say, the code complies and run perfectly from Maven in the command line.
Does anybody have similar issues with Netbeans 6.8?
Thanks in advance,
GA
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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.
[Lift] Re: Reg setting the name attr for SHtml.Text
Thanks, that was helpful..There is a lot to understand. On Dec 24, 8:40 pm, Naftoli Gugenheim naftoli...@gmail.com wrote: SHtml's functions rely on autogenerated names to work. Among other things it makes sites more secure. If you need a custom name, don't use SHtml. Rather output an xml element manually, either inline or via a template, and use S.param to get the URL query parameter when the form is submitted. It returns a Box that's empty when the parameter does not exist and Full when it does. - rkrkdev...@gmail.com wrote: I'm new to Scala/Lift, i have a question reg SHtml.Text, If i have the following code bind(entry,xhtml, something - SHtml.text(something, something = _), submit - SHtml.submit(Add, processAdd)) i can get the value entered within processAdd for ex, println(Val... + something) works fine.. But if i want to have a fixed name for the input something like - bind(entry,xhtml, something - SHtml.text(something, something = _,name-something), submit - SHtml.submit(Add, processAdd)) the above code has name attr, how should i get the entered value from the form ? using S.attr(something) ? i tried this but doesn't work. Am i doing something wrong.. Thanks -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, 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.
Re: [Lift] Re: Lift is awesome (with reservations)
On Friday 25 December 2009 20:09:10 Timothy Perrett wrote: It would be really good for us as a team to know what it is you *dont* get? Is it conceptual? code? If we can understand what is daunting for newbies that would really be helpful. I think that Mr. Lindpere basically made this pretty clear: - The structure of Lift is too messy - The documentation is unstructured - Lift is not easy enough to understand without having to look at varying amounts of examples. However, since I understand that these points are pretty... vague, I will elaborate with my own experience (which still is pretty on-topic) I had one year ago when I started using Lift. I'll try to picture the way I thought back then. - It is difficult to track exactly how a request is handled: it goes through views/dispatchPF's, and then it suddenly ends up reading a HTML file with lift: tags inside of it, or not... Then there are the various hooks that come into play, and overridden snippet definitions, snippets fetching templates on their own, SiteMap entries that can override default request paths, and so on. At the end of the day, you just use that site map/menu system in combination with Mapper, comet actor, or whatever, without really having a clue about how it works. You cannot tell which path the request took or where to expect it to be next without looking at the Lift source code. Something that would really help would be a clear flow chart that you could show newbies and that depicted the path of a request in Lift (including all of the forks it could take). That would be pretty helpful. - The once clean model/view separation isn't so clean any more. The prime example is of course MappedTextarea that is mentioned over and over again (with its height/width), but even in classes such as ProtoUser, you find view code that doesn't belong. - Lift doesn't really contain newbie-friendly building blocks that can be reused easily. E.g. there's ProtoUser which is a black box of example code, instead of something more true to the Scala way of doing things like User with LastName with EmailField with Password... that would make the modules useful and actually reusable. When I asked about how to remove the email field from ProtoUser and how to replace it with an OpenID, I got the response that I should copy-paste the code from ProtoUser into a new class and do the integration myself. The whole construct simply isn't useful. - The API isn't consistent. Sometimes you find methods à la cached_? and sometimes isCached, sometimes methods use Box[]es for no apparent reason, sometimes you use objects and sometimes vals and so on. I've stopped thinking about this since I've memorized the most important parts of Lift, but this is something you stumble over as a newbie. I hope that this will be largely corrected in 1.1/2.0. When I started using Lift, I almost immediately went back to the Step framework [0] since it was so much easier to understand but still actually useful and powerful. Only after a while did I dare go back to Lift again. [0] http://github.com/alandipert/step Cheers, Tim David Flemström david.flemst...@gmail.com signature.asc Description: This is a digitally signed message part.
[Lift] Re: Lift is awesome (with reservations)
I mostly agree with what David said and I'll add this: * I think _? and _! in methods come from Ruby, but they don't fit the naming conventions in Java/Scala (I think Scala should mostly follow Java conventions with some exceptions). This is a really minor point though. * object User extends User with MetaMegaProtoUser[User]. ProtoUser should just go away, the namings are ridiculous and it mixes HTML with persistence. Luckily one can just ignore the whole mapper module. * Some exceptions seem to just get eaten and I have no idea where things went wrong * I haven't taken a closer look at Box yet, but I understand that they are like Option, but have a third possibility of capturing an exceptional situation. Is this really better than using Exceptions? While Java's checked exceptions may have proven to be a failure, I don't think it's necessary. * there are several classes that have lots of methods in them that don't all belong together. For example: S, LiftRules, I'm sure there's more. Some packages have too many classes as well. I think there should be a cleaner separation of concerns. * I find Lift to be generally concept-heavy and invents new concepts instead of reusing well-known ones. You have to know much to use it effectively. I do not think Lift in it's current form is usable for average developers. Maybe that isn't the goal, but this makes me think there should be a post-Lift framework that takes all the good things, makes it better structured and documented and generally more usable by normal people :) Disclaimer: a lot of this might come from the fact that I'm not very used to functional programming. Even as I've used Scala almost daily for a year and a half (and even a little bit at my day job) I find Lift's programming style foreign at times. I would really prefer a more OO solution in quite a few places where Lift solves things in a functional way. Erkki L On Dec 25, 11:55 pm, David Flemström david.flemst...@gmail.com wrote: On Friday 25 December 2009 20:09:10 Timothy Perrett wrote: It would be really good for us as a team to know what it is you *dont* get? Is it conceptual? code? If we can understand what is daunting for newbies that would really be helpful. I think that Mr. Lindpere basically made this pretty clear: - The structure of Lift is too messy - The documentation is unstructured - Lift is not easy enough to understand without having to look at varying amounts of examples. However, since I understand that these points are pretty... vague, I will elaborate with my own experience (which still is pretty on-topic) I had one year ago when I started using Lift. I'll try to picture the way I thought back then. - It is difficult to track exactly how a request is handled: it goes through views/dispatchPF's, and then it suddenly ends up reading a HTML file with lift: tags inside of it, or not... Then there are the various hooks that come into play, and overridden snippet definitions, snippets fetching templates on their own, SiteMap entries that can override default request paths, and so on. At the end of the day, you just use that site map/menu system in combination with Mapper, comet actor, or whatever, without really having a clue about how it works. You cannot tell which path the request took or where to expect it to be next without looking at the Lift source code. Something that would really help would be a clear flow chart that you could show newbies and that depicted the path of a request in Lift (including all of the forks it could take). That would be pretty helpful. - The once clean model/view separation isn't so clean any more. The prime example is of course MappedTextarea that is mentioned over and over again (with its height/width), but even in classes such as ProtoUser, you find view code that doesn't belong. - Lift doesn't really contain newbie-friendly building blocks that can be reused easily. E.g. there's ProtoUser which is a black box of example code, instead of something more true to the Scala way of doing things like User with LastName with EmailField with Password... that would make the modules useful and actually reusable. When I asked about how to remove the email field from ProtoUser and how to replace it with an OpenID, I got the response that I should copy-paste the code from ProtoUser into a new class and do the integration myself. The whole construct simply isn't useful. - The API isn't consistent. Sometimes you find methods à la cached_? and sometimes isCached, sometimes methods use Box[]es for no apparent reason, sometimes you use objects and sometimes vals and so on. I've stopped thinking about this since I've memorized the most important parts of Lift, but this is something you stumble over as a newbie. I hope that this will be largely corrected in 1.1/2.0. When I started using Lift, I almost immediately went back to the Step framework [0] since it was so much easier to understand but still
[Lift] Re: Lift is awesome (with reservations)
Eh... sorry, ignore the point about Box in the previous message. I looked it up while posting but forgot to delete that paragraph. I do understand where it may be useful in some cases. On Dec 26, 2:19 am, Erkki Lindpere vill...@gmail.com wrote: I mostly agree with what David said and I'll add this: * I think _? and _! in methods come from Ruby, but they don't fit the naming conventions in Java/Scala (I think Scala should mostly follow Java conventions with some exceptions). This is a really minor point though. * object User extends User with MetaMegaProtoUser[User]. ProtoUser should just go away, the namings are ridiculous and it mixes HTML with persistence. Luckily one can just ignore the whole mapper module. * Some exceptions seem to just get eaten and I have no idea where things went wrong * I haven't taken a closer look at Box yet, but I understand that they are like Option, but have a third possibility of capturing an exceptional situation. Is this really better than using Exceptions? While Java's checked exceptions may have proven to be a failure, I don't think it's necessary. * there are several classes that have lots of methods in them that don't all belong together. For example: S, LiftRules, I'm sure there's more. Some packages have too many classes as well. I think there should be a cleaner separation of concerns. * I find Lift to be generally concept-heavy and invents new concepts instead of reusing well-known ones. You have to know much to use it effectively. I do not think Lift in it's current form is usable for average developers. Maybe that isn't the goal, but this makes me think there should be a post-Lift framework that takes all the good things, makes it better structured and documented and generally more usable by normal people :) Disclaimer: a lot of this might come from the fact that I'm not very used to functional programming. Even as I've used Scala almost daily for a year and a half (and even a little bit at my day job) I find Lift's programming style foreign at times. I would really prefer a more OO solution in quite a few places where Lift solves things in a functional way. Erkki L On Dec 25, 11:55 pm, David Flemström david.flemst...@gmail.com wrote: On Friday 25 December 2009 20:09:10 Timothy Perrett wrote: It would be really good for us as a team to know what it is you *dont* get? Is it conceptual? code? If we can understand what is daunting for newbies that would really be helpful. I think that Mr. Lindpere basically made this pretty clear: - The structure of Lift is too messy - The documentation is unstructured - Lift is not easy enough to understand without having to look at varying amounts of examples. However, since I understand that these points are pretty... vague, I will elaborate with my own experience (which still is pretty on-topic) I had one year ago when I started using Lift. I'll try to picture the way I thought back then. - It is difficult to track exactly how a request is handled: it goes through views/dispatchPF's, and then it suddenly ends up reading a HTML file with lift: tags inside of it, or not... Then there are the various hooks that come into play, and overridden snippet definitions, snippets fetching templates on their own, SiteMap entries that can override default request paths, and so on. At the end of the day, you just use that site map/menu system in combination with Mapper, comet actor, or whatever, without really having a clue about how it works. You cannot tell which path the request took or where to expect it to be next without looking at the Lift source code. Something that would really help would be a clear flow chart that you could show newbies and that depicted the path of a request in Lift (including all of the forks it could take). That would be pretty helpful. - The once clean model/view separation isn't so clean any more. The prime example is of course MappedTextarea that is mentioned over and over again (with its height/width), but even in classes such as ProtoUser, you find view code that doesn't belong. - Lift doesn't really contain newbie-friendly building blocks that can be reused easily. E.g. there's ProtoUser which is a black box of example code, instead of something more true to the Scala way of doing things like User with LastName with EmailField with Password... that would make the modules useful and actually reusable. When I asked about how to remove the email field from ProtoUser and how to replace it with an OpenID, I got the response that I should copy-paste the code from ProtoUser into a new class and do the integration myself. The whole construct simply isn't useful. - The API isn't consistent. Sometimes you find methods à la cached_? and sometimes isCached, sometimes methods use Box[]es for no apparent reason, sometimes you use objects and sometimes vals and
[Lift] Re: Lift is awesome (with reservations)
Well, I'm not sure if I completely get it yet or if I can summarize well enough, but: I should look at Lift through more functional programming goggles, some things in it don't make a lot of sense when looked through OO goggles. From looking through some of the docs, examples and sources, I have a basic understanding now about how the requests are served: what rules can be defined in LiftRules during the Boot process and by what conventions templates, snippets and other stuff are looked up. I don't know how to summarize it though. Erkki L On Dec 25, 4:51 pm, greekscala hellectro...@gmail.com wrote: Hello, I would like to hear more about, how you get lift. I am new to lift too and trying to get a better and clearer viewpoint. Maybe it can help others to. If you can summarize it in a few sentences. This would be really great. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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 is awesome (with reservations)
I think the best things I think you could do to help newbies is document in a well-structured way: * all the conventions over configuration rules * what classes to use for the basic stuff (what is S for and how it should be used, all the things you can do with LiftRules, etc.) * more advanced uses of bind(...) in snippets * better docs for the Lift tags. On Dec 25, 9:09 pm, Timothy Perrett timo...@getintheloop.eu wrote: It would be really good for us as a team to know what it is you *dont* get? Is it conceptual? code? If we can understand what is daunting for newbies that would really be helpful. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Sending malformed HTML in custom dispatch
I'm using custom dispatch (to handle both XML media files). Often, I will want to send a page that contains user-inputted (X)HTML. This will often be malformed HTML that is nevertheless rendered fine by a modern browser. How would I send this through? I tried PlainTextResponse, but it sends the wrong mime type and shows up as well... plaintext. And XHtmlResponse requires valid XHTML. Is there any response that sends a String and claims that it's (x) html? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
