[Lift] Need Help with the RuntimeException
Hello: I've got this exception accessing one of the page, but I cannot find the reason ( and the runtime exception gives very ambigulous information). Can someone help to get the reason? Thanks. Message: java.lang.RuntimeException: FATAL scala.Predef$.error(Predef.scala:76) scala.xml.parsing.MarkupParser$class.xToken(MarkupParser.scala:267) net.liftweb.util.PCDataXmlParser.xToken(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.xEQ(MarkupParser.scala:714) net.liftweb.util.PCDataXmlParser.xEQ(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.xAttributes(MarkupParser.scala: 287) net.liftweb.util.PCDataXmlParser.xAttributes(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.xTag(MarkupParser.scala:365) net.liftweb.util.PCDataXmlParser.xTag(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:667) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91)
[Lift] Attribute as MappedField efficiency concerns
I have been surprised looking at how Mapper and Record frameworks use object of anonymous classes extending (Mapped)Field to represent attributes. This provide a powerful mechanisms to incorporate in Field traits and classes, services for persistency and representation. Based on this I am trying to subclass Record in order to implement persistency using XML files and keeping complex models (models with many connection between different objects) in memory. I made previous experience in designing such a service trying to avoid the use of reflection for efficiency reasons, but I finished with a generative approach, I am not completely satisfied (different tools for model design and code generation). Here it comes Scala and its brilliant use in Lift, opening up new opportunities. Nevertheless before going on I am concerned about implementation effciency and specifically about memory consumption, in comparison to a more conservative approach in representing attributes as simple var or val. As far as I understood the pattern lead to many anonymous classes, each representing a field in a record. What is the impact of this approach on memory consumption? Is field access time negatively affected? Thanks for suggestions on this topic. Regards beppe --~--~-~--~~~---~--~~ 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: JPA or JDO best for us on Google App Engine?
Thanks David. That frees us up to choose JDO or JPA. PS: I've read the PDF of the Lift book and about half the PDF of your Scala book. I have to say the quality of writing and clarity of content is very high. And the productivity of the authors is simply phenomenal. Mal. On Apr 12, 3:27 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Sat, Apr 11, 2009 at 10:21 PM, Oliver Lambert olambo...@gmail.comwrote: On Sun, Apr 12, 2009 at 2:54 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Sat, Apr 11, 2009 at 8:36 PM, mal3 malcolm.gor...@gmail.com wrote: We are going to use the Google App Engine (GAE) for our app using GWT with the new Google GWT Eclipse plugin support. Our Scala and Lift skills are not up to the task of doing it in Lift right now. Once we have Exploring Lift and Beginning Scala books in our hot little hands in May, we will begin to port the app over to Lift. We need to choose between JPA and JDO. Which is the best choice in anticipation of using Lift on GAE in a couple of months time? So far as I can see, Lift supports JPA but not JDO. Lift supports either. Lift is persistence agnostic. Lift has a module, mapper, that has JDBC support. Derek and Co. have built some nice JPA archetypes, but you can use JDO to your heart's content with Lift. But there are no JDO examples while there are JPA and mapper ones. The issue is what Lift supports. The HTTP request/response part of Lift is agnostic about persistence. I made sure that this was the case. Use of JPA in Scala/Lift was not well documented before Derek came along, but it's quickly becoming the persistence mechanism of choice for Lift apps. Perhaps if folks start using JDO with Lift, that will garner community support and there will be a lot of JDO code that people contribute. So, I advocate using the persistence mechanism that one feels most comfortable with. I'll make sure that if folks start using JDO and they contribute JDO examples into the community that JDO gets the same level of support as JPA and mapper. Thanks, David Mal. -- 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: stateful vs stateless snippet
On Sun, Apr 12, 2009 at 3:49 PM, marius d. marius.dan...@gmail.com wrote:
As I said you CAN use it to span the same snippet instance for
multiple pages. Please see the two fundamental functions offered by
StatefulSnippet: link and redirect. Lift book provided correct
information.
It can be used, but doesn't always give the same instance when the back
button is used?
Therefore, all my fields are reset to null. Is this the expected
functionality, or a bug (my code or Lift's)?
I am using Stateful link and redirect and the application works fine, apart
from the back button.
On Apr 12, 5:44 am, Oliver Lambert olambo...@gmail.com wrote:
On Sun, Apr 12, 2009 at 7:14 AM, marius d. marius.dan...@gmail.com
wrote:
The StatefulSnippet is not a snippet instance that is always used in
the context of your session.
Yikes! in that case, I wrote a whole application based on false
assumption.
It says in the lift book
a StatefulSnippet is ideal for small, conversational state, such as a
form
that spans multiple pages
If it spans multiple pages, doesn't this kind of imply the same instance
in
the session?
Anyway thanks for this info. Any reason why a StatefulSnippet always has
a
dispatch function and
a Stateless one, by default, has not?
The reason that I see ...
Stateless snippets are the most used artifacts to attach business
logic to your view. Because it is so common besides DispatchSnippet
trait, Lift loads and invoke Snippets functions using reflection.
Since discriminating at runtime between a stateless and a stateful
requires a trait (forget about annotations for now) well that trait is
StatefulSnippet.
to avoid RequestVar-s but keep state for current rendering pipeline in
the snippet.
2. You can indicate that you want to reuse the same instance across
multiple pages using link or redirectTo functions from the
StatefulSnippet
So depending what you want to doyou can use the statefull or stateless
nature of snippets. For stateless snippets you can just declare the
class and the method and just use it. Such as:
class Foo {
def bar(xml: NodeSeq) :NodeSeq = ...
}
.. and in your markup
lift:Foo.bar/
you can also say
class Foo extends DispatchSniuppet {
def dispatch = ...
}
which is also a stateless snippet.
Br's,
Marius
On Apr 11, 7:21 am, Oliver Lambert olambo...@gmail.com wrote:
I have a stateful snippet that doesn't always appear to work with the
back
button.
Sometimes, when the back button is used, a new stateful snippet
instance
appears to be created. Has this happened to anyone else?
Anyway, I've converted what I had to use a SessionVar to store the
state.
Should I replace the stateful snippet with a stateless one - does a
stateful
snippet that isn't storing any state have any extra overhead over a
stateless one?
If I do use a stateless snipet can I still have a dispatch method?
cheers
Oliver
--~--~-~--~~~---~--~~
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 Help with the RuntimeException
You have malformed XML in your view file. If you're using Lift 1.0, you should be able to type mvn test from the command line and all of the view files will be tested for correctness and failures should be reported. On Sun, Apr 12, 2009 at 1:55 AM, sailormoo...@gmail.com sailormoo...@gmail.com wrote: Hello: I've got this exception accessing one of the page, but I cannot find the reason ( and the runtime exception gives very ambigulous information). Can someone help to get the reason? Thanks. Message: java.lang.RuntimeException: FATAL scala.Predef$.error(Predef.scala:76) scala.xml.parsing.MarkupParser$class.xToken(MarkupParser.scala:267) net.liftweb.util.PCDataXmlParser.xToken(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.xEQ(MarkupParser.scala:714) net.liftweb.util.PCDataXmlParser.xEQ(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.xAttributes(MarkupParser.scala: 287) net.liftweb.util.PCDataXmlParser.xAttributes(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.xTag(MarkupParser.scala:365) net.liftweb.util.PCDataXmlParser.xTag(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:667) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682) net.liftweb.util.PCDataXmlParser.element1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content1(MarkupParser.scala:481) net.liftweb.util.PCDataXmlParser.content1(PCDataMarkupParser.scala: 91) scala.xml.parsing.MarkupParser$class.content(MarkupParser.scala:505) net.liftweb.util.PCDataXmlParser.content(PCDataMarkupParser.scala:91) scala.xml.parsing.MarkupParser$class.element1(MarkupParser.scala:682)
[Lift] Re: Attribute as MappedField efficiency concerns
Personally I'm not aware of a benchmark yielding concrete comparison numbers. However this questions extends to Scala's anonymous class files generation and surprisingly Scala's performance is unbelievably close to Java's. JIT compilers really do their job. Now comparing Record fields which are Scala objects the access to those is quite fast perhaps not as fast as regular fields access but I wouldn't be worried about that at all. Because we're talking about persistence the time spent with datastore conversations exceeds by far the time of accessing fields. I would expect very little differences ... but again I don't have concrete numbers. The memory consumption is a little higher of course but again I wouldn't be worried to much about this as Record's fields are typically very thin. We also thought making record to use annotated vars but this is more restrictive besides we can not have Scala annotations with retention policy RUNTIME ... which would make us use Java annotation :( Br's, Marius On Apr 12, 1:39 pm, Giuseppe Fogliazza g.foglia...@mcmspa.it wrote: I have been surprised looking at how Mapper and Record frameworks use object of anonymous classes extending (Mapped)Field to represent attributes. This provide a powerful mechanisms to incorporate in Field traits and classes, services for persistency and representation. Based on this I am trying to subclass Record in order to implement persistency using XML files and keeping complex models (models with many connection between different objects) in memory. I made previous experience in designing such a service trying to avoid the use of reflection for efficiency reasons, but I finished with a generative approach, I am not completely satisfied (different tools for model design and code generation). Here it comes Scala and its brilliant use in Lift, opening up new opportunities. Nevertheless before going on I am concerned about implementation effciency and specifically about memory consumption, in comparison to a more conservative approach in representing attributes as simple var or val. As far as I understood the pattern lead to many anonymous classes, each representing a field in a record. What is the impact of this approach on memory consumption? Is field access time negatively affected? Thanks for suggestions on this topic. Regards beppe --~--~-~--~~~---~--~~ 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: stateful vs stateless snippet
On Sun, Apr 12, 2009 at 5:29 AM, Oliver Lambert olambo...@gmail.com wrote:
On Sun, Apr 12, 2009 at 3:49 PM, marius d. marius.dan...@gmail.comwrote:
As I said you CAN use it to span the same snippet instance for
multiple pages. Please see the two fundamental functions offered by
StatefulSnippet: link and redirect. Lift book provided correct
information.
It can be used, but doesn't always give the same instance when the back
button is used?
Therefore, all my fields are reset to null. Is this the expected
functionality, or a bug (my code or Lift's)?
I am using Stateful link and redirect and the application works fine, apart
from the back button.
If you're using the back button and you're presenting forms to the user,
what you're seeing is the expected (perhaps not desired) behavior.
In order to figure out which stateful snippet is being used, Lift either
inserts a hidden field on the form or adds a parameter to the link URL. In
both cases, these hidden items refer to a function that binds the instance
of the stateful snippet to the name of the snippet so that the same instance
will be used. If you press the back button and a URL does not have the
query parameter, there's no way for Lift to know which instance of the
stateful snippet to attach to the particular snippet name and Lift creates a
new one.
More broadly, I opted to not have ugly URLs in Lift. Seaside and other
frameworks that are more stateful than Lift have to put a token in the URL
indicating the state of the application for that particular URL. This
allows you to have multiple instances of a given multi-page form going at
the same time, all with back-button support. The cost is ugly URLs and the
inability to send a given URL to a friend (because the state information is
part of the URL.) In Seaside, you have to specify that a particular URL is
durable and it's not uglified. In Lift, by default, the URLs are pretty and
stateless.
So, you've found a corner case of the downside of this choice. I'm hoping
to add wizard functionality to Lift for 1.1 (although it's not on the
official schedule) and that would give you better statefulness, ugly URLs,
and better back-button support.
Thanks,
David
On Apr 12, 5:44 am, Oliver Lambert olambo...@gmail.com wrote:
On Sun, Apr 12, 2009 at 7:14 AM, marius d. marius.dan...@gmail.com
wrote:
The StatefulSnippet is not a snippet instance that is always used in
the context of your session.
Yikes! in that case, I wrote a whole application based on false
assumption.
It says in the lift book
a StatefulSnippet is ideal for small, conversational state, such as a
form
that spans multiple pages
If it spans multiple pages, doesn't this kind of imply the same instance
in
the session?
Anyway thanks for this info. Any reason why a StatefulSnippet always has
a
dispatch function and
a Stateless one, by default, has not?
The reason that I see ...
Stateless snippets are the most used artifacts to attach business
logic to your view. Because it is so common besides DispatchSnippet
trait, Lift loads and invoke Snippets functions using reflection.
Since discriminating at runtime between a stateless and a stateful
requires a trait (forget about annotations for now) well that trait is
StatefulSnippet.
to avoid RequestVar-s but keep state for current rendering pipeline in
the snippet.
2. You can indicate that you want to reuse the same instance across
multiple pages using link or redirectTo functions from the
StatefulSnippet
So depending what you want to doyou can use the statefull or stateless
nature of snippets. For stateless snippets you can just declare the
class and the method and just use it. Such as:
class Foo {
def bar(xml: NodeSeq) :NodeSeq = ...
}
.. and in your markup
lift:Foo.bar/
you can also say
class Foo extends DispatchSniuppet {
def dispatch = ...
}
which is also a stateless snippet.
Br's,
Marius
On Apr 11, 7:21 am, Oliver Lambert olambo...@gmail.com wrote:
I have a stateful snippet that doesn't always appear to work with
the
back
button.
Sometimes, when the back button is used, a new stateful snippet
instance
appears to be created. Has this happened to anyone else?
Anyway, I've converted what I had to use a SessionVar to store the
state.
Should I replace the stateful snippet with a stateless one - does a
stateful
snippet that isn't storing any state have any extra overhead over a
stateless one?
If I do use a stateless snipet can I still have a dispatch method?
cheers
Oliver
--
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
[Lift] Re: [scala] Google App Engine for Scala!
Hi there, On Sun, Apr 12, 2009 at 12:46 AM, Atsuhiko Yamanaka atsuhiko.yaman...@gmail.com wrote: Hi, On Sat, Apr 11, 2009 at 10:43 PM, David Pollak feeder.of.the.be...@gmail.com wrote: GAE supports JPA and there's a lot of Lift JPA support... so maybe we can update the example code to use JPA and we'll have persistence via BigTable. I may have missed something, but it seems that the combination of scala and DataNucleus(used via JPA on GAE/J) does not work, as far as I have been trying. Are there somebody who have succeeded to use scala and JPA on GAE/J? Can we work around this problem by implementing entity classes in Java? FYI, it must be trivial, but I have confirmed that Lift(org.scala_libs.jpa) has persistence via BigTable through JPA on GAE/J by using entity classes in Java! Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Fax +81-22-224-8773 Skype callto://jcraft/ --~--~-~--~~~---~--~~ 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: JPA or JDO best for us on Google App Engine?
On Sun, Apr 12, 2009 at 3:42 AM, mal3 malcolm.gor...@gmail.com wrote: Thanks David. That frees us up to choose JDO or JPA. Yes. If you choose JDO, it'd be great for you to blog and/or send stuff to this list about how to do it. PS: I've read the PDF of the Lift book and about half the PDF of your Scala book. I have to say the quality of writing and clarity of content is very high. Thanks! Feel encouraged to blog your kind words, and critical feedback as well, about the books. APress, our publisher, loves community feedback... and I improve myself by hearing what other people think. Thanks! And the productivity of the authors is simply phenomenal. Mal. On Apr 12, 3:27 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Sat, Apr 11, 2009 at 10:21 PM, Oliver Lambert olambo...@gmail.com wrote: On Sun, Apr 12, 2009 at 2:54 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Sat, Apr 11, 2009 at 8:36 PM, mal3 malcolm.gor...@gmail.com wrote: We are going to use the Google App Engine (GAE) for our app using GWT with the new Google GWT Eclipse plugin support. Our Scala and Lift skills are not up to the task of doing it in Lift right now. Once we have Exploring Lift and Beginning Scala books in our hot little hands in May, we will begin to port the app over to Lift. We need to choose between JPA and JDO. Which is the best choice in anticipation of using Lift on GAE in a couple of months time? So far as I can see, Lift supports JPA but not JDO. Lift supports either. Lift is persistence agnostic. Lift has a module, mapper, that has JDBC support. Derek and Co. have built some nice JPA archetypes, but you can use JDO to your heart's content with Lift. But there are no JDO examples while there are JPA and mapper ones. The issue is what Lift supports. The HTTP request/response part of Lift is agnostic about persistence. I made sure that this was the case. Use of JPA in Scala/Lift was not well documented before Derek came along, but it's quickly becoming the persistence mechanism of choice for Lift apps. Perhaps if folks start using JDO with Lift, that will garner community support and there will be a lot of JDO code that people contribute. So, I advocate using the persistence mechanism that one feels most comfortable with. I'll make sure that if folks start using JDO and they contribute JDO examples into the community that JDO gets the same level of support as JPA and mapper. Thanks, David Mal. -- 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 -- 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: Attribute as MappedField efficiency concerns
To amplify on Marius' comment: The cost of extra classes is trivial. While there is start-up time associated with loading the classes, for a long-running process, you'll see no measurable difference for using lots of different classes. Martin has run the numbers and lots of other people have benchmarked Scala and the difference between Java and Scala is +/- 5% (sometimes Scala is faster... especially related to collections, sometimes Java is faster, especially related to static access vs. object access.) For a web application, even when you're keeping your XML data in memory, the practical difference is nil. In terms of the actual cost of Lift's object fields vs. direct reference to the field itself, you have the following additional costs: 2 references for the base instance (the object handle and the object reference in the GC pool) 1 reference to the enclosing record 1 reference to the current data 1 reference to the old data (fields are versioned) 1 reference to the class of the object This means that the additional cost is 5 references. On a 32 bit JVM, this is 4 bytes x 6 and on a 64 bit JVM, it's 8 bytes x 6. So, you're looking at 48 bytes of overhead per field worst case on a 64 bit JVM. Granted this is non-trivial, but it's also unlikely to eclipse the cost of the underlying data. Also, please see http://blog.lostlake.org/index.php?/archives/19-Keeping-the-meaning-with-the-bytes.html Thanks, David On Sun, Apr 12, 2009 at 5:54 AM, marius d. marius.dan...@gmail.com wrote: Personally I'm not aware of a benchmark yielding concrete comparison numbers. However this questions extends to Scala's anonymous class files generation and surprisingly Scala's performance is unbelievably close to Java's. JIT compilers really do their job. Now comparing Record fields which are Scala objects the access to those is quite fast perhaps not as fast as regular fields access but I wouldn't be worried about that at all. Because we're talking about persistence the time spent with datastore conversations exceeds by far the time of accessing fields. I would expect very little differences ... but again I don't have concrete numbers. The memory consumption is a little higher of course but again I wouldn't be worried to much about this as Record's fields are typically very thin. We also thought making record to use annotated vars but this is more restrictive besides we can not have Scala annotations with retention policy RUNTIME ... which would make us use Java annotation :( Br's, Marius On Apr 12, 1:39 pm, Giuseppe Fogliazza g.foglia...@mcmspa.it wrote: I have been surprised looking at how Mapper and Record frameworks use object of anonymous classes extending (Mapped)Field to represent attributes. This provide a powerful mechanisms to incorporate in Field traits and classes, services for persistency and representation. Based on this I am trying to subclass Record in order to implement persistency using XML files and keeping complex models (models with many connection between different objects) in memory. I made previous experience in designing such a service trying to avoid the use of reflection for efficiency reasons, but I finished with a generative approach, I am not completely satisfied (different tools for model design and code generation). Here it comes Scala and its brilliant use in Lift, opening up new opportunities. Nevertheless before going on I am concerned about implementation effciency and specifically about memory consumption, in comparison to a more conservative approach in representing attributes as simple var or val. As far as I understood the pattern lead to many anonymous classes, each representing a field in a record. What is the impact of this approach on memory consumption? Is field access time negatively affected? Thanks for suggestions on this topic. Regards beppe -- 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: Lift helloworld on App Engine: java.lang.NoClassDefFoundError: Could not initialize class net.liftweb.http.LiftRules$
I have tried the build from http://github.com/ymnk/liftweb/tree/master It works fine for simple example. I am testing JPA. I did not encounter the class not found problem and list my problem below a. Actor problem, solved with new build (I only use lift-util, lift-webkit) b. Session problem, add sessions-enabledtrue/sessions-enabled in appengine-web.xml c. commons-fileupload could not be loaded, add commons-fileupload.jar to WEB-INF/lib I think after that you could deploy your helloworld. Anyway, I could make it work in Eclipse. 2009/4/12 David Pollak feeder.of.the.be...@gmail.com See this fork of Lift:http://github.com/ymnk/liftweb/tree/master We'll roll the changes into 1.1-SNAPSHOT next week. On Sat, Apr 11, 2009 at 6:18 PM, Dave Briccetti da...@davebsoft.comwrote: Hi. Should this be working now, or are we waiting for code changes? 1. ... 2. W 04-11 06:09PM 30.161 failed LiftFilter java.lang.NoClassDefFoundError: Could not initialize class net.liftweb.http.LiftRules$ at net.liftweb.http.LiftFilter.init(LiftServlet.scala:546) at org.mortbay.jetty.servlet.FilterHolder.doStart (FilterHolder.java:99) at org.mortbay.component.AbstractLifeCycle.start (AbstractLifeCycle.java:40) at org.mortbay.jetty.servlet.ServletHandler.initialize (ServletHandler.java:589) at org.mortbay.jetty.servlet.Context.startContext(Context.java: 139) at org.mortbay.jetty.webapp.WebAppContext.startContext (WebAppContext.java:1218) at org.mortbay.jetty.handler.ContextHandler.doStart --~--~-~--~~~---~--~~ 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: TemplateCache
Interesting marius - I havent checked out the code yet, but did you manage to work around the thread safe issues? Cheers, Tim On Apr 11, 9:16 pm, marius d. marius.dan...@gmail.com wrote: I just committed a SoftReferenceCache implementation in utils and it is used by InMemoryCache. So far testing it looks pretty good. The point of a SoftReferenceMap is probably obvious to prevent (as much as possible) OOME. This is fine IMHO cause it's more important to have the application running an not crash due to large potentially large caches. Of course if a cache template is gc-ed it will be re-cached on the subsequent attempt to use it. I would appreciate any early feedback. Br's, Marius On Apr 6, 1:00 am, Derek Chen-Becker dchenbec...@gmail.com wrote: I agree. Thread safety would be nice, and should be easily achievable with some existing code. The beauty of traits is that we can get these orthogonal behaviors through composition. Derek On Sun, Apr 5, 2009 at 2:21 PM, Timothy Perrett timo...@getintheloop.euwrote: Just taken a look over the code - looks pretty cool! I like your ideas for ConcurrentHashMap - all sounds pretty awesome... regarding the use of EHCache, I rekon as long as provide a hook mechinism into the cache system, then sure, we should let people worry about those issues in there specific implementation as 90% of users simply wont need that functionality IMO. Cheers, Tim On Apr 5, 8:53 pm, Timothy Perrett timo...@getintheloop.eu wrote: Wow, derek you must be watching Github like a hawk haha ;-) Just to bring an off list convo between myself and Marius onto the list, are we looking at having some generic caching infrastructure in lift? This would be great re the localization / translation stuff im working on which currently uses KeyedCache in lift-util as a base. Im just doing a git pull for the cache branch... Cheers Tim On 05/04/2009 20:38, marius d. marius.dan...@gmail.com wrote: Good :) ... I was also thinking on a flush-able caching mechanism. So far the InMemoryCache is more for exemplification as it is not yet thread safe. It is based on LRU cache but I'm also thinking to also combine the ConcurrentHashMap approach with LRU ... also I was thinking to a SoftReference map (as I implemented this once in Java) but we'll see. It's evolving. I'm not sure at all if we should use EHCahe or JBossCahe like solutions as we don't really need distributed caching. Basides if people will want this they can just plugin their own caching mechanisms. Br's, Marius On Apr 5, 10:24 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: I just saw the commit from Marius on a preliminary template cache and it looks good. I was thinking the same thing in terms of where and how to hook it. I think that there are some possibilities for some more functionality on the TemplateCache trait, including a programmatic flush (in case you're pushing new template files in production and want to force re-fetching, for instance), but I like the basic concept. Derek --~--~-~--~~~---~--~~ 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: JPA or JDO best for us on Google App Engine?
Thanks for the positive feedback on the book. If you have any critique of the content, please feel free to post it on the book group list: http://groups.google.com/group/the-lift-book As for JPA vs JDO I think you should have no problem going either route. I have no experience with JDO, so I can't comment there, but Scala has actually made JPA easier to use due to the availability of mixin traits and some type niceties. If you do go JDO I think we would all love to see any notes, stories, etc about your experience, and we could even build a JDO archetype if there is some scaffolding that would help people using JDO get a Lift app up and running quickly. Derek On Sun, Apr 12, 2009 at 4:42 AM, mal3 malcolm.gor...@gmail.com wrote: Thanks David. That frees us up to choose JDO or JPA. PS: I've read the PDF of the Lift book and about half the PDF of your Scala book. I have to say the quality of writing and clarity of content is very high. And the productivity of the authors is simply phenomenal. Mal. On Apr 12, 3:27 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Sat, Apr 11, 2009 at 10:21 PM, Oliver Lambert olambo...@gmail.com wrote: On Sun, Apr 12, 2009 at 2:54 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Sat, Apr 11, 2009 at 8:36 PM, mal3 malcolm.gor...@gmail.com wrote: We are going to use the Google App Engine (GAE) for our app using GWT with the new Google GWT Eclipse plugin support. Our Scala and Lift skills are not up to the task of doing it in Lift right now. Once we have Exploring Lift and Beginning Scala books in our hot little hands in May, we will begin to port the app over to Lift. We need to choose between JPA and JDO. Which is the best choice in anticipation of using Lift on GAE in a couple of months time? So far as I can see, Lift supports JPA but not JDO. Lift supports either. Lift is persistence agnostic. Lift has a module, mapper, that has JDBC support. Derek and Co. have built some nice JPA archetypes, but you can use JDO to your heart's content with Lift. But there are no JDO examples while there are JPA and mapper ones. The issue is what Lift supports. The HTTP request/response part of Lift is agnostic about persistence. I made sure that this was the case. Use of JPA in Scala/Lift was not well documented before Derek came along, but it's quickly becoming the persistence mechanism of choice for Lift apps. Perhaps if folks start using JDO with Lift, that will garner community support and there will be a lot of JDO code that people contribute. So, I advocate using the persistence mechanism that one feels most comfortable with. I'll make sure that if folks start using JDO and they contribute JDO examples into the community that JDO gets the same level of support as JPA and mapper. Thanks, David Mal. -- 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: [scala] Google App Engine for Scala!
Cool, so the ScalaJPA stuff works fine under GAE? Derek On Sun, Apr 12, 2009 at 8:00 AM, Atsuhiko Yamanaka atsuhiko.yaman...@gmail.com wrote: Hi there, On Sun, Apr 12, 2009 at 12:46 AM, Atsuhiko Yamanaka atsuhiko.yaman...@gmail.com wrote: Hi, On Sat, Apr 11, 2009 at 10:43 PM, David Pollak feeder.of.the.be...@gmail.com wrote: GAE supports JPA and there's a lot of Lift JPA support... so maybe we can update the example code to use JPA and we'll have persistence via BigTable. I may have missed something, but it seems that the combination of scala and DataNucleus(used via JPA on GAE/J) does not work, as far as I have been trying. Are there somebody who have succeeded to use scala and JPA on GAE/J? Can we work around this problem by implementing entity classes in Java? FYI, it must be trivial, but I have confirmed that Lift(org.scala_libs.jpa) has persistence via BigTable through JPA on GAE/J by using entity classes in Java! Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Fax +81-22-224-8773 Skype callto://jcraft/ --~--~-~--~~~---~--~~ 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] Getting started source document
Hi folks, Is the source document of the Getting starded guide available somewhere? I'm following it and I thought that I could send fixes in a patch form. Regards, Frederik --~--~-~--~~~---~--~~ 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] Help with PocketChange project
Hello, I've started reading through Exploring Lift and I'm having trouble with running the PocketChange demo. I've ran the following commands: git clone git://github.com/tjweir/pocketchangeapp.git cd to PocketChange directory mvn install mvn jetty:run -U When the jetty server starts, the following two errors appear: 2009-04-12 17:05:47.728::INFO: No Transaction manager found - if your webapp requires one, please configure one. org.postgresql.util.PSQLException: Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections. at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:122) at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:65) at org.postgresql.jdbc2.AbstractJdbc2Connection.init(AbstractJdbc2Connection.java:116) at org.postgresql.jdbc3.AbstractJdbc3Connection.init(AbstractJdbc3Connection.java:30) ... ERROR - Failed to Boot java.lang.NullPointerException: Looking for Connection Identifier ConnectionIdentifier(lift) but failed to find either a JNDI data source with the name lift or a lift connection manager with the correct name at net.liftweb.mapper.DB$$anonfun$3$$anonfun$apply$7.apply(DB.scala:95) at net.liftweb.mapper.DB$$anonfun$3$$anonfun$apply$7.apply(DB.scala:95) at net.liftweb.util.EmptyBox.openOr(Box.scala:372) at net.liftweb.mapper.DB$$anonfun$3.apply(DB.scala:95) ... Is there a step I'm missing? Thanks, Xavi --~--~-~--~~~---~--~~ 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] CRUDifying a model
I have a model defined with the CRUDify trait. I'm under the impression that I need to add something to the sitemap for the crudified pages to be available, and that defining my model with CRUDify should create some basic UI and addition pages for my model. Basically, given a model x with crudify, what do I have to do to get the model accessible over the web with a minimum of fuss? Thanks. --~--~-~--~~~---~--~~ 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: Getting started source document
http://github.com/tjweir/liftbook/tree/ef3f7417ca2e3a5dde21667f0ca12c0c276329a8/getting_started On Sun, Apr 12, 2009 at 1:00 PM, Frederik Deweerdt frederik.dewee...@xprog.eu wrote: Hi folks, Is the source document of the Getting starded guide available somewhere? I'm following it and I thought that I could send fixes in a patch form. Regards, Frederik -- 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: CRUDifying a model
In Boot.scala, when you're constructing the menu, put MyModel.menu (which returns a List[Menu]) in the list of menu items. On Sun, Apr 12, 2009 at 3:16 PM, ari arimat...@gmail.com wrote: I have a model defined with the CRUDify trait. I'm under the impression that I need to add something to the sitemap for the crudified pages to be available, and that defining my model with CRUDify should create some basic UI and addition pages for my model. Basically, given a model x with crudify, what do I have to do to get the model accessible over the web with a minimum of fuss? Thanks. -- 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: Help with PocketChange project
It's probably better to send PocketChange questions to the Lift Book list, which is here http://groups.google.com/group/the-lift-book/ And there is a thread regarding your issue here: http://groups.google.com/group/the-lift-book/browse_frm/thread/7791a6f79654d568 If you open Boot.scala, you'll see that we're using Postgres as a database. You'll need to change that to suit your set-up. On Apr 12, 5:21 pm, Xavi Ramirez xavi@gmail.com wrote: Hello, I've started reading through Exploring Lift and I'm having trouble with running the PocketChange demo. I've ran the following commands: git clone git://github.com/tjweir/pocketchangeapp.git cd to PocketChange directory mvn install mvn jetty:run -U When the jetty server starts, the following two errors appear: 2009-04-12 17:05:47.728::INFO: No Transaction manager found - if your webapp requires one, please configure one. org.postgresql.util.PSQLException: Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections. at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:122) at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:65) at org.postgresql.jdbc2.AbstractJdbc2Connection.init(AbstractJdbc2Connection.java:116) at org.postgresql.jdbc3.AbstractJdbc3Connection.init(AbstractJdbc3Connection.java:30) ... ERROR - Failed to Boot java.lang.NullPointerException: Looking for Connection Identifier ConnectionIdentifier(lift) but failed to find either a JNDI data source with the name lift or a lift connection manager with the correct name at net.liftweb.mapper.DB$$anonfun$3$$anonfun$apply$7.apply(DB.scala:95) at net.liftweb.mapper.DB$$anonfun$3$$anonfun$apply$7.apply(DB.scala:95) at net.liftweb.util.EmptyBox.openOr(Box.scala:372) at net.liftweb.mapper.DB$$anonfun$3.apply(DB.scala:95) ... Is there a step I'm missing? Thanks, Xavi --~--~-~--~~~---~--~~ 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] Override Menu HTML
Hi, Currently lift:Menu.builder/ renders an unordered list (UL). How do I override this HTML to have each entry in the menu around a div, for example? joao --~--~-~--~~~---~--~~ 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] XML Creation
Hello:
Thanks for the previous answers of my questions.
I would like to know how to make the following example work by Lift:
( I use the old style Java scriptlet for example ).
table
% for (int i = 0; i data.size(); i++) { %
trtd%= data.name %/td/tr
% } %
/table
I cannot find an example like this, and I don't know if it should be
done by a single snippet with all the rows, or some list/array to
iterate in the view.
Thanks.
--~--~-~--~~~---~--~~
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: Override Menu HTML
At this point you would have to write your own version of Menu.builder. Usually you can modify presentation with CSS. Is that not feasible here? Derek 2009/4/12 João Pereira joaomiguel.pere...@gmail.com Hi, Currently lift:Menu.builder/ renders an unordered list (UL). How do I override this HTML to have each entry in the menu around a div, for example? joao --~--~-~--~~~---~--~~ 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: XML Creation
I would do this with a snippet tag that looked like:
lift:MyTable.foo
table
tb:entries
trtdentry:name //td/tr
/tb:entries
/table
/lift:MyTable.foo
Then the snippet would look like
class MyTable {
def foo (xhtml : NodeSeq) : NodeSeq = {
val data = ... fill this in ...
val entries =
data.flatMap(bind(entry, chooseTemplate(tb, entries, xhtml),
name - Text(_.name)))
bind(tb, xhtml, entries - entries)
}
}
That's from memory so I may be a little off. I'm also assuming that data is
some sort of Scala collection. Anyways, the combination of bind and
chooseTemplate lets you keep all the presentation XML and Scala logic
cleanly separated.
Derek
On Sun, Apr 12, 2009 at 10:03 PM, sailormoo...@gmail.com
sailormoo...@gmail.com wrote:
Hello:
Thanks for the previous answers of my questions.
I would like to know how to make the following example work by Lift:
( I use the old style Java scriptlet for example ).
table
% for (int i = 0; i data.size(); i++) { %
trtd%= data.name %/td/tr
% } %
/table
I cannot find an example like this, and I don't know if it should be
done by a single snippet with all the rows, or some list/array to
iterate in the view.
Thanks.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
