[Lift] Re: Widgets
Yeah, I found that (had to download the latest... I'm a bit behind). It gives the gist. Had fun with the TableSorter... The book is looking very good! I think I'm going to try to read it from cover to cover. If I do, I'll send you errata as I go. Chas. Derek Chen-Becker wrote: We have a bit in the book, chapter 12. Derek On Wed, Apr 1, 2009 at 2:22 PM, Charles F. Munat c...@munat.com mailto:c...@munat.com wrote: I haven't had a chance to play around with the Lift widgets yet. Is there any documentation anywhere about them? Chas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Need for lightweight JPA archetype
Hmmm. This brings up something I've been meaning to ask about. I have a public JPA app which has a log-in only maintenance area. I'm thinking about moving the maintenance part to a subdomain and serving it via SSL. I think it would be easier to pull out a separate sub-project, so I might have the persistance sub-project, the public sub-project, and the admin-subproject. Is this a good idea? And is it just as easy as copying the current webapp subproject, renaming it, and then deleting the parts that don't belong in each of the public and admin sub-projects? But then how would I package it? How would I deploy it? Has anyone done anything like this? Chas. Timothy Perrett wrote: I 100% see why you want a seperate module for persistance, but workflow wise I've found JPA a lot more productive if it's in the lift app as it means you don't have to keep deploying the JAR into your local repo. Perhaps lift-jpa-archetype-blank-split lift-jpa-archetype-blank-consolidated Thoughts? Tim On Apr 2, 7:33 am, Derek Chen-Becker dchenbec...@gmail.com wrote: I thought I had sent out an email on the list earlier asking what people would want to see in such an archetype. As a base, probably a master POM with a module for the persistence unit and a module for the Lift side of things. The persistence unit could have a skeleton persistence.xml in the right place but otherwise be empty. The Lift side could have the basic Boot and perhaps a Model class set up with a placeholder persistence setup. Thoughts? Derek On Wed, Apr 1, 2009 at 3:16 PM, Timothy Perrett timo...@getintheloop.euwrote: Glad im not the only one ;-) On Apr 1, 11:15 pm, Viktor Klang viktor.kl...@gmail.com wrote: Timmy, yeah, I can see that coming in handy. Cheers, Viktor On Wed, Apr 1, 2009 at 11:13 PM, Tim Perrett timo...@getintheloop.eu wrote: Guys, Do people see room for a blank JPA archetype just like we have blank and basic of normal lift archetypes? IMO, whilst its great having the basic one for learning and examples, having something thats a workable starting point without having to remove code etc would be helpful. I appreciate this is a bit lazy - but i don't think it would take much work and would provide a neat solution Thoughts? Tim -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Wiki example with specs and Mockito
Hi,
The Wiki example specification, which was previously specified using
JMock broke when we migrated to Scala 2.7.2 (compiler issue, couldn't
solve it).
However, the latest version of specs (1.4.4-SNAPSHOT) provides an
integration with Mockito which is even nicer when just doing stubbing.
So the Wiki Specification is now back on track and you can pull it
from git.
I want to note also one thing. The way the original example was
written wasn't very stub-friendly, so I had to change:
object WikiEntry extends WikiEntry with LongKeyedMetaMapper[WikiEntry]
to
object WikiEntry extends MetaWikiEntry // introduced the MetaWikiEntry
trait
trait MetaWikiEntry extends WikiEntry with LongKeyedMetaMapper
[WikiEntry]
and
class Wiki {
import WikiEntry._
to
// using the MetaWikiEntry trait to stub the database accesses
class Wiki extends MetaWikiEntry {
My hope is that Powermock (http://code.google.com/p/powermock) is
going to catchup with the latest version of Mockito and that we'll be
able to mock/stub any static method. In the meantime, I would advise
to avoid static imports, like import WikiEntry._ to facilitate
specifications/testing.
Cheers,
Eric.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Need for lightweight JPA archetype
I don't know if this is typical, but I typically deploy my apps in an EAR, in which case you just add another EAR Build module that packages up the Persistence module as an EJB module (v3) and then adds the WAR(s). It requires that you make some slight changes to the POM for the Persistence module (change packaging to ejb), but otherwise it's a simple change. Otherwise, you can just deploy the JPA module jar and webapp modules separately. To answer your question, I think that you should be able to just duplicate the existing project, although I think that you should be able to handle enforcing login and SSL via SiteMap for just the portions you want to protect. Derek On Thu, Apr 2, 2009 at 12:41 AM, Charles F. Munat c...@munat.com wrote: Hmmm. This brings up something I've been meaning to ask about. I have a public JPA app which has a log-in only maintenance area. I'm thinking about moving the maintenance part to a subdomain and serving it via SSL. I think it would be easier to pull out a separate sub-project, so I might have the persistance sub-project, the public sub-project, and the admin-subproject. Is this a good idea? And is it just as easy as copying the current webapp subproject, renaming it, and then deleting the parts that don't belong in each of the public and admin sub-projects? But then how would I package it? How would I deploy it? Has anyone done anything like this? Chas. Timothy Perrett wrote: I 100% see why you want a seperate module for persistance, but workflow wise I've found JPA a lot more productive if it's in the lift app as it means you don't have to keep deploying the JAR into your local repo. Perhaps lift-jpa-archetype-blank-split lift-jpa-archetype-blank-consolidated Thoughts? Tim On Apr 2, 7:33 am, Derek Chen-Becker dchenbec...@gmail.com wrote: I thought I had sent out an email on the list earlier asking what people would want to see in such an archetype. As a base, probably a master POM with a module for the persistence unit and a module for the Lift side of things. The persistence unit could have a skeleton persistence.xml in the right place but otherwise be empty. The Lift side could have the basic Boot and perhaps a Model class set up with a placeholder persistence setup. Thoughts? Derek On Wed, Apr 1, 2009 at 3:16 PM, Timothy Perrett timo...@getintheloop.eu wrote: Glad im not the only one ;-) On Apr 1, 11:15 pm, Viktor Klang viktor.kl...@gmail.com wrote: Timmy, yeah, I can see that coming in handy. Cheers, Viktor On Wed, Apr 1, 2009 at 11:13 PM, Tim Perrett timo...@getintheloop.eu wrote: Guys, Do people see room for a blank JPA archetype just like we have blank and basic of normal lift archetypes? IMO, whilst its great having the basic one for learning and examples, having something thats a workable starting point without having to remove code etc would be helpful. I appreciate this is a bit lazy - but i don't think it would take much work and would provide a neat solution Thoughts? Tim -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Need for lightweight JPA archetype
Works for me :) On Wed, Apr 1, 2009 at 11:51 PM, Timothy Perrett timo...@getintheloop.euwrote: I 100% see why you want a seperate module for persistance, but workflow wise I've found JPA a lot more productive if it's in the lift app as it means you don't have to keep deploying the JAR into your local repo. Perhaps lift-jpa-archetype-blank-split lift-jpa-archetype-blank-consolidated Thoughts? Tim On Apr 2, 7:33 am, Derek Chen-Becker dchenbec...@gmail.com wrote: I thought I had sent out an email on the list earlier asking what people would want to see in such an archetype. As a base, probably a master POM with a module for the persistence unit and a module for the Lift side of things. The persistence unit could have a skeleton persistence.xml in the right place but otherwise be empty. The Lift side could have the basic Boot and perhaps a Model class set up with a placeholder persistence setup. Thoughts? Derek On Wed, Apr 1, 2009 at 3:16 PM, Timothy Perrett timo...@getintheloop.eu wrote: Glad im not the only one ;-) On Apr 1, 11:15 pm, Viktor Klang viktor.kl...@gmail.com wrote: Timmy, yeah, I can see that coming in handy. Cheers, Viktor On Wed, Apr 1, 2009 at 11:13 PM, Tim Perrett timo...@getintheloop.eu wrote: Guys, Do people see room for a blank JPA archetype just like we have blank and basic of normal lift archetypes? IMO, whilst its great having the basic one for learning and examples, having something thats a workable starting point without having to remove code etc would be helpful. I appreciate this is a bit lazy - but i don't think it would take much work and would provide a neat solution Thoughts? Tim -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Widget CSS
Can you scope your stylesheet props? ... such as adding prefixes to classes etc. ... or use styles per ID-s. Looks to me that even if we change the order the application specific styles could potentially conflict with TableSorter's. The TableSorter's CSS are coming from JQuery plugin and not really proprietary so we probably should not change that. Do you have an example of the conflict? Br's, Marius On Apr 2, 7:47 am, Charles F. Munat c...@munat.com wrote: I've been playing with the very cool TableSorter widget. Nice work. One hassle though -- it inserts its stylesheet *after* my stylesheet, so it overrides my styles. I could change things locally, but that's a hassle. Might be able to add important qualifiers or some trick like that, but it would be easiest if I could just turn that stylesheet off and use my own. Any luck on that, or do I have to reinvent the TableSorter? Chas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: The Lift 1.1 list
Hi David, On Thu, Apr 2, 2009 at 12:11 AM, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Improved testing framework and better testing support when running in test mode. Can you elaborate on what your plans are for this? Thanks. Bill --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: The Lift 1.1 list
On Thu, Apr 2, 2009 at 2:30 AM, Bill Venners b...@artima.com wrote: Hi David, On Thu, Apr 2, 2009 at 12:11 AM, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Improved testing framework and better testing support when running in test mode. Can you elaborate on what your plans are for this? It's a goal, not a set of plans. I'm expecting one of the committers would take ownership and figure it out. Wanna be a committer, take ownership, and figure it out? Thanks. Bill -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: The Lift 1.1 list
My resources are pretty limited, but I'd love to at least contribute what I can to the OSGi support. I'd love to see a plugin system for lift apps that's sensible! Speaking of which, perhaps a plugin system that's sensible should be part of the list? I know grails does some neat stuff there with creating plugins (but their packaging/distribution model was less than desirable IMHO). Granted, a plugin in grails usually means nice library in scala, but being able to define extension points and plug in features would be handy (in certain circumstances. Hudson is my example of a good use of these features). -Josh On Wed, Apr 1, 2009 at 12:11 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, I think we've got our Lift 1.1 list. If anyone has anything to add, please speak up now. - Improved documentation: better VScalaDoc coverage as well as better tutorial and cook-book documentation. - Improved J2EE support including JTA and Portlets. - Finish Record/Field code with backing store including JDBC, JPA and Goat Rodeo (what's Goat Rodeo? http://goatrodeo.org) - Improved client-side JavaScript support and better JavaScript abstractions. - Client/Server data synchronization (integrated with Record/Field) - Improved support for REST. - Improved performance including caching templates when running in production mode. - OSGi support. - Improved testing framework and better testing support when running in test mode. - Implement Servlet 3.0 support. - HTML 5 and Web Sockets support and integration with Kaazing's Web Sockets server. Also, sensing which browser is making the request and performing optimizations based on that browser's characteristics (specifically, Chrome and Firefox 3.1 support) We will have bug-fix releases of 1.0 along the way and we'll have a release off the 1.0 branch when Scala 2.8 is released. Feedback is welcome in the next 3 days. Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Widget CSS
Well, maybe I'm missing something, but when I turn on the TableSorter, the header cells of my table change color to the colors specified in the TableSorter CSS. That's because the colors I set in my default CSS file came earlier in the cascade. It's not a big deal for me, but I thought I'd mention it. I don't have time to play with it today, but maybe tomorrow I can try using styles per id. That will probably work. I'll let you know. Chas. marius d. wrote: Can you scope your stylesheet props? ... such as adding prefixes to classes etc. ... or use styles per ID-s. Looks to me that even if we change the order the application specific styles could potentially conflict with TableSorter's. The TableSorter's CSS are coming from JQuery plugin and not really proprietary so we probably should not change that. Do you have an example of the conflict? Br's, Marius On Apr 2, 7:47 am, Charles F. Munat c...@munat.com wrote: I've been playing with the very cool TableSorter widget. Nice work. One hassle though -- it inserts its stylesheet *after* my stylesheet, so it overrides my styles. I could change things locally, but that's a hassle. Might be able to add important qualifiers or some trick like that, but it would be easiest if I could just turn that stylesheet off and use my own. Any luck on that, or do I have to reinvent the TableSorter? Chas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Menu widget bugginess
Hmmm. Your google-fu is very powerful! The fix is so simpel! I think this will probably work in this instance, but I'm pretty sure it doesn't work in every case, e.g. form inputs... else why the bother of using iframes via bgiframe.js? But for the Widgets examples, it looks like plain old divs, so I'll check it out when I get a break. Thanks! Chas. Viktor Klang wrote: Hello Chas, Can it be related to this: http://webdemar.com/webdesign/superfish-jquery-menu-ie-z-index-bug/ Cheers, Viktor On Thu, Apr 2, 2009 at 3:40 AM, Charles F. Munat c...@munat.com mailto:c...@munat.com wrote: I'm running the Lift Menu widget on my Mac via mvn jetty:run, then looking at it in IE Tester running in Windows XP Pro in a VMWare virtual machine on a Fedora 9 box on the same network. (Whew.) In IE 8 it works fine. In IE 7 and IE 6, on the CalendarWeekView and CalendarDayView pages, the third submenu link slides under the week or day view of the calendar and becomes inaccessible (and invisible as well). This is a typical problem with these piece of shit browsers that every self-respecting human on this planet should have rejected long ago... whoops. Did I write that out loud? The fix involves bigiframe.js, which I see is included in the toserve directory and on the page, so I'm not really sure why this problem is occurring. Isn't that what bigiframe.js is supposed to solve? Chas. -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Need for lightweight JPA archetype
Where is the code for these archetypes and how tricky is it to create them? Chas. Timothy Perrett wrote: I guess if your deploying into an enterprise container, then EAR is fine, however if your deploying into Jetty then you don't have the possibility of deploying to EAR. I just think that having the possibility of creating either a merged project or a split project is important as JPA brings things to the table some great features that people should be able to use however they want. IMO, the archetypes are enablers - I know we could create this stuff manually, but we want to enable people to be productive quickly. Thoughts? Tim On Apr 2, 3:06 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: Works for me :) On Wed, Apr 1, 2009 at 11:51 PM, Timothy Perrett timo...@getintheloop.euwrote: I 100% see why you want a seperate module for persistance, but workflow wise I've found JPA a lot more productive if it's in the lift app as it means you don't have to keep deploying the JAR into your local repo. Perhaps lift-jpa-archetype-blank-split lift-jpa-archetype-blank-consolidated Thoughts? Tim On Apr 2, 7:33 am, Derek Chen-Becker dchenbec...@gmail.com wrote: I thought I had sent out an email on the list earlier asking what people would want to see in such an archetype. As a base, probably a master POM with a module for the persistence unit and a module for the Lift side of things. The persistence unit could have a skeleton persistence.xml in the right place but otherwise be empty. The Lift side could have the basic Boot and perhaps a Model class set up with a placeholder persistence setup. Thoughts? Derek On Wed, Apr 1, 2009 at 3:16 PM, Timothy Perrett timo...@getintheloop.eu wrote: Glad im not the only one ;-) On Apr 1, 11:15 pm, Viktor Klang viktor.kl...@gmail.com wrote: Timmy, yeah, I can see that coming in handy. Cheers, Viktor On Wed, Apr 1, 2009 at 11:13 PM, Tim Perrett timo...@getintheloop.eu wrote: Guys, Do people see room for a blank JPA archetype just like we have blank and basic of normal lift archetypes? IMO, whilst its great having the basic one for learning and examples, having something thats a workable starting point without having to remove code etc would be helpful. I appreciate this is a bit lazy - but i don't think it would take much work and would provide a neat solution Thoughts? Tim -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Need for lightweight JPA archetype
Hmm. I forgot about EARs. Thanks for this information. I'll play around with it over the weekend. Chas. Derek Chen-Becker wrote: I don't know if this is typical, but I typically deploy my apps in an EAR, in which case you just add another EAR Build module that packages up the Persistence module as an EJB module (v3) and then adds the WAR(s). It requires that you make some slight changes to the POM for the Persistence module (change packaging to ejb), but otherwise it's a simple change. Otherwise, you can just deploy the JPA module jar and webapp modules separately. To answer your question, I think that you should be able to just duplicate the existing project, although I think that you should be able to handle enforcing login and SSL via SiteMap for just the portions you want to protect. Derek On Thu, Apr 2, 2009 at 12:41 AM, Charles F. Munat c...@munat.com mailto:c...@munat.com wrote: Hmmm. This brings up something I've been meaning to ask about. I have a public JPA app which has a log-in only maintenance area. I'm thinking about moving the maintenance part to a subdomain and serving it via SSL. I think it would be easier to pull out a separate sub-project, so I might have the persistance sub-project, the public sub-project, and the admin-subproject. Is this a good idea? And is it just as easy as copying the current webapp subproject, renaming it, and then deleting the parts that don't belong in each of the public and admin sub-projects? But then how would I package it? How would I deploy it? Has anyone done anything like this? Chas. Timothy Perrett wrote: I 100% see why you want a seperate module for persistance, but workflow wise I've found JPA a lot more productive if it's in the lift app as it means you don't have to keep deploying the JAR into your local repo. Perhaps lift-jpa-archetype-blank-split lift-jpa-archetype-blank-consolidated Thoughts? Tim On Apr 2, 7:33 am, Derek Chen-Becker dchenbec...@gmail.com mailto:dchenbec...@gmail.com wrote: I thought I had sent out an email on the list earlier asking what people would want to see in such an archetype. As a base, probably a master POM with a module for the persistence unit and a module for the Lift side of things. The persistence unit could have a skeleton persistence.xml in the right place but otherwise be empty. The Lift side could have the basic Boot and perhaps a Model class set up with a placeholder persistence setup. Thoughts? Derek On Wed, Apr 1, 2009 at 3:16 PM, Timothy Perrett timo...@getintheloop.euwrote: Glad im not the only one ;-) On Apr 1, 11:15 pm, Viktor Klang viktor.kl...@gmail.com mailto:viktor.kl...@gmail.com wrote: Timmy, yeah, I can see that coming in handy. Cheers, Viktor On Wed, Apr 1, 2009 at 11:13 PM, Tim Perrett timo...@getintheloop.eu wrote: Guys, Do people see room for a blank JPA archetype just like we have blank and basic of normal lift archetypes? IMO, whilst its great having the basic one for learning and examples, having something thats a workable starting point without having to remove code etc would be helpful. I appreciate this is a bit lazy - but i don't think it would take much work and would provide a neat solution Thoughts? Tim -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: The Lift 1.1 list
Just my two pence, but right now I understand these things are possible with ViewDispatchPF and SnippetDispatchPF etc etc and all the other tools we have in lift for creating modular view and logic code. However, the one thing I would say is that a lot of people appear to struggle with the particulars of how the hell one goes about creating a plugin / module / component – this must mean we are not doing something right... Even if it is just in communication of these things to the community as a whole. @dpp I know you mentioned you were going to make me a sample (re this thread: http://groups.google.com/group/liftweb/browse_thread/thread/932a730659975d0d ) I know its a big ask, but any chance you could bash something out that the community can consume and regurgitate some proper documentation / tutorial on? (perhaps I could scala-blog it or similar) Cheers, Tim On Apr 2, 4:34 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Thu, Apr 2, 2009 at 7:30 AM, Josh Suereth joshua.suer...@gmail.comwrote: My resources are pretty limited, but I'd love to at least contribute what I can to the OSGi support. I'd love to see a plugin system for lift apps that's sensible! Cool. I'm hoping that Heiko will lead the efforts, but extra hands always help. :-) Speaking of which, perhaps a plugin system that's sensible should be part of the list? I know grails does some neat stuff there with creating plugins (but their packaging/distribution model was less than desirable IMHO). Granted, a plugin in grails usually means nice library in scala, but being able to define extension points and plug in features would be handy (in certain circumstances. Hudson is my example of a good use of these features). I don't understand what a plugin is in the context of Lift. There's not much you can't do simply by defining a DispatchPF or a page with SiteMap. -Josh On Wed, Apr 1, 2009 at 12:11 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, I think we've got our Lift 1.1 list. If anyone has anything to add, please speak up now. - Improved documentation: better VScalaDoc coverage as well as better tutorial and cook-book documentation. - Improved J2EE support including JTA and Portlets. - Finish Record/Field code with backing store including JDBC, JPA and Goat Rodeo (what's Goat Rodeo?http://goatrodeo.org) - Improved client-side JavaScript support and better JavaScript abstractions. - Client/Server data synchronization (integrated with Record/Field) - Improved support for REST. - Improved performance including caching templates when running in production mode. - OSGi support. - Improved testing framework and better testing support when running in test mode. - Implement Servlet 3.0 support. - HTML 5 and Web Sockets support and integration with Kaazing's Web Sockets server. Also, sensing which browser is making the request and performing optimizations based on that browser's characteristics (specifically, Chrome and Firefox 3.1 support) We will have bug-fix releases of 1.0 along the way and we'll have a release off the 1.0 branch when Scala 2.8 is released. Feedback is welcome in the next 3 days. Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Need for lightweight JPA archetype
Are you eyeing up for your first commit Chas? ;-) The src of the JPA archetype is here: http://github.com/dpp/liftweb/tree/4a5d4530b407782a2f0e0e99b277432dbb41b640/lift-archetype-jpa-basic Cheers, Tim On Apr 2, 6:02 pm, Charles F. Munat c...@munat.com wrote: Where is the code for these archetypes and how tricky is it to create them? Chas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Forms validation formatter
One follow up question, relating to the contexts I mentioned earlier:
Following my approach mentioned below, let's assume I have a template
for embedding. This template contains the HTML code for a tabular
list of data entities. Depending on where the template is embedded,
some of the entities' fields should appear as links: There are 2
linkable reference fields A and B, and depending on the context,
either A, B, or A and B should be rendered as links to the referenced
entity.
This logic obviously can't go into the template. Also, the model's
toForm method is unsuitable (having the model referring to a
RequestVar seems evil to me). No no, this should go into the snippet,
where such logic belongs. But this would mean having to go through the
templates XML tree before calling Site.toForm(site, form), enclosing
all affected liftf:field elements with the respective links. This
sounds very, very wrong.
Thus, from my current understanding, this context-sensitive rendering
of fields is best done using the explicit lift-tag/bind approach. So
I'll probably have to have explicit bind calls anyways, and won't be
able to use my initial approach of having the mapper class (or it's
companion object) fill out the forms itself.
I'd be happy if someone could prove me wrong ...
Best,
Clemens
PS: Exercise for the reader: Instead of selective linking, have only
either A or B be displayed, depending on the embedding context.
On 31-Mar-09, at 3:59 PM, marius d. wrote:
Outer Template
lift:surround with=default at=content
h2Create a New Site/h2
lift:snippet type=SiteOps.add form=post eager_eval=true
table
tfoot
tr
td colspan=3site:submitSubmit/site:submit/td
/tr
/tfoot
lift:embed what=/sites/_site /
/table
/lift:snippet
/lift:surround
End Outer Template
Embedded Template
tbody
tr
tdliftf:field_label name=nameName/liftf:field_label:/
td
tdliftf:field name=nameA Hospital Site/liftf:field/td
tdliftf:field_msg name=name //td
/tr
/tbody
End Embedded Template
SiteOps
def add(form: NodeSeq): NodeSeq = {
val invokedAs = S.invokedAs
val site = Site.create
def newSite(form: NodeSeq): NodeSeq = {
def saveMe(): Unit = {
site.validate match {
case Nil = site.save ; S.notice(Added + site.name);
S.redirectTo(/sites/)
case xs = S.error(xs) ; S.mapSnippet(invokedAs, newSite)
}
}
bind(site, Site.toForm(site, form), submit -
submit(Save, saveMe))
}
newSite(form)
}
End SiteOps
The Site.toForm function is pretty much the same as found in
MetaRecord. It will eventually call each fields' toForm function
(which are the original Lift 1.0 mapper versions, no changes there).
Am I really doing things outside the rendering pipeline (this is
not a
rhetorical question)?
Nope sorry ... I misunderstood your case. By bad entirely.
It all seems to work, incl. validation.
Also, the eagerly evaluated template, which will be passed to toForm,
contains only field tags, no other lift tags.
Again, imagine a few dozen different entities, each with a ton of
fields. I'm sure you'll understand that I'm hesitant to bind each
field manually (once for the list page, once for the display page,
once for the add page, and again once for the edit page, even though
the last 2 can surely be combined into one bind call in the code).
I obviously have to declare each field in the model, and refer to it
in the view. I really wouldn't mind not having to mention it anywhere
inbetween.
This is actually a nice thing to do. Sorry that I misunderstood your
intentions :)
Thank you for all your help,
Clemens
Clemens Oertel
clem...@oertel.ca
Clemens Oertel
clem...@oertel.ca
Clemens Oertel
clem...@oertel.ca
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: The Lift 1.1 list
Tim, It's on my backlog. Right now I'm working on a preso for a class I'm teaching today at Cal Berkeley. Tomorrow is tax day and next week is a family vacation. I'll try to get something to you. Thanks, David On Apr 2, 2009 9:07 AM, Timothy Perrett timo...@getintheloop.eu wrote: Just my two pence, but right now I understand these things are possible with ViewDispatchPF and SnippetDispatchPF etc etc and all the other tools we have in lift for creating modular view and logic code. However, the one thing I would say is that a lot of people appear to struggle with the particulars of how the hell one goes about creating a plugin / module / component – this must mean we are not doing something right... Even if it is just in communication of these things to the community as a whole. @dpp I know you mentioned you were going to make me a sample (re this thread: http://groups.google.com/group/liftweb/browse_thread/thread/932a730659975d0d ) I know its a big ask, but any chance you could bash something out that the community can consume and regurgitate some proper documentation / tutorial on? (perhaps I could scala-blog it or similar) Cheers, Tim On Apr 2, 4:34 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Thu, Apr 2, 2009 at 7:30 AM, Josh Suereth joshua.suer...@gmail.com wrote: My resources are pretty limited, but I'd love to at least contribute what I can to the OSG... feeder.of.the.be...@gmail.com wrote:Folks,I think we've got our Lift 1.1 list. ... Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp--~--~-~--~~... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: The Lift 1.1 list
Hi David, On Thu, Apr 2, 2009 at 9:28 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Thu, Apr 2, 2009 at 2:30 AM, Bill Venners b...@artima.com wrote: Hi David, On Thu, Apr 2, 2009 at 12:11 AM, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Improved testing framework and better testing support when running in test mode. Can you elaborate on what your plans are for this? It's a goal, not a set of plans. I'm expecting one of the committers would take ownership and figure it out. Wanna be a committer, take ownership, and figure it out? Ooh, I stepped in that one. The testing Lift apps is a good, real use case for both ScalaTest and Specs. I hope to meet with Eric Torreborre Monday. I'll talk with him about what's needed for Lift, as I think he's more familiar with its testing needs. I have definitely wanted to do some work with Lift so I can become more familiar with it as a web app framework, but just haven't had time yet. I'm gradually popping things off my stack of tasks, so I'll get there eventually. Bill Thanks. Bill -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Need for lightweight JPA archetype
Yup. But there seem to be a few candidates... Timothy Perrett wrote: Are you eyeing up for your first commit Chas? ;-) The src of the JPA archetype is here: http://github.com/dpp/liftweb/tree/4a5d4530b407782a2f0e0e99b277432dbb41b640/lift-archetype-jpa-basic Cheers, Tim On Apr 2, 6:02 pm, Charles F. Munat c...@munat.com wrote: Where is the code for these archetypes and how tricky is it to create them? Chas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Need for lightweight JPA archetype
Probally between yourself and Derek in all honesty - I simply dont have the time right now and my lift time and what I do with it has other investments right now... Derek might well be swamped with the book at the moment... so perhaps there are not so many candidates as you think :-) Crack on is what I say - make a branch, knock yourself out and then post to the list before merging to master Cheers, Tim On Apr 2, 7:17 pm, Charles F. Munat c...@munat.com wrote: Yup. But there seem to be a few candidates... Timothy Perrett wrote: Are you eyeing up for your first commit Chas? ;-) The src of the JPA archetype is here: http://github.com/dpp/liftweb/tree/4a5d4530b407782a2f0e0e99b277432dbb... Cheers, Tim On Apr 2, 6:02 pm, Charles F. Munat c...@munat.com wrote: Where is the code for these archetypes and how tricky is it to create them? Chas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: The Lift 1.1 list
Ok no worries - personally, I dont have any burning need for it right this moment but I could certainly make serious use of it within the next month. Cheers, Tim On Apr 2, 7:10 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Tim, It's on my backlog. Right now I'm working on a preso for a class I'm teaching today at Cal Berkeley. Tomorrow is tax day and next week is a family vacation. I'll try to get something to you. Thanks, David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Proposed URL Shortening widget
Guys,
I've been contemplating doing this for a while and am now finding
myself with a bunch of free time tomorrow and a need to write some
code.
So, I want to make a widget that shortens URL's in an extendable
way... Im thinking of having something like:
trait URLReductionProvider { ... }
object TinyURL extends URLReductionProvider
object IsGd extends URLReductionProvider
object BitLy extends URLReductionProvider
You get the general idea...
So, im thinking of implementing the actual URL fetching stuff as a
partial function so that users could do:
def reductionResult = {
case Full(result) = // result is the URL, insert into database etc
case _ = // something went wrong
}
My question is however, if i make this actor based, could someone
implement it so rather than writing there URL to database in a
separate thread to the main one, would it be possible for them to say,
use a JsCmd and return that to update the browser? Im guessing not
unless it was a CometActor right.
This then got me thinking, do you guys thing this is worth doing actor
based, or is it just ok to make a blocking call to the provider?
(tinyurl or is.gd etc)
Cheers, Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Proposed URL Shortening widget
What about easily turning any lift app into a url shortener service?
Wouldn't be too hard...
Granted, some services (bit.ly) add statistics, visualization, conversation
tracking, etc. which aren't just url shortening.
--j
On Thu, Apr 2, 2009 at 12:13 PM, Tim Perrett timo...@getintheloop.euwrote:
Guys,
I've been contemplating doing this for a while and am now finding
myself with a bunch of free time tomorrow and a need to write some
code.
So, I want to make a widget that shortens URL's in an extendable
way... Im thinking of having something like:
trait URLReductionProvider { ... }
object TinyURL extends URLReductionProvider
object IsGd extends URLReductionProvider
object BitLy extends URLReductionProvider
You get the general idea...
So, im thinking of implementing the actual URL fetching stuff as a
partial function so that users could do:
def reductionResult = {
case Full(result) = // result is the URL, insert into database etc
case _ = // something went wrong
}
My question is however, if i make this actor based, could someone
implement it so rather than writing there URL to database in a
separate thread to the main one, would it be possible for them to say,
use a JsCmd and return that to update the browser? Im guessing not
unless it was a CometActor right.
This then got me thinking, do you guys thing this is worth doing actor
based, or is it just ok to make a blocking call to the provider?
(tinyurl or is.gd etc)
Cheers, Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: The Lift 1.1 list
+10 for documentation effort. Speaking from the noob perspective, the documentation is the biggest barrier to entry for Lift. Currently there are 3 places to get lift documentation: -Get Started Tutorial -Lift Book -Lift Wiki The first two sources are excellent, but the last one is bit lacking. I think it'd be a big win if we can clean up the wiki. Or, at the very least we should get rid of obsolete articles/code. Also, I feel it would be helpful if all the documentation was in one location, opposed to separated into various in PDFs and webpages. Just adding my two cents. Thanks, Xavi On Thu, Apr 2, 2009 at 1:23 AM, Derek Chen-Becker dchenbec...@gmail.com wrote: +10 on JodaTime. +1 on documentation effort, something I've got on my ever-growing TODO list... Derek On Wed, Apr 1, 2009 at 3:51 PM, Charles F. Munat c...@munat.com wrote: +1 Anything to get away from that damn Java Date/Calendar crap. Agreed on need to review API. Chas. Timothy Perrett wrote: I think your right Jorge... 2.8 brings some important changes that could quite possibly have some pretty significant breaking changes in the Lift API. I also agree with the JodaTime in record/field, sounds like perfect sense. Cheers, Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Menu widget
I posted this yesterday but I haven't seen it appear yet...sorry if it
is here twice.
I downloaded the scripts separately because I didn't know how to
update my repository/library to include the MenuWidget class and the
appropriate .js and .css files. I tried running mvn install on my
webapp, but it didn't download those new files.
I fixed the problem with my .css file so it compiles now, however I'm
still not getting the nice stylish superfish navbar. Instead, I'm
getting a vertical bulleted list of links to my different pages. I
think it's a problem with my template. Here are the relevant
sections:
html xmlns=http://www.w3.org/1999/xhtml; xmlns:lift=http://
liftweb.net/
head
meta http-equiv=content-type content=text/html;
charset=UTF-8 /
meta name=description content= /
meta name=keywords content= /
titleMy WebApp lift:Menu.title / /title
lift:StyleSheet.entryForm /
lift:StyleSheet.fancyType /
script id=jquery src=/classpath/jquery.js type=text/
javascript/
script id=json src=/classpath/json.js type=text/javascript/
/head
body
div class=container
div style=text-align: center
br/
h1 class=alt
Welcome to My WebApp /h1
/div
hr/
div
lift:MyMenu.render /
div
lift:Msgs/
hr class=space /
/div
/div
MyMenu is the snippet that contains the render method, which looks
like this:
def render(xhtml: NodeSeq): NodeSeq = {
MenuWidget(MenuStyle.NAVBAR)
}
Does anyone see what might be wrong here?
Thanks,
David
On Apr 1, 11:04 am, marius d. marius.dan...@gmail.com wrote:
Is there a reason why you downloaded he scripts separately? ... the
superfish dependencies are offered by the widget. Please see the lift-
widgets project and the test applicaiton from there.
Br's,
Marius
On Mar 31, 11:48 pm, DavidV david.v.villa...@gmail.com wrote:
I would like to use this newMenuWidget, so I got the source code from
GitHub and put it into my application as a snippet. I also downloaded
all of the necessary superfish .css and .js files from the superfish
website and put those in local sub-directories of the src/main/
webapp folder. When I try to compile the code in maven, however, I
get the following error.
C:\Source\trunk\eclipse\testLiftmvn clean jetty:run
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'jetty'.
[INFO]
[INFO] Building testLift
[INFO] task-segment: [clean, jetty:run]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory C:\Source\trunk\eclipse\testLift\target
[INFO] Preparing jetty:run
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [yuicompressor:compress {execution: default}]
[INFO] jquery.hoverIntent.js (4637b) - jquery.hoverIntent.js (0b)[0%]
[INFO] superfish.js (3837b) - superfish.js (0b)[0%]
[INFO] entryform.css (11417b) - entryform.css (10202b)[89%]
[INFO] print.css (1341b) - print.css (821b)[61%]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Illegal group reference
[INFO]
[INFO] Trace
java.lang.IllegalArgumentException: Illegal group reference
at java.util.regex.Matcher.appendReplacement(Matcher.java:713)
at com.yahoo.platform.yui.compressor.CssCompressor.compress
(CssCompresso
r.java:78)
at
net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo.processFile(YuiCom
pressorMojo.java:182)
at net.sf.alchim.mojo.yuicompressor.MojoSupport.processDir
(MojoSupport.j
ava:151)
at net.sf.alchim.mojo.yuicompressor.MojoSupport.execute
(MojoSupport.java
:105)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPlugi
nManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecy
cle(DefaultLifecycleExecutor.java:924)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(Def
aultLifecycleExecutor.java:767)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:529)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone
Goal(DefaultLifecycleExecutor.java:512)
at
[Lift] Re: Proposed URL Shortening widget
Hey Jorge,
Im not sure I 100% follow what your saying - are you proposing
creating a widget that actually has a shortening algorithm? IMO, isnt
it better to not re-invent the wheel and use an existing service?
(take advantage of their short domain names etc)
What are your thoughts on the blocking vs non-blocking thing?
Cheers, Tim
On Apr 2, 9:48 pm, Jorge Ortiz jorge.or...@gmail.com wrote:
What about easily turning any lift app into a url shortener service?
Wouldn't be too hard...
Granted, some services (bit.ly) add statistics, visualization, conversation
tracking, etc. which aren't just url shortening.
--j
On Thu, Apr 2, 2009 at 12:13 PM, Tim Perrett timo...@getintheloop.euwrote:
Guys,
I've been contemplating doing this for a while and am now finding
myself with a bunch of free time tomorrow and a need to write some
code.
So, I want to make a widget that shortens URL's in an extendable
way... Im thinking of having something like:
trait URLReductionProvider { ... }
object TinyURL extends URLReductionProvider
object IsGd extends URLReductionProvider
object BitLy extends URLReductionProvider
You get the general idea...
So, im thinking of implementing the actual URL fetching stuff as a
partial function so that users could do:
def reductionResult = {
case Full(result) = // result is the URL, insert into database etc
case _ = // something went wrong
}
My question is however, if i make this actor based, could someone
implement it so rather than writing there URL to database in a
separate thread to the main one, would it be possible for them to say,
use a JsCmd and return that to update the browser? Im guessing not
unless it was a CometActor right.
This then got me thinking, do you guys thing this is worth doing actor
based, or is it just ok to make a blocking call to the provider?
(tinyurl or is.gd etc)
Cheers, Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Menu widget bugginess
Have I mentioned my extreme dislike for IE? I wonder if there's anything we can do from the widget side to, say, explicitly add z-order... Derek On Thu, Apr 2, 2009 at 9:59 AM, Charles F. Munat c...@munat.com wrote: Hmmm. Your google-fu is very powerful! The fix is so simpel! I think this will probably work in this instance, but I'm pretty sure it doesn't work in every case, e.g. form inputs... else why the bother of using iframes via bgiframe.js? But for the Widgets examples, it looks like plain old divs, so I'll check it out when I get a break. Thanks! Chas. Viktor Klang wrote: Hello Chas, Can it be related to this: http://webdemar.com/webdesign/superfish-jquery-menu-ie-z-index-bug/ Cheers, Viktor On Thu, Apr 2, 2009 at 3:40 AM, Charles F. Munat c...@munat.com mailto:c...@munat.com wrote: I'm running the Lift Menu widget on my Mac via mvn jetty:run, then looking at it in IE Tester running in Windows XP Pro in a VMWare virtual machine on a Fedora 9 box on the same network. (Whew.) In IE 8 it works fine. In IE 7 and IE 6, on the CalendarWeekView and CalendarDayView pages, the third submenu link slides under the week or day view of the calendar and becomes inaccessible (and invisible as well). This is a typical problem with these piece of shit browsers that every self-respecting human on this planet should have rejected long ago... whoops. Did I write that out loud? The fix involves bigiframe.js, which I see is included in the toserve directory and on the page, so I'm not really sure why this problem is occurring. Isn't that what bigiframe.js is supposed to solve? Chas. -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] [Bug] liftAjax.js generation bug in case of LiftRules.enableLiftGC = false
Hi there,
There is a bug in ScriptRenderer.scala I've described here:
http://liftweb.lighthouseapp.com/projects/26102/tickets/31-bug-liftajaxjs-generation-bug-in-case-of-liftrulesenableliftgc-false#ticket-31-1.
I've got a quick fix for it but I don't think it's the best one
(sorry, can't provide normal patch now, I'm on windows):
ScriptRenderer.scala
function addPageName(url) {
return url.replace(' + LiftRules.ajaxPath + ', ' +
LiftRules.ajaxPath + liftPage + );
}
function lift_actualAjaxCall(data, onSuccess, onFailure) {
+
LiftRules.jsArtifacts.ajax(AjaxInfo(JE.JsRaw
(data),
POST,
LiftRules.ajaxPostTimeout,
false,
script,
Full
(onSuccess), Full(onFailure)))+
}
+
LiftRules.jsArtifacts.onLoad(new JsCmd() {def
toJsCmd = lift_doAjaxCycle()}).toJsCmd)
val liftPage = if (LiftRules.enableLiftGC) /'+lift_page else
--
One more. I've found inconsistent statements in Liftweb book (pdf
compilation master-20090309 from github). I'm not sure wheather it
still exists but anyway:
paragraph 3.4 states:
3. Check to see if the request should be handled by a View. This is
covered in section
3.6
4. If the request is not handled by a View, find a template that
matches and use it. We’ll
cover templates in section 3.5
but paragraph 3.6 states:
In either case, View lookup and dispatch is done after template
resolution, so templates take priority.
Cheers,
Alex Nemish
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Need for lightweight JPA archetype
I agree. The cost of creating the archetypes is relatively low, so having variations on a theme would be nice. Derek. On Thu, Apr 2, 2009 at 9:27 AM, Timothy Perrett timo...@getintheloop.euwrote: I guess if your deploying into an enterprise container, then EAR is fine, however if your deploying into Jetty then you don't have the possibility of deploying to EAR. I just think that having the possibility of creating either a merged project or a split project is important as JPA brings things to the table some great features that people should be able to use however they want. IMO, the archetypes are enablers - I know we could create this stuff manually, but we want to enable people to be productive quickly. Thoughts? Tim On Apr 2, 3:06 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: Works for me :) On Wed, Apr 1, 2009 at 11:51 PM, Timothy Perrett timo...@getintheloop.eu wrote: I 100% see why you want a seperate module for persistance, but workflow wise I've found JPA a lot more productive if it's in the lift app as it means you don't have to keep deploying the JAR into your local repo. Perhaps lift-jpa-archetype-blank-split lift-jpa-archetype-blank-consolidated Thoughts? Tim On Apr 2, 7:33 am, Derek Chen-Becker dchenbec...@gmail.com wrote: I thought I had sent out an email on the list earlier asking what people would want to see in such an archetype. As a base, probably a master POM with a module for the persistence unit and a module for the Lift side of things. The persistence unit could have a skeleton persistence.xml in the right place but otherwise be empty. The Lift side could have the basic Boot and perhaps a Model class set up with a placeholder persistence setup. Thoughts? Derek On Wed, Apr 1, 2009 at 3:16 PM, Timothy Perrett timo...@getintheloop.eu wrote: Glad im not the only one ;-) On Apr 1, 11:15 pm, Viktor Klang viktor.kl...@gmail.com wrote: Timmy, yeah, I can see that coming in handy. Cheers, Viktor On Wed, Apr 1, 2009 at 11:13 PM, Tim Perrett timo...@getintheloop.eu wrote: Guys, Do people see room for a blank JPA archetype just like we have blank and basic of normal lift archetypes? IMO, whilst its great having the basic one for learning and examples, having something thats a workable starting point without having to remove code etc would be helpful. I appreciate this is a bit lazy - but i don't think it would take much work and would provide a neat solution Thoughts? Tim -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Menu widget
Do you have lift-widgets module as a dependency in your pom.xml?
dependency
groupIdnet.liftweb/groupId
artifactIdlift-widgets/artifactId
version1.1-SNAPSHOT/version
/dependency
That's needed to get the dropdown widget code.
Derek
On Thu, Apr 2, 2009 at 3:13 PM, DavidV david.v.villa...@gmail.com wrote:
I posted this yesterday but I haven't seen it appear yet...sorry if it
is here twice.
I downloaded the scripts separately because I didn't know how to
update my repository/library to include the MenuWidget class and the
appropriate .js and .css files. I tried running mvn install on my
webapp, but it didn't download those new files.
I fixed the problem with my .css file so it compiles now, however I'm
still not getting the nice stylish superfish navbar. Instead, I'm
getting a vertical bulleted list of links to my different pages. I
think it's a problem with my template. Here are the relevant
sections:
html xmlns=http://www.w3.org/1999/xhtml; xmlns:lift=http://
liftweb.net/
head
meta http-equiv=content-type content=text/html;
charset=UTF-8 /
meta name=description content= /
meta name=keywords content= /
titleMy WebApp lift:Menu.title / /title
lift:StyleSheet.entryForm /
lift:StyleSheet.fancyType /
script id=jquery src=/classpath/jquery.js type=text/
javascript/
script id=json src=/classpath/json.js type=text/javascript/
/head
body
div class=container
div style=text-align: center
br/
h1 class=alt
Welcome to My WebApp /h1
/div
hr/
div
lift:MyMenu.render /
div
lift:Msgs/
hr class=space /
/div
/div
MyMenu is the snippet that contains the render method, which looks
like this:
def render(xhtml: NodeSeq): NodeSeq = {
MenuWidget(MenuStyle.NAVBAR)
}
Does anyone see what might be wrong here?
Thanks,
David
On Apr 1, 11:04 am, marius d. marius.dan...@gmail.com wrote:
Is there a reason why you downloaded he scripts separately? ... the
superfish dependencies are offered by the widget. Please see the lift-
widgets project and the test applicaiton from there.
Br's,
Marius
On Mar 31, 11:48 pm, DavidV david.v.villa...@gmail.com wrote:
I would like to use this newMenuWidget, so I got the source code from
GitHub and put it into my application as a snippet. I also downloaded
all of the necessary superfish .css and .js files from the superfish
website and put those in local sub-directories of the src/main/
webapp folder. When I try to compile the code in maven, however, I
get the following error.
C:\Source\trunk\eclipse\testLiftmvn clean jetty:run
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'jetty'.
[INFO]
[INFO] Building testLift
[INFO]task-segment: [clean, jetty:run]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory C:\Source\trunk\eclipse\testLift\target
[INFO] Preparing jetty:run
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [yuicompressor:compress {execution: default}]
[INFO] jquery.hoverIntent.js (4637b) - jquery.hoverIntent.js (0b)[0%]
[INFO] superfish.js (3837b) - superfish.js (0b)[0%]
[INFO] entryform.css (11417b) - entryform.css (10202b)[89%]
[INFO] print.css (1341b) - print.css (821b)[61%]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Illegal group reference
[INFO]
[INFO] Trace
java.lang.IllegalArgumentException: Illegal group reference
at java.util.regex.Matcher.appendReplacement(Matcher.java:713)
at com.yahoo.platform.yui.compressor.CssCompressor.compress
(CssCompresso
r.java:78)
at
net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo.processFile(YuiCom
pressorMojo.java:182)
at net.sf.alchim.mojo.yuicompressor.MojoSupport.processDir
(MojoSupport.j
ava:151)
at net.sf.alchim.mojo.yuicompressor.MojoSupport.execute
(MojoSupport.java
:105)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPlugi
nManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:558)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:499)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecy
cle(DefaultLifecycleExecutor.java:924)
