[Lift] Re: Lift deal breakers

I agree with Chas but unfortunately it sounds like a lot of work to change. I would be happy if Lift used JQuery for this but then it would be tied to a specific library. I wouldn't mind but I can see why Lift folks would. On Sep 13, 6:00 pm, "Charles F. Munat" wrote: > marius d. wrote: > > I

[Lift] Re: Lift deal breakers

My sites are low traffic mostly, so a fraction of a second isn't that important to me, but I can see how it might be to you. (Which is not to say that I don't try to minimize hits to the database, combine files, minify, etc., all of which are fractional-second improvements, usually.) I don't u

[Lift] Re: Lift deal breakers

On Mon, Sep 14, 2009 at 9:29 PM, Charles F. Munat wrote: > > When you say that "direct JS callbacks (i.e. onclick="foo()") > outperforms _any_ other approach" what is the source for your assertion? > And what do you mean by "outperforms"? What are the criteria? Are you > talking about speed? > Y

[Lift] Re: Lift deal breakers

When you say that "direct JS callbacks (i.e. onclick="foo()") outperforms _any_ other approach" what is the source for your assertion? And what do you mean by "outperforms"? What are the criteria? Are you talking about speed? If so, what is the magnitude of the difference? Is it significant?

[Lift] Re: Lift deal breakers

Done David Pollak wrote: > > > On Sat, Sep 12, 2009 at 11:48 AM, Charles F. Munat > wrote: > > > I, too, would like to be able to move the liftAjax script call to the > bottom of the page. > > > Open a ticket and I'll see what I can do... it shouldn't be too

[Lift] Re: Lift deal breakers

On Mon, Sep 14, 2009 at 8:20 PM, Timothy Perrett wrote: > > Just wading into the fray here... > > Looking at people who have responded to this thread, they are mainly > people i've not seen on the list before (sorry if your regulars > perhaps i should pay more attention!) and that indicates to me

[Lift] Re: Lift deal breakers

Just wading into the fray here... Looking at people who have responded to this thread, they are mainly people i've not seen on the list before (sorry if your regulars perhaps i should pay more attention!) and that indicates to me that general users dont want *any* js in page (either in the head,

[Lift] Re: Lift deal breakers

Nothing in Lift the way it exists today would preclude such a setup. Just as I was able to integrate with Cappuccino (which is all JS-generated view), it's dead simple to integrate with any other "non-markup" framework. The thing that triggered this thread was Lift's insertion of JavaScript into a

[Lift] Re: Lift deal breakers

On Mon, Sep 14, 2009 at 12:51 AM, valotas wrote: > > > > 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 conten

[Lift] Re: Lift deal breakers

On Sat, Sep 12, 2009 at 7:21 AM, Indrajit Raychaudhuri wrote: > > > > On Sep 12, 7:02 pm, "marius d." wrote: > > On Sep 12, 8:34 am, Indrajit Raychaudhuri wrote: > > > > > Even if we assumed that Lift managed to do all the hard work, we still > > > have a contradictory situation: the being comp

[Lift] Re: Lift deal breakers

On Sat, Sep 12, 2009 at 11:48 AM, Charles F. Munat wrote: > > I, too, would like to be able to move the liftAjax script call to the > bottom of the page. > Open a ticket and I'll see what I can do... it shouldn't be too hard > > Chas. > > Dustin Whitney wrote: > > Hey, I like Lift so in an eff

[Lift] Re: Lift deal breakers

On Sep 14, 7:35 am, "Charles F. Munat" wrote: > > But we've got a desideratum, anyway. Maybe down the road someone will > have time to look at it. > > Thanks for the clarification! And also enable somebody (myself) take a pause and (re-)learn/ understand many important concepts in the way. Tha

[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 tha

[Lift] Re: Lift deal breakers

This is pretty close to what I'm doing. I have a REST backend (in Lift) that serves the data, and a separate Ext JS front end (one single page with a lot of Ext JS) running in a separate Lift app. It's still in progress and I haven't worked out all the details yet, but I'm very happy with it s

[Lift] Re: Lift deal breakers

Well, conciseness is always good. I haven't looked at (and don't have time to look at) the code that inserts this stuff, so I'll take your word for it that it's a big undertaking. Lord knows, I don't have time, so I'm certainly not complaining. But we've got a desideratum, anyway. Maybe down t

[Lift] Re: Lift deal breakers

On Sep 13, 8:00 pm, "Charles F. Munat" wrote: > marius d. wrote: > > I'm thinking that instead of: > > > Press me > button> > > > We could have: > > > Press me > > This is not what I had in mind at all. You still have the event handler > in the HTML. The idea, I thought, was to attach the event

[Lift] Re: Lift deal breakers

