[Lift] Re: Lift deal breakers
On Sep 14, 3:43 am, marius d. marius.dan...@gmail.com wrote:
I kinda used the term js file a bit too loosely. It is true that each
page would likely have different functions there and even the same
page on subsequent load would have different content so the file can
not really be cached.
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
...
.. and at the end of the page:
script type=text/javascript
function liftAjax(id) {
liftAjax.lift_ajaxHandler(id + '=true',null, null, null); return
false;}
...
/script
With this approach you still have an onclick event binded to the dom
element (in this case button) with html and this is bad practice for
javascript development. Additionally you create another function
called liftAjax at the window scope witch is again bad practice!
What I described on my previous post is that good javascript
development practice means that there should be nothing that has to do
with javascript except script tags inside the html. Now If you can to
get as less script tags as possible inside html is also better.
Likely there will be more synthetic functions that would need to be
generated depending on specific cases. This approach would result in a
slightly larger markup but I'm not sure if the impact is negligible or
not. In essence we are replacing a function call with another one more
concise which helps just in having a more concise function calls in
the markup.
BUT most likely for functions like liftAjax above we should put them
in liftAjax.js that lift generates and those would just be helper
function. This means that the script block above will not be needed
anymore. Thoughts?
Thanks Xavi for the good points.
Br's,
Marius
On Sep 13, 7:03 pm, Xavi Ramirez xavi@gmail.com wrote:
If I understand everything correctly, the proposal is to dynamically
create a js file for each page request to add event handlers?
If this is true, then I'm against the proposal for the following two
reasons:
1. Every page will load slower
Since the js file is dynamically create on each request, the js file
will be un-cacheable. This means the browser be will forced to make
an addition HTTP request to the server to render each page. This adds
roughly 150ms to the page load time (50ms to 200ms for network lag,
50ms for download, 10ms for js execution).
This is partially true. If you have a page that can be cached except
some javascript for example it is better to have the javascript as an
external file. If not you could ad the dynamically created javascript
inside the html body but it is still better to load it at the end of
your html document.
2. Each page will be more fragile
Requiring the synthetic js file will add another point of failure.
Even now-a-days with the ubiquity of broadband, connects still get
lost and files still get corrupted.
It's true that most modern web pages already depend a number of
external JS and CSS files, but typically these files are static and
easily cached.
Just adding my 2 cents.
-Xavi
On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote:
I think so too. Does anyone have an opinion against this? I'll
probably have some time this week or next weekend to work on it.
Br's,
Marius
On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote:
A synthetic file sounds good to me and would probably be preferable.
Cheers, Tim
On 13 Sep 2009, at 20:31, marius d. wrote:
That looks a little cleaner but we'll have to look more into it if
we'd want to go on this path. Perhaps accumulate those function into
synthetic js file .. we'll see
In my opinion what should be a high priority in this thread is to
strip the javascript of the html elements and bind the javascript
events from within one javascript snippet written at the end of the
html page or as an exernal js file and only if the user wants to.
That is my 2 cents!
Yoryos
--~--~-~--~~~---~--~~
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 deal breakers
I also think that javascript should go just before the boby's closing
tag. The main reason: Yahoo's YSlow and Google's Page speed both
telling you that is better to have as less scripts as possible and all
of them placed at the end of the page. The optimal would be one
javascript at the end of the page no matter how big it is as it would
be cached by any modern browser and it will be used from the local
cache on other requests from the same domain.
Of course optimal is not always what you can get. Assuming that you
have many javascript files it is also better to have them at the
bottom of the page. You will see a major performance boost because
browsers pause the rendering of the page in order to download
javascript. That is because javascript code could contain a
document.write witch means that it will change the dom of the page and
this is something that the browser will not be able to know in advance
in order to continue the parsing of the page. Moving javascript at the
bottom of the page will not decrease the page loading time BUT will
give the user something to see (the whole page) making him thing that
the page loads faster. Of course the browser will still have to get
the javascript and eval it.
As for unobtrusive, jquery (and the most js frameworks) provides a
solution binding an event on an html element after the page has been
loaded. So instead of having somthing like:
button onclick=liftAjax.lift_ajaxHandler
(quot;F1029758482780OTA=truequot;,
null, null, null); return false;Press me/button
you could have something like:
button id=liftajax_{some_generated_id}Press me/button
and at the end of the page add the javascript:
text type=text/javascript
$(function() {
$(#liftajax_{some_generated_id}).click(function()
{the_lift_ajaxHandler_call_here()})
})
/script
If the ajax handle call is basically the same for most of the elements
you could instead of adding an id, add a class to the the button for
example:
button class=liftajaxPress me/button
and then at the end of the page add:
text type=text/javascript
$(function() {
$(.liftajax).click(function() {the_lift_ajaxHandler_call_here()})
})
/script
I personally use jQuery but the above can be done without the help of
any javascript framework. And to make things much more better you
could have all the handler scripts in a separete dynamicaly created
file and the at the end of the html have something like:
script type=text/javscript src=/path/to/the/dynamicaly/created/js/
with/a/random/id/to/prevent/caching/script
One reason for keeping me away from using lift for a project is this
mess with javascript. I mean, I first want plain html and nothing
else. If I get the html to work for me the I just add the javascript I
want or let the framework add it, but that should be done in an
elegant way in order to be able to switch it off or on or completely
replace it with my own. I don't want any framework to add by default
the javascript for me because it makes things harder to understand and
this is something bad for someone new to it.
I would be glad to help in this matter in any way possible.
Sorry for my English,
it's not my mother language!
Yoryos
On Sep 13, 6:35 am, marius d. marius.dan...@gmail.com wrote:
Technically it could (as I implied above) but this can be lucrative
and IMHO the benefits are simply not that big. I'm not saying that
things are nailed down but I'd love to see a list of practical
benefits for Lift to not add event handlers such as on click to the
elements but rather programatically using synthetic (lift generated)
JS functions that would add events (i.e. JQuery, YUI ways).
Br's,
Marius
On Sep 12, 9:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Maybe adding javascript event handlers could be delegated to something that
depends on which library is being used?
-
Kevin Wrightkev.lee.wri...@googlemail.com wrote:
Moving the script import shouldn't be too difficult, we have the lift:tail
element and tail merge (which acts exactly the same as head merge) for just
this sort of problem.
On Sat, Sep 12, 2009 at 8:07 PM, Dustin Whitney
dustin.whit...@gmail.comwrote:
One nice thing about jquery's events, if done wisely, is they are applied
after the DOM is loaded. With an onclick a button can be clicked and some
ajax call is fired that returns and tries to modify a part of the DOM that
hasn't been loaded. This is especially true if you have lots of
javascript
includes at the top of the page. I have waded my way through many wonky
javascript bugs like this. They don't happen in your local environment
because they load so quickly, but when pushed to production, problems
ensue. Maybe there is a hook in the lift ajax js that waits to fire the
call until after the DOM is loaded?
-D
On Sat, Sep 12, 2009 at 2:48 PM, Charles F. Munat c...@munat.com wrote:
I, too, would like to be able to move the liftAjax script call to
[Lift] lift views
Hi all! Just a proposal: wouldn't be better to have the views look like more an html page. I mean for the basic project created, instead of having an index.html look like lift:surround with=default2 at=content h2Welcome to your project!/h2 plift:helloWorld.howdy //p /lift:surround have something like: html lift:surround with=default2 at=content head titleA better title than the one in default.html/title /head body h2Welcome to your project!/h2 plift:helloWorld.howdy //p /body /lift:surround /html Yes we have more boilerplate code but with that way it would be much more easier the edditing of the page. Yoryos --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
