DWR

Allow automatic script concatenation

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: 4.0
  • Component/s: Engine
  • Description:
    Hide
    Automatically allow YUI performance #6

    We can't just do an <script src="dwr/everything.js"/> because that would give away the complete list of exported classes - something that we forbid for security reasons right now. Plus there are good reasons for only wanting the interfaces that you use on the existing page.

    Bu how about:
    <script src="dwr/getResources?include=utils,MyInterface1,MyInterface,..."/>

    There are some issues, like what if someone has exported a class called utils, but the general idea is very close. Maybe we should force people to write interface/MyInterface1 or something similar. We actively want this to be cached - I wonder if there are any cases where parameters inhibit caching?

    I wonder if it'd be more natural to have something like Dojo's djConfig structure? Define that before the <script> tag that loads DWR's client code, and there you can set what interfaces to load, any cache settings, whatever else might get added down the road... I'm just thinking in terms of being a developer, which is more natual? ...

    <script src="app/dwr/include=interface/class1,interface/class2&noCache=true"></script>

    ...or...

    <script>
     var dwrConfig = {
      include : [ "interface/class1", "interface/class2" ],
      noCache : true
    };
    </script>
    <script src="app/dwr/dwr.js"></script>

    Yes, it's more typing certainly, but I'm just thinking about some cases I have where I may have 10-15 or more classes being imported, do I really want to do that on one long line as a query string, or is it more natural to do it in Javascript like that? Also, I think it makes it so that you always load dwr.js and nothing else, so *maybe* it's simpler (I'm not so sure about that).

    Show
    Automatically allow YUI performance #6 We can't just do an <script src="dwr/everything.js"/> because that would give away the complete list of exported classes - something that we forbid for security reasons right now. Plus there are good reasons for only wanting the interfaces that you use on the existing page. Bu how about: <script src="dwr/getResources?include=utils,MyInterface1,MyInterface,..."/> There are some issues, like what if someone has exported a class called utils, but the general idea is very close. Maybe we should force people to write interface/MyInterface1 or something similar. We actively want this to be cached - I wonder if there are any cases where parameters inhibit caching? I wonder if it'd be more natural to have something like Dojo's djConfig structure? Define that before the <script> tag that loads DWR's client code, and there you can set what interfaces to load, any cache settings, whatever else might get added down the road... I'm just thinking in terms of being a developer, which is more natual? ... <script src="app/dwr/include=interface/class1,interface/class2&noCache=true"></script> ...or... <script>  var dwrConfig = {   include : [ "interface/class1", "interface/class2" ],   noCache : true }; </script> <script src="app/dwr/dwr.js"></script> Yes, it's more typing certainly, but I'm just thinking about some cases I have where I may have 10-15 or more classes being imported, do I really want to do that on one long line as a query string, or is it more natural to do it in Javascript like that? Also, I think it makes it so that you always load dwr.js and nothing else, so *maybe* it's simpler (I'm not so sure about that).

Activity

Hide
Frank W. Zammetti added a comment - 29/May/08 11:36 PM

I was thinking about my dwrConfig suggestion a bit more... I'm not so sure it's a good idea now.

First, it forces multiple (at least two) network requests instead of just one... one to download the base DWR Javascript, then at least one more to get the concatenated interface & utils scripts... maybe more if each interface is loaded separately.

Second, it means DWR has to introduce some sort of script loader mechanism. Now, it may not be too complex a thing, depends on how you approach it, but it's certainly more than is there now.

Third, it increases the odds of a page stalling while for resources (more than there would be if we had a single script file to retrieve I mean),. for the reasons stated in the first point.

So, after further thought, I don't really see my own suggestion as being a good one after all While I still think the query string approach might lead to some really long URLs, and has those same cache issues that you spoke about on the mailing list potentially (there seemed to be some differing opinions on that), I'd say it's probably preferable to the dwrConfig idea.

(at least, that's my thinking today... ask me again tomorrow! LOL)

Show
Frank W. Zammetti added a comment - 29/May/08 11:36 PM I was thinking about my dwrConfig suggestion a bit more... I'm not so sure it's a good idea now. First, it forces multiple (at least two) network requests instead of just one... one to download the base DWR Javascript, then at least one more to get the concatenated interface & utils scripts... maybe more if each interface is loaded separately. Second, it means DWR has to introduce some sort of script loader mechanism. Now, it may not be too complex a thing, depends on how you approach it, but it's certainly more than is there now. Third, it increases the odds of a page stalling while for resources (more than there would be if we had a single script file to retrieve I mean),. for the reasons stated in the first point. So, after further thought, I don't really see my own suggestion as being a good one after all While I still think the query string approach might lead to some really long URLs, and has those same cache issues that you spoke about on the mailing list potentially (there seemed to be some differing opinions on that), I'd say it's probably preferable to the dwrConfig idea. (at least, that's my thinking today... ask me again tomorrow! LOL)
Hide
David Marginian added a comment - 17/Dec/09 5:29 AM

This is covered by JAWR. Not sure if we should tackle this and duplicate efforts.

Show
David Marginian added a comment - 17/Dec/09 5:29 AM This is covered by JAWR. Not sure if we should tackle this and duplicate efforts.

People

Dates

  • Created:
    29/May/08 9:54 AM
    Updated:
    17/Dec/09 5:29 AM