|
»
»
»
Jawr now supports DWR 3. Plugin offer for DWR codebase.
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Jawr now supports DWR 3. Plugin offer for DWR codebase.
by Jordi Hernandez
::
Rate this Message:
Hi everyone,
With the help of Jose Noheda I have been able to provide DWR 3 support in Jawr. I had to create a separate plugin since Jawr is coded against java 1.4. To get the latest version of Jawr go here, and to get the DWR 3 plugin go here. Joe, if you want I can donate the plugin code to DWR so it can be included in the main distribution. The point in doing that would be to cover the script concatenation functionality some people has been asking for. And Jawr also has i18n support for javascript, which has also been requested in the list. The plugin itself consists of one class right now. If you want to have a look it's here. Regards, Jordi Hernandez |
|
|
Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by XMaNIaC
::
Rate this Message:
Congrats on the job Jordi!
If the code is finally donated I'll do some extra work to integrate Spring MVC LocaleResolver and message bundles with the i18n architecture Regards
On Tue, Jun 10, 2008 at 10:21 AM, Jordi Hernandez <jordihs@...> wrote:
|
|
|
Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by Jordi Hernandez
::
Rate this Message:
Actually, I was going to support Spring's LocaleResolver in Jawr but I had no time to do it. It will surely be included with the next release of Jawr. :-)
|
|
|
Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by XMaNIaC
::
Rate this Message:
Hi,
I've been playing around with jawr a little bit more (IWebMvc now packs it by default instead of the previous ant tasks) and the power this library offers is awesome. It can generate different bundles, apply post-processors, minify/compress/concatenate files, detect orphans, seemlessly change between debugging and production modes, saves lines in JSP, works with v2 and v3 and much more. I'm really impressed. Joe, may be we should take in consideration the offer and let jawr manage some of these tasks. I only see advantages, it saves DWR some work (that can be invested in other core tasks) and we would have a mantainer just devoted to it (and quite experienced in the area to boot). Regards On Tue, Jun 10, 2008 at 10:42 AM, Jordi Hernandez <jordihs@...> wrote:
|
|
|
RE: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by mikewse
::
Rate this Message:
Hi Jose,
Does JAWR cover everything that was intended to
do in DWR's own version? Also, without adding dependencies? F
ex, I am concerned about not having to depend on JSP, or any other
view layer, for the concat feature.
Best regards
Mike
|
|
|
Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by XMaNIaC
::
Rate this Message:
I think it goes far beyond. Here's a list of useful features for us:
Regards On Wed, Jun 11, 2008 at 9:08 PM, Mike Wilson <mikewse@...> wrote:
|
|
|
RE: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by Jordi Hernandez
::
Rate this Message:
Unfortunately, Jawr does depend on dynamic pages at the moment with JSP, GSP and facelets being supported at the time.
My proposal is to include this plugin as an add-on for extended functionality and interoperability, at least as things are now. In the future I'm planning to add a plain HTML functionality, but meanwhile I'd think of this as an add-on or an interoperability plugin that offers extended javascript combination and compression abilities for users whishing to get it. Do let me know about further doubts, regards Jordi
|
|
|
RE: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by Jordi Hernandez
::
Rate this Message:
Hi again,
I have just released version 2.4 of Jawr, which is no longer dependent on dynamic view layers such as JSP. It can now be used with static HTML so that's one less drawback to fully integrate it with DWR. I have modified the DWR 3 sample war to use Jawr, you can get it from this page. Note that not all the pages are modified to use Jawr, but you can get a feel of how it works. If you have any further questions do let me know. Regards, Jordi Hernández.
|
|
|
Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by XMaNIaC
::
Rate this Message:
I would have liked something along
<script src="loader.js?files=bundle.css,/js/someBundle.js"></script> to save lines of code and requests but nice work! By the way have you read http://ajaxian.com/archives/modulesjs-a-new-stand-alone-javascript-module-loader? It's a link from an article at Ajaxian today about module loading that may come handy Regards On Mon, Jun 16, 2008 at 4:07 PM, Jordi Hernandez <jordihs@...> wrote:
|
|
|
Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by Jordi Hernandez
::
Rate this Message:
The problem with such approach is that the loader would never be cached: any url with parameters is automatically not eligible for caching.
So yes, there is an extra request but after the first time, the loader is cached and any other page using it loads even faster. The few extra lines, well.. just a few. Besides it is consistent with the taglib. In the DWR 3 WAR, since you remove 5-6 script tags, you actually save lines :-) And yes, I read that, thanks. Regards, J.
|
|
|
Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by XMaNIaC
::
Rate this Message:
Sorry, I wasn't clear the first time. I wasn't thinking in a loader but in a server side process that can return JS code directly. To avoid the caching problem you can use a REST style URL better:
<script src="/loader/css/bundle/js/someBundle"></script> What's your opinion on module loading instead of using document.write? I can see some benefits Regards, On Mon, Jun 16, 2008 at 4:33 PM, Jordi Hernandez <jordihs@...> wrote:
|
|
|
Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by Jordi Hernandez
::
Rate this Message:
But for now, that is a major change. Each resource has a dynamic URL based on its hashcode. When the servlet receives an If-modified-since header, it doesn't think twice and return 304 not modified. If you used such a scheme (interesting on the other hand), you should take in account etag and expires header logic, which isn't as bullet proof for caching as the current approach, because even when you change your script, the users are requesting the same url. Another downside is that if an app uses a mixed HTML+JSP approach (which is the most usual thing), the URL for the same bundle is different from the HTML page to the JSP page (is you use the taglibs that is). Which is awful for caching as well. My major inspiration for writing Jawr was this article. The author says the only sure way to keep resources in cache, and to avoid users having unwanted cached files at the same time, is to change the URL every time the resource changes. I think that, while easily overlooked, the automatic prefix is one major feature in Jawr, and using a REST style url would make us lose that advantage... Anyway, did you see theserverside.com today? :-)
|
|
|
Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by Joe Walker-3
::
Rate this Message:
Hi Jordi, Sorry for the delay. I'd like to include something like this in DWR - it makes lots of sense. From one perspective, we're just a remoting library, however in reality we have a fairly intimate relationship with the libraries that we squirt scripts into, so this type of thing is a logical direction. Some questions: - I would like DWR to be able to package itself in a single JAR without lots of complicated dependencies. Do you think we can support this type of deployment? - Before we can accept code that we re-distribute we like to have a CLA. It's a simple bit of paper that makes sure that DWR users can be sure that the code they're using is legit. Is that OK. You can find out more here: http://directwebremoting.org/dwr/development/icla Thanks, Joe. On Tue, Jun 10, 2008 at 9:21 AM, Jordi Hernandez <jordihs@...> wrote:
|
|
|
Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by Jordi Hernandez
::
Rate this Message:
Hi Joe, I'll try to answer your questions:
- As for the packaging, the Jawr library itself depends only on log4j for its runtime. Depending on which features are used, some more dependencies (such as the YUI compiler) may be required (I guess that's obvious, just trying to be as clear as possible here). Unfortunately, log4j is unavoidable as it's all over the code already. My offering of code was referred to the plugin required to have Jawr work with DWR 3, in the same fashion that you have several packages that integrate DWR with, say, Spring. If that is what we do, then log4j and the the Jawr would both be requiredas at minimum. But if you would like to include the whole Jawr library in the DWR distribution, then that's fine with me as long as Jawr can keep its separate identity as a project (you could do that even without asking me for it actually, since Jawr uses the apache 2.0 license anyway). - And as for the CLA, I have no problem with it. It does not make me surrender any thing beyond what is stated with Apache 2.0 license (but please do correct me if that's wrong). However, some of code in the main Jawr distribution is from a third party: the JSMin minifier by Douglas Crockford, which is a single class distributed with a BSD style license (very liberal, the code can be reused and redistributed freely). You can see it yourself: http://inconspicuous.org/projects/jsmin/jsmin.java There is also another tiny bit of code I borrowed from JSon java, also BSD license (it's just a method, but I still felt I had to credit them). It is used in the i18n messages generator to escape strings (and frankly, it can be easily replaced by my own code). The JSmin minifier is the default one (being the only one bundled, it makes sense). But I am aware that DWR has its own minifier so maybe we could replace it. That is kind of delicate since it would force me to create a specific DWR code branch. But if the BSD licensed code doesn't fit DWR, I guess we can work something out. Thanks for your interest, let me know if you have any further questions. regards, Jordi.
|
|
|
Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by Frank W. Zammetti
::
Rate this Message:
Jordi Hernandez wrote:
> Hi Joe, I'll try to answer your questions: > > - As for the packaging, the Jawr library itself depends only on log4j for > its runtime. Depending on which features are used, some more dependencies > (such as the YUI compiler) may be required (I guess that's obvious, just > trying to be as clear as possible here). Unfortunately, log4j is unavoidable > as it's all over the code already. I think Jakarta Commons Logging (JCL) might be the better option, and IIRC DWR already uses it... going from Log4J to JCL shouldn't be a *whole* lot more than a few global search-and-replaces, except perhaps if you've used more than simple log statements (I had to do this in one project and it was pretty much that easy). Frank -- Frank W. Zammetti Author of "Practical DWR 2 Projects" and "Practical JavaScript, DOM Scripting and Ajax Projects" and "Practical Ajax Projects With Java Technology" for info: apress.com/book/search?searchterm=zammetti&act=search Java Web Parts - javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! My "look ma, I have a blog too!" blog: zammetti.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Jawr now supports DWR 3. Plugin offer for DWR codebase.
by Joe Walker-3
::
Rate this Message:
So my gut reaction is that I shouldn't delay up 3.0 to work on this. But that we should look at this for 3.1. I'd like to consider a few UI libraries and work out how best for DWR to integrate with them, and this will be part of ensuring that we can deliver Javascript cleanly and efficiently. You're right about the CLA, it is just a formalized Apache2. The issue is simply that as a user of an open source library you might be worried that the contributors were committing code that they didn't have rights to. If we have a full set of CLAs on file then we can say - Look: we're clean. Joe. On Wed, Jul 2, 2008 at 8:09 PM, Jordi Hernandez <jordihs@...> wrote:
|
