[jQuery] Re: Macro templates for jQuery & UI
Hi, I think, that's a really great plugin! It can also be used to get international content. For this, it would be fantastic, if you can add one possibility. I want to register my own additional helper functions (for example for format a decimal as money). Which can be called at the variables. That would be really great! Mathias On Feb 23, 6:16 am, Stan Lemon <[EMAIL PROTECTED]> wrote: > Greetings, > There has been some conversation on the UI list about templating > solutions for jQuery. Ext has a light weight template library which > handles basic variable assignment and supporting formatting methods. > I finally decided to port the Ext solution to jQuery. I've tried to > conform to the UI API in my port. It was suggested that I pass this > port onto the general list for feedback and thoughts. My goal here is > really to propose the idea. I think UI could benefit from a baaic > template library, whether that be this port or a different > implementation. > > Anyhow, take a look at:http://stanlemon.net/files/ui.template.js > > Thoughts and feedback are much appreciated. > > Pax, > - Stan
[jQuery] error at new plugin page
Hallo, It seems, that there is an error at the new plugin page: "jQuery Extensions" for example should have 8 plugins. But if I'm looking into this category, there are only 4 Extensions. I cannot see a "next" or "previous" link. How can I get a complete list of avaiable plugins? Mathias
[jQuery] adding a callback to thickbox
Hallo, is it possible to add a callback to thickbox? I'm loading a form via ajax and I want to handle this form with ajax again. But I cannot find a possibility to register a callback function to use the form plugin. There should be a way like thickboxLink Is there a way to do it? Mathias
[jQuery] Re: trigger "$(document).ready" manually
Ok, it's quite easy to recall ready:
Don't register your ready functions like this:
$(document).ready(...);
Register it like this:
$(document).bind("ready",...);
Now, trigger the ready event:
$(document).trigger("ready");
This works. I think, it's a bit confusing, because $(document).ready
is an event (at least in the api). So, I expect, that it can be called
like an event.
Mathias
[jQuery] Re: trigger "$(document).ready" manually
Well, I have an ajax call to the server. The sever decides what to do. Normally, there is just one small part of the page, which will be changed per json. But there is one possibility, which needs to refresh nearly the complete page. No I have to recall ready. There are three possibilites: 1. I can send a special state which will reload the complete page. This method is stupid, because I need an additional server request (I can send the data with the first response). 2. I can write a special function, which will be called in $ (ducument).ready(). But this is just a workaround 3. ready can be called. I think, that's the most obvious way, the problem can be solved. And it is the easiest. If it is not possible yet, it's a feature request ;) Mathias
[jQuery] trigger "$(document).ready" manually
Good evening,
It is possible to call
1. $('#field').trigger("click");
2. $(document).trigger("myOwnEvent");
But it seems, that this is not possible to call
$(ducument).trigger("ready");
Is "ready" not an event? (Yes, I mean ready from $
(document).ready(function() {...})). I need to recall this event,
because I have changed a big part of my page.
Mathias
[jQuery] getUrlParam in version 2
Hallo,
I have rewritten my plugin to get GET-Params. It is now able to get
document params:
$(document).getUrlParam("param1").
And it is able to get params of an image/javaScript link:
$("#javaScriptFile1").getUrlParam("ajaxUrl");
I need the last method, because my php script is generating a special
value. Now, I want to use this value in JavaScript, but I don't want
to write the value to my html-page (clear unobtrusive JavaScript). So
I include the JavaScript file like this:
The new version can be found at
http://www.mathias-bank.de/2007/04/21/jquery-plugin-geturlparam-version-2/
Mathias
[jQuery] Re: jQuery selectors speed improvements - A different perspective
Well, I have written a treemap implementation in PHP and JavaScript (like the one of SequoiaView - http://www.win.tue.nl/sequoiaview/). And in this application, there is a difference. Of course, in most applications, there will be no difference. But there are cases, in which you need a fast selector speed, because you have many elements (>1000). The application is workable in a browser, but you need fast algorithms. The question is: can you use jquery, jquery's style and (for me, that's important) can you use the fantastic jquery plugins or do you have to reinvent everything. I think, the jquery community can profit from big applications like the treemap implementation, because in this way, there will be new interesting plugins (all plugins, I have written, are created in combination with this project). So it is necessary, to enable users to use jquery even in complex applications. That's the reason, why I have said, that it doesn't matter, if you use a special performance plugin or not. The only important thing is that you can use the plugins and the programming style. This is much more important than any filesize. Mathias On 3 Apr., 19:06, "Glen Lipka" <[EMAIL PROTECTED]> wrote: > What about the common "Grid"? When you have a table with 100-1000+ rows and > 5-10+ columns and then you want to resize columns, or bind click functions > to them, or enable drag and drop or have collapsable rows, or sorting. > > This is where selector speed should make a difference. The 1.0 version of > Slocums grid should be a perfect real world test. Put 1000 rows in it. > Then use it with a jQuery base, and then a DomQuery base. Does the user see > a differece then? > > Other than that, what are real world examples where it would matter? > > Glen
[jQuery] Re: jQuery selectors speed improvements - A different perspective
Hi, I also think, that performance is very important for a good library. No one uses jquery without any plugin (even if he / she has written an own plugin which uses jquery). Of course, it is important to have small files. But I think, it is still more important, to have a performant core, which enables to build complex and powerful plugins. There should be a trade off between size and performance. So, there are to ways: * We need a plugin, that enables to speed up the core. It can be used in web applications, which need a lot of perfomance. It doesn't matter, if some core functions are not used any more (performance is the goal). It is important, that the jquery style still remains and that other jquery plugins will still work (this is very important, I think). * It doesn't matter, if jquery is <20kb or <30kb. But it shouldn't be 100kb. The jquery core enables to write performant applications and it should still be small. There must be a trade off. I like both approaches. But there should be the possibility to speed up the core. I don't want to use another library just because I need to write a performant application. And I don't want to rewrite good plugins just because I cannot use the original jquery core. If we want to have many good plugins, than there should be the possibility to reuse the plugins in every situation. Mathias On 2 Apr., 18:08, "Dan G. Switzer, II" <[EMAIL PROTECTED]> wrote: > Here's my 2 cents... > > I think the core developers now have a pretty good idea of what the jQuery > "core" should and shouldn't be. I some sense, the hardest part is trying to > decide how much to include in the base package. It's also one of the largest > contributors to the overall size of the library. > > So, while I like the fact they want to keep the size as small as possible > (and it's cool telling people it's less than 20k) I'd much rather see speed > optimizations go in and the size increase a little bit. > > I don't want to see it turn into a beast-but anything under 25K still isn't > much data (and even that should be cached for most browser configurations.) > > As long as feature additions are kept at a minimum, I don't mind an increase > in size for performance gains. > > -Dan > > _ > > From: jquery-en@googlegroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of Glen Lipka > Sent: Monday, April 02, 2007 11:35 AM > To: jquery-en@googlegroups.com > Subject: [jQuery] Re: jQuery selectors speed improvements - A different > perspective > > I agree. At many big corporations you already have scripts that are > required. Google analytics scripts, Survey scripts, offermatica scripts, > e-commerce scripts. Plus the general cruft of legacy scripts for a myriad > of purposes. Not to mention all the screenshots and 100K of marketing text. > > Selling jQuery as the answer for client-side interactivity is much easier > when we say, "It's only 20k" > > This implies using jQuery on sites that need speed and do not have a ton of > "selecting" to do. > > For more intensive sites with larger selecting needs, I think it might be > worthwhile to have a "Selector Turbo" plugin that might be large, but will > increase selector speed for applications that need it. Is something like > this possible? > > Glen > > On 4/2/07, Rey Bango <[EMAIL PROTECTED]> wrote: > > Hi everyone, > > After reading Ralf Engelschall's posting about jQuery select speed > improvements, I have to say that I was so impressed by how a small > change can dramatically help improve performance. As Karl said, awesome > work on the speed enhancements and also on not increasing the file size. > > The latter is a BIG thing for the jQuery project. The general reason > that other libraries such as DomQuery or Base2 can have dramatic speed > enhancements is because they're not focused on keeping down the size of > their files and/or the final compressed product. Its definitely not a > knock at them. Both Dean and Jack are awesome developers and have great > solutions. File size, though, is not they're focus and that gives them a > lot of flexibility in making design decisions that can produce dramatic > results. > > One of the goals of the jQuery project is that we're constantly trying > to improve the features while still maintaining a nice, tight package. I > think to date, the core team has done an absolutely amazing job of > balancing out functionality and performance. Another goal is to nurture > this awesome community so that developers feel empowered to extend the > jQuery core in unique ways that add tremendous value to the whole > project. Again, I think this is something that we've done SO much better > than any project out there. > > I think its important that everyone have an understanding of why certain > things are done on the project so that when you see a comparison test > and wonder why we're not the fastest, you have a clearer picture of how > something like a selector performance test fits into the overall > strategy of the pr
