Monday, August 14th, 2006
Introducing LaCo (or AJAX for the non-programmer)
<>p> From “The Spotty Blog” today, we learn about a new Ajax toolkit that allows developers to add Ajax functionality “without getting their hands dirty” with the actual code – LaCo – Late Content.They demonstrate four different kinds of usage:
- Automatic – giving sections of the site a src in a laco_src attribute
- User-activeated – a laco_target attribute in the link fires off the action
- User-ativated with a toggle – the same, but with the option to hide as well
- On Mouse Over – activated on hover with laco_target and laco_toggle attributes
All that’s required to use this library is to include prototype and the laco.js files into your page. You can grab the download here and try it out.
Related Content:
3.5 rating from 34 votes
[...] From the Ajaxian weblog comes a new Ajax library, LaCo. [...]
This is in some sense similar to Hinclude. Both of these are nice for simple useless includes but not really useable in mainstream applications. One major thing which is missing from these types of framework(s) is ability to parse javascript as part of returning content. For example if you include a page which contains document.write(); it simply gets lost.
Weak. Doesn’t work in Safari.
Bill…your snide remark is a bit disconcerting. You’re assuming that if a toolkit doesn’t work in 0.5% of the entire world population of browsers, then it’s ‘weak’. Give us a break.
Try being constructive; if the kit is built on prototype, then the breakdown is in their script with regards to safari and can probably be fixed.
It’s fair for a toolkit in this day and age to support Safari.
Lets see if the posting bug is fixed …
Nope
This is not valid. Not even close to being valid. This would merely be bad if it were not for the fact that there are many many ways to acheive this using valid markup. Why is this even getting attention?
»Bill Snebold
++
Dan/Bill,
I suppose my feedback stems from oddities I get when I feel like I’m testing code in FF, IE (5+) and Opera figuring I’ve hit the majority of browsers only to have a “This doesn’t look right in Safari” comment. Normally, the differences between the browsers are pretty small when you stick to standards-based code – but it’s hard for me (and the company I work for) to justify additional work hours to support a browser that has a small user base if there are problems.
There may be problems with this particular library, but I was reacting to the “Weak. Doesn’t work in Safari” comment rather than really taking a look at the code being presented.
That being said, I apologize.
Link is broken, dawg.
Hey all,
It seems to me that this is not Ajax but merely javascript with some css. I could be wrong but doesnt Ajax implies XML/JSON, also with come server side scripting…?!?
This is usefull but again as Tahir noted is useless in large web applications..
Anyway my two cents…
Don’t worry Jon, you are 100% right. A simple “weak, does not work” is not a bugreport that you or anyone else can work with.
While “Weak. Doesn’t work in Safari.” may be a little harsh of a comment, I do agree with the point here. This is a nice little piece of code, but it doesn’t work in Safari. While Safari may not hold very much of the share as far as web browsers go, I don’t see how anyone can say that it doesn’t matter if you are turning away potential customers. Any web shop, like the one I work for SpinWeb can not possibly be taken seriously if they were to ignore any of their clients’ customers. Especially when it is not that hard to code for Safari in the first place!
This looks quite interesting. The non-validation would be a deal breaker for me, but as a designer I like the concept. I would like to be able to use Ajax techniques to create pages that do not refresh, but are still accessible, SEO friendly and valid, so I think this shows that things like that can be achievable.
I look forward to seeing more scripts like that in the future that I can hopefully use.
If you’re not supporting Safari, you’re not supporting the very people who are most likely to check out cutting-edge new stuff and recommend it to their peers. Not testing in Safari is just plain stupid.
The whole Safari conversation is interesting. Unfortunately I agree with the Safari supporters. For purpose built sites is might be acceptable to support a reasonable and limited number of browsers, but Safari is growing and certainly enough of a contingent that the complaints you clients get (in response to the small but loud group of Mac/Safari users viewing their site) will be enough to turn a lot of people off of a project.
Now as for LKM’s comment. It seems a little strongly worded. LKM, if what you said *were* true I imagine Apple developers/Mac users would have jumped on the bandwagon ages ago. Lead the way, so to speak.
This actually surprizes me, so I’m not trying to denigrate you or Mac users as a whole. But for whatever reason, most of the open toolkits I’ve come across (Dojo, Rico/Prototype) seems to have issues with Safari, which is one of the only truly compliant browsers out there?
Anyway, thats were I’m at. I love the idea of toolkits. LaCo sounds very interesting, especially for the javascript inept (I’m looking at myself) but I’ve already gone down the road with Dojo developing a great looking snappy website only to find out the client needed Safari support. I wanted to do the kicking and screaming thing, but I saw it as a valid requirment. On my own site Safari is about 8% of my traffic. Thats enough I’d get a pretty big earful if I suddenly decided to spruce it up and broke it for that 8%. :)