hey all,

I'm working through a thread on the Chrome Frame mailing list and trying to diagnose an issue with this page on the latest Chrome:

http://dojotoolkit.org/documentation/tutorials/1.6/datagrid/demo/datagrid.html

It's so slow that I wasn't sure at first if I'd done something wrong. A quick look at the waterfall showed it requesting this file which clocks in at 11MB source, 1.26MB zipped on the wire:

http://dojotoolkit.org/documentation/tutorials/1.6/datagrid/demo/all-batting.json

The only thing nice I can say about that is that at least you're getting a good compression ratio. But seriously. 11MB. For a demo/tutorial.

Is that getting included in source package downloads too?

Search Discussions

  • Tom Trenka at Apr 19, 2012 at 11:01 am
    None of the tutorials are included in a source package download, if that
    allays your fears. That's a website thing, and IIRC its there to show that
    the grid can actually handle an 11MB download...
    On Thu, Apr 19, 2012 at 9:38 AM, Alex Russell wrote:

    hey all,

    I'm working through a thread on the Chrome Frame mailing list and trying
    to diagnose an issue with this page on the latest Chrome:


    http://dojotoolkit.org/documentation/tutorials/1.6/datagrid/demo/datagrid.html

    It's so slow that I wasn't sure at first if I'd done something wrong. A
    quick look at the waterfall showed it requesting this file which clocks in
    at 11MB source, 1.26MB zipped on the wire:


    http://dojotoolkit.org/documentation/tutorials/1.6/datagrid/demo/all-batting.json

    The only thing nice I can say about that is that at least you're getting a
    good compression ratio. But seriously. 11MB. For a demo/tutorial.

    Is that getting included in source package downloads too?
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120419/0bda1dc2/attachment.htm
  • Bryan Forbes at Apr 19, 2012 at 11:31 am

    Alex Russell wrote:
    hey all,

    I'm working through a thread on the Chrome Frame mailing list and trying to diagnose an issue with this page on the latest Chrome:

    http://dojotoolkit.org/documentation/tutorials/1.6/datagrid/demo/datagrid.html
    That's my tutorial, so I'll fess up.
    It's so slow that I wasn't sure at first if I'd done something wrong. A quick look at the waterfall showed it requesting this file which clocks in at 11MB source, 1.26MB zipped on the wire:

    http://dojotoolkit.org/documentation/tutorials/1.6/datagrid/demo/all-batting.json
    The bottleneck here is dojo.data.ItemFileWriteStore. The 1.7 tutorial
    has been updated to use dojo.store.Memory + dojo.data.ObjectStore which
    greatly improves the performance. Perhaps we should update the 1.6
    tutorials to use dojo.store.Memory + dojo.data.ObjectStore. Can you try
    the 1.7 demo and see if there's as bad of a problem?

    http://dojotoolkit.org/documentation/tutorials/1.7/datagrid/demo/datagrid.html
    The only thing nice I can say about that is that at least you're getting a good compression ratio. But seriously. 11MB. For a demo/tutorial.
    I needed a chunk of data that had meaning and which I could do
    meaningful advanced calculations on and sortable. Historical baseball
    batting data seemed like a good fit since there are about a million
    different calculations you can do to get whatever statistic you want
    (think Sabremetrics).
    Is that getting included in source package downloads too?
    It is not.

    --
    Bryan Forbes
    http://www.reigndropsfall.net

    GPG Fingerprint
    3D7D B728 713A BB7B B8B1 5B61 3888 17E0 70CA 0F3D

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 195 bytes
    Desc: OpenPGP digital signature
    Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120419/f6dbe665/attachment.sig
  • Bill Keese at Apr 19, 2012 at 11:41 am
    But, why aren't you using a client/server fetch-on-demand store like
    dojo.store.Json? Perhaps that was too complicated for a tutorial.
    On Friday, April 20, 2012, Bryan Forbes wrote:

    Alex Russell wrote:
    hey all,

    I'm working through a thread on the Chrome Frame mailing list and trying
    to diagnose an issue with this page on the latest Chrome:
    http://dojotoolkit.org/documentation/tutorials/1.6/datagrid/demo/datagrid.html

    That's my tutorial, so I'll fess up.
    It's so slow that I wasn't sure at first if I'd done something wrong. A
    quick look at the waterfall showed it requesting this file which clocks in
    at 11MB source, 1.26MB zipped on the wire:
    http://dojotoolkit.org/documentation/tutorials/1.6/datagrid/demo/all-batting.json

    The bottleneck here is dojo.data.ItemFileWriteStore. The 1.7 tutorial
    has been updated to use dojo.store.Memory + dojo.data.ObjectStore which
    greatly improves the performance. Perhaps we should update the 1.6
    tutorials to use dojo.store.Memory + dojo.data.ObjectStore. Can you try
    the 1.7 demo and see if there's as bad of a problem?


    http://dojotoolkit.org/documentation/tutorials/1.7/datagrid/demo/datagrid.html
    The only thing nice I can say about that is that at least you're getting
    a good compression ratio. But seriously. 11MB. For a demo/tutorial.

    I needed a chunk of data that had meaning and which I could do
    meaningful advanced calculations on and sortable. Historical baseball
    batting data seemed like a good fit since there are about a million
    different calculations you can do to get whatever statistic you want
    (think Sabremetrics).
    Is that getting included in source package downloads too?
    It is not.

    --
    Bryan Forbes
    http://www.reigndropsfall.net

    GPG Fingerprint
    3D7D B728 713A BB7B B8B1 5B61 3888 17E0 70CA 0F3D
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120420/84632bdf/attachment.htm
  • Shane O'Sullivan at Apr 19, 2012 at 11:46 am
    I'm not clear what we're trying to say with this demo - no application
    developer would ever download such a huge file and process it in the
    browser. They would stream it, fetch what they need, and split the
    processing between the server and the client. Can the demo be changed
    to do that? A simple PHP script might do. It would be a more
    realistic example of what people would really want to know how to
    achieve, and also not download 11mb of data
    On 19 April 2012 08:31, Bryan Forbes wrote:
    Alex Russell wrote:
    hey all,

    I'm working through a thread on the Chrome Frame mailing list and trying to diagnose an issue with this page on the latest Chrome:

    ? http://dojotoolkit.org/documentation/tutorials/1.6/datagrid/demo/datagrid.html
    That's my tutorial, so I'll fess up.
    It's so slow that I wasn't sure at first if I'd done something wrong. A quick look at the waterfall showed it requesting this file which clocks in at 11MB source, 1.26MB zipped on the wire:

    ? ?http://dojotoolkit.org/documentation/tutorials/1.6/datagrid/demo/all-batting.json
    The bottleneck here is dojo.data.ItemFileWriteStore. The 1.7 tutorial
    has been updated to use dojo.store.Memory + dojo.data.ObjectStore which
    greatly improves the performance. Perhaps we should update the 1.6
    tutorials to use dojo.store.Memory + dojo.data.ObjectStore. Can you try
    the 1.7 demo and see if there's as bad of a problem?

    http://dojotoolkit.org/documentation/tutorials/1.7/datagrid/demo/datagrid.html
    The only thing nice I can say about that is that at least you're getting a good compression ratio. But seriously. 11MB. For a demo/tutorial.
    I needed a chunk of data that had meaning and which I could do
    meaningful advanced calculations on and sortable. Historical baseball
    batting data seemed like a good fit since there are about a million
    different calculations you can do to get whatever statistic you want
    (think Sabremetrics).
    Is that getting included in source package downloads too?
    It is not.

    --
    Bryan Forbes
    http://www.reigndropsfall.net

    GPG Fingerprint
    3D7D B728 713A BB7B B8B1 ?5B61 3888 17E0 70CA 0F3D


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors


    --
    Blog: shaneosullivan.wordpress.com
    Twitter: twitter.com/chofter
  • Tom Trenka at Apr 19, 2012 at 12:22 pm
    Gentlemen,

    We at DTK have *always* done our best to be server-agnostic. That means
    *not* advocating any particular server approach, and not making any
    assumptions about how or where data is coming from. To date, that has been
    a huge advantage for us. What Bryan did was to show that if you are in a
    situation where you might be getting a very large chunk of data, DTK (and
    the data grid in particular) can still handle it. I think you might be
    surprised at the performance of things like this, to be honest.

    In addition, I'd mention that not all front-end devs have control over how
    data is being served to them. Do you want a library to dictate to an
    enterprise server team how they need to write their code? As a front-end
    person working with that library, do you think they even have that option?

    I can tell you from personal experience that at least one major database
    platform has big issues with doing some kind of paging--to the point that
    creating a JsonRest-based server is not always an option. Do we simply
    tell those users that you can't use one of the most popular components of
    DTK, or do we show that if you need to shove 11MB of data down a pipe, we
    can handle it?

    Cheers--
    Tom

    On Thu, Apr 19, 2012 at 10:46 AM, Shane O'Sullivan wrote:

    I'm not clear what we're trying to say with this demo - no application
    developer would ever download such a huge file and process it in the
    browser. They would stream it, fetch what they need, and split the
    processing between the server and the client. Can the demo be changed
    to do that? A simple PHP script might do. It would be a more
    realistic example of what people would really want to know how to
    achieve, and also not download 11mb of data
    On 19 April 2012 08:31, Bryan Forbes wrote:
    Alex Russell wrote:
    hey all,

    I'm working through a thread on the Chrome Frame mailing list and
    trying to diagnose an issue with this page on the latest Chrome:
    http://dojotoolkit.org/documentation/tutorials/1.6/datagrid/demo/datagrid.html
    That's my tutorial, so I'll fess up.
    It's so slow that I wasn't sure at first if I'd done something wrong. A
    quick look at the waterfall showed it requesting this file which clocks in
    at 11MB source, 1.26MB zipped on the wire:
    http://dojotoolkit.org/documentation/tutorials/1.6/datagrid/demo/all-batting.json
    The bottleneck here is dojo.data.ItemFileWriteStore. The 1.7 tutorial
    has been updated to use dojo.store.Memory + dojo.data.ObjectStore which
    greatly improves the performance. Perhaps we should update the 1.6
    tutorials to use dojo.store.Memory + dojo.data.ObjectStore. Can you try
    the 1.7 demo and see if there's as bad of a problem?
    http://dojotoolkit.org/documentation/tutorials/1.7/datagrid/demo/datagrid.html
    The only thing nice I can say about that is that at least you're
    getting a good compression ratio. But seriously. 11MB. For a demo/tutorial.
    I needed a chunk of data that had meaning and which I could do
    meaningful advanced calculations on and sortable. Historical baseball
    batting data seemed like a good fit since there are about a million
    different calculations you can do to get whatever statistic you want
    (think Sabremetrics).
    Is that getting included in source package downloads too?
    It is not.

    --
    Bryan Forbes
    http://www.reigndropsfall.net

    GPG Fingerprint
    3D7D B728 713A BB7B B8B1 5B61 3888 17E0 70CA 0F3D


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors


    --
    Blog: shaneosullivan.wordpress.com
    Twitter: twitter.com/chofter
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120419/a4393a13/attachment.htm
  • Sasha Firsov at Apr 19, 2012 at 12:46 pm

    On 2012-04-19 09:22, Tom Trenka wrote:
    In addition, I'd mention that not all front-end devs have control over
    how data is being served to them. Do you want a library to dictate to
    an enterprise server team how they need to write their code?
    :) No need to answer. But as DTK guys we could give reference
    implementation to jump start that part.

    My proposal would be a bit more proactive on simulation part.
    Simulation of XHR is not an issue, and duplicated 100K times JSON string
    or XML from JS as well.
    This way we are not tight to back-end still able to go over almost
    complete chain of delivery.
    As a front-end person working with that library, do you think they
    even have that option?
    You are right. 50% could not. But another 50% would be happy to get
    whatever is given. And the reason would be to have DTK "standard"-
    compliant solution.
    Be great on most popular (PHP, jsp, asp).

    Sasha
  • Tom Trenka at Apr 19, 2012 at 5:40 pm
    Have to be honest, Sasha...I have a very hard time trying to understand
    what you are trying to say. Can you be clearer about your intentions here?

    -- Tom
    On Thu, Apr 19, 2012 at 11:46 AM, Sasha Firsov wrote:
    On 2012-04-19 09:22, Tom Trenka wrote:
    In addition, I'd mention that not all front-end devs have control over
    how data is being served to them. Do you want a library to dictate to
    an enterprise server team how they need to write their code?
    :) No need to answer. But as DTK guys we could give reference
    implementation to jump start that part.

    My proposal would be a bit more proactive on simulation part.
    Simulation of XHR is not an issue, and duplicated 100K times JSON string
    or XML from JS as well.
    This way we are not tight to back-end still able to go over almost
    complete chain of delivery.
    As a front-end person working with that library, do you think they
    even have that option?
    You are right. 50% could not. But another 50% would be happy to get
    whatever is given. And the reason would be to have DTK "standard"-
    compliant solution.
    Be great on most popular (PHP, jsp, asp).

    Sasha
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120419/ff5ebec2/attachment.htm
  • Sasha Firsov at Apr 19, 2012 at 6:20 pm
    My bad. Please bug me if thoughts are still not clear. inline...
    On 2012-04-19 14:40, Tom Trenka wrote:
    Have to be honest, Sasha...I have a very hard time trying to
    understand what you are trying to say. Can you be clearer about your
    intentions here?
    To be evangelist :) As you noticed I am not doing much contribution.
    Just backing the DTK user interest. Trying to fill missed ideas.
    In current thread I am responding on mixing JS with back-end PHP.
    While there is a complain on using PHP, there was no solution given by
    JS on heavy grid load ( or I missed it on this thread ).
    I am supporting both (JS and back-end) load test data feed. More inline..
    -- Tom

    On Thu, Apr 19, 2012 at 11:46 AM, Sasha Firsov <suns at firsov.net
    wrote:
    On 2012-04-19 09:22, Tom Trenka wrote:
    In addition, I'd mention that not all front-end devs have
    control over
    how data is being served to them. Do you want a library to
    dictate to
    an enterprise server team how they need to write their code?
    :) No need to answer. But as DTK guys we could give reference
    implementation to jump start that part.
    As front-end developer on new (sub-)projects I often have a chance to
    define back-to-front end protocol. And the best way is to create dummy
    data generator(reference implementation) in back-end environment(either
    PHP or JSP). Than, having this emulator on hands, back-end guys (often
    myself) do the real job, but keeping protocol intact.

    My proposal would be a bit more proactive on simulation part.
    Simulation of XHR is not an issue, and duplicated 100K times JSON
    string
    or XML from JS as well.
    This way we are not tight to back-end still able to go over almost
    complete chain of delivery.
    The volume could be generated on back-end by PHP as done for now in
    discussed grid sample or faked by front-end.
    The XHR object (perhaps via "load simulator" transport) could do the
    heavy data set generation and giving those simulated data to success
    handler.
    This will eliminate the need for PHP still keeping testing code closest
    to actual back-end use.

    I guess this part was not clear?

    The "load simulator" transport does not call back-end but treat URL
    parameters to render matching data(paging/sorting/filtering.
    In real life always there is a need to get data from back-end and
    contributor has no reason to spend extra time for such JS simulators. It
    has sense for DTK as framework. To make back-end related test cases
    complete, "timeout", "error" of various kinds to simulate different HTTP
    response behaviors. Special case is password validation.
    As a front-end person working with that library, do you think they
    even have that option?
    You are right. 50% could not. But another 50% would be happy to get
    whatever is given. And the reason would be to have DTK "standard"-
    compliant solution.
    Be great on most popular (PHP, jsp, asp).
    Just stating that for populist reasons DTK should give reference
    implementation on most popular platforms, not just PHP.
    Those sample implementations would work with DTK components.
    Often after some changes as on back-end as on front-end it is difficult
    to guess what tier messed up application.
    Switching to URLs with "approved" reference app tests will allow to
    expose what tier is broken. (Front-end should work with ref impl.)

    Sasha
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120419/3c7d4411/attachment-0001.htm
  • Tom Trenka at Apr 19, 2012 at 7:57 pm
    Again, I apologize. Unfortunately I am terrible with languages, otherwise
    I might try to understand you in Russian. Let me ask in terms of the
    following:

    As front-end developer on new (sub-)projects I often have a chance to
    define back-to-front end protocol. And the best way is to create dummy
    data generator(reference implementation) in back-end environment(either PHP
    or JSP). Than, having this emulator on hands, back-end guys (often myself)
    do the real job, but keeping protocol intact.
    I've been doing hard-core consulting for close to 15 years now, and I have
    to admit that it's been rare indeed that as a front-end developer I could
    dictate the back-end (unless I was writing it, which I've done more than a
    few times). Do you think this is truly realistic, or do you know something
    that I don't? I only ask because if things have changed, it'd be good to
    know about it. Personally, I don't think things have changed at all...and
    if you have found yourself in a position where you're able to dictate the
    back-end most of the time, I applaud you. And if I get back into
    consulting, I'd like to plumb your mind as to how you've been able to do
    that =)

    Just stating that for populist reasons DTK should give reference
    implementation on most popular platforms, not just PHP.
    Those sample implementations would work with DTK components.
    Often after some changes as on back-end as on front-end it is difficult to
    guess what tier messed up application.
    Switching to URLs with "approved" reference app tests will allow to expose
    what tier is broken. (Front-end should work with ref impl.)
    A list of what back-end implementations you are thinking about, as well as
    how to implement them on a shoe-string budget, would be most helpful.

    Cheers,
    Tom
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120419/21eab763/attachment.htm
  • Sasha Firsov at Apr 20, 2012 at 12:36 am

    On 2012-04-19 16:57, Tom Trenka wrote:
    I've been doing hard-core consulting for close to 15 years now, and I
    have to admit that it's been rare indeed that as a front-end developer
    I could dictate the back-end (unless I was writing it, which I've done
    more than a few times). Do you think this is truly realistic, or do
    you know something that I don't? I only ask because if things have
    changed, it'd be good to know about it. Personally, I don't think
    things have changed at all...and if you have found yourself in a
    position where you're able to dictate the back-end most of the time, I
    applaud you. And if I get back into consulting, I'd like to plumb
    your mind as to how you've been able to do that =)
    My web stack experience is few years shorter. Such things have not
    changed much. Perhaps explanation is environment. Half of my projects
    where small team start-ups. There individual influence is significant.
    Especially supported by working DTK samples.
    In current project we need to enhance back-end for data
    paging/filtering/sorting. I will propose protocol from DTK store
    samples. For back-end people it does not matter much what parameters
    format to use. If they will have ref. code, it would be good enough
    argument to approve. Thanks Kris for link!

    In my current environment I would need to create back-end free UI
    development cycle. Perhaps it will give a chance to implement early
    mentioned XHR simulator transports.

    Cheers,
    Sasha
  • Bill Keese at Apr 19, 2012 at 11:32 pm
    I agree, it would be good for both demo and tutorial purposes to use
    dojo.store.Json
    connected to an example PHP file, allowing store.Json to page through the
    data store results, rather than downloading 11MB of data. Presumably the
    PHP example file would be very small, like 30 lines of code.

    It doesn't mean that we are giving up being "server agnostic", or anything
    like that.

    On Fri, Apr 20, 2012 at 1:46 AM, Sasha Firsov wrote:
    On 2012-04-19 09:22, Tom Trenka wrote:
    In addition, I'd mention that not all front-end devs have control over
    how data is being served to them. Do you want a library to dictate to
    an enterprise server team how they need to write their code?
    :) No need to answer. But as DTK guys we could give reference
    implementation to jump start that part.

    My proposal would be a bit more proactive on simulation part.
    Simulation of XHR is not an issue, and duplicated 100K times JSON string
    or XML from JS as well.
    This way we are not tight to back-end still able to go over almost
    complete chain of delivery.
    As a front-end person working with that library, do you think they
    even have that option?
    You are right. 50% could not. But another 50% would be happy to get
    whatever is given. And the reason would be to have DTK "standard"-
    compliant solution.
    Be great on most popular (PHP, jsp, asp).

    Sasha
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120420/2039d650/attachment.htm
  • Kris Zyp at Apr 19, 2012 at 11:44 pm

    On 4/19/2012 9:32 PM, Bill Keese wrote:
    I agree, it would be good for both demo and tutorial purposes to
    use dojo.store.Json connected to an example PHP file, allowing
    store.Json to page through the data store results, rather than
    downloading 11MB of data.
    If it would be of any help:
    https://github.com/SitePen/dgrid/blob/master/test/data/rest.php

    Presumably the PHP example file would be very small, like 30 lines
    of code.
    28 lines, good guess :) (although three of those are for handling
    children queries, as it is used for tree grid tests).
    Kris

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120419/fe0a96ff/attachment.htm
  • Alex Russell at Apr 22, 2012 at 1:32 pm
    Heck, you could just rename it to "stress_test.html" and add some content at the top that says "this page will take forever to load because it's parsing 11MB of JSON, the real magic happens when you scroll the grid after it loads". You'd at least know what you're looking at.

    But I still am left with two questions:

    * Why the hell do you need so much data from the server to show this? Can't you auto-generate it on the client from random sources and still show the API at work?
    * What's the point of this page? The grid is so tiny I feel claustrophobic looking at the data and I don't understand how this much data in a grid is ever a good UI unless it's also wired up to a search box that'll filter it.
    On Apr 20, 2012, at 4:32 AM, Bill Keese wrote:

    I agree, it would be good for both demo and tutorial purposes to use dojo.store.Json connected to an example PHP file, allowing store.Json to page through the data store results, rather than downloading 11MB of data. Presumably the PHP example file would be very small, like 30 lines of code.

    It doesn't mean that we are giving up being "server agnostic", or anything like that.


    On Fri, Apr 20, 2012 at 1:46 AM, Sasha Firsov wrote:
    On 2012-04-19 09:22, Tom Trenka wrote:
    In addition, I'd mention that not all front-end devs have control over
    how data is being served to them. Do you want a library to dictate to
    an enterprise server team how they need to write their code?
    :) No need to answer. But as DTK guys we could give reference
    implementation to jump start that part.

    My proposal would be a bit more proactive on simulation part.
    Simulation of XHR is not an issue, and duplicated 100K times JSON string
    or XML from JS as well.
    This way we are not tight to back-end still able to go over almost
    complete chain of delivery.
    As a front-end person working with that library, do you think they
    even have that option?
    You are right. 50% could not. But another 50% would be happy to get
    whatever is given. And the reason would be to have DTK "standard"-
    compliant solution.
    Be great on most popular (PHP, jsp, asp).

    Sasha
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedApr 19, '12 at 10:38a
activeApr 22, '12 at 1:32p
posts14
users7
websitedojotoolkit.org

People

Translate

site design / logo © 2022 Grokbase