Jesse Kuhnert wrote:
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.
There is a delay whenever using a dojo page - I see it more at home than
on my dev box, and that concerns me:
I don't know what dojo does that makes the browser think twice before it
shows a page but it does somthing, and this 0.5 seconds (in the good
case) where my browser window is white - this 0.5 seconds will lead my
customers to click to the competitor's web site, so I just can not
afford it.
this "white delay" exists also to some extent in prototype but dojo
breaks the records there...
As said, in (current) tapestry pages (also with forms) this does not
happen, and as for me, it also shouldn't.
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?
Thats certainly not my point, since in case of dojo it seems one is on
the safe side - ideology does not play a role here...
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?
I just looked at tacos demo again - don't know its current state but it
is not very fast loading, to say the least.
I will be glad to look at whatever you want to show me...
Cheers,
Ron
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
