[Lift] Re: About the performance
Thanks David. I think lift can give me what I want. There is no doubt on it now. All the problem is can I master it enough. Thanks for all your words. On Dec 13, 3:12 am, David Pollak wrote: > Folks, > > In order to properly benchmark a Lift app and to get maximum performance: > > - Run in production mode. Templates and other things are aggressively > cached in production mode. > - Explicitly declare all of your snippets rather than requiring lookup > via reflection. > - If you are using a template created via the basic archetype, you are > doing at least 1 DB round trip for each request as part of the transaction > wrapper. There are ways around this. > - Before starting your benchmark, load every page in the benchmark at > least 50,000 times. This gets HotSpot warmed up. > > I would suggest benchmarking based on traffic and load... can your site > serve the number of pages/sec that you expect at peak load? That's a more > realistic benchmark than the number of ms it takes to serve a given page. > > Thanks, > > David > > On Sat, Dec 12, 2009 at 8:28 AM, Timothy Perrett > wrote: > > > > > Personally, I think it would be better if you took a step back and look t > > *your* use case. Why do you need this speed, in what areas do you need it? > > (page serving, dispatching etc) > > > If you better outline what you want, then we can advise on realistic > > expectations. > > > Cheers, Tim > > > On 12 Dec 2009, at 16:10, James Black wrote: > > > > On Sat, Dec 12, 2009 at 5:12 AM, daiwhea wrote: > > > I just have a test with some example lift apps. But I'm sorry to say > > > that I cannot achieve this high performance on my dev box(Dell xps > > > 420, 6 G RAM, Quad CPU) > > > > my env is Ubuntu 8.10. > > > java version "1.6.0_14" > > > Java(TM) SE Runtime Environment (build 1.6.0_14-b08) > > > Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode) > > > > with the latest : lift-archetype-jpa-basic > > > -DarchetypeArtifactId=lift-archetype-jpa-basic \ > > > -DarchetypeVersion=1.1-M7 > > > > I haven't tried to get it as fast as I can, but the jpa project goes to > > the database, so you may want to use lift-archetype-basic. > > > > Also, the first time you load it there may be a slow down due to > > initializations, so to get a good test you may want to write a unit test > > that will load it perhaps 100 times and then you can get the average, > > fastest and slowest times to get an idea how it is performing. > > > > Also, you may need to subtract any javascript/css files, or, when you > > compare to PHP make certain you have similar files being loaded for PHP for > > a true comparison. > > > > -- > > > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > > To post to this group, send email to lift...@googlegroups.com. > > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com > > . > > > For more options, visit this group at > >http://groups.google.com/group/liftweb?hl=en. > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to lift...@googlegroups.com. > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com > > . > > For more options, visit this group at > >http://groups.google.com/group/liftweb?hl=en. > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: About the performance
In fact, what I need is just page serving. But the visiting is not averaged, that's the key reason we wish at least the index page should be responsed less than 10Milliseconds. I just take a ab test with "ab -kc 100 -n 1 http://localhost:9090/authors/list";, seems it outpaced what I want. Maybe we can switch to lift completely. ^_^ Thanks. Document Path: /authors/list Document Length:3607 bytes Concurrency Level: 100 Time taken for tests: 44.055 seconds Complete requests: 1 Failed requests:5056 (Connect: 0, Receive: 0, Length: 5056, Exceptions: 0) Write errors: 0 Keep-Alive requests:1 Total transferred: 39787048 bytes HTML transferred: 36122294 bytes Requests per second:226.99 [#/sec] (mean) Time per request: 440.550 [ms] (mean) Time per request: 4.406 [ms] (mean, across all concurrent requests) Transfer rate: 881.95 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect:00 0.5 0 6 Processing: 6 438 370.83852507 Waiting:0 438 370.83852507 Total: 6 438 370.83852507 Percentage of the requests served within a certain time (ms) 50%385 66%568 75%682 80%733 90%853 95%946 98% 1603 99% 1838 100% 2507 (longest request) On Dec 13, 12:28 am, Timothy Perrett wrote: > Personally, I think it would be better if you took a step back and look t > *your* use case. Why do you need this speed, in what areas do you need it? > (page serving, dispatching etc) > > If you better outline what you want, then we can advise on realistic > expectations. > > Cheers, Tim > > On 12 Dec 2009, at 16:10, James Black wrote: > > > > > On Sat, Dec 12, 2009 at 5:12 AM, daiwhea wrote: > > I just have a test with some example lift apps. But I'm sorry to say > > that I cannot achieve this high performance on my dev box(Dell xps > > 420, 6 G RAM, Quad CPU) > > > my env is Ubuntu 8.10. > > java version "1.6.0_14" > > Java(TM) SE Runtime Environment (build 1.6.0_14-b08) > > Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode) > > > with the latest : lift-archetype-jpa-basic > > -DarchetypeArtifactId=lift-archetype-jpa-basic \ > > -DarchetypeVersion=1.1-M7 > > > I haven't tried to get it as fast as I can, but the jpa project goes to > > the database, so you may want to use lift-archetype-basic. > > > Also, the first time you load it there may be a slow down due to > > initializations, so to get a good test you may want to write a unit test > > that will load it perhaps 100 times and then you can get the average, > > fastest and slowest times to get an idea how it is performing. > > > Also, you may need to subtract any javascript/css files, or, when you > > compare to PHP make certain you have similar files being loaded for PHP for > > a true comparison. > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to lift...@googlegroups.com. > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: About the performance
Thanks, we use ab test for our php pages. Do you mean write a unit test by myself? I'm sorry I don't know Scala or lift well. Is there an example test for this kink of benchmark? Thanks. On Dec 13, 12:10 am, James Black wrote: > On Sat, Dec 12, 2009 at 5:12 AM, daiwhea wrote: > > I just have a test with some example lift apps. But I'm sorry to say > > that I cannot achieve this high performance on my dev box(Dell xps > > 420, 6 G RAM, Quad CPU) > > > my env is Ubuntu 8.10. > > java version "1.6.0_14" > > Java(TM) SE Runtime Environment (build 1.6.0_14-b08) > > Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode) > > > with the latest : lift-archetype-jpa-basic > > -DarchetypeArtifactId=lift-archetype-jpa-basic \ > > -DarchetypeVersion=1.1-M7 > > I haven't tried to get it as fast as I can, but the jpa project goes to > the database, so you may want to use lift-archetype-basic. > > Also, the first time you load it there may be a slow down due to > initializations, so to get a good test you may want to write a unit test > that will load it perhaps 100 times and then you can get the average, > fastest and slowest times to get an idea how it is performing. > > Also, you may need to subtract any javascript/css files, or, when you > compare to PHP make certain you have similar files being loaded for PHP for > a true comparison. -- 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] Feature Request: Header offset in lift-textile
It'd be nice to have a header-offset feature in lift-textile. That is, if header_offset=1 gets passed in as an argument, h1. => h2. => etc. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: MappedField Callback(s)
Why not just subclass the get/set methods on the MappedField and do the callbacks there? On Fri, Dec 11, 2009 at 3:02 PM, Timothy Perrett wrote: > Peter, > > Have you any code on a branch or similar? I think this conversation > will progress best with code samples. > > Cheers, Tim > > On Dec 11, 7:18 pm, Peter Robinett wrote: > > MetaMapper has a bunch of nice callback methods (afterCreate, > > beforeValidation, etc) that you can hook into. Recently I've found > > myself wanting one on MappedField so I can do something when its value > > changes. I could call a method myself right next to every time I > > update a value but a callback is more generic. Is this a reasonable > > idea? Would this be something people would like contributed back into > > Lift? Are there any other callbacks on MappedField that would be > > useful? > > > > Peter > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] About the performance
Folks, In order to properly benchmark a Lift app and to get maximum performance: - Run in production mode. Templates and other things are aggressively cached in production mode. - Explicitly declare all of your snippets rather than requiring lookup via reflection. - If you are using a template created via the basic archetype, you are doing at least 1 DB round trip for each request as part of the transaction wrapper. There are ways around this. - Before starting your benchmark, load every page in the benchmark at least 50,000 times. This gets HotSpot warmed up. I would suggest benchmarking based on traffic and load... can your site serve the number of pages/sec that you expect at peak load? That's a more realistic benchmark than the number of ms it takes to serve a given page. Thanks, David On Sat, Dec 12, 2009 at 8:28 AM, Timothy Perrett wrote: > Personally, I think it would be better if you took a step back and look t > *your* use case. Why do you need this speed, in what areas do you need it? > (page serving, dispatching etc) > > If you better outline what you want, then we can advise on realistic > expectations. > > Cheers, Tim > > On 12 Dec 2009, at 16:10, James Black wrote: > > > > > > > On Sat, Dec 12, 2009 at 5:12 AM, daiwhea wrote: > > I just have a test with some example lift apps. But I'm sorry to say > > that I cannot achieve this high performance on my dev box(Dell xps > > 420, 6 G RAM, Quad CPU) > > > > my env is Ubuntu 8.10. > > java version "1.6.0_14" > > Java(TM) SE Runtime Environment (build 1.6.0_14-b08) > > Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode) > > > > with the latest : lift-archetype-jpa-basic > > -DarchetypeArtifactId=lift-archetype-jpa-basic \ > > -DarchetypeVersion=1.1-M7 > > > > > > I haven't tried to get it as fast as I can, but the jpa project goes to > the database, so you may want to use lift-archetype-basic. > > > > Also, the first time you load it there may be a slow down due to > initializations, so to get a good test you may want to write a unit test > that will load it perhaps 100 times and then you can get the average, > fastest and slowest times to get an idea how it is performing. > > > > Also, you may need to subtract any javascript/css files, or, when you > compare to PHP make certain you have similar files being loaded for PHP for > a true comparison. > > > > -- > > > > You received this message because you are subscribed to the Google Groups > "Lift" group. > > To post to this group, send email to lift...@googlegroups.com. > > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Scala to JavaScript DSL ...
That is certainly one way to go but personally I'm not at all a fan of
this string literals approach,. For instance if Scala would not have
had built in XML support using XML as string literals Lift would
probably loose some of its attractions... but that's my opinion.
Furthermore a DSL like language allows better compositionality than
concatenating strings when we want to iteratively add JS code ... for
instance calling the same function multiple times with different
arguments, or collecting code fragments generated by different
application components etc.
Also it seems to me that your approach (somehow similar with
Velocity's) is more expensive but I admit that this is not at all a
strong argument because we're talking about small javascript fragments
so the delta is negligible.
Br's,
Marius
On Dec 12, 8:42 pm, Alex Boisvert wrote:
> Personally, I would rather go with a JavaScript literal and a simple
> templating mechanism for substitution/binding of Javascript literals + Json
> objects that would drive dynamic code (if conditionals, for-loops, ...).
>
> Taking your example,
>
> def myFunc = {"""
> function myFunc( param1, param2 ) {
> if (param1 < ${limit}) {
> var home = ( ${max} - 3 ) / 2;
> var someArray = ${array};
> myFunc(1, 2, "do it", home);
> $("#myID").attr("value", "123");
> }
> for (var i in ${someArray}) {
> console.log("Hi there " + i);
> }
> function ( arg1, arg2 ) {
> alert("Anonymous function " + arg1 + arg2)
> }(1, 2);
> }""".jsBind(
> "max" -> max,
> "array" -> array,
> "someArray" -> someArray,
> ...
> )
>
> Not a fully fleshed out example but you get the idea. You'd still be able
> to bind existing JsExp/JsCmds so some parts could still be abstracted and
> typed checked.
>
> I would find this more readable and simpler that learning a quirky DSL
> syntax. And I could still copy/paste Javascript code to/from the browser
> and test it easily.
>
> alex
>
> On Sat, Dec 12, 2009 at 2:07 AM, Marius Danciu wrote:
>
> > All,
>
> > I just want to see if there is any interest in the approach discussed here.
> > As you know Lift has some interesting support for building JavaScript
> > constructs from Scala code usig JsExp, JsCmd etc classes. I used quite a lot
> > this support and it's great but if your JS code that you want to send down
> > to the browser (say as an Ajax or Comet partial update response) gets a bit
> > more complicated then constructing the JS fragment leads IMO to some
> > cumbersome Scala code. I found myselft in quite a few situation to use JsRaw
> > to write the JavaScript fragment in order for the code reader to understand
> > what JavaScript code will be generated. But of course with JsRaw we put
> > everything into a String so I'm not a big fan of this approach. So I started
> > to define a JavaScript like "DSL" that IMO is closer to JavaScript form.
> > Attached is a source code smaple of how this looks like, so for instance we
> > can have something like:
>
> > val js = JsFunc('myFunc, 'param1, 'param2) {
> > JsIf('param1 __< 30) {
> > Var('home) := Wrap(234 __- 3) __/ 2 `;`
> > Var('someArray) := JsArray(1, 2, 3, 4, 5) `;`
> > 'myFunc(1, 2, "do it", 'home) `;`
> > $("#myID") >> 'attr("value", "123") `;`
> > } ~
> > JsForEach(Var('i) in 'someArray) {
> > 'console >> 'log("Hi there " __+ 'i) `;`
> > } ~
> > JsAnonFunc('arg1, 'arg2) {
> > 'alert("Anonymous function " __+ 'arg1 __+ 'arg2)
> > }(1, 2) `;`
> > }
>
> > println(js.toJs)
>
> > this yields the following JavaScript code:
>
> > function myFunc( param1, param2 ) {
> > if (param1 < 30) {
> > var home = ( 234 - 3 ) / 2;
> > var someArray = [ 1, 2, 3, 4, 5 ];
> > myFunc(1, 2, "do it", home);
> > $("#myID").attr("value", "123");
> > }
> > for (var i in someArray) {
> > console.log("Hi there " + i);
> > }
> > function ( arg1, arg2 ) {
> > alert("Anonymous function " + arg1 + arg2)
> > }(1, 2);
> > }
>
> > ... ok I just droped nonsense code in there for exemplification. A few
> > words:
>
> > 1. JsIf, JsForEach describe JavaScript if and for(each) statements
> > 2. Functions like __<, __>, ... __+, __- are function that alows definition
> > of boolean and/or algebraic expressions.
> > 3. Wrap just wraps an expression into ()
> > 4. Var defined a variable
> > 5 := defines an assignment
> > 6. JsFunc declares a JS function
> > 7. JsAnonFunc declares an anonymous function
> > 8. 'myFunc(1, 2, "do it", 'home) is simply a javascript function
> > invocation by providing 4 parameter.
> > 9. ~ is just a function that chains statements that don;t necessarily end
> > in ;
>
> > Do you think that something like this would be usable in Lift?
>
> > Br's,
> > Marius
>
> > --
> > 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 fr
Re: [Lift] Scala to JavaScript DSL ...
Personally, I would rather go with a JavaScript literal and a simple
templating mechanism for substitution/binding of Javascript literals + Json
objects that would drive dynamic code (if conditionals, for-loops, ...).
Taking your example,
def myFunc = {"""
function myFunc( param1, param2 ) {
if (param1 < ${limit}) {
var home = ( ${max} - 3 ) / 2;
var someArray = ${array};
myFunc(1, 2, "do it", home);
$("#myID").attr("value", "123");
}
for (var i in ${someArray}) {
console.log("Hi there " + i);
}
function ( arg1, arg2 ) {
alert("Anonymous function " + arg1 + arg2)
}(1, 2);
}""".jsBind(
"max" -> max,
"array" -> array,
"someArray" -> someArray,
...
)
Not a fully fleshed out example but you get the idea. You'd still be able
to bind existing JsExp/JsCmds so some parts could still be abstracted and
typed checked.
I would find this more readable and simpler that learning a quirky DSL
syntax. And I could still copy/paste Javascript code to/from the browser
and test it easily.
alex
On Sat, Dec 12, 2009 at 2:07 AM, Marius Danciu wrote:
> All,
>
> I just want to see if there is any interest in the approach discussed here.
> As you know Lift has some interesting support for building JavaScript
> constructs from Scala code usig JsExp, JsCmd etc classes. I used quite a lot
> this support and it's great but if your JS code that you want to send down
> to the browser (say as an Ajax or Comet partial update response) gets a bit
> more complicated then constructing the JS fragment leads IMO to some
> cumbersome Scala code. I found myselft in quite a few situation to use JsRaw
> to write the JavaScript fragment in order for the code reader to understand
> what JavaScript code will be generated. But of course with JsRaw we put
> everything into a String so I'm not a big fan of this approach. So I started
> to define a JavaScript like "DSL" that IMO is closer to JavaScript form.
> Attached is a source code smaple of how this looks like, so for instance we
> can have something like:
>
>
> val js = JsFunc('myFunc, 'param1, 'param2) {
> JsIf('param1 __< 30) {
> Var('home) := Wrap(234 __- 3) __/ 2 `;`
> Var('someArray) := JsArray(1, 2, 3, 4, 5) `;`
> 'myFunc(1, 2, "do it", 'home) `;`
> $("#myID") >> 'attr("value", "123") `;`
> } ~
> JsForEach(Var('i) in 'someArray) {
> 'console >> 'log("Hi there " __+ 'i) `;`
> } ~
> JsAnonFunc('arg1, 'arg2) {
>'alert("Anonymous function " __+ 'arg1 __+ 'arg2)
> }(1, 2) `;`
> }
>
> println(js.toJs)
>
> this yields the following JavaScript code:
>
>
> function myFunc( param1, param2 ) {
> if (param1 < 30) {
> var home = ( 234 - 3 ) / 2;
> var someArray = [ 1, 2, 3, 4, 5 ];
> myFunc(1, 2, "do it", home);
> $("#myID").attr("value", "123");
> }
> for (var i in someArray) {
> console.log("Hi there " + i);
> }
> function ( arg1, arg2 ) {
> alert("Anonymous function " + arg1 + arg2)
> }(1, 2);
> }
>
>
> ... ok I just droped nonsense code in there for exemplification. A few
> words:
>
> 1. JsIf, JsForEach describe JavaScript if and for(each) statements
> 2. Functions like __<, __>, ... __+, __- are function that alows definition
> of boolean and/or algebraic expressions.
> 3. Wrap just wraps an expression into ()
> 4. Var defined a variable
> 5 := defines an assignment
> 6. JsFunc declares a JS function
> 7. JsAnonFunc declares an anonymous function
> 8. 'myFunc(1, 2, "do it", 'home) is simply a javascript function
> invocation by providing 4 parameter.
> 9. ~ is just a function that chains statements that don;t necessarily end
> in ;
>
>
> Do you think that something like this would be usable in Lift?
>
> Br's,
> Marius
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Scala to JavaScript DSL ...
I agree. Although to be more specific I guess my proposal can be split
in 2:
1. The syntax style proposed that would probably evolve depending on
the feedback.
2. The existence of lift-js project.
Br's,
Marius
On Dec 12, 6:44 pm, Indrajit Raychaudhuri wrote:
> On 12/12/09 4:39 PM, Marius wrote:
>
>
>
> > My notes inline.
>
> > On Dec 12, 12:34 pm, Timothy Perrett wrote:
> >> Hey Marius,
>
> >> Within this DSL will you be using JsObj under the hood or lift-json?
>
> > I was thinking to use lift-json in this case ... but I'd also of
> > prefer having a lift-js project.
>
> >> I would be very reluctant about adding new things to lift that don't
> >> unify our Js and JSON libs.
>
> > Depends what you mean by unify. lift-json is not the same with js
> > support, js should utilize lift-json to build json constructs being
> > part of the javascript generated but lift-json has nothing to to with
> > a potential lift-js project. Therefore I would keep lift-json and lift-
> > js separated and have lift-js utilize lift-json whenever possible.
>
> I would be hugely in favor of lift-js. I see lift-json deal with the
> data container related functionality. This would be clearly demarcated
> from lift-js (the scripting, method calls etc.) that is primarily used
> for deeper framework level integration for building (mostly web)
> applications.
>
> In that sense, lift-webkit could also shed some weight in favor of
> lift-js (parts of net.liftweb.http.js, for example). On one hand we
> would have a neatly composed package with focused purpose and on the
> other hand lift-webkit would feel 'lighter' to projects that don't need
> any of the js functionality at all.
>
> The dependency tree could look like (lower components depend on one or
> more above them):
>
> lift-common
> lift-actor [1]
> lift-json [1]
> lift-util [2]
> lift-js [2]
> lift-webkit [3]
>
> [1] Independent of each other currently.
> [2] Can interchange depending on how things go.
> [3] In some sense lift-webkit still ends up depending on lift-js
> transitively. But that's better than 2.7M monolith :) It can even create
> opportunity for marking lift-js as 'optional dependency' for lift-webkit.
>
> In any case, this is a derived profit and doesn't have to be the primary
> goal.
>
>
>
> >> On this note, will this unification take place before 2.0?
>
> > Too soon to tell. I'm not sure yet if people like this proposal so we
> > first need acceptance and then talk schedules.
>
> >> Cheers, Tim
>
> >> Sent from my iPhone
>
> >> On 12 Dec 2009, at 10:07, Marius Danciu wrote:
>
> >>> All,
>
> >>> I just want to see if there is any interest in the approach
> >>> discussed here. As you know Lift has some interesting support for
> >>> building JavaScript constructs from Scala code usig JsExp, JsCmd etc
> >>> classes. I used quite a lot this support and it's great but if your
> >>> JS code that you want to send down to the browser (say as an Ajax or
> >>> Comet partial update response) gets a bit more complicated then
> >>> constructing the JS fragment leads IMO to some cumbersome Scala
> >>> code. I found myselft in quite a few situation to use JsRaw to write
> >>> the JavaScript fragment in order for the code reader to understand
> >>> what JavaScript code will be generated. But of course with JsRaw we
> >>> put everything into a String so I'm not a big fan of this approach.
> >>> So I started to define a JavaScript like "DSL" that IMO is closer to
> >>> JavaScript form. Attached is a source code smaple of how this looks
> >>> like, so for instance we can have something like:
>
> >>> val js = JsFunc('myFunc, 'param1, 'param2) {
> >>> JsIf('param1 __< 30) {
> >>> Var('home) := Wrap(234 __- 3) __/ 2 `;`
> >>> Var('someArray) := JsArray(1, 2, 3, 4, 5) `;`
> >>> 'myFunc(1, 2, "do it", 'home) `;`
> >>> $("#myID")>> 'attr("value", "123") `;`
> >>> } ~
> >>> JsForEach(Var('i) in 'someArray) {
> >>> 'console>> 'log("Hi there " __+ 'i) `;`
> >>> } ~
> >>> JsAnonFunc('arg1, 'arg2) {
> >>> 'alert("Anonymous function " __+ 'arg1 __+ 'arg2)
> >>> }(1, 2) `;`
> >>> }
>
> >>> println(js.toJs)
>
> >>> this yields the following JavaScript code:
>
> >>> function myFunc( param1, param2 ) {
> >>> if (param1< 30) {
> >>> var home = ( 234 - 3 ) / 2;
> >>> var someArray = [ 1, 2, 3, 4, 5 ];
> >>> myFunc(1, 2, "do it", home);
> >>> $("#myID").attr("value", "123");
> >>> }
> >>> for (var i in someArray) {
> >>> console.log("Hi there " + i);
> >>> }
> >>> function ( arg1, arg2 ) {
> >>> alert("Anonymous function " + arg1 + arg2)
> >>> }(1, 2);
> >>> }
>
> >>> ... ok I just droped nonsense code in there for exemplification. A
> >>> few words:
>
> >>> 1. JsIf, JsForEach describe JavaScript if and for(each) statements
> >>> 2. Functions like __<, __>, ... __+, __- are function that alows
> >>> definition of boolean and/or algebraic expressions.
> >>> 3. Wrap just wraps an expression int
[Lift] Re: MappedField Callback(s)
Not yet, I was planning on working on it next week. Peter On Dec 11, 3:02 pm, Timothy Perrett wrote: > Peter, > > Have you any code on a branch or similar? I think this conversation > will progress best with code samples. > > Cheers, Tim > > On Dec 11, 7:18 pm, Peter Robinett wrote: > > > > > MetaMapper has a bunch of nice callback methods (afterCreate, > > beforeValidation, etc) that you can hook into. Recently I've found > > myself wanting one on MappedField so I can do something when its value > > changes. I could call a method myself right next to every time I > > update a value but a callback is more generic. Is this a reasonable > > idea? Would this be something people would like contributed back into > > Lift? Are there any other callbacks on MappedField that would be > > useful? > > > Peter -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Scala to JavaScript DSL ...
On 12/12/09 4:39 PM, Marius wrote:
> My notes inline.
>
> On Dec 12, 12:34 pm, Timothy Perrett wrote:
>> Hey Marius,
>>
>> Within this DSL will you be using JsObj under the hood or lift-json?
>
> I was thinking to use lift-json in this case ... but I'd also of
> prefer having a lift-js project.
>
>>
>> I would be very reluctant about adding new things to lift that don't
>> unify our Js and JSON libs.
>
> Depends what you mean by unify. lift-json is not the same with js
> support, js should utilize lift-json to build json constructs being
> part of the javascript generated but lift-json has nothing to to with
> a potential lift-js project. Therefore I would keep lift-json and lift-
> js separated and have lift-js utilize lift-json whenever possible.
I would be hugely in favor of lift-js. I see lift-json deal with the
data container related functionality. This would be clearly demarcated
from lift-js (the scripting, method calls etc.) that is primarily used
for deeper framework level integration for building (mostly web)
applications.
In that sense, lift-webkit could also shed some weight in favor of
lift-js (parts of net.liftweb.http.js, for example). On one hand we
would have a neatly composed package with focused purpose and on the
other hand lift-webkit would feel 'lighter' to projects that don't need
any of the js functionality at all.
The dependency tree could look like (lower components depend on one or
more above them):
lift-common
lift-actor [1]
lift-json [1]
lift-util [2]
lift-js [2]
lift-webkit [3]
[1] Independent of each other currently.
[2] Can interchange depending on how things go.
[3] In some sense lift-webkit still ends up depending on lift-js
transitively. But that's better than 2.7M monolith :) It can even create
opportunity for marking lift-js as 'optional dependency' for lift-webkit.
In any case, this is a derived profit and doesn't have to be the primary
goal.
>
>>
>> On this note, will this unification take place before 2.0?
>
> Too soon to tell. I'm not sure yet if people like this proposal so we
> first need acceptance and then talk schedules.
>
>>
>> Cheers, Tim
>>
>> Sent from my iPhone
>>
>> On 12 Dec 2009, at 10:07, Marius Danciu wrote:
>>
>>> All,
>>
>>> I just want to see if there is any interest in the approach
>>> discussed here. As you know Lift has some interesting support for
>>> building JavaScript constructs from Scala code usig JsExp, JsCmd etc
>>> classes. I used quite a lot this support and it's great but if your
>>> JS code that you want to send down to the browser (say as an Ajax or
>>> Comet partial update response) gets a bit more complicated then
>>> constructing the JS fragment leads IMO to some cumbersome Scala
>>> code. I found myselft in quite a few situation to use JsRaw to write
>>> the JavaScript fragment in order for the code reader to understand
>>> what JavaScript code will be generated. But of course with JsRaw we
>>> put everything into a String so I'm not a big fan of this approach.
>>> So I started to define a JavaScript like "DSL" that IMO is closer to
>>> JavaScript form. Attached is a source code smaple of how this looks
>>> like, so for instance we can have something like:
>>
>>> val js = JsFunc('myFunc, 'param1, 'param2) {
>>> JsIf('param1 __< 30) {
>>> Var('home) := Wrap(234 __- 3) __/ 2 `;`
>>> Var('someArray) := JsArray(1, 2, 3, 4, 5) `;`
>>> 'myFunc(1, 2, "do it", 'home) `;`
>>> $("#myID")>> 'attr("value", "123") `;`
>>>} ~
>>>JsForEach(Var('i) in 'someArray) {
>>> 'console>> 'log("Hi there " __+ 'i) `;`
>>>} ~
>>>JsAnonFunc('arg1, 'arg2) {
>>> 'alert("Anonymous function " __+ 'arg1 __+ 'arg2)
>>>}(1, 2) `;`
>>> }
>>
>>> println(js.toJs)
>>
>>> this yields the following JavaScript code:
>>
>>> function myFunc( param1, param2 ) {
>>> if (param1< 30) {
>>> var home = ( 234 - 3 ) / 2;
>>> var someArray = [ 1, 2, 3, 4, 5 ];
>>> myFunc(1, 2, "do it", home);
>>> $("#myID").attr("value", "123");
>>> }
>>> for (var i in someArray) {
>>> console.log("Hi there " + i);
>>> }
>>> function ( arg1, arg2 ) {
>>> alert("Anonymous function " + arg1 + arg2)
>>> }(1, 2);
>>> }
>>
>>> ... ok I just droped nonsense code in there for exemplification. A
>>> few words:
>>
>>> 1. JsIf, JsForEach describe JavaScript if and for(each) statements
>>> 2. Functions like __<, __>, ... __+, __- are function that alows
>>> definition of boolean and/or algebraic expressions.
>>> 3. Wrap just wraps an expression into ()
>>> 4. Var defined a variable
>>> 5 := defines an assignment
>>> 6. JsFunc declares a JS function
>>> 7. JsAnonFunc declares an anonymous function
>>> 8. 'myFunc(1, 2, "do it", 'home) is simply a javascript function
>>> invocation by providing 4 parameter.
>>> 9. ~ is just a function that chains statements that don;t
>>> necessarily end in ;
>>
>>> Do you think that something like this would be usable in Lift?
>>
>>> Br's,
>>>
Re: [Lift] Re: (Maven problem?) Char encoding problem using S.?
On 12/12/09 4:11 PM, Jeppe Nejsum Madsen wrote: > Indrajit Raychaudhuri writes: > >> On 11/12/09 5:28 PM, Jeppe Nejsum Madsen wrote: >>> Jean-Adrien writes: >>> >>> >>> [...] >>> >>> I have the same issues with the localized properties >>> = Conclusion = The problem here comes from my initial configuration. But in my sense it is not a good idea to store i18n data in another format than UTF-8. >>> >>> Agreed >> >> However, for minimum grief I always use unicode escaping (using \u) in >> locale properties. > > But it is not really an option (I think) to edit files like > this. Sure, for one off changes it's possible, but for an entire > application that needs to be translated into several locales I don't > think this is feasible. Agreed on the inconvenience factor. But not relying on the actual encoding of the file and using \u is what worked most reliably for me (fully localized web applications supporting 10+ languages). FWIW, PropertyResourceBundle uses properties.load(InputStream) which assumes ISO-8859-1 (Latin1) encoded stream. In Java 6, however, you have properties.load(Reader) which does not have this limitation. > >> >> The output of "native2ascii src/main/resources/translate_fr.properties" >> should interest you :) > > I know about this tool, but this means an extra step in the build > process and it's not really supported by IDE's. All in all making the > turnaround time longer... Some build plugin exists: Ant: http://ant.apache.org/manual/OptionalTasks/native2ascii.html Maven MOJO: http://mojo.codehaus.org/native2ascii-maven-plugin/ (as Tim already mentioned) Maven (via antrun): http://docs.codehaus.org/display/MAVENUSER/Maven+and+native2ascii IntelliJ IDEA has first class support for this. Not sure about other IDE support but looks like quite a few exist for Eclipse as well. (I haven't used Eclipse or Netbeans for quite sometime now.) > >> You don't have to use the xml format really. Just escape the characters >> with unicode encoding (\u) and you should be covered. > > See above :-) > > > /Jeppe > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] About the performance
Personally, I think it would be better if you took a step back and look t *your* use case. Why do you need this speed, in what areas do you need it? (page serving, dispatching etc) If you better outline what you want, then we can advise on realistic expectations. Cheers, Tim On 12 Dec 2009, at 16:10, James Black wrote: > > > On Sat, Dec 12, 2009 at 5:12 AM, daiwhea wrote: > I just have a test with some example lift apps. But I'm sorry to say > that I cannot achieve this high performance on my dev box(Dell xps > 420, 6 G RAM, Quad CPU) > > my env is Ubuntu 8.10. > java version "1.6.0_14" > Java(TM) SE Runtime Environment (build 1.6.0_14-b08) > Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode) > > with the latest : lift-archetype-jpa-basic > -DarchetypeArtifactId=lift-archetype-jpa-basic \ > -DarchetypeVersion=1.1-M7 > > > I haven't tried to get it as fast as I can, but the jpa project goes to the > database, so you may want to use lift-archetype-basic. > > Also, the first time you load it there may be a slow down due to > initializations, so to get a good test you may want to write a unit test that > will load it perhaps 100 times and then you can get the average, fastest and > slowest times to get an idea how it is performing. > > Also, you may need to subtract any javascript/css files, or, when you > compare to PHP make certain you have similar files being loaded for PHP for a > true comparison. > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] About the performance
On Sat, Dec 12, 2009 at 5:12 AM, daiwhea wrote: > I just have a test with some example lift apps. But I'm sorry to say > that I cannot achieve this high performance on my dev box(Dell xps > 420, 6 G RAM, Quad CPU) > > my env is Ubuntu 8.10. > java version "1.6.0_14" > Java(TM) SE Runtime Environment (build 1.6.0_14-b08) > Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode) > > with the latest : lift-archetype-jpa-basic > -DarchetypeArtifactId=lift-archetype-jpa-basic \ > -DarchetypeVersion=1.1-M7 > > I haven't tried to get it as fast as I can, but the jpa project goes to the database, so you may want to use lift-archetype-basic. Also, the first time you load it there may be a slow down due to initializations, so to get a good test you may want to write a unit test that will load it perhaps 100 times and then you can get the average, fastest and slowest times to get an idea how it is performing. Also, you may need to subtract any javascript/css files, or, when you compare to PHP make certain you have similar files being loaded for PHP for a true comparison. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] About the performance
I'm new to both Scala/Lift. I have worked with PHP for several years. I just want to choose a web framework with high performance and developing speed. I have seen "David Pollak" said at infoQ site that the lift framework has very high speed. It will just take 1 Milliseconds for page without db query. It seems what I'm looking for. I just have a test with some example lift apps. But I'm sorry to say that I cannot achieve this high performance on my dev box(Dell xps 420, 6 G RAM, Quad CPU) my env is Ubuntu 8.10. java version "1.6.0_14" Java(TM) SE Runtime Environment (build 1.6.0_14-b08) Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode) with the latest : lift-archetype-jpa-basic -DarchetypeArtifactId=lift-archetype-jpa-basic \ -DarchetypeVersion=1.1-M7 But even for the /index page without db query, I cannot get a response less than 10 Milliseconds. In fact it is: INFO - Service request (GET) /index took 22 Milliseconds I wondered that how can I get a response less than 10Milliseconds without db query. In fact, it's really easy to achieve this response speed without db query in PHP. I think Java take all the classes into memory, it should be faster than PHP. I just run the app via mvn jetty:run. And I also test to deploy it to a standalone jetty server. Seems it won't help a little. Is there any suggestions for the response speed? Thanks for you replies. ^_^ This is the home of lift lover. -- 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: Scala to JavaScript DSL ...
My notes inline.
On Dec 12, 12:34 pm, Timothy Perrett wrote:
> Hey Marius,
>
> Within this DSL will you be using JsObj under the hood or lift-json?
I was thinking to use lift-json in this case ... but I'd also of
prefer having a lift-js project.
>
> I would be very reluctant about adding new things to lift that don't
> unify our Js and JSON libs.
Depends what you mean by unify. lift-json is not the same with js
support, js should utilize lift-json to build json constructs being
part of the javascript generated but lift-json has nothing to to with
a potential lift-js project. Therefore I would keep lift-json and lift-
js separated and have lift-js utilize lift-json whenever possible.
>
> On this note, will this unification take place before 2.0?
Too soon to tell. I'm not sure yet if people like this proposal so we
first need acceptance and then talk schedules.
>
> Cheers, Tim
>
> Sent from my iPhone
>
> On 12 Dec 2009, at 10:07, Marius Danciu wrote:
>
> > All,
>
> > I just want to see if there is any interest in the approach
> > discussed here. As you know Lift has some interesting support for
> > building JavaScript constructs from Scala code usig JsExp, JsCmd etc
> > classes. I used quite a lot this support and it's great but if your
> > JS code that you want to send down to the browser (say as an Ajax or
> > Comet partial update response) gets a bit more complicated then
> > constructing the JS fragment leads IMO to some cumbersome Scala
> > code. I found myselft in quite a few situation to use JsRaw to write
> > the JavaScript fragment in order for the code reader to understand
> > what JavaScript code will be generated. But of course with JsRaw we
> > put everything into a String so I'm not a big fan of this approach.
> > So I started to define a JavaScript like "DSL" that IMO is closer to
> > JavaScript form. Attached is a source code smaple of how this looks
> > like, so for instance we can have something like:
>
> > val js = JsFunc('myFunc, 'param1, 'param2) {
> > JsIf('param1 __< 30) {
> > Var('home) := Wrap(234 __- 3) __/ 2 `;`
> > Var('someArray) := JsArray(1, 2, 3, 4, 5) `;`
> > 'myFunc(1, 2, "do it", 'home) `;`
> > $("#myID") >> 'attr("value", "123") `;`
> > } ~
> > JsForEach(Var('i) in 'someArray) {
> > 'console >> 'log("Hi there " __+ 'i) `;`
> > } ~
> > JsAnonFunc('arg1, 'arg2) {
> > 'alert("Anonymous function " __+ 'arg1 __+ 'arg2)
> > }(1, 2) `;`
> > }
>
> > println(js.toJs)
>
> > this yields the following JavaScript code:
>
> > function myFunc( param1, param2 ) {
> > if (param1 < 30) {
> > var home = ( 234 - 3 ) / 2;
> > var someArray = [ 1, 2, 3, 4, 5 ];
> > myFunc(1, 2, "do it", home);
> > $("#myID").attr("value", "123");
> > }
> > for (var i in someArray) {
> > console.log("Hi there " + i);
> > }
> > function ( arg1, arg2 ) {
> > alert("Anonymous function " + arg1 + arg2)
> > }(1, 2);
> > }
>
> > ... ok I just droped nonsense code in there for exemplification. A
> > few words:
>
> > 1. JsIf, JsForEach describe JavaScript if and for(each) statements
> > 2. Functions like __<, __>, ... __+, __- are function that alows
> > definition of boolean and/or algebraic expressions.
> > 3. Wrap just wraps an expression into ()
> > 4. Var defined a variable
> > 5 := defines an assignment
> > 6. JsFunc declares a JS function
> > 7. JsAnonFunc declares an anonymous function
> > 8. 'myFunc(1, 2, "do it", 'home) is simply a javascript function
> > invocation by providing 4 parameter.
> > 9. ~ is just a function that chains statements that don;t
> > necessarily end in ;
>
> > Do you think that something like this would be usable in Lift?
>
> > Br's,
> > Marius
> > --
>
> > You received this message because you are subscribed to the Google
> > Groups "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com
> > .
> > For more options, visit this group
> > athttp://groups.google.com/group/liftweb?hl=en
> > .
> >
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: (Maven problem?) Char encoding problem using S.?
Have you seen: http://mojo.codehaus.org/native2ascii-maven-plugin/ Looks like you could automate that into your build process, no? Cheers, Tim On 12 Dec 2009, at 10:41, Jeppe Nejsum Madsen wrote: > But it is not really an option (I think) to edit files like > this. Sure, for one off changes it's possible, but for an entire > application that needs to be translated into several locales I don't > think this is feasible. > >> >> The output of "native2ascii src/main/resources/translate_fr.properties" >> should interest you :) > > I know about this tool, but this means an extra step in the build > process and it's not really supported by IDE's. All in all making the > turnaround time longer... > >> You don't have to use the xml format really. Just escape the characters >> with unicode encoding (\u) and you should be covered. > > See above :-) -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: (Maven problem?) Char encoding problem using S.?
Indrajit Raychaudhuri writes: > On 11/12/09 5:28 PM, Jeppe Nejsum Madsen wrote: >> Jean-Adrien writes: >> >> >> [...] >> >> I have the same issues with the localized properties >> >>> = Conclusion = >>> >>> The problem here comes from my initial configuration. But in my sense >>> it is not a good idea to store i18n data in another format than UTF-8. >> >> Agreed > > However, for minimum grief I always use unicode escaping (using \u) in > locale properties. But it is not really an option (I think) to edit files like this. Sure, for one off changes it's possible, but for an entire application that needs to be translated into several locales I don't think this is feasible. > > The output of "native2ascii src/main/resources/translate_fr.properties" > should interest you :) I know about this tool, but this means an extra step in the build process and it's not really supported by IDE's. All in all making the turnaround time longer... > You don't have to use the xml format really. Just escape the characters > with unicode encoding (\u) and you should be covered. See above :-) /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Scala to JavaScript DSL ...
Hey Marius,
Within this DSL will you be using JsObj under the hood or lift-json?
I would be very reluctant about adding new things to lift that don't
unify our Js and JSON libs.
On this note, will this unification take place before 2.0?
Cheers, Tim
Sent from my iPhone
On 12 Dec 2009, at 10:07, Marius Danciu wrote:
> All,
>
> I just want to see if there is any interest in the approach
> discussed here. As you know Lift has some interesting support for
> building JavaScript constructs from Scala code usig JsExp, JsCmd etc
> classes. I used quite a lot this support and it's great but if your
> JS code that you want to send down to the browser (say as an Ajax or
> Comet partial update response) gets a bit more complicated then
> constructing the JS fragment leads IMO to some cumbersome Scala
> code. I found myselft in quite a few situation to use JsRaw to write
> the JavaScript fragment in order for the code reader to understand
> what JavaScript code will be generated. But of course with JsRaw we
> put everything into a String so I'm not a big fan of this approach.
> So I started to define a JavaScript like "DSL" that IMO is closer to
> JavaScript form. Attached is a source code smaple of how this looks
> like, so for instance we can have something like:
>
>
> val js = JsFunc('myFunc, 'param1, 'param2) {
> JsIf('param1 __< 30) {
> Var('home) := Wrap(234 __- 3) __/ 2 `;`
> Var('someArray) := JsArray(1, 2, 3, 4, 5) `;`
> 'myFunc(1, 2, "do it", 'home) `;`
> $("#myID") >> 'attr("value", "123") `;`
> } ~
> JsForEach(Var('i) in 'someArray) {
> 'console >> 'log("Hi there " __+ 'i) `;`
> } ~
> JsAnonFunc('arg1, 'arg2) {
>'alert("Anonymous function " __+ 'arg1 __+ 'arg2)
> }(1, 2) `;`
> }
>
> println(js.toJs)
>
> this yields the following JavaScript code:
>
>
> function myFunc( param1, param2 ) {
> if (param1 < 30) {
> var home = ( 234 - 3 ) / 2;
> var someArray = [ 1, 2, 3, 4, 5 ];
> myFunc(1, 2, "do it", home);
> $("#myID").attr("value", "123");
> }
> for (var i in someArray) {
> console.log("Hi there " + i);
> }
> function ( arg1, arg2 ) {
> alert("Anonymous function " + arg1 + arg2)
> }(1, 2);
> }
>
>
> ... ok I just droped nonsense code in there for exemplification. A
> few words:
>
> 1. JsIf, JsForEach describe JavaScript if and for(each) statements
> 2. Functions like __<, __>, ... __+, __- are function that alows
> definition of boolean and/or algebraic expressions.
> 3. Wrap just wraps an expression into ()
> 4. Var defined a variable
> 5 := defines an assignment
> 6. JsFunc declares a JS function
> 7. JsAnonFunc declares an anonymous function
> 8. 'myFunc(1, 2, "do it", 'home) is simply a javascript function
> invocation by providing 4 parameter.
> 9. ~ is just a function that chains statements that don;t
> necessarily end in ;
>
>
> Do you think that something like this would be usable in Lift?
>
> Br's,
> Marius
> --
>
> You received this message because you are subscribed to the Google
> Groups "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en
> .
>
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Strange Mapper behaviour
David Pollak writes: [...] >> I did some digging and it seem an exception is being swallowed at line >> 984 in MetaMapper.scala. So if some code in a mapped field throws during >> boot, it is not included in the mappedFieldList. >> >> So I suggest just logging a warning here. Now that I know that instances >> are created during boot, I can work around it... >> > > Actually, I'm going to add the warning to S.redirect Using it outside of an > HTTP request is a less than optimal design and flagging that will achieve > the larger goal. > > In terms of your code, this is a really bad mix of view and model. Just > sayin' If you mean the fact that a redirect can happen in the data layer, I agree completely :-) If something else, please explain, always happy to improve the design. But note that the underlying issue (that certain fields end up not being considered by Mapper at all if an exception is thrown in some of the fields) still exists. Are there any legitimate exceptions catched here that would cause confusion if a warning was logged in this case? /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Scala to JavaScript DSL ...
All,
I just want to see if there is any interest in the approach discussed here.
As you know Lift has some interesting support for building JavaScript
constructs from Scala code usig JsExp, JsCmd etc classes. I used quite a lot
this support and it's great but if your JS code that you want to send down
to the browser (say as an Ajax or Comet partial update response) gets a bit
more complicated then constructing the JS fragment leads IMO to some
cumbersome Scala code. I found myselft in quite a few situation to use JsRaw
to write the JavaScript fragment in order for the code reader to understand
what JavaScript code will be generated. But of course with JsRaw we put
everything into a String so I'm not a big fan of this approach. So I started
to define a JavaScript like "DSL" that IMO is closer to JavaScript form.
Attached is a source code smaple of how this looks like, so for instance we
can have something like:
val js = JsFunc('myFunc, 'param1, 'param2) {
JsIf('param1 __< 30) {
Var('home) := Wrap(234 __- 3) __/ 2 `;`
Var('someArray) := JsArray(1, 2, 3, 4, 5) `;`
'myFunc(1, 2, "do it", 'home) `;`
$("#myID") >> 'attr("value", "123") `;`
} ~
JsForEach(Var('i) in 'someArray) {
'console >> 'log("Hi there " __+ 'i) `;`
} ~
JsAnonFunc('arg1, 'arg2) {
'alert("Anonymous function " __+ 'arg1 __+ 'arg2)
}(1, 2) `;`
}
println(js.toJs)
this yields the following JavaScript code:
function myFunc( param1, param2 ) {
if (param1 < 30) {
var home = ( 234 - 3 ) / 2;
var someArray = [ 1, 2, 3, 4, 5 ];
myFunc(1, 2, "do it", home);
$("#myID").attr("value", "123");
}
for (var i in someArray) {
console.log("Hi there " + i);
}
function ( arg1, arg2 ) {
alert("Anonymous function " + arg1 + arg2)
}(1, 2);
}
... ok I just droped nonsense code in there for exemplification. A few
words:
1. JsIf, JsForEach describe JavaScript if and for(each) statements
2. Functions like __<, __>, ... __+, __- are function that alows definition
of boolean and/or algebraic expressions.
3. Wrap just wraps an expression into ()
4. Var defined a variable
5 := defines an assignment
6. JsFunc declares a JS function
7. JsAnonFunc declares an anonymous function
8. 'myFunc(1, 2, "do it", 'home) is simply a javascript function invocation
by providing 4 parameter.
9. ~ is just a function that chains statements that don;t necessarily end in
;
Do you think that something like this would be usable in Lift?
Br's,
Marius
--
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.
App.scala
Description: Binary data
Re: [Lift] Re: (Maven problem?) Char encoding problem using S.?
On 11/12/09 5:28 PM, Jeppe Nejsum Madsen wrote: > Jean-Adrien writes: > > > [...] > > I have the same issues with the localized properties > >> = Conclusion = >> >> The problem here comes from my initial configuration. But in my sense >> it is not a good idea to store i18n data in another format than UTF-8. > > Agreed However, for minimum grief I always use unicode escaping (using \u) in locale properties. The output of "native2ascii src/main/resources/translate_fr.properties" should interest you :) > >> Maybe lift should not use java.util.Properties to handle i18n strings. > > Could be nice, but not java standard, so there may be interop > problems. But maybe a LiftRule setting for a UTF8 property reader > >> Moreover keys in properties file does not allow spaces, and the >> feature to use S ? "a key with space that will be used as a default >> value" does not work. > > You can have spaces in keys: > > Last\ Name = Efternavn > >> Another approach would be to use java.util.Properties in its xml form: >> value this one supports UTF-8, but once can >> find it too versatile. > > Oh no! I definitely don't want to go that route...much too verbose. You don't have to use the xml format really. Just escape the characters with unicode encoding (\u) and you should be covered. > > /Jeppe > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > -- 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.
