On Sep 12, 8:34 am, Indrajit Raychaudhuri <indraj...@gmail.com> wrote:
> Even if we assumed that Lift managed to do all the hard work, we still
> have a contradictory situation: the <body/> 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 <body> tag and thereby sneaking into the
> <body/>. Worse, it's going to be incredibly difficult to implement a
> rich client interface (Cappuccino, Dojo, Sproutcore etc. - those who
> want to take complete control over the DOM) without the developer
> constantly having to prevent Lift and the UI framework not wrestle and
> step into the each other. A web *application* (like CMS) can get away
> with that, but not a *framework* (like Lift).

What control of Lift over the DOM are you talking about. Lift's
generated scripts in HTML is minimal, and it is about Comet mostly.
Lift scripts do not really stay in other frameworks way. If you have a
concrete example where Lift's stays in the way of integrating other
tools please be specific about the problem and we'll see what/if we
can do something about it. What is the exact wrestle here?


>
> And I am given to understand spiders are nowadays smart to recognize
> dom events handlers (e.g., onclick) and decide what to do when it
> encounters them.
>
> Oh, and while at that, 'view source' a GWT based application and help
> youself have a perspective :)
>
> Cheers, Indrajit
>
> On Sep 12, 5:07 pm, "marius d." <marius.dan...@gmail.com> wrote:
>
> > +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 the page is not bad either. IN certain situations users may
> > need this loaded prior their own js code. Besides I really doubt that
> > putting it at the end of the page would really make any practical
> > difference.
>
> > Not putting lift's JS callas such as Ajax at onclick events like that
> > can become quite lucrative from framework perspective because:
>
> > 1. Lift would have to queue all these events and add them to a JS
> > sequence and add this js to the served page.
> > 2. that would create a dependency to JQuery events style that would
> > have to be changed when YUI is in place or potentially other
> > framework. If we'd still want this style but be JS library agnostic
> > we'd have to do our own DOM manipulation etc which just adds more
> > overhead without any practical gain.
>
> > Br's,
> > Marius
>
> > On Sep 11, 10:18 pm, Andrew Scherpbier <and...@scherpbier.org> wrote:
>
> > > 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:<buttononclick="liftAjax.lift_ajaxHandler(&quot;F1029758482780OTA=true&quot;,
> > >  null, null, null); return false;">Press me</button>That onclick is not 
> > > ok.  It's bad for SEO and makes the page harder to read.  Ideally, no 
> > > javascript should appear on the page whatsoever. (I presume here SEO == 
> > > Search Engine Optimization.)
> > > If you are going to use AJAX in your website, you have to use Javascript, 
> > > right?  If you don't want to use AJAX with lift, don't...  Just use 
> > > standard forms and links.  (Also turn off client-side garbage collection 
> > > and any comet stuff in Boot.scala...)
> > > So assuming you actually want an ajaxButton, the onclick needs to get in 
> > > there somehow.  The only other way would be to have lift create some 
> > > javascript that modifies the DOM to somehow add that onclick.  I think 
> > > that would be much harder to read!
> > > For the SEO stuff, are you assuming deep traversal (clicking through 
> > > forms) into your webapp by spiders?  I don't know of any spiders that do 
> > > that very well.  Anyway, if that's what you want, then I wouldn't use 
> > > AJAX for anything.
> > > A neat trick to let spiders get to all your public pages if your site has 
> > > a complex form/ajax based navigation system is to use a site map and make 
> > > sure all your main URLS are simple, non-form URLs.
> > > Criticism is best if one can demonstrate a better alternative.Client Side 
> > > Load Time:
> > > I strive for that A in Y-Slow, so when I 
> > > see<scripttype="text/javascript"src="/ajax_request/liftAjax.js"></script>at
> > >  the top of the page, I feel a little uneasy, and there is nothing I can 
> > > do (I think) to move it to the bottom of the page. Have you actually 
> > > verified that this makes a difference?  I haven't verified this, so 
> > > pardon my ignorance.  It just seems like it either makes a difference of 
> > > milliseconds or no difference at all because modern browsers make 
> > > parallel requests and start rendering before everything is available.
> > > I'm sure if you can demonstrate two pages where the only difference is 
> > > the location of the script include, and the one with the script include 
> > > up front is noticeably slower than the other one, I'm sure something can 
> > > be done.
> > > --Andrew
> > > -Dustin
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to