[Lift] Re: Lift deal breakers
On Sep 14, 3:43 am, "marius d." 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:
>
> Press me button>
>
> We could have:
>
> Press me
>
> ...
>
> .. and at the end of the page:
>
>
>
> function liftAjax(id) {
> liftAjax.lift_ajaxHandler(id + '=true',null, null, null); return
> false;}
>
> ...
>
>
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 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. 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 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:
Press me
you could have something like:
Press me
and at the end of the page add the javascript:
$(function() {
$("#liftajax_{some_generated_id}").click(function()
{the_lift_ajaxHandler_call_here()})
})
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:
Press me
and then at the end of the page add:
$(function() {
$(".liftajax").click(function() {the_lift_ajaxHandler_call_here()})
})
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:
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." 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 wrote:
>
> > Maybe adding javascript event handlers could be delegated to something that
> > depends on which library is being used?
>
> > -
>
> > Kevin Wright wrote:
>
> > Moving the script import shouldn't be too difficult, we have the
> > 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
> > wrote:
>
> > > 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 wrote:
>
> > >> I, too, would like to be able to move the liftAjax script call to the
> > >> bottom of the page.
>
> > >> Chas.
>
> > >> Dustin Whitney wrote:
> > >> > Hey, I like Lift so in an effort to improve it I am submitting some
> > >> > criticism.
>
> > >> > Obtrusive javascript:
>
> > >> > when I create an ajaxButton I get this html:
>
> > >> > > >> onclick="liftAjax.lift_ajaxHandler("F1029758482780OTA=true",
> > >> null,
> > >> null, null); return false;">Press
[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 Welcome to your project! have something like: A better title than the one in default.html Welcome to your project! 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 -~--~~~~--~~--~--~---
