[Lift] Re: Lift 1.1-M8
I'm wondering about scala 2.8 compatibility, is it in or when is it planned? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: The quality of the Lift list [was: Don't shoot the non-XML messenger ...]
I've been recently really surprised (in positive way) by the Lift community. I also have some experience in maintaining a community and its spirit and i absolutely agree with and support David and his ideas and decisions. Would be really nice to keep the spirit! On Oct 14, 10:49 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, It is not lightly that I ban someone from the group... this is only the second time I've banned a substantive poster. I'm going to discuss some of the process and then touch on some of the substance of the questions that the poster was getting at. The Lift community, reflected on this list, is an inquisitive, friendly place where people who have a passion for building great web apps converge and contribute to making Lift a really great open source framework. Newbies are the lifeblood of the group because they come with fresh perspectives and new ways of looking at things. Questions from newbies help us refine and enhance Lift and the associated documentation. Folks who are building production apps on Lift receive the fastest turn-around because these folks are betting their careers and their enterprises (even enterprises of one) on Lift and they deserve the best support in the industry for taking this risk. A big part of why this community is successful (in terms of size, quality of discussion, and quality of results) is because we keep the quality of discussion high. How do we do this? The folks who have been on the list generally keep the level of discussion to the Lift ideals. We reward newbies with quick answers and encourage friendly discourse. We are generally slower to respond to those that are less reflective of the list ideals. I warn folks who are pushing boundaries (usually privately, but every once in a while publicly) and where the line is. In this case, nothing worked. The poster was neither asking questions, giving usable feedback, or being polite in his engagement with the folks on the list. I received a substantial number of private communications about this poster (which is pretty rare), and I took action. In terms of the substance, let me address to threat issue first. I threatened to ban the poster from the list. Perhaps DHH or Martin would not make such a threat. I am very sure that the quality of discussion on the Lift list is higher than that on the Rails list (one of the reasons I started Lift was to be part of a nicer community.) One cost of having a nicer place is excluding those who do not fit. The second threat I made was to relay a tongue-in-cheek private communication I received about the poster to the list (after receiving the okay from the guy that made the communication to me.) This threat was obvious, using video game rating language http://www.esrb.org/ratings/ratings_guide.jsp, Comic mischief and Cartoon violence. It was something that even a 6 year old can distinguish from reality. Put another way, the poster was talking about Kafkaesque experiences with using Lift and I responded with Jonesianhttp://www.youtube.com/watch?v=CrupqdGvsocfeature=PlayListp=62FED00...language. In terms of the broader issue of Lift's HTML templating system being XHTML only, yes, that's true. Lift treats HTML templates as XML. Lift's templating system is not a String templating system but an XML templating system. This satisfies the needs to render content to HTML browsers. If there are needs for generating other kinds of content, Lift is not as good, but in many cases there are better libraries for doing so. Lift makes it very simple to integrate other rendering/templating engines into Lift, usually with a single line of code the dispatches the HTTP request to an alternate provider of a LiftResponse. If the poster had simply said, I want to template non-HTML output, can you show me how? he would have gotten a nice example (and I might have even rolled it into demo.liftweb.net or maybe Tim might have blogged about it. Keeping things in XML has a number of advantages and a few disadvantages. First, the disadvantages: (1) you can't template non-XHTML responses and (2) everything must be well formed XML. The advantages are (1) security (2) performance (it's easier to cache XML and the cost of mutating XML trees is O(log N)), (3) there is better separation of logic from the view (perhaps Terrance Parr's String Template library achieves this level of separation), and (4) the ability to mutate the resulting page (rewrite tags, move stuff to head/tail, consolidate scripts) is more performant and less error-prone than doing the same with a String-based representation. I will address Bill's security question. For String-based rendering systems that emit HTML, the developer is the one who must make a decision at each insertion point as to whether the incoming String needs to be escaped. Because Strings are untyped, you don't know what they mean, if they're safe to
[Lift] Re: Why fields are declared as 'object' with Mapper/Record?
to Naftoli: i added implicits as you said and removed all 'onRegister' stuff, i think its useless.. Here's the result: http://github.com/ojow/Random-code/blob/master/RecordRelatedStuff.scala --~--~-~--~~~---~--~~ 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: Why fields are declared as 'object' with Mapper/Record?
edit: not all 'onRegister' stuff but most of it, only left two points of extension for intercepting the prototype creation. --~--~-~--~~~---~--~~ 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: Why fields are declared as 'object' with Mapper/Record?
On 13 окт, 10:40, David Pollak feeder.of.the.be...@gmail.com wrote: I've got a change on review board that will pick up vals and lazy vals that are MappedFields. Seehttp://reviewboard.liftweb.net/r/40/ However, until certain defects in the Scala compiler (https://lampsvn.epfl.ch/trac/scala/ticket/2463andhttps://lampsvn.epfl.ch/trac/scala/ticket/1006) are fixed, these features are dangerous and should not be used. That's cool! 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: Why fields are declared as 'object' with Mapper/Record?
I've spent some time and came up with this code: http://github.com/ojow/Random-code/blob/master/Test.scala I think it should allow all the needed stuff, it keeps meaning with the bytes and also: * its reusable/extensible in many directions, no static stuff * i checked generated .class files and looks like no extra hidden fields or heave methods are generated, so its technically light-weight * it doesn't use/need reflection (not sure if its good or bad) Would be nice to hear some feedback on that. P.S. I'm still a newbie in Scala so excuse me if this code is worthless and if i'm just stealing your time. On Oct 7, 3:54 am, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Oct 6, 2009 at 10:16 AM, Oleg G. ojo...@gmail.com wrote: As i said before i'm not sure that i'm getting the whole picture and maybe my initial question is incorrect in its root. Still: Suppose i have a Person class declared with Mapper/Record and i want to reuse the class and all the code associated with it in another module/project. My first thought was to extend the Person class and override some of its fields by mixing in some additional traits (see my simplified example code in the initial message). But i noticed that inner objects cannot be overriden (its not obvious for me but i can get it if i dig it). You can't do this. There was a Scala language feature that would have allowed this (overriding an object) but it hasn't made the cut for 2.7 or 2.8. So how do i reuse Mapper/Record based code if i need to extend/ customize the data structures? Unfortunately, you can't. Once you've got a field defined, there's nothing you can do to change it in a subclass. On Oct 6, 11:59 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Oct 6, 2009 at 9:50 AM, Oleg G. ojo...@gmail.com wrote: Thanks for all the answers and especially for David's clarification. It would be really cool to upgrade the 'keeping the meaning with the bytes' thing (http://blog.lostlake.org/index.php?/archives/19-Keeping- the-meaning-with-the-bytes.html) to allow extension/customization. What kind of extensions/customizations? MappedXXX can all be subclassed, extended and customized. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to 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: Why fields are declared as 'object' with Mapper/Record?
Well i don't think its a lot of complexity. Yes its 4 declarations instead of 1 for each field. But 3 of those are generatable by IDE same way as any Java IDE generates setters and getters. All the rest is spring-style instantiations/injections. And usage is even simplier and readable (i mean syntax record.field=value). The field list method can be implemented via reflection to reduce amount of code required from users. Anyway thanks for your feedback, David, i really appreciate it. I'll try to see if i can integrate my model with Lift and implement it for Google Datastore. Then i'll report back. I understand that i still need to do more work before any serious conclusions can be made. --~--~-~--~~~---~--~~ 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: Why fields are declared as 'object' with Mapper/Record?
On 13 окт, 00:08, naf g naftoli...@gmail.com wrote: Why do you have two classes, Model and Record? What are they and why are they interdependent? I thought about Model being a place for metainformation (like database structure, options/properties etc), or maybe it can be described as global context for Record-related activity. They are dependant to allow Field operations to reach the context. --~--~-~--~~~---~--~~ 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: Why fields are declared as 'object' with Mapper/Record?
Thanks again for your answers, David. I've got your point and it all looks much more clear to me now. On 13 окт, 01:19, David Pollak feeder.of.the.be...@gmail.com wrote: On Mon, Oct 12, 2009 at 10:38 AM, Oleg G. ojo...@gmail.com wrote: Well i don't think its a lot of complexity. You asked for feedback, I gave you my opinion. Yes its 4 declarations instead of 1 for each field. But 3 of those are generatable by IDE same way as any Java IDE generates setters and getters. And this is a failure on its face. Anything that requires an IDE to generate code represents a failure. It represents failure because the code is (1) much less maintainable, (2) depends on IDE vendors to support it, and (3) is harder for non-IDE users (me included... emacs is my tool for a lot of my Lift-based development). All the rest is spring-style instantiations/injections. And usage is even simplier and readable (i mean syntax record.field=value). The field list method can be implemented via reflection to reduce amount of code required from users. Calculating what fields are to be included in the List is what originally led to using object. Anyway thanks for your feedback, David, i really appreciate it. I'll try to see if i can integrate my model with Lift and implement it for Google Datastore. Then i'll report back. I understand that i still need to do more work before any serious conclusions can be made. While I appreciate your effort, it is is not in line with the goals of Lift. The default is not to keep the meaning with the bytes (having _name implies to me don't use this, use name instead). The complexity is significant... so significant that it requires IDE support to use effectively. The problem that it addresses is the overriding definitions of fields in subclasses issue which is important, but in this case the cure is much, much worse than disease. Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to 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: Why fields are declared as 'object' with Mapper/Record?
After reading Naftoli's post i checked the way inner object laziness
is implemented. And it appears to be not thread safe.
Following code:
class A { val a = 1 }
class B { object b extends A }
Generates getter for b as follows:
public final B$b$ b();
Code:
0: aload_0
1: getfield#18; //Field b$module:LB$b$;
4: ifnonnull 19
7: aload_0
8: new #20; //class B$b$
11: dup
12: aload_0
13: invokespecial #23; //Method B$b$.init:(LB;)V
16: putfield#18; //Field b$module:LB$b$;
19: aload_0
20: getfield#18; //Field b$module:LB$b$;
23: areturn
Looks like its not synchronized? I also looked at lazy vals generated
code (when i was thinking on val based Records) and dropped the idea
because of synchronization for every single access to a field.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Why fields are declared as 'object' with Mapper/Record?
Sorry if its a stupid question, but why?
I like the idea very much and trying to understand all the aspects.
Fields declared as 'objects' can't be overridden. Is it intended? If
so why?
Consider following oversimplified example:
trait Field
trait Prop1
trait Prop2
trait Prop3
class Person {
val name = new Field with Prop1 with Prop2
}
class CustomPerson extends Person {
override val name = new Field with Prop1 with Prop2 with Prop3
}
Is there something wrong?
--~--~-~--~~~---~--~~
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: Why fields are declared as 'object' with Mapper/Record?
Thanks for all the answers and especially for David's clarification. It would be really cool to upgrade the 'keeping the meaning with the bytes' thing (http://blog.lostlake.org/index.php?/archives/19-Keeping- the-meaning-with-the-bytes.html) to allow extension/customization. Generally, yes. I haven't dived into the reflection-based layout or the Scala-related reflection stuff in 2.8 deeply enough to say that we could do a val-based Record implementation. Is there any reason (other than time constraints) to not update the Record framework to take advantage of the newer language features? Tim -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to 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: Why fields are declared as 'object' with Mapper/Record?
As i said before i'm not sure that i'm getting the whole picture and maybe my initial question is incorrect in its root. Still: Suppose i have a Person class declared with Mapper/Record and i want to reuse the class and all the code associated with it in another module/project. My first thought was to extend the Person class and override some of its fields by mixing in some additional traits (see my simplified example code in the initial message). But i noticed that inner objects cannot be overriden (its not obvious for me but i can get it if i dig it). So how do i reuse Mapper/Record based code if i need to extend/ customize the data structures? On Oct 6, 11:59 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Oct 6, 2009 at 9:50 AM, Oleg G. ojo...@gmail.com wrote: Thanks for all the answers and especially for David's clarification. It would be really cool to upgrade the 'keeping the meaning with the bytes' thing (http://blog.lostlake.org/index.php?/archives/19-Keeping- the-meaning-with-the-bytes.html) to allow extension/customization. What kind of extensions/customizations? MappedXXX can all be subclassed, extended and customized. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