Hi Marius, Ahh yes I see. That's very different from what I originally understood. Your implementation makes sense. Thanks, Xavi On Sun, Sep 13, 2009 at 8:43 PM, marius d. wrote: > > I kinda used the term js file a bit too loosely. It is true that each > page would likely have different func

[Lift] Re: Lift deal breakers

This is how we do JavaScript/ExtJS development at my work place, except with a twist. We actually have a javascript-only project for a our javascript "library". We use the maven-javascript-tools plugins to create a javascript project that relies on others (in our case, things like Simile Timeline

[Lift] Re: Lift deal breakers

marius d. wrote: > I'm thinking that instead of: > > Press me button> > > We could have: > > Press me This is not what I had in mind at all. You still have the event handler in the HTML. The idea, I thought, was to attach the event handler from an external file using the id (or class) of the

[Lift] Re: Lift deal breakers

Is the DOM approach ruled out? I.e., generate a short script tag that is generated from the events needed to be listened for, which are delegated to a javascript generator that depends on the library. The actual JS files would be static. Maybe I missed where this option was eliminated? Also, wh

[Lift] Re: Lift deal breakers

I'm afraid I have to disagree. As a website developer, I've been putting all my JS into an external file (per page when necessary) for many years without any problems. Every good JS programmer I know does the same. It is considered *more* not less robust to put the JS in an external file and a

[Lift] Re: Lift deal breakers

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 We could have: Press me ..

[Lift] Re: Lift deal breakers

You mean cached by the browser? Isn't that a matter of setting headers, since it won't change in the session--or will it? Can one app switch dynamically from JQuery to YUI? - Xavi Ramirez wrote: If I understand everything correctly, the proposal is to dynam

[Lift] Re: Lift deal breakers

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

[Lift] Re: Lift deal breakers

+1 I would much prefer it if all JS were in external files (synthetic as necessary) and simply attached to the DOM via ids or classes. I have been building my sites this way for years, and I find it the best practice for reasons already put forth in this discussion. Chas. Timothy Perrett wro

[Lift] Re: Lift deal breakers

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 2

[Lift] Re: Lift deal breakers

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 se

[Lift] Re: Lift deal breakers

On Sep 13, 11:33 am, valotas wrote: > 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 op

[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

[Lift] Re: Lift deal breakers

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 programatica

[Lift] Re: Lift deal breakers

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

[Lift] Re: Lift deal breakers

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 >

[Lift] Re: Lift deal breakers

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

[Lift] Re: Lift deal breakers

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="l

[Lift] Re: Lift deal breakers

On Sep 12, 7:02 pm, "marius d." wrote: > On Sep 12, 8:34 am, Indrajit Raychaudhuri wrote: > > > Even if we assumed that Lift managed to do all the hard work, we still > > have a contradictory situation: the being completely devoid of > > scripts but still have 'JS loaded at the end of the pag

[Lift] Re: Lift deal breakers

On Sep 12, 8:34 am, Indrajit Raychaudhuri wrote: > Even if we assumed that Lift managed to do all the hard work, we still > have a contradictory situation: the being completely devoid of > scripts but still have 'JS loaded at the end of the page'. It still > has to be before the close of tag

[Lift] Re: Lift deal breakers

I am not a fan of buttons in the html that don't do anything if javascript is disabled. To stop them from coming up in a text based browser or something similar, I've always had the rule for myself that any forms or buttons dependent on javascript must be inserted by javascript, and everything that

[Lift] Re: Lift deal breakers

Even if we assumed that Lift managed to do all the hard work, we still have a contradictory situation: the being completely devoid of scripts but still have 'JS loaded at the end of the page'. It still has to be before the close of tag and thereby sneaking into the . Worse, it's going to be incr

[Lift] Re: Lift deal breakers

+1 Andrew. Regarding the "rule" - absolutely no javascript in the markup doesn't make a lot of sense. Some of the Lift's generated javascript for comet/ ajax calls is put inline at the end of the page. I see no practical reason not to do that. On the other hand putting liftAjax.js on the top of t

[Lift] Re: Lift deal breakers

Hey, If I understand Dustin correctly here he wants unobtrusive javascript. That is no javascript in the elements but javascript code that hooks into the dom and attaches events as needed. I am not familiar enough with the internals of lift's js wrapping to know how easy it would be to do it thi

[Lift] Re: Lift deal breakers

I'm not sure how you'd implement an _ajax_ Button without Javascript. :-) I also don't see how it is bad for SEO. These days, depending on the page and search engine, Javascript either gets executed (if there are JS blocks that run onload or inline) or ignored. In case of less popular pages, JS i

[Lift] Re: Lift deal breakers

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: Press mebutton