Cerainly. If there's no need for any of its functionality, it should not be included in the page at all.
Viktor On 1/8/07, Numa Schmeder <[EMAIL PROTECTED]> wrote:
22k of javascript to download is not that much on broadband connection on a modern computer, but on smart phone using GPRS that's a lot! It's true an abstraction is not that clean and where does the abstraction should stop is hard to decide. But at least it should be possible to avoid the use of dojo on a per page basis to keep things lite and have a very minimalist js to include if dojo is used for simple tasks. And in some projects, some pages don't use js at all, so why downloading something you don't use (as told by Ron it slows thing down)? Numa Le 8 janv. 07 à 17:11, Markus Joschko a écrit : > In principle I agree that a javascript abstraction layer is a fine > thing. > But just looking at the amount of client side javascript code thats > necessary to support all the web 2.0 goodness I'm really curious where > and how the abstraction cut should/could be made. Should there be a > very basic tapestry javascript library to support XHR or JSON requests > which would reinvent the wheel? Or should these operations not be > supported out of the box but only with the dojo extension? I mean even > in the current code base is a generic response builder which allows to > add other js libraries (at least that was the case half a year ago). > But as far as I know nobody has ever used this possibility. > > I think I would favor a slimmed down dojo library as well. Maybe with > an easy option to build a customized version to fit additional needs > (like custom packages etc). > > > > > > On 1/8/07, Numa Schmeder <[EMAIL PROTECTED]> wrote: >> I am also voting for an abstraction layer, dojo slows thing down and >> is not always fully compatible with all browsers and version.s Keep >> in mind that tapestry is used for public website and not only >> intranets where you can control the client's browser. >> >> Numa >> >> Le 8 janv. 07 à 13:33, Davor Hrg a écrit : >> >> > I'm for the abstraction too, >> > it will also force better separation from the framework >> > the AJAX and other client side features provide. >> > >> > I suppose this would simplify using different versions of dojo also >> > easier. >> > >> > Davor Hrg >> > >> > On 1/8/07, RonPiterman <[EMAIL PROTECTED]> wrote: >> >> >> >> Hi - I would like to share some thoughts about 4.1 dojo >> integration - >> >> maybe it will help to improve T5... >> >> >> >> I use Dojo in two projects - the first one, base on tapestry 4.0, >> >> is a >> >> heavy-ajax base project - everything is done via Async requests >> - we >> >> have some custom widgets and so on... dojo is really a bless ! >> >> >> >> in another project, based on 4.1, we use normal (sync) navigation, >> >> its a >> >> classic web site, but for some small things we do use Async >> >> requests- In >> >> this second project dojo is mostly responsible for slowing down >> page >> >> loading- bootstrapping on every navigation change makes a really >> >> heavy >> >> feeling of bad response time... >> >> >> >> now howard mentioned the possibility of adding an abstraction >> >> layer on >> >> top of dojo, to loose the bundling of dojo with tapestry. >> >> >> >> I would vote for that, and for making the dojo support a >> >> subproject of >> >> tapestry. >> >> >> >> my 2 cents... >> >> cheers, >> >> Ron >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
