[Lift] Re: Documentation Site
Well, this is an apt discussion at this point in time I feel. One of the weakness of the Lift Project is really the sparse documentation, as well as the rapid cycle of development obsoleting virtually many of the slightly older code out there. I don't mind contributing my time improving the documentation. Perhaps one of the reasons why people don't contribute back is that the wiki is not very prominent, for one reason or another. It's just rarely referenced anywhere else most of the time. Would appreciate a more concentrated effort on this. I haven't actually seen the lift 1.1 scala docs. For example, http://www.scala-tools.org/mvnsites-snapshots/liftweb/lift-base/lift-common/scaladocs/index.html points to a blank page - that's for Lift common. I mostly rely on the IDE(idea) to open up declarations via maven.. not exactly the best method since the source code is more often than not not commented. The lift framework is pretty massive, I think that's the reason why it's difficult to write comprehensive documentation for it. I'm just wondering what is a good way to go about doing that? A list of how-tos plus in depth discussion about each part of the framework i.e. base, or common, or? Perhaps there can be one page for every logical object in Lift. regards, CH On Dec 21, 6:12 am, Timothy Perrett timo...@getintheloop.eu wrote: I really don't think thats the issue - Lift is not closed to committing... if that were the case, David would never have recruited us onto the team ;-) 95% of all OSS projects i've ever come across have the same policy when it comes to wikis etc... they are organic, community driven beasts. For instance, I was no aware that you had written any articles... but that is great. You say you want them fleshed out? In what way / what information do you need. Writing documentation is actually a great way to understand something because it means you have to fully grok it in order to teach others - we need to solve the documentation issue for sure, and any contribution you or others have is very much welcome. Cheers, Tim On 20 Dec 2009, at 21:43, Randinn wrote: To give the benefit of doubt to people who use Lift knowing that is closed to commiting they may think the same about the documentation. I have added a bit but I've more thrown up a few pages and figured someone with more knowledge would flesh them out. On Dec 20, 8:47 pm, Timothy Perrett timo...@getintheloop.eu wrote: 1.0 is the last official release that was not a milestone or snapshot - thus, they are the primary api docs right now until we release 2.0 (that is, what was being called 1.1 is being renamed to 2.0). API docs are a process issue, and handled as part of our build process - they will always live both on scala-tools and liftweb.net where applicable. They wont ever sit anywhere else (officially). Yes, the wiki is a little out dated. I forget the number of times i've tried to spear head a wiki effort... the bottom line is that other people need to start writing content - there are a fair number of competent lift users in the community who simply are not giving anything back by way of articles or wiki cleaning - thus our docs get out dated fast because the team prefer to write code than documentation. We even tried to appointed a wiki gardener but he appears to have just disappeared into the ether... Id be open to hearing suggestions on how one could keep the wiki more up to date? Short of users actually contributing back, there is a limit on what the team can do at anyone time. We are getting there, but its not going to be an overnight process. Blogs - a fundamental corner stone of the internet and your right, they are a great information repository. Perhaps we could syndicate some blogs onto liftweb.net during the rewrite (yes, im going to rewrite it at last!)... certainly open for that. Cheers, Tim PS: Sorry that was a bit of a rant, but this is a frustrating issue that i've been pushing for over a year ;-) On Dec 19, 1:16 pm, Hannes hannes.flo...@gmx.li wrote: Definitely! I would like one location for everything, but I believe that the current situation is not like that. - there two API docs 1.0 and 1.1, the latter is hard to find - there's liftweb.net (a little bit out-dated) - there's the Wiki - there's David's Blog (that has some unique information) What did I forget? thanks. Why not improve the existing wiki on github? Or fork the book and make improvements that way? I'm not opposed to additional resources, but why create another place where docs may or not be out of date? I think that Lift is still at the point where one location of docs is better. My opinion. On Dec 19, 6:37 am, Hannes hannes.flo...@gmx.li wrote: Hi Lifters, I'm thinking about setting up a site that takes together all available information about Lift (Links, News, ...). I would like to know, if this
[Lift] Re: [scala-internals] RC4 candidate for the first 2.8.0 beta
On Sun, Dec 20, 2009 at 12:39 PM, martin odersky martin.oder...@epfl.ch 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.
Re: [Lift] Validation errors shown on CRUDify models?
tommycli tommy...@ucla.edu writes:
Are validation errors shown on CRUDify create/edit pages?
I have validators set up like this:
object subdomain extends MappedString(this,64) {
override def validations = List(valUnique(Subdomain taken.)_,
valRegex(Pattern.compile(^[A-Za-z0-9-]*$),
Subdomains must only contain
letters, numbers, and
hyphens.
)_) ::: super.validations
override def displayName = Subdomain
override def dbIndexed_? = true
}
And on an invalid entry, the form will just silently fail - that is,
when submitted, it will just give back the exact same form state - no
error messages, no changes in the filled-out entries. This confuses me.
How should the messages be displayed? AFAIK, per field message display
is not supported atm. You can display all errors (incl field errors) by
including the
lift:Msgs showAll=true/
snippet. Note the showAll attribute which is now needed to show field
level errors.
/Jeppe
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [Lift Announce] **Important** Announcing the Lift 2.0 branch
Indrajit, Great to see the next refactoring round! I got the branch and there are a lot of oddities, e.g.: - All the POMs I looked at are still 1.1, not 2.0 - framework/pom.xml references module lift-archetypes and lift-examples - The parent POM is empty Maybe you did not update the branch on GitHub with your latest changes? Heiko 2009/12/20 Indrajit Raychaudhuri indraj...@gmail.com Okay Folks, Lift 2.0 branch has shaped up enough for everybody to play with. Checkout the branch irc_wip_lift20 and get going! Just be aware that it's still undergoing updated and changes incrementally and there are few rough edges. Key changes: 1. The project tree has been restructured according to the proposal sent out earlier [1]. To summarize, we now have three top level projects (framework, archetypes and examples) each with independent build life-cycle. There are other additional infra projects that are less to do with the actual code. A quick summary of the top-level projects: 1. Framework: The whole of Lift Framework that matter most to most. The usual modules (viz., lift-base, lift-persistence and lift-modules) have got nested within. Therefore, from now on, building Lift framework would mean just that. Doing a git pull or git clone as usual, changing to framework directory and running mvn install. 2. Archetypes: The standard distributed archetypes. The archetypes help you get quick started with a Lift based project. If you are not into building maven archetypes, you can stay clear of this. But a quick probe is welcome. 3. Examples: All the Lift examples are grouped into this project. If you are generally interested in learning different techniques from examples you don't have to build the whole of Lift anymore. Well that was still the case earlier, but now it's even more obvious. And it's true the other way round too, if you have to build Lift framework from source, you don't have to build the examples along with it. Another point: the examples won't be deployed on scala-tools maven repo anymore. Those war files up there serve no good purpose. Everything now gets neatly tucked into their respective homes :) Additional points that you should be aware of: A. Availability on scala-tools repository: - Components of framework would be available - Components of archetypes would be available - Components of examples would *not* be available B. Availability on scala-tools Maven site: Site generated from framework would be the main content of scala-tools Maven site. Depending on how things go, we might even have a home of it's own at http://dev.liftweb.net. (Separate proposal coming up) C. Lift Parent Project Model: The top level pom.xml has moved to it's own home at resources/project- model. This would stay as a 'flyweight' project (as in boxing, not GoF) on it's own that would strictly control the common behavior, plugin dependencies, versions etc. for all the top level projects (framework, archetypes, examples). This would be deployed on scala- tools repository. D. Lift Site Skin (WIP): I haven't started working on this yet. But the intent is to create a project site that is of some real value and serves as placeholder for mostly 'auto-generated' docs. See #B above. E. Still pending: a. Migration to Scala 2.8 branch. Intend to have stable master created first with everything working as usual without being caught into Scala release cycle. Hopefully, this branch and '280_port' would merge soon! b. Higher quality site generation (See #B above, proposal coming up) c. Site skin (See #D above) d. Hudson integration and better release management. So that certain steps in Committer release process [2] become automatic (waiting for merge to master and hudson maintenance) e. Having a nice README.md at the top level f. General spit and polish F: To be decided: a. Future of lift-core. (Separate mail coming) b. Relevance of OtherLicensedWorks.txt (repo distribution of javamail is now under CDDL and license automatically reflects in dependency page) c. Need for remove-trailings.sh (can be replaced by git pre-commit hook) [1] http://groups.google.com/group/liftweb/browse_thread/thread/450a3e741999b5df [2] http://wiki.github.com/dpp/liftweb/committer-release-process Feedbacks most welcome! Cheers, Indrajit -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Documentation Site
Well for the current information the places to go are http://scala-tools.org/mvnsites-snapshots/liftweb/index.html and http://wiki.github.com/dpp/liftweb if that will help you. On Dec 21, 7:47 pm, johncch john...@gmail.com wrote: Well, this is an apt discussion at this point in time I feel. One of the weakness of the Lift Project is really the sparse documentation, as well as the rapid cycle of development obsoleting virtually many of the slightly older code out there. I don't mind contributing my time improving the documentation. Perhaps one of the reasons why people don't contribute back is that the wiki is not very prominent, for one reason or another. It's just rarely referenced anywhere else most of the time. Would appreciate a more concentrated effort on this. I haven't actually seen the lift 1.1 scala docs. For example,http://www.scala-tools.org/mvnsites-snapshots/liftweb/lift-base/lift-... points to a blank page - that's for Lift common. I mostly rely on the IDE(idea) to open up declarations via maven.. not exactly the best method since the source code is more often than not not commented. The lift framework is pretty massive, I think that's the reason why it's difficult to write comprehensive documentation for it. I'm just wondering what is a good way to go about doing that? A list of how-tos plus in depth discussion about each part of the framework i.e. base, or common, or? Perhaps there can be one page for every logical object in Lift. regards, CH On Dec 21, 6:12 am, Timothy Perrett timo...@getintheloop.eu wrote: I really don't think thats the issue - Lift is not closed to committing... if that were the case, David would never have recruited us onto the team ;-) 95% of all OSS projects i've ever come across have the same policy when it comes to wikis etc... they are organic, community driven beasts. For instance, I was no aware that you had written any articles... but that is great. You say you want them fleshed out? In what way / what information do you need. Writing documentation is actually a great way to understand something because it means you have to fully grok it in order to teach others - we need to solve the documentation issue for sure, and any contribution you or others have is very much welcome. Cheers, Tim On 20 Dec 2009, at 21:43, Randinn wrote: To give the benefit of doubt to people who use Lift knowing that is closed to commiting they may think the same about the documentation. I have added a bit but I've more thrown up a few pages and figured someone with more knowledge would flesh them out. On Dec 20, 8:47 pm, Timothy Perrett timo...@getintheloop.eu wrote: 1.0 is the last official release that was not a milestone or snapshot - thus, they are the primary api docs right now until we release 2.0 (that is, what was being called 1.1 is being renamed to 2.0). API docs are a process issue, and handled as part of our build process - they will always live both on scala-tools and liftweb.net where applicable. They wont ever sit anywhere else (officially). Yes, the wiki is a little out dated. I forget the number of times i've tried to spear head a wiki effort... the bottom line is that other people need to start writing content - there are a fair number of competent lift users in the community who simply are not giving anything back by way of articles or wiki cleaning - thus our docs get out dated fast because the team prefer to write code than documentation. We even tried to appointed a wiki gardener but he appears to have just disappeared into the ether... Id be open to hearing suggestions on how one could keep the wiki more up to date? Short of users actually contributing back, there is a limit on what the team can do at anyone time. We are getting there, but its not going to be an overnight process. Blogs - a fundamental corner stone of the internet and your right, they are a great information repository. Perhaps we could syndicate some blogs onto liftweb.net during the rewrite (yes, im going to rewrite it at last!)... certainly open for that. Cheers, Tim PS: Sorry that was a bit of a rant, but this is a frustrating issue that i've been pushing for over a year ;-) On Dec 19, 1:16 pm, Hannes hannes.flo...@gmx.li wrote: Definitely! I would like one location for everything, but I believe that the current situation is not like that. - there two API docs 1.0 and 1.1, the latter is hard to find - there's liftweb.net (a little bit out-dated) - there's the Wiki - there's David's Blog (that has some unique information) What did I forget? thanks. Why not improve the existing wiki on github? Or fork the book and make improvements that way? I'm not opposed to additional resources, but why create another place where docs may or not be out of date? I think that Lift is still at the
[Lift] Re: About the performance
Spoken like a true zealot. The difference between us is that I've used both Java and .NET in a professional capacity, and you obviously have not. If you did, you wouldn't have any questions about the performance and stability of CLR. it's also much more primitive than modern JVMs I'd say it's a bit simpler than modern JVMs, and if anything, that's an advantage. It's a lot easier to walk if you don't shoot yourself in both feet to begin with like Sun did. And they need dynamic runtime for the same exact reason why Sun is adding dynamic extensions in Java 7 - so that dynamic languages would get a bit faster. As a heavy user of Groovy and an occasional user of IronPython, I'm glad they're putting in the effort. Regarding the benchmarks, just for the heck of it, I've grabbed the C# and Java variants of Manderlbrot benchmark from Language Shootout site (http://shootout.alioth.debian.org/u32q/csharp.php), compiled them both for Java (using JDK 1.6.0_17) and .NET (using v3.5 of C# compiler) and ran them on my Windows 7 box (4GB RAM, 3-core Phenom II @ 2.8GHz). With identical parameters, .NET version takes 14 seconds, and Java version takes 16 seconds (yes, I did use the server runtime in Java's case). I can post the exact command lines and source code, or you can grab the source code and verify yourself. Likewise, the Fannkuch benchmark took 22 seconds on CLR vs 24 seconds on Server JRE, and there's a version of this benchmark optimized for CLR (using unsafe code, stack allocation and pointer math) that completes in 15 (!) seconds. Try it yourself if you have access to a Windows machine, those microbenchmarks are not that hard to run. So much for CLR being nowhere near JVM. If you want a larger, more realistic benchmark, compare Lucene.NET to Lucene. It runs substantially faster, despite being pretty much a straight, class-for-class port of Java code. On Dec 14, 10:05 am, Marcin Mielżyński l...@gazeta.pl wrote: On 2009-12-14 02:26, DMB wrote: That's a common misconception among Java folks. Leaving aside the relative merits of the various web frameworks, .NET runtime is about 10% faster on Windows in steady state than Sun Server JRE, and it uses Back it up by a decent benchmark, otherwise tell me where would .NET end up here:http://www.stefankrause.net/wp/?p=6 It's a common misconception among .NET folks that they think what they think. half as much RAM to boot. Mono is slower than JRE (aside from app start-up times, which are faster), but its memory consumption profile is similar to that of Microsoft runtime. It helps when the runtime is Because .NET is not dynamic enough, it doesnt have runtime profiling etc, why did they need DLR then ? (And how much memory does it use ? :) actually designed in a way that doesn't make methods virtual by I cant see the point. Can .NET devirtualize virtual methods ? (JVMs can completely devirtualize abstract method callsites too and inline them without guards if there's single implementer) default, has reified generics, bytecode that's optimized for JIT, and Generics yest, it's a plus, but .NET jit is NOWHERE near modern JVMs. easy to use infrastructure to write your own compilers (which enables, e.g. precompiled ASPX pages and regexes). Offline compilation kills peak performance. .NET is not really an option in the open source world (for a variety of well known reasons), but make no mistake -- it is a technically superior runtime in most aspects that matter. I'm hoping LLVM will close the gap on the Linux/UNIX side. I think today's Sun JRE does a good job given what it has to work with, but it's crippled from the start by some unfortunate design choices, and I don't see much improvement anywhere on the horizon, aside from the dynamic extensions and OSGI in Java 7. Which is why people are looking at e.g. Scala. Once the developer tries closures and functional programming on sequences, it's kinda hard to go back to Java. Yes, .NET learned bunch of things from Java and many mistakes has been fixed, but it's also much more primitive than modern JVMs, also, it's specification isn't that demanding. It's also light years behind in terms of optimization tricks, stability and portability. lopex -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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 Announce] **Important** Announcing the Lift 2.0 branch
Heiko, That looks like the initial check-in I did on the branch. There has been quite a few commits since. I double checked to ensure the git push. Seems fine. Looks like the little bird agrees too :) [http://twitter.com/liftweb/status/6862128603] Cheers, Indrajit On 21/12/09 3:41 PM, Heiko Seeberger wrote: Indrajit, Great to see the next refactoring round! I got the branch and there are a lot of oddities, e.g.: * All the POMs I looked at are still 1.1, not 2.0 * framework/pom.xml references module lift-archetypes and lift-examples * The parent POM is empty Maybe you did not update the branch on GitHub with your latest changes? Heiko 2009/12/20 Indrajit Raychaudhuri indraj...@gmail.com mailto:indraj...@gmail.com Okay Folks, Lift 2.0 branch has shaped up enough for everybody to play with. Checkout the branch irc_wip_lift20 and get going! Just be aware that it's still undergoing updated and changes incrementally and there are few rough edges. Key changes: 1. The project tree has been restructured according to the proposal sent out earlier [1]. To summarize, we now have three top level projects (framework, archetypes and examples) each with independent build life-cycle. There are other additional infra projects that are less to do with the actual code. A quick summary of the top-level projects: 1. Framework: The whole of Lift Framework that matter most to most. The usual modules (viz., lift-base, lift-persistence and lift-modules) have got nested within. Therefore, from now on, building Lift framework would mean just that. Doing a git pull or git clone as usual, changing to framework directory and running mvn install. 2. Archetypes: The standard distributed archetypes. The archetypes help you get quick started with a Lift based project. If you are not into building maven archetypes, you can stay clear of this. But a quick probe is welcome. 3. Examples: All the Lift examples are grouped into this project. If you are generally interested in learning different techniques from examples you don't have to build the whole of Lift anymore. Well that was still the case earlier, but now it's even more obvious. And it's true the other way round too, if you have to build Lift framework from source, you don't have to build the examples along with it. Another point: the examples won't be deployed on scala-tools maven repo anymore. Those war files up there serve no good purpose. Everything now gets neatly tucked into their respective homes :) Additional points that you should be aware of: A. Availability on scala-tools repository: - Components of framework would be available - Components of archetypes would be available - Components of examples would *not* be available B. Availability on scala-tools Maven site: Site generated from framework would be the main content of scala-tools Maven site. Depending on how things go, we might even have a home of it's own at http://dev.liftweb.net. (Separate proposal coming up) C. Lift Parent Project Model: The top level pom.xml has moved to it's own home at resources/project- model. This would stay as a 'flyweight' project (as in boxing, not GoF) on it's own that would strictly control the common behavior, plugin dependencies, versions etc. for all the top level projects (framework, archetypes, examples). This would be deployed on scala- tools repository. D. Lift Site Skin (WIP): I haven't started working on this yet. But the intent is to create a project site that is of some real value and serves as placeholder for mostly 'auto-generated' docs. See #B above. E. Still pending: a. Migration to Scala 2.8 branch. Intend to have stable master created first with everything working as usual without being caught into Scala release cycle. Hopefully, this branch and '280_port' would merge soon! b. Higher quality site generation (See #B above, proposal coming up) c. Site skin (See #D above) d. Hudson integration and better release management. So that certain steps in Committer release process [2] become automatic (waiting for merge to master and hudson maintenance) e. Having a nice README.md at the top level f. General spit and polish F: To be decided: a. Future of lift-core. (Separate mail coming) b. Relevance of OtherLicensedWorks.txt (repo distribution of javamail is now under CDDL and license automatically reflects in dependency page) c. Need for remove-trailings.sh (can be replaced by git pre-commit hook) [1] http://groups.google.com/group/liftweb/browse_thread/thread/450a3e741999b5df [2] http://wiki.github.com/dpp/liftweb/committer-release-process Feedbacks most welcome!
[Lift] Re: **Important** Announcing the Lift 2.0 branch
Hi Indrajit, I am new to both Scala and Lift. I have spent some time exploring Scala and only a little on Lift 1.0. I plan to do some real work with Lift soon, would you recommend that I focus on Lift 2.0 branch? Is there any guesstimate Lift 2.0 release schedule? Regards chungonn On Dec 21, 3:34 am, Indrajit Raychaudhuri indraj...@gmail.com wrote: Okay Folks, Lift 2.0 branch has shaped up enough for everybody to play with. Checkout the branch irc_wip_lift20 and get going! Just be aware that it's still undergoing updated and changes incrementally and there are few rough edges. Key changes: 1. The project tree has been restructured according to the proposal sent out earlier [1]. To summarize, we now have three top level projects (framework, archetypes and examples) each with independent build life-cycle. There are other additional infra projects that are less to do with the actual code. A quick summary of the top-level projects: 1. Framework: The whole of Lift Framework that matter most to most. The usual modules (viz., lift-base, lift-persistence and lift-modules) have got nested within. Therefore, from now on, building Lift framework would mean just that. Doing a git pull or git clone as usual, changing to framework directory and running mvn install. 2. Archetypes: The standard distributed archetypes. The archetypes help you get quick started with a Lift based project. If you are not into building maven archetypes, you can stay clear of this. But a quick probe is welcome. 3. Examples: All the Lift examples are grouped into this project. If you are generally interested in learning different techniques from examples you don't have to build the whole of Lift anymore. Well that was still the case earlier, but now it's even more obvious. And it's true the other way round too, if you have to build Lift framework from source, you don't have to build the examples along with it. Another point: the examples won't be deployed on scala-tools maven repo anymore. Those war files up there serve no good purpose. Everything now gets neatly tucked into their respective homes :) Additional points that you should be aware of: A. Availability on scala-tools repository: - Components of framework would be available - Components of archetypes would be available - Components of examples would *not* be available B. Availability on scala-tools Maven site: Site generated from framework would be the main content of scala-tools Maven site. Depending on how things go, we might even have a home of it's own athttp://dev.liftweb.net. (Separate proposal coming up) C. Lift Parent Project Model: The top level pom.xml has moved to it's own home at resources/project- model. This would stay as a 'flyweight' project (as in boxing, not GoF) on it's own that would strictly control the common behavior, plugin dependencies, versions etc. for all the top level projects (framework, archetypes, examples). This would be deployed on scala- tools repository. D. Lift Site Skin (WIP): I haven't started working on this yet. But the intent is to create a project site that is of some real value and serves as placeholder for mostly 'auto-generated' docs. See #B above. E. Still pending: a. Migration to Scala 2.8 branch. Intend to have stable master created first with everything working as usual without being caught into Scala release cycle. Hopefully, this branch and '280_port' would merge soon! b. Higher quality site generation (See #B above, proposal coming up) c. Site skin (See #D above) d. Hudson integration and better release management. So that certain steps in Committer release process [2] become automatic (waiting for merge to master and hudson maintenance) e. Having a nice README.md at the top level f. General spit and polish F: To be decided: a. Future of lift-core. (Separate mail coming) b. Relevance of OtherLicensedWorks.txt (repo distribution of javamail is now under CDDL and license automatically reflects in dependency page) c. Need for remove-trailings.sh (can be replaced by git pre-commit hook) [1]http://groups.google.com/group/liftweb/browse_thread/thread/450a3e741... [2]http://wiki.github.com/dpp/liftweb/committer-release-process Feedbacks most welcome! Cheers, Indrajit -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: **Important** Announcing the Lift 2.0 branch
Hi Chungonn, At the moment the Lift 2.0 branch is updated and synchronized with the master. So yes, feel free to check that out and play with it by all means. However, be aware that I am making lot of commits on that branch (mostly cosmetic and build related). So keep a watch and keep doing frequent git pulls [1]. Lift 2.0 would be on Scala 2.8 so it has a dependency on the release schedule of Scala 2.8. But we are hoping for an early 2010 release. [1] Watch http://twitter.com/liftweb to keep track :) Cheers, Indrajit On 21/12/09 3:53 PM, chungonn wrote: Hi Indrajit, I am new to both Scala and Lift. I have spent some time exploring Scala and only a little on Lift 1.0. I plan to do some real work with Lift soon, would you recommend that I focus on Lift 2.0 branch? Is there any guesstimate Lift 2.0 release schedule? Regards chungonn On Dec 21, 3:34 am, Indrajit Raychaudhuriindraj...@gmail.com wrote: Okay Folks, Lift 2.0 branch has shaped up enough for everybody to play with. Checkout the branch irc_wip_lift20 and get going! Just be aware that it's still undergoing updated and changes incrementally and there are few rough edges. Key changes: 1. The project tree has been restructured according to the proposal sent out earlier [1]. To summarize, we now have three top level projects (framework, archetypes and examples) each with independent build life-cycle. There are other additional infra projects that are less to do with the actual code. A quick summary of the top-level projects: 1. Framework: The whole of Lift Framework that matter most to most. The usual modules (viz., lift-base, lift-persistence and lift-modules) have got nested within. Therefore, from now on, building Lift framework would mean just that. Doing a git pull or git clone as usual, changing to framework directory and running mvn install. 2. Archetypes: The standard distributed archetypes. The archetypes help you get quick started with a Lift based project. If you are not into building maven archetypes, you can stay clear of this. But a quick probe is welcome. 3. Examples: All the Lift examples are grouped into this project. If you are generally interested in learning different techniques from examples you don't have to build the whole of Lift anymore. Well that was still the case earlier, but now it's even more obvious. And it's true the other way round too, if you have to build Lift framework from source, you don't have to build the examples along with it. Another point: the examples won't be deployed on scala-tools maven repo anymore. Those war files up there serve no good purpose. Everything now gets neatly tucked into their respective homes :) Additional points that you should be aware of: A. Availability on scala-tools repository: - Components of framework would be available - Components of archetypes would be available - Components of examples would *not* be available B. Availability on scala-tools Maven site: Site generated from framework would be the main content of scala-tools Maven site. Depending on how things go, we might even have a home of it's own athttp://dev.liftweb.net. (Separate proposal coming up) C. Lift Parent Project Model: The top level pom.xml has moved to it's own home at resources/project- model. This would stay as a 'flyweight' project (as in boxing, not GoF) on it's own that would strictly control the common behavior, plugin dependencies, versions etc. for all the top level projects (framework, archetypes, examples). This would be deployed on scala- tools repository. D. Lift Site Skin (WIP): I haven't started working on this yet. But the intent is to create a project site that is of some real value and serves as placeholder for mostly 'auto-generated' docs. See #B above. E. Still pending: a. Migration to Scala 2.8 branch. Intend to have stable master created first with everything working as usual without being caught into Scala release cycle. Hopefully, this branch and '280_port' would merge soon! b. Higher quality site generation (See #B above, proposal coming up) c. Site skin (See #D above) d. Hudson integration and better release management. So that certain steps in Committer release process [2] become automatic (waiting for merge to master and hudson maintenance) e. Having a nice README.md at the top level f. General spit and polish F: To be decided: a. Future of lift-core. (Separate mail coming) b. Relevance of OtherLicensedWorks.txt (repo distribution of javamail is now under CDDL and license automatically reflects in dependency page) c. Need for remove-trailings.sh (can be replaced by git pre-commit hook) [1]http://groups.google.com/group/liftweb/browse_thread/thread/450a3e741... [2]http://wiki.github.com/dpp/liftweb/committer-release-process Feedbacks most welcome! Cheers, Indrajit -- You received this message because you are subscribed to the Google Groups Lift group. To post to this
Re: [Lift] Re: **Important** Announcing the Lift 2.0 branch
Hi Indrajit, Thanks for the speedy response. Cheers! chungonn Indrajit Raychaudhuri wrote, On 12/21/09 7:59 PM: Hi Chungonn, At the moment the Lift 2.0 branch is updated and synchronized with the master. So yes, feel free to check that out and play with it by all means. However, be aware that I am making lot of commits on that branch (mostly cosmetic and build related). So keep a watch and keep doing frequent git pulls [1]. Lift 2.0 would be on Scala 2.8 so it has a dependency on the release schedule of Scala 2.8. But we are hoping for an early 2010 release. [1] Watch http://twitter.com/liftweb to keep track :) Cheers, Indrajit On 21/12/09 3:53 PM, chungonn wrote: Hi Indrajit, I am new to both Scala and Lift. I have spent some time exploring Scala and only a little on Lift 1.0. I plan to do some real work with Lift soon, would you recommend that I focus on Lift 2.0 branch? Is there any guesstimate Lift 2.0 release schedule? Regards chungonn On Dec 21, 3:34 am, Indrajit Raychaudhuriindraj...@gmail.com wrote: Okay Folks, Lift 2.0 branch has shaped up enough for everybody to play with. Checkout the branch irc_wip_lift20 and get going! Just be aware that it's still undergoing updated and changes incrementally and there are few rough edges. Key changes: 1. The project tree has been restructured according to the proposal sent out earlier [1]. To summarize, we now have three top level projects (framework, archetypes and examples) each with independent build life-cycle. There are other additional infra projects that are less to do with the actual code. A quick summary of the top-level projects: 1. Framework: The whole of Lift Framework that matter most to most. The usual modules (viz., lift-base, lift-persistence and lift-modules) have got nested within. Therefore, from now on, building Lift framework would mean just that. Doing a git pull or git clone as usual, changing to framework directory and running mvn install. 2. Archetypes: The standard distributed archetypes. The archetypes help you get quick started with a Lift based project. If you are not into building maven archetypes, you can stay clear of this. But a quick probe is welcome. 3. Examples: All the Lift examples are grouped into this project. If you are generally interested in learning different techniques from examples you don't have to build the whole of Lift anymore. Well that was still the case earlier, but now it's even more obvious. And it's true the other way round too, if you have to build Lift framework from source, you don't have to build the examples along with it. Another point: the examples won't be deployed on scala-tools maven repo anymore. Those war files up there serve no good purpose. Everything now gets neatly tucked into their respective homes :) Additional points that you should be aware of: A. Availability on scala-tools repository: - Components of framework would be available - Components of archetypes would be available - Components of examples would *not* be available B. Availability on scala-tools Maven site: Site generated from framework would be the main content of scala-tools Maven site. Depending on how things go, we might even have a home of it's own athttp://dev.liftweb.net. (Separate proposal coming up) C. Lift Parent Project Model: The top level pom.xml has moved to it's own home at resources/project- model. This would stay as a 'flyweight' project (as in boxing, not GoF) on it's own that would strictly control the common behavior, plugin dependencies, versions etc. for all the top level projects (framework, archetypes, examples). This would be deployed on scala- tools repository. D. Lift Site Skin (WIP): I haven't started working on this yet. But the intent is to create a project site that is of some real value and serves as placeholder for mostly 'auto-generated' docs. See #B above. E. Still pending: a. Migration to Scala 2.8 branch. Intend to have stable master created first with everything working as usual without being caught into Scala release cycle. Hopefully, this branch and '280_port' would merge soon! b. Higher quality site generation (See #B above, proposal coming up) c. Site skin (See #D above) d. Hudson integration and better release management. So that certain steps in Committer release process [2] become automatic (waiting for merge to master and hudson maintenance) e. Having a nice README.md at the top level f. General spit and polish F: To be decided: a. Future of lift-core. (Separate mail coming) b. Relevance of OtherLicensedWorks.txt (repo distribution of javamail is now under CDDL and license automatically reflects in dependency page) c. Need for remove-trailings.sh (can be replaced by git pre-commit hook) [1]http://groups.google.com/group/liftweb/browse_thread/thread/450a3e741... [2]http://wiki.github.com/dpp/liftweb/committer-release-process Feedbacks most
[Lift] Re: Nexus/Hudson maitenance on scala-tools.org
The hudson upgrade has been completed, however the nexus upgrade ran into some issues. We've reverted to the previous version of nexus. There will be a continuing maintenance window (for nexus only) from 8pm - 11pm EST today (December 21st). Thanks for your patience! - Josh Suereth On Fri, Dec 18, 2009 at 3:38 PM, Josh Suereth joshua.suer...@gmail.comwrote: All, Nexus/Hudson will be temporarily disabled Saturday/Sunday from 8-11pm EST. These services are being upgraded. I'll post an email 15 minutes before the actual shutdown and immediately after things are back up and working. You should be able to make use of artifacts on the scala-tools.org server, however nightly builds and posting releases will be disabled. If anyone has a specific release/test they need performed during this period please send me an email and I can accomodate you. Thanks for your cooperation! - Josh Suereth -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] Status of DB backend for record?
Hi, What's the status of the DB backend for Record? I'm asking because, I'm about to start adding temporal object support to mapper but would hate to repeat this exercise soon if mapper is going to be superseded by record ;-) Alternatively, can somebody in the know enlighten me how mapper fits (if at all) into the big picture when Record is eventually in place? /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Sitemap - rendering title attributes for the links
Can someone point me in the right direction to get tooltips (title attributes) rendered in my sitemap? I'd like to add text to each link, so they get rendered like this: lia href=link title=what will happen when you click on this linksome page/a/li thx - Alex -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: [maven-and-scala] Re: Nexus/Hudson maitenance on scala-tools.org
Neato! Thank you very much for the upgrade and the update on that! Should we expect a java5 environment as well, or are you deferring this for now? Cheers, Indrajit On 21/12/09 7:44 PM, Josh Suereth wrote: The hudson upgrade has been completed, however the nexus upgrade ran into some issues. We've reverted to the previous version of nexus. There will be a continuing maintenance window (for nexus only) from 8pm - 11pm EST today (December 21st). Thanks for your patience! - Josh Suereth On Fri, Dec 18, 2009 at 3:38 PM, Josh Suereth joshua.suer...@gmail.com mailto:joshua.suer...@gmail.com wrote: All, Nexus/Hudson will be temporarily disabled Saturday/Sunday from 8-11pm EST. These services are being upgraded. I'll post an email 15 minutes before the actual shutdown and immediately after things are back up and working. You should be able to make use of artifacts on the scala-tools.org http://scala-tools.org server, however nightly builds and posting releases will be disabled. If anyone has a specific release/test they need performed during this period please send me an email and I can accomodate you. Thanks for your cooperation! - Josh Suereth -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: Confused about validation
Nice to see that there is discussion about this. I do not have much web framework background but the Wicket Validators are really nice. with best regards On 18 Dez., 10:13, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: Naftoli Gugenheim naftoli...@gmail.com writes: What would such an abstraction do? What code would you like to write (including templates) and what should it do? I had some input here: http://groups.google.com/group/liftweb/browse_thread/thread/814de5be3... /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Status of DB backend for record?
I think it's safe to say Mapper will live into the indefinite future, so please make your changes on Mapper. On Mon, Dec 21, 2009 at 6:30 AM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: Hi, What's the status of the DB backend for Record? I'm asking because, I'm about to start adding temporal object support to mapper but would hate to repeat this exercise soon if mapper is going to be superseded by record ;-) Alternatively, can somebody in the know enlighten me how mapper fits (if at all) into the big picture when Record is eventually in place? /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- 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.
Re: [Lift] Re: [maven-and-scala] Re: Nexus/Hudson maitenance on scala-tools.org
Deferred for now. I was trying to figure out how to set up build nodes which would handle building against various platforms (e.g. windows, mac, ubuntu, fedora, etc.). This is where we could better customize what's installed on our build farm. Might take a different approach short term, but this is where we'd like to take it long term. - Josh On Mon, Dec 21, 2009 at 9:38 AM, Indrajit Raychaudhuri indraj...@gmail.comwrote: Neato! Thank you very much for the upgrade and the update on that! Should we expect a java5 environment as well, or are you deferring this for now? Cheers, Indrajit On 21/12/09 7:44 PM, Josh Suereth wrote: The hudson upgrade has been completed, however the nexus upgrade ran into some issues. We've reverted to the previous version of nexus. There will be a continuing maintenance window (for nexus only) from 8pm - 11pm EST today (December 21st). Thanks for your patience! - Josh Suereth On Fri, Dec 18, 2009 at 3:38 PM, Josh Suereth joshua.suer...@gmail.com mailto:joshua.suer...@gmail.com wrote: All, Nexus/Hudson will be temporarily disabled Saturday/Sunday from 8-11pm EST. These services are being upgraded. I'll post an email 15 minutes before the actual shutdown and immediately after things are back up and working. You should be able to make use of artifacts on the scala-tools.org http://scala-tools.org server, however nightly builds and posting releases will be disabled. If anyone has a specific release/test they need performed during this period please send me an email and I can accomodate you. Thanks for your cooperation! - Josh Suereth -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: **Important** Announcing the Lift 2.0 branch
On Sun, Dec 20, 2009 at 10:37 PM, Xuefeng Wu ben...@gmail.com wrote: That's great that Lift2.0 is on Scala 2.8 Lift is not on Scala 2.8 at this time. There is an experimental branch that we're using to track master which compiles a subset of Lift against Scala 2.8. At some point in the future, the master version of Lift will run on Scala 2.8. That may mean that the release version of Lift 2.0 come shortly after the release version of Scala 2.8. That may mean that after Scala 2.8 is released, we will do a release of Lift 2.0.x built against Scala 2.8. However, anything built against Scala 2.8 is going to be source code incompatible with anything built with Scala 2.7.x. We do not have the resources to maintain two parallel branches of Lift that run against Scala 2.7.x and 2.8. There are source code incompabilities between the two versions and without an #ifdef mechanism in Scala, it's just not feasible to support both versions of the language. We will listen to the community (with a special ear toward the production sites using Lift) as to when the best time to make Scala 2.8 the version of Scala supported by Lift master. On Mon, Dec 21, 2009 at 1:17 PM, Indrajit Raychaudhuri indraj...@gmail.com wrote: Eventually, yes, Lift 2.0 would be on Scala 2.8. But that's not the only difference between Lift 1.0 and Lift 2.0. To follow the context, you might want to take a look at this thread: http://groups.google.com/group/liftweb/browse_thread/thread/479edef7700ccce6 . Cheers, Indrajit On 21/12/09 8:22 AM, Xuefeng Wu wrote: I mean that lift1.1 and lift2.0 may have the same futures, But lift1.1 is for Scala2.7 and lift2.0 is for Scala2.8. With Scala2.8 stable , the lift1.1 could not be enhanced. It's better than Lift2.0-Scala2.7 and Lift2.0-Scala2.8. And there're better explain why Lift2.0 and Lift1.1 if people ask what's the different between Lift2.0 and Lift1.1? On Mon, Dec 21, 2009 at 9:31 AM, Randinn rand...@gmail.com mailto:rand...@gmail.com wrote: Why not with 2.8 just going to beta 2.0 my estimation is that 2.0 will be finished before On Dec 21, 12:03 pm, Xuefeng Wu ben...@gmail.com mailto:ben...@gmail.com wrote: Why not release Lift2.0 with Scala2.8? On Mon, Dec 21, 2009 at 3:34 AM, Indrajit Raychaudhuri indraj...@gmail.com mailto:indraj...@gmail.comwrote: Okay Folks, Lift 2.0 branch has shaped up enough for everybody to play with. Checkout the branch irc_wip_lift20 and get going! Just be aware that it's still undergoing updated and changes incrementally and there are few rough edges. Key changes: 1. The project tree has been restructured according to the proposal sent out earlier [1]. To summarize, we now have three top level projects (framework, archetypes and examples) each with independent build life-cycle. There are other additional infra projects that are less to do with the actual code. A quick summary of the top-level projects: 1. Framework: The whole of Lift Framework that matter most to most. The usual modules (viz., lift-base, lift-persistence and lift-modules) have got nested within. Therefore, from now on, building Lift framework would mean just that. Doing a git pull or git clone as usual, changing to framework directory and running mvn install. 2. Archetypes: The standard distributed archetypes. The archetypes help you get quick started with a Lift based project. If you are not into building maven archetypes, you can stay clear of this. But a quick probe is welcome. 3. Examples: All the Lift examples are grouped into this project. If you are generally interested in learning different techniques from examples you don't have to build the whole of Lift anymore. Well that was still the case earlier, but now it's even more obvious. And it's true the other way round too, if you have to build Lift framework from source, you don't have to build the examples along with it. Another point: the examples won't be deployed on scala-tools maven repo anymore. Those war files up there serve no good purpose. Everything now gets neatly tucked into their respective homes :) Additional points that you should be aware of: A. Availability on scala-tools repository: - Components of framework would be available - Components of archetypes would be available - Components of examples would *not* be available B. Availability on scala-tools Maven site: Site generated from
Re: [Lift] The future of lift-core
On Sun, Dec 20, 2009 at 11:39 AM, Indrajit Raychaudhuri indraj...@gmail.com wrote: Folks, lift-core is a 'meta' project that can be added as a dependency to a Lift project to pull in all the Lift modules. This serves as a singular configuration point in a Lift based application. However, since lift-core downloads all the Lift modules (irrespective of whether the project needs it), adding this as the dependency slow down things for a standard project that doesn't need some additional modules. In a sense, we have moved quite a bit from the initial purpose of having single dependency on this 'meta' project in a Lift application. Further, the name is a misnomer now! The question, therefore is: Should we consider deprecating this? If not, we need to document when it should be preferred and when not. If yes, what should be the time frame for making the move? With Lift 2.0 coming up, Lift 2.0 is not coming up it's merely a rename of Lift 1.1 based on the naming rules that Heiko proposed and the Lift community adopted. The fact that the next release of Lift is going to be called 2.0 rather than 1.1 does not change the scope of the release. With that being said, deprecating lift-core is fine by me as long as there is an easy to understand deprecation message with clear instructions as to how to replace lift-core with whatever is necessary. now might be a good time to make a decision. Thoughts? Cheers, Indrajit NB: An open question to anybody in the Lift: Who among you are actually using lift-core in you project and what is the level of impact you foresee in case you have to move on to have an alternative approach. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Directory structure
On Sun, Dec 20, 2009 at 12:48 PM, Alex Boisvert alex.boisv...@gmail.comwrote: I don't think it's worth a lot of effort. If it's been tried and doesn't work nicely, I'm fine with sticking with the current structure. +1 I dislike the current lift-xxx structure, but we've got higher priorities. At some point, though, you have to decide who's boss, you or the build system ;) (I love taking jabs at Maven, sorry) Come on, you gotta open a can of whup-butt on Maven, Mr. Buildr-man. ;-) alex On Sun, Dec 20, 2009 at 12:42 PM, Indrajit Raychaudhuri indraj...@gmail.com wrote: Alex, Yes, it's possible to have artifactId ≠ directoryName for Maven projects. But last time I did this Maven chose to be very cruel with me (site generation, relative path resolutions etc. broke). Also see the point and convergence to decision here: http://groups.google.com/group/liftweb/msg/73a5652a55076384 In this case, I would usually type out cd liftcore blindly and the right thing would happen automatically thanks to shopt -s cdspell in my .bashrc config. But I digress. However, I won't mind re-opening this discussion on 'lift-' prefix if you want me to. Cheers, Indrajit On 21/12/09 1:29 AM, Alex Boisvert wrote: While we're discussing lift-core in a separate thread, I wanted to bring up a minor annoyance All module directories in the repository start with lift-, boisv...@smudge:~/git/liftweb$ tree -L 2 | grep lift |-- lift-archetypes | |-- lift-archetype-basic | |-- lift-archetype-blank | |-- lift-archetype-jpa-basic | |-- lift-archetype-jpa-blank | |-- lift-archetype-jpa-blank-single |-- lift-base | |-- lift-actor | |-- lift-common | |-- lift-json | |-- lift-util | |-- lift-webkit |-- lift-core |-- lift-examples | |-- hellolift |-- lift-misc | |-- lift-installer |-- lift-modules | |-- lift-amqp | |-- lift-facebook | |-- lift-jta | |-- lift-machine | |-- lift-oauth | |-- lift-openid | |-- lift-osgi | |-- lift-paypal | |-- lift-testkit | |-- lift-textile | |-- lift-widgets | |-- lift-wizard | |-- lift-xmpp |-- lift-persistence | |-- lift-jpa | |-- lift-mapper | |-- lift-record This naming isn't very practical when navigating the directory structure since it meddles with completion. e.g. cd TAB (beep!) lift- TAB (beep!) c TAB (finally completes core) Does Maven support simpler names? Could we have something like this? |-- base | |-- actor | |-- common | |-- json | |-- util | |-- webkit |-- modules | |-- amqp | |-- ... | |-- ... (I'm not suggesting change the names of the modules; just the names of the directories) alex -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] PayPal X
On Sun, Dec 20, 2009 at 2:42 PM, Timothy Perrett timo...@getintheloop.euwrote: Guys, Is their any appetite for adding support for the new Paypal X services? https://www.x.com/index.jspa Basically it allows you to seamlessly integrate the billing cycle without transferring to paypal I personally dont have a burning need, but im thinking it would be a cool extension to the paypal module. I'd love to see you write this Tim. ;-) Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: CMS or wiki built with Lift?
On Sun, Dec 20, 2009 at 1:43 PM, jlist9 jli...@gmail.com wrote: Thanks! No checkins for hoisted yet. I'll check out Democritus. I started working on Hoisted for my local elementary school and got un-sidetracked with paying work. Sorry. On Sun, Dec 20, 2009 at 12:44 PM, Randinn rand...@gmail.com wrote: Well, as far as CMS Glenn is working on one here http://github.com/glennSilverman/democritus and David is starting one here http://github.com/dpp/hoisted On Dec 21, 7:24 am, jlist9 jli...@gmail.com wrote: Hi, I haven't found anything when I searched but I'd like to double check here - is there an open source CMS (content management system) or wiki system built with Lift? I need to update a simple site and I'm hoping that I can learn Lift by examples. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- 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.
Re: [Lift] Validation errors shown on CRUDify models?
On Mon, Dec 21, 2009 at 1:53 AM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote:
tommycli tommy...@ucla.edu writes:
Are validation errors shown on CRUDify create/edit pages?
I have validators set up like this:
object subdomain extends MappedString(this,64) {
override def validations = List(valUnique(Subdomain taken.)_,
valRegex(Pattern.compile(^[A-Za-z0-9-]*$),
Subdomains must only contain
letters, numbers, and
hyphens.
)_) ::: super.validations
override def displayName = Subdomain
override def dbIndexed_? = true
}
And on an invalid entry, the form will just silently fail - that is,
when submitted, it will just give back the exact same form state - no
error messages, no changes in the filled-out entries. This confuses me.
How should the messages be displayed? AFAIK, per field message display
is not supported atm.
Yeah... I need to fix that. http://github.com/dpp/liftweb/issues#issue/254
You can display all errors (incl field errors) by
including the
lift:Msgs showAll=true/
snippet. Note the showAll attribute which is now needed to show field
level errors.
/Jeppe
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
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: Paranamer? Missing com.thoughtworks.paranamer:paranamer:jar:2.0
Thanks for confirming that it is indeed there. The problem was my thoughtworks directory in my local repository was owned by root, for some reason. Problem solved. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: Catch file upload exceptions?
Have you tried using in boot LiftRules.exceptionHandler.prepend (...) ? Br's, Marius On Dec 21, 11:43 pm, tiro tim.romb...@googlemail.com wrote: Hi, just wondering if anybody knows of a handy way to properly handle the exceptions that are thrown when a user uploads a file that exceeds the size limit (or who knows what else can happen)? The stack trace that I see in such a case is as follows -- and apart from trying S.addAround I don't see a any place where one could insert some exception handling: Message: org.apache.commons.fileupload.FileUploadBase $SizeLimitExceededException: the request was rejected because its size (7385713) exceeds the configured maximum (6291456) org.apache.commons.fileupload.FileUploadBase $FileItemIteratorImpl.init(FileUploadBase.java:914) org.apache.commons.fileupload.FileUploadBase.getItemIterator (FileUploadBase.java:331) org.apache.commons.fileupload.servlet.ServletFileUpload.getItemIterator (ServletFileUpload.java:148) net.liftweb.http.provider.servlet.HTTPRequestServlet$$anon$1.init (HTTPRequestServlet.scala:110) net.liftweb.http.provider.servlet.HTTPRequestServlet.extractFiles (HTTPRequestServlet.scala:100) net.liftweb.http.Req$$anonfun$5.apply(Req.scala:182) net.liftweb.http.Req$$anonfun$5.apply(Req.scala:156) net.liftweb.http.Req.x$17(Req.scala:351) net.liftweb.http.Req.uploadedFiles(Req.scala:350) net.liftweb.http.LiftSession.runParams(LiftSession.scala:306) net.liftweb.http.LiftSession.processRequest(LiftSession.scala:492) net.liftweb.http.LiftServlet.net$liftweb$http$LiftServlet$ $dispatchStatefulRequest(LiftServlet.scala:261) net.liftweb.http.LiftServlet$$anonfun$3.apply(LiftServlet.scala:171) net.liftweb.http.LiftServlet$$anonfun$3.apply(LiftServlet.scala:171) net.liftweb.http.S$.net$liftweb$http$S$$wrapQuery(S.scala:974) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit$1$ $anonfun$apply$25.apply(S.scala:1114) net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:911) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit $1.apply(S.scala:1112) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$.net$liftweb$http$S$$_nest2InnerInit(S.scala:) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun $apply$28$$anonfun$apply$29$$anonfun$apply$30$$anonfun$apply$31.apply (S.scala:1133) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun $apply$28$$anonfun$apply$29$$anonfun$apply$30.apply(S.scala:1132) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun $apply$28$$anonfun$apply$29.apply(S.scala:1131) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun $apply$28.apply(S.scala:1130) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1.apply (S.scala:1129) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$.net$liftweb$http$S$$_innerInit(S.scala:1128) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38$$anonfun$apply $39$$anonfun$apply$40$$anonfun$apply$41$$anonfun$apply$42.apply (S.scala:1175) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38$$anonfun$apply $39$$anonfun$apply$40$$anonfun$apply$41.apply(S.scala:1174) net.liftweb.http.CoreRequestVarHandler$class.apply(Vars.scala:325) net.liftweb.http.RequestVarHandler$.apply(Vars.scala:248) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38$$anonfun$apply $39$$anonfun$apply$40.apply(S.scala:1173) net.liftweb.http.CoreRequestVarHandler$class.apply(Vars.scala:325) net.liftweb.http.TransientRequestVarHandler$.apply(Vars.scala:252) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38$$anonfun$apply $39.apply(S.scala:1172) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38.apply(S.scala: 1171) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$_init$1.apply(S.scala:1170) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$._init(S.scala:1169) net.liftweb.http.S$.init(S.scala:825) net.liftweb.http.LiftServlet.doService(LiftServlet.scala:170) net.liftweb.http.LiftServlet$$anonfun$doIt$1$1.apply (LiftServlet.scala:72) net.liftweb.http.LiftServlet$$anonfun$doIt$1$1.apply
[Lift] Externalizing log4j configuration
Hi, all. I'm building a web app in Lift 1.0 and deploying to Jetty 6.1.22. I'm trying to figure out the best way (or any way) to externalize the log4j configuration. My ideal deployment would look like this: /usr/local/jetty/webapps/myapp.war /well/known/location/myapp-log4j.xml (i.e. not in the .war) If /well/known/location doesn't exist, a sane log4j.xml (possibly from within the .war) should be used. Anyone have advice on how to achieve this? I took a look at http://wiki.liftweb.net/index.php/HowTo_configure_logging, and the default.log4j.xml thing works, but I want config outside the .war. Is overrding LogBoot.defaultProps in Boot.scala -- as mentioned in the linked article -- the answer? (e.g. have it try to return the contents of /well/known/location/myapp-log4j.xml) Thanks, Mark. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: Skittr example in bad shape
Hi,
I noticed logged in user still can't see messages by other users they
follow. There were couple of messages still missing parameters. Patch
shows the parts that need to be modified to get it working again.
- Vesa
diff --git a/lift-examples/skittr/src/main/scala/com/skittr/actor/
UserActor.scala b/lift-examples/skittr/src/main/scala/com/skittr/actor/
UserActor.scala
index cb51f45..a057192 100644
--- a/lift-examples/skittr/src/main/scala/com/skittr/actor/
UserActor.scala
+++ b/lift-examples/skittr/src/main/scala/com/skittr/actor/
UserActor.scala
@@ -101,7 +101,7 @@ class UserActor extends LiftActor {
// tell all our friends that we follow them
case ConfigFollowers =
- friends.flatMap(f = UserList.find(f).toList).foreach(_ !
AddFollower)
+ friends.flatMap(f = UserList.find(f).toList).foreach(_ !
AddFollower(this))
// if the autogen property is set, then have each of the
actors
// randomly generate a message
if (User.shouldAutogen_? || System.getProperty(autogen) !=
null) autoGen
@@ -110,11 +110,12 @@ class UserActor extends LiftActor {
// if we add a friend,
case AddFriend(name) =
+
friends = (name :: friends).sort(_ _)
// find the user
UserList.find(name).foreach{
ua =
-ua ! AddFollower // tell him we're a follower
+ua ! AddFollower(this) // tell him we're a follower
(ua !? GetUserIdAndName) match { // get the user info
case UserIdInfo(id, _,_, _) = Friend.create.owner
(userId).friend(id).save // and persist a friend connection in the DB
case _ =
@@ -127,7 +128,7 @@ class UserActor extends LiftActor {
// find the user
UserList.find(name).foreach{
ua =
-ua ! RemoveFollower // tell them we're no longer following
+ua ! RemoveFollower(this) // tell them we're no longer
following
(ua !? GetUserIdAndName) match { // delete from database
case UserIdInfo(id, _,_,_) = Friend.findAll(By
(Friend.owner, userId), By(Friend.friend, id)).foreach(_.delete_!)
case _ =
On 17 joulu, 16:35, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Thu, Dec 17, 2009 at 4:35 AM, Vesa brut...@gmail.com wrote:
Hi,
I was trying to run the skittr example from the lift-examples and it
doesn't seem to work. It's demonstrating usage of comet but it doesn't
get that far as the comet actor never receives any messages due to a
bug. Also the indentation is a mix of spaces and tabs of different
width and looks quite messed up. How should I deliver a fix when I'm
done?
There's a single simple bug. When we moved from Scala Actors to Lift
Actors, we moved from a case object AddTimelineViewer to case class
AddTimelineViewer(who: SimpleActor[Any]) Unfortunately, the compiler didn't
flag the actor ! AddTimelineViewer line as a bug... it converted the line to
actor ! (who = AddTimelineViewer.apply) and passed a function as a
message. I've fixed the code locally (WatchUser.scala lines 49-52 become):
override def localSetup {
userActor = name.flatMap(name = UserList.find(name))
userActor.foreach{ua = ua ! AddTimelineViewer(this) ; messages = (ua
!? GetTimeline) match {case Timeline(m) = m; case _ = Nil}}
}
I'll get a patch onto review board by end of day today.
- Vesa
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://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: Catch file upload exceptions?
I'm not sure that is what the OP is after - it would work, but that's not what he is asking IMHO I'll take a look tomorrow and see what could be done cheers, Tim On Dec 21, 9:52 pm, Marius marius.dan...@gmail.com wrote: Have you tried using in boot LiftRules.exceptionHandler.prepend (...) ? Br's, Marius On Dec 21, 11:43 pm, tiro tim.romb...@googlemail.com wrote: Hi, just wondering if anybody knows of a handy way to properly handle the exceptions that are thrown when a user uploads a file that exceeds the size limit (or who knows what else can happen)? The stack trace that I see in such a case is as follows -- and apart from trying S.addAround I don't see a any place where one could insert some exception handling: Message: org.apache.commons.fileupload.FileUploadBase $SizeLimitExceededException: the request was rejected because its size (7385713) exceeds the configured maximum(6291456) org.apache.commons.fileupload.FileUploadBase $FileItemIteratorImpl.init(FileUploadBase.java:914) org.apache.commons.fileupload.FileUploadBase.getItemIterator (FileUploadBase.java:331) org.apache.commons.fileupload.servlet.ServletFileUpload.getItemIterator (ServletFileUpload.java:148) net.liftweb.http.provider.servlet.HTTPRequestServlet$$anon$1.init (HTTPRequestServlet.scala:110) net.liftweb.http.provider.servlet.HTTPRequestServlet.extractFiles (HTTPRequestServlet.scala:100) net.liftweb.http.Req$$anonfun$5.apply(Req.scala:182) net.liftweb.http.Req$$anonfun$5.apply(Req.scala:156) net.liftweb.http.Req.x$17(Req.scala:351) net.liftweb.http.Req.uploadedFiles(Req.scala:350) net.liftweb.http.LiftSession.runParams(LiftSession.scala:306) net.liftweb.http.LiftSession.processRequest(LiftSession.scala:492) net.liftweb.http.LiftServlet.net$liftweb$http$LiftServlet$ $dispatchStatefulRequest(LiftServlet.scala:261) net.liftweb.http.LiftServlet$$anonfun$3.apply(LiftServlet.scala:171) net.liftweb.http.LiftServlet$$anonfun$3.apply(LiftServlet.scala:171) net.liftweb.http.S$.net$liftweb$http$S$$wrapQuery(S.scala:974) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit$1$ $anonfun$apply$25.apply(S.scala:1114) net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:911) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit $1.apply(S.scala:1112) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$.net$liftweb$http$S$$_nest2InnerInit(S.scala:) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun $apply$28$$anonfun$apply$29$$anonfun$apply$30$$anonfun$apply$31.apply (S.scala:1133) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun $apply$28$$anonfun$apply$29$$anonfun$apply$30.apply(S.scala:1132) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun $apply$28$$anonfun$apply$29.apply(S.scala:1131) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun $apply$28.apply(S.scala:1130) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1.apply (S.scala:1129) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$.net$liftweb$http$S$$_innerInit(S.scala:1128) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38$$anonfun$apply $39$$anonfun$apply$40$$anonfun$apply$41$$anonfun$apply$42.apply (S.scala:1175) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38$$anonfun$apply $39$$anonfun$apply$40$$anonfun$apply$41.apply(S.scala:1174) net.liftweb.http.CoreRequestVarHandler$class.apply(Vars.scala:325) net.liftweb.http.RequestVarHandler$.apply(Vars.scala:248) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38$$anonfun$apply $39$$anonfun$apply$40.apply(S.scala:1173) net.liftweb.http.CoreRequestVarHandler$class.apply(Vars.scala:325) net.liftweb.http.TransientRequestVarHandler$.apply(Vars.scala:252) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38$$anonfun$apply $39.apply(S.scala:1172) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38.apply(S.scala: 1171) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$_init$1.apply(S.scala:1170) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67)
[Lift] Re: PayPal X
Cool - I'll have a play overthe hols. It's a SOAP api so I'd need to depend on CXF or JAXWS... Do you forsee any license conflicts before I start work? Cheers, Tim On Dec 21, 6:58 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Sun, Dec 20, 2009 at 2:42 PM, Timothy Perrett timo...@getintheloop.euwrote: Guys, Is their any appetite for adding support for the new Paypal X services? https://www.x.com/index.jspa Basically it allows you to seamlessly integrate the billing cycle without transferring to paypal I personally dont have a burning need, but im thinking it would be a cool extension to the paypal module. I'd love to see you write this Tim. ;-) Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://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.
Re: [Lift] Re: PayPal X
On Mon, Dec 21, 2009 at 4:28 PM, Timothy Perrett timo...@getintheloop.euwrote: Cool - I'll have a play overthe hols. It's a SOAP api so I'd need to depend on CXF or JAXWS... Do you forsee any license conflicts before I start work? As long as those libraries are Apache 2 or MIT/BSD licenses, all is good. Cheers, Tim On Dec 21, 6:58 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Sun, Dec 20, 2009 at 2:42 PM, Timothy Perrett timo...@getintheloop.euwrote: Guys, Is their any appetite for adding support for the new Paypal X services? https://www.x.com/index.jspa Basically it allows you to seamlessly integrate the billing cycle without transferring to paypal I personally dont have a burning need, but im thinking it would be a cool extension to the paypal module. I'd love to see you write this Tim. ;-) Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- 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.
Re: [Lift] Sitemap - rendering title attributes for the links
You could add MetaData 'title' by Elem 's method '%'
a href=linksome page/a % (title - what will happen when you click
on this
link)
or use { }
a href=link title={myLinkTitle}some page/a
On Mon, Dec 21, 2009 at 10:38 PM, Alex Black a...@alexblack.ca wrote:
Can someone point me in the right direction to get tooltips (title
attributes) rendered in my sitemap?
I'd like to add text to each link, so they get rendered like this:
lia href=link title=what will happen when you click on this
linksome page/a/li
thx
- Alex
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
Scala中文社区: http://groups.google.com/group/scalacn
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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: PayPal X
Looks like JAX-WS reference implementation is dual licensed CDDL or GPLv2. -Ross On Dec 21, 2009, at 7:32 PM, David Pollak wrote: On Mon, Dec 21, 2009 at 4:28 PM, Timothy Perrett timo...@getintheloop.eu wrote: Cool - I'll have a play overthe hols. It's a SOAP api so I'd need to depend on CXF or JAXWS... Do you forsee any license conflicts before I start work? As long as those libraries are Apache 2 or MIT/BSD licenses, all is good. Cheers, Tim On Dec 21, 6:58 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Sun, Dec 20, 2009 at 2:42 PM, Timothy Perrett timo...@getintheloop.euwrote: Guys, Is their any appetite for adding support for the new Paypal X services? https://www.x.com/index.jspa Basically it allows you to seamlessly integrate the billing cycle without transferring to paypal I personally dont have a burning need, but im thinking it would be a cool extension to the paypal module. I'd love to see you write this Tim. ;-) Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://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, 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] 280_port and yuicompressor problem
I just recently started tinkering around with 2.8.. actually a recent
upgrade of Netbeans kind of necessitated it.. (the only Scala plugin
for Netbeans 6.8 requires Scala 2.8.xxx, ughh).
So most of my code is close anyway, except for anything that depends
on specs. But I had to get the 280_port of lift to compile locally
for my web services. When I try it fails very near the end with:
...
[INFO] [yuicompressor:compress {execution: default}]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.RuntimeException
at
com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceNumber
(JavaScriptCompressor.java:299)
at com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse
(JavaScriptCompressor.java:335)
at com.yahoo.platform.yui.compressor.JavaScriptCompressor.init
(JavaScriptCompressor.java:532)
at net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo.processFile
(YuiCompressorMojo.java:178)
...
I'm using maven 2.2.1 and Java 1.6.0.0 on Ubuntu.
Any ideas?
Alan
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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: Catch file upload exceptions?
It's good way to handle exception. And I think it's better that it could pop dialog to tell users what's wrong. http://www.mail-archive.com/liftweb@googlegroups.com/msg03001.html http://wiki.liftweb.net/index.php/HowTo_use_error_pages On Tue, Dec 22, 2009 at 5:52 AM, Marius marius.dan...@gmail.com wrote: Have you tried using in boot LiftRules.exceptionHandler.prepend (...) ? Br's, Marius On Dec 21, 11:43 pm, tiro tim.romb...@googlemail.com wrote: Hi, just wondering if anybody knows of a handy way to properly handle the exceptions that are thrown when a user uploads a file that exceeds the size limit (or who knows what else can happen)? The stack trace that I see in such a case is as follows -- and apart from trying S.addAround I don't see a any place where one could insert some exception handling: Message: org.apache.commons.fileupload.FileUploadBase $SizeLimitExceededException: the request was rejected because its size (7385713) exceeds the configured maximum (6291456) org.apache.commons.fileupload.FileUploadBase $FileItemIteratorImpl.init(FileUploadBase.java:914) org.apache.commons.fileupload.FileUploadBase.getItemIterator (FileUploadBase.java:331) org.apache.commons.fileupload.servlet.ServletFileUpload.getItemIterator (ServletFileUpload.java:148) net.liftweb.http.provider.servlet.HTTPRequestServlet$$anon$1.init (HTTPRequestServlet.scala:110) net.liftweb.http.provider.servlet.HTTPRequestServlet.extractFiles (HTTPRequestServlet.scala:100) net.liftweb.http.Req$$anonfun$5.apply(Req.scala:182) net.liftweb.http.Req$$anonfun$5.apply(Req.scala:156) net.liftweb.http.Req.x$17(Req.scala:351) net.liftweb.http.Req.uploadedFiles(Req.scala:350) net.liftweb.http.LiftSession.runParams(LiftSession.scala:306) net.liftweb.http.LiftSession.processRequest(LiftSession.scala:492) net.liftweb.http.LiftServlet.net$liftweb$http$LiftServlet$ $dispatchStatefulRequest(LiftServlet.scala:261) net.liftweb.http.LiftServlet$$anonfun$3.apply(LiftServlet.scala:171) net.liftweb.http.LiftServlet$$anonfun$3.apply(LiftServlet.scala:171) net.liftweb.http.S$.net$liftweb$http$S$$wrapQuery(S.scala:974) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit$1$ $anonfun$apply$25.apply(S.scala:1114) net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:911) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit $1.apply(S.scala:1112) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$.net$liftweb$http$S$$_nest2InnerInit(S.scala:) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun $apply$28$$anonfun$apply$29$$anonfun$apply$30$$anonfun$apply$31.apply (S.scala:1133) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun $apply$28$$anonfun$apply$29$$anonfun$apply$30.apply(S.scala:1132) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun $apply$28$$anonfun$apply$29.apply(S.scala:1131) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun $apply$28.apply(S.scala:1130) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1.apply (S.scala:1129) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$.net$liftweb$http$S$$_innerInit(S.scala:1128) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38$$anonfun$apply $39$$anonfun$apply$40$$anonfun$apply$41$$anonfun$apply$42.apply (S.scala:1175) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38$$anonfun$apply $39$$anonfun$apply$40$$anonfun$apply$41.apply(S.scala:1174) net.liftweb.http.CoreRequestVarHandler$class.apply(Vars.scala:325) net.liftweb.http.RequestVarHandler$.apply(Vars.scala:248) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38$$anonfun$apply $39$$anonfun$apply$40.apply(S.scala:1173) net.liftweb.http.CoreRequestVarHandler$class.apply(Vars.scala:325) net.liftweb.http.TransientRequestVarHandler$.apply(Vars.scala:252) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38$$anonfun$apply $39.apply(S.scala:1172) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$38.apply(S.scala: 1171) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$$anonfun$_init$1.apply(S.scala:1170) net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:67) net.liftweb.http.S$._init(S.scala:1169)
[Lift] Re: Nexus/Hudson maitenance on scala-tools.org
The scala-tools.org maintenance/upgrade has been completed. Any further service interruptions should be reported to ad...@scala-tools.org Thanks! - Josh On Fri, Dec 18, 2009 at 3:38 PM, Josh Suereth joshua.suer...@gmail.comwrote: All, Nexus/Hudson will be temporarily disabled Saturday/Sunday from 8-11pm EST. These services are being upgraded. I'll post an email 15 minutes before the actual shutdown and immediately after things are back up and working. You should be able to make use of artifacts on the scala-tools.org server, however nightly builds and posting releases will be disabled. If anyone has a specific release/test they need performed during this period please send me an email and I can accomodate you. Thanks for your cooperation! - Josh Suereth -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] 280_port and yuicompressor problem
If you google [yuicompressor:compress {execution: default}] would find so
many information about this.
It's not caused by scala2.8 or lift.
On Tue, Dec 22, 2009 at 9:10 AM, Alan M alan.morten...@gmail.com wrote:
I just recently started tinkering around with 2.8.. actually a recent
upgrade of Netbeans kind of necessitated it.. (the only Scala plugin
for Netbeans 6.8 requires Scala 2.8.xxx, ughh).
So most of my code is close anyway, except for anything that depends
on specs. But I had to get the 280_port of lift to compile locally
for my web services. When I try it fails very near the end with:
...
[INFO] [yuicompressor:compress {execution: default}]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.RuntimeException
at
com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceNumber
(JavaScriptCompressor.java:299)
at com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse
(JavaScriptCompressor.java:335)
at com.yahoo.platform.yui.compressor.JavaScriptCompressor.init
(JavaScriptCompressor.java:532)
at net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo.processFile
(YuiCompressorMojo.java:178)
...
I'm using maven 2.2.1 and Java 1.6.0.0 on Ubuntu.
Any ideas?
Alan
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
Scala中文社区: http://groups.google.com/group/scalacn
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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: Sitemap - rendering title attributes for the links
Hi Xuefeng,
I'm using the default Lift Sitemap, so I don't think I can use either
of your suggestions, or, I don't see how to use them. The sitemap
renders the links for me... I have seen how to set the class of the
elements that it renders, but not how to add other attributes such as
title.
- Alex
You could add MetaData 'title' by Elem 's method '%'
a href=linksome page/a % (title - what will happen when you click
on this
link)
or use { }
a href=link title={myLinkTitle}some page/a
On Mon, Dec 21, 2009 at 10:38 PM, Alex Black a...@alexblack.ca wrote:
Can someone point me in the right direction to get tooltips (title
attributes) rendered in my sitemap?
I'd like to add text to each link, so they get rendered like this:
lia href=link title=what will happen when you click on this
linksome page/a/li
thx
- Alex
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
Scala中文社区: http://groups.google.com/group/scalacn
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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 to JavaScript DSL ...
Inlined
2009/12/19 Marius marius.dan...@gmail.com
If I may a few notes:
Syntactically it doesn't seem to me that there are much differences
between this and the initial proposal. Probably the most noticeable
diffs are in algebraic expressions like
Var(y) := (2:Expr) * x * 2
which probably looks more appealing than
Var(y) := 2 __* x __* 2
First, I should confess that I didn't look at your source code before I
wrote my approach, although I saw it now. That said, I agree that there is
plenty in common between the two approaches, and also a couple of
differences. Feel free to use whatever blend you like!
The other thing is that you don't end JS statements with ; ... I
don't think this is a good JS practice. I added `;` function to allow
user to specify this terminator when needed.
It would be trivial to have my implementation add semicolons in the
generated code without requiring any change in the DSL's usage.
I'm also not at all in favor of function names starting with capital
letter.
Please rename them to whatever you like!
I was also running into a Scala compiler crash when using constructs
like: case class Fnc(name: String)(params: String*)(body : = String)
{} :D
Then possibly functions are better suited than case classes for providing
the names of the DSL syntax. If that means you prefer lowercase names please
change them!
I'm not sure why in things like: def Function()(argNames: String*)
(body: PartialFunction[List[JSIdent], Unit]): JSAnonFunc you used
PartialFunctions ... you are callin gthe PF without checking if the
function is defined for its parameter which could lead to MachError.
What would it help to intercept such a situation--to provide a more
descriptive error message? It's an error either way.
In any case, I realized after I wrote it (as I mentioned) that the signature
could be changed to
def Function(numParams: Int)(body: PartialFunction[List[JSIdent], Unit])
that is, there is no reason to specify names for the parameters. Since the
PF format binds scala identifiers to represent the arguments, names could be
autogenerated. Similarly,
val x = Var(x)
could be changed to
val x = Var()
and x would represent a JS var whose name is autogenerated.
I could be totally wrong but it seems to me that the ability to have Scala
identifiers and not just implicitly converted symbols provides more
scalability. For instance you could have utility functions in Scala that
help build the javascript but don't need the implicits in scope.
I see you took a different approach of building JS code in a more
imperative manner where generated code is kept in the ThreadGlobal
state. My initial approach and actually my design intent was to use
functional composition to write the code which tremendously simplifies
the library code.
Could you elaborate? What makes your code more functional?
With your approach,
JsIf('param1 30) {
Var ('home) := (234: Js) + 3 / 3 `;`
println(Hi there)
Var ('someArray) := JsArray(1, 2, 3, 4, 5) `;`
'myFunc(1, 2, do it, 'home) `;`
$(#myID) 'attr(value, 123) `;`
} ~
would not work, because JsIf's second parameter list takes a =Js, that is,
it only uses on the expression returned. In the above example, the
Var('home) ... line goes into a black hole.
In my case you have much more flexibility because the entire code block does
not have to be one long expression. All DSL invocations are captured.
This is also the reason my approach does not require using semicolons.
Also, it would be advantageous if the result of executing the DSL was the
regular Lift JavaScript AST. This would avoid code duplication in terms of
the algorithm that generates the output javascript text (which if it does
not already could have shared features like whitespace compression or pretty
printing), while at the same time allowing the generated AST to be processed
by code that can also work with plain Lift JavaScript AST objects. I'm not
clear how that would work with your approach, but with mine it's trivial.
I should mention that much of the inspiration for this builder approach came
from the SWT DSL, by Rodant.
I made some adjustments to my initial approach and something like:
val js = JsFunc('myFunc, 'param1, 'param2) {
JsIf('param1 30) {
Var ('home) := (234: Js) + 3 / 3 `;`
Var ('someArray) := JsArray(1, 2, 3, 4, 5) `;`
'myFunc(1, 2, do it, 'home) `;`
$(#myID) 'attr(value, 123) `;`
} ~
JsForEach(Var('i) in 'someArray) {
'console 'log(Hi there + 'i) `;`
} ~
JsAnonFunc('arg1, 'arg2) {
'alert(Anonymous function + 'arg1 + 'arg2)
}(1, 2) `;`
}
println(js.toJs)
generates
function myFunc( param1, param2 ) {
if (param1 30) {
var home = 234 + 3 / 3;
var someArray = [ 1, 2, 3, 4, 5 ];
myFunc(1, 2, do it, home);
$(#myID).attr(value, 123);
}
for (var i in someArray) {
console.log(Hi there 'i);
}
function (
Re: [Lift] Re: Sitemap - rendering title attributes for the links
Sorry I misunderstand you.
And I do not know how to too.
Maybe you should use
lispan title=about this sitelift:Menu.item name=about//span/li
instead of lift:Menu.builder /
On Tue, Dec 22, 2009 at 11:29 AM, Alex Black a...@alexblack.ca wrote:
Hi Xuefeng,
I'm using the default Lift Sitemap, so I don't think I can use either
of your suggestions, or, I don't see how to use them. The sitemap
renders the links for me... I have seen how to set the class of the
elements that it renders, but not how to add other attributes such as
title.
- Alex
You could add MetaData 'title' by Elem 's method '%'
a href=linksome page/a % (title - what will happen when you
click
on this
link)
or use { }
a href=link title={myLinkTitle}some page/a
On Mon, Dec 21, 2009 at 10:38 PM, Alex Black a...@alexblack.ca wrote:
Can someone point me in the right direction to get tooltips (title
attributes) rendered in my sitemap?
I'd like to add text to each link, so they get rendered like this:
lia href=link title=what will happen when you click on this
linksome page/a/li
thx
- Alex
--
You received this message because you are subscribed to the Google
Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
Scala中文社区: http://groups.google.com/group/scalacn
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
Scala中文社区: http://groups.google.com/group/scalacn
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from 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: Validation errors shown on CRUDify models?
Thanks guys.
On Dec 21, 11:59 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Mon, Dec 21, 2009 at 1:53 AM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote:
tommycli tommy...@ucla.edu writes:
Are validation errors shown on CRUDify create/edit pages?
I have validators set up like this:
object subdomain extends MappedString(this,64) {
override def validations = List(valUnique(Subdomain taken.)_,
valRegex(Pattern.compile(^[A-Za-z0-9-]*$),
Subdomains must only contain
letters, numbers, and
hyphens.
)_) ::: super.validations
override def displayName = Subdomain
override def dbIndexed_? = true
}
And on an invalid entry, the form will just silently fail - that is,
when submitted, it will just give back the exact same form state - no
error messages, no changes in the filled-out entries. This confuses me.
How should the messages be displayed? AFAIK, per field message display
is not supported atm.
Yeah... I need to fix that. http://github.com/dpp/liftweb/issues#issue/254
You can display all errors (incl field errors) by
including the
lift:Msgs showAll=true/
snippet. Note the showAll attribute which is now needed to show field
level errors.
/Jeppe
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://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] About the Chat demo of the Lift?
Hi all I have a silly question about the Chat demo. How could i create a Chat room in this demo ? Maybe i can define a variable or some other method to achieve the purpose ! Now all the people are in the same Chat room ( global ) in the example, so i want to create more than one Chat rooms that every one can contain 100 people. Thanks for any suggestion! Cheers, Neil -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] About the Chat demo of the Lift?
see this http://github.com/maweis1981/chatOnLift - mawei...@gmail.com 13585201588 http://maweis.com On Tue, Dec 22, 2009 at 2:31 PM, Neil.Lv anim...@gmail.com wrote: Hi all I have a silly question about the Chat demo. How could i create a Chat room in this demo ? Maybe i can define a variable or some other method to achieve the purpose ! Now all the people are in the same Chat room ( global ) in the example, so i want to create more than one Chat rooms that every one can contain 100 people. Thanks for any suggestion! Cheers, Neil -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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] How could i send a HTTP get or post request in the Snippet or Views in the Lift?
Hi all, How could i send a HTTP get or post request in the Snippet or Views in the Lift? For example, the weather API . I want to send an HTTP get request or post request to another website that it supplies some APIs, then in the lift we can receive the return data such as XML data, so we can use these XML or Json data in the Snippet or the Views. Thanks for any help! Cheers, Neil -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: About the Chat demo of the Lift?
OK, and Where is the code about the Creating more Chat Rooms? Thanks very much! Cheers, Neil On Dec 22, 2:34 pm, Margaret mawei...@gmail.com wrote: see this http://github.com/maweis1981/chatOnLift - mawei...@gmail.com 13585201588http://maweis.com On Tue, Dec 22, 2009 at 2:31 PM, Neil.Lv anim...@gmail.com wrote: Hi all I have a silly question about the Chat demo. How could i create a Chat room in this demo ? Maybe i can define a variable or some other method to achieve the purpose ! Now all the people are in the same Chat room ( global ) in the example, so i want to create more than one Chat rooms that every one can contain 100 people. Thanks for any suggestion! Cheers, Neil -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, 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: About the Chat demo of the Lift?
maybe need create more comet actor or add room entity to filter request and response. - mawei...@gmail.com 13585201588 http://maweis.com On Tue, Dec 22, 2009 at 3:05 PM, Neil.Lv anim...@gmail.com wrote: OK, and Where is the code about the Creating more Chat Rooms? Thanks very much! Cheers, Neil On Dec 22, 2:34 pm, Margaret mawei...@gmail.com wrote: see this http://github.com/maweis1981/chatOnLift - mawei...@gmail.com 13585201588http://maweis.com On Tue, Dec 22, 2009 at 2:31 PM, Neil.Lv anim...@gmail.com wrote: Hi all I have a silly question about the Chat demo. How could i create a Chat room in this demo ? Maybe i can define a variable or some other method to achieve the purpose ! Now all the people are in the same Chat room ( global ) in the example, so i want to create more than one Chat rooms that every one can contain 100 people. Thanks for any suggestion! Cheers, Neil -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from 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: How could i send a HTTP get or post request in the Snippet or Views in the Lift?
Well from your Snippet method you can just use HttpURLConnection, or Apache Commons Client to make remote requests to other services. Of course typically you won't do this directly from the snippet method but from a Service layer of your application. One you get the response (say it's an XML) you parse it using Scala XML class and the extract relevant information using pattern matching or by some other means. From here you just construct the NodeSeq that the Snippet/View needs to return. As a side note ... If those requests are taking a long time, you can wrap your snippet in lift:lazy-load ... and it will be loaded asynchronously. There is another attribute (lift:parallel=true)that you could specify to a snippet that it will be run asynchronously allowing other snippets to process and the result will be merged into the HTTP response right before sending the response to the client. Note that you need to set LiftRules.allowParallelSnippets Br's, Marius On Dec 22, 8:39 am, Neil.Lv anim...@gmail.com wrote: Hi all, How could i send a HTTP get or post request in the Snippet or Views in the Lift? For example, the weather API . I want to send an HTTP get request or post request to another website that it supplies some APIs, then in the lift we can receive the return data such as XML data, so we can use these XML or Json data in the Snippet or the Views. Thanks for any help! Cheers, Neil -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
