That seems like a very valid concern. (good morning to you as well...or good night? ;) )
I'm not quite sure how to best answer that question to be honest. I have to be honest that I am trying to enlist the help of other more qualified sources for a better answer. We'll see what they say. The very basics of form interactions are still a concern of my own. I do see the point of not liking the idea of having dojo, however small and compressed the core dl may be, being forced on you in certain areas whether you like it or not. What then prevents your problem from having Form.jsforced on you when using the Form component? Small and concise it may be, but I would argue that http://archive.dojotoolkit.org/nightly/src/validate.js is equally as small and focused, only better. Of course if you don't have client validation enabled then there wouldn't be any automatic validate.js inclusions on your page. Just as much as http://archive.dojotoolkit.org/nightly/src/rpc/JsonService.js wouldn't be included on your page unless you were using JSON specific features. I do have to admit though that I'm rather enamored with the concept of being able to do this on one of my pages without very much thought: <script type="text/javascript" > dojo.require("dojo.validate"); do Some weird validation... or... dojo.require("dojo.storage.Storage"); and then being able to play with the stored flash state that tapestry has in my form with very well defined and easy to use API's. </script> I don't know. Is this a question of which library should be included by default, or are you saying that you think the tapestry dev's should continue to manually write their own javascript libraries so that tapestry isn't percieved as being particularly fond of one implementation over another? Javascrip gets loaded into the browser by tapestry already whether people like it or not, it's more a question of ~which~ javascript we want getting loaded into our browsers..A highly evolved/dynamic/supported/tested library maintained by very focused developers, or a mishmash of varying javascript styles being maintained by an already overburdened tapestry development team? I think more likely than not that the core of your argument is the download size of the core dojo.js library file, whichever custom profile you have decided to build? This is the only point I can't dismiss without further help/support. You are able to build as large or small a dojo.js file as you like, depending on how much you want to be available in your sharable/cachable js package. Whatever you don't want to include in the core will still be available via more "cachable" javascript inclusion calls. If this is related to your experiences with tacos, then I should probably apologize ahead of time. There was a huge design oversight that I hadn't realized I had committed until only a week or two ago...Which is that if you don't configure it to be off by default dojo will attempt to parse the DOM of your page for each page load to see if you have defined any dojo "widgets" that need parsing/configuring. I was planning on having this feature off by default for any/everything tapestry related. We already have a well defined model for dealing with components. (Just set djConfig { parseWidgets: false } . ) Would this be resolvable if I were able to put up a web page somewhere with a very simple interface that just downloads dojo.js with widget parsing turned off, say, providing focus to a sample form input field? j On 2/1/06, Ron Piterman <[EMAIL PROTECTED]> wrote: > > My concern is very simple, I take my current project as example: > > There are portions where Ajax is so important I will infact restrict > those portions to browsers supported by the ajax implementation we will > use. > > Then again, there are portions of the application - say, login page, > where all I want is deliver good functionality to all users on all > browsers and *fast*, without having to give away very basic things that > are presently there like the nice focus feature of the form component. > > Now do I need dojo for that very basic functionality? - and I am not > talking even about the Date component - just the very basics. > > What is the cost of using dojo? for me right now it seems simply too > heavy on the browser - > > I don't think we are in a position to make tapestry the bleading edge > framework for web 2.0 only - and say, well, out applications do have > some (performance) problems when you surf them on a PII win98 machine. > > now about tacos->tapestry, I think we see it alike. > for me, I am convinced that the existance of tacos (and some other > libraries which *will* come soon ;-) ) is an oxygen for the evolvement > of tapestry - decentralisation, letting the community evolve and live > its own life and make that interact etc. > > Cheers and again, good morning... > Ron > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
