Hi Larry -
Thanks for your thoughtful response. A few thoughts below:
> [A good idea. I've added issue 60 to the issues system at the Google code
> site and will add it.
> One question is what should the value be for the trunk version.
> The trunk version is beyond 2.2.0 but will not be the exact same as 2.3.0
> until 2.3.0 is out.
> So should the current trunk version be "2.2.0+"? (But then its a string, not
> a number.)
> ]
Well, if we're dealing with 2.2.x-style versions, it would need to be
a string in any case, with the 2 decimal points. I think this is fine,
since you can still do comparisons like { if (version.indexOf('2.') ==
0) ... }. As for the trunk version, jQuery seems to go with "pre":
http://dev.jquery.com/browser/trunk/jquery/version.txt - I think
either way would work -
> And really, the current trunk is where people should be. 2.2.0 works well,
> but a number of things were only partially done or not yet handled within
> 2.2.0. See the trunk changes.txt for all of the details. I believe that the
> trunk ver works well and is self consistent with one exception: the trunk zip
> files need to be updated to handle a change in the underlying Simile Ajax
> library. But downloading the trunk via svn works well.]
Well, I'd like people to be able to link directly to the Timeline JS,
preferably as a stable release so that no one ends up with code that
worked previously breaking overnight because of changes to the trunk.
Is 2.2.0 actually buggy, or just not as good as the trunk?
> [Interesting. A couple of things come to mind:
> 1. Ver 2.2.0 has two painters in it and localization files. So depending on
> the usage, some of that can be removed.
> 2. Probably a bigger issue is the size of jQuery, it may well have grown in
> the year or so between 1.2 and 2.2.0.
> 3. As noted, more features. Not sure of the right answer there. I have pushed
> back against some feature ideas that I felt did not have to be part of the
> core library.
> ]
For what it's worth, the way I've tried to approach this in my own
project is to make sure that there's a core library file or set of
files that can be used independently of additional features. In the
case of TimeMap, this is the minimum code required to display the
application from JSON data. It's not clear to me to what extent one
can do this in Timeline right now, and it certainly seems impossible
to do it using the bundled versions of either Timeline or SIMILE Ajax
- so to get any real savings in download size, you'd need to download
the source, figure out which files you can do without, and make your
own bundle with your own compressor. It seems like it might be really
useful to simply set this up as a second build task, making a timeline-
core-bundle.js. Then folks who want, say, one of the additional event
painters could choose to either use the full bundle (easier) or use
the core bundle and load the single event painter script separately
(lighter weight).
> To answer your bigger question of the inclusion of jquery:
> a) The Ajax api file is designed to not load jquery if it is already loaded.
> But I could easily understand if that sw is not working right, it probably
> isn't tested much, if at all. If you could test it, that'd be great.
I'll see if I can take a look - haven't tested this yet.
> b) I agree that the inclusion of jquery should be looked at again. I'd prefer
> the writing of an api and compatibility layer that would enable libraries
> other than jquery to be used once the correct compatibility layer was
> written. Personally, I prefer the YUI library for anumber of reasons.
> Prototype is also popular.
Yes - I guess I feel that unless the project is going to rely on a
library like jQuery and use it heavily, taking full advantage of it,
there's no reason to include it - which core JS library to use feels
like a personal choice that should be left to the developer :).
> 1) More reference documentation
> 2) More cookbook-style docs (also know as recipes)
> 3) Tests, perhaps viahttp://seleniumhq.org/ That way we can tell if the
> changes are breaking anything....
> There have been a number of changes to the Timeline code base which broke
> things. I don't really like to spend my open source time testing others'
> code, finding errors and then backing out their changes. So I've put emphasis
> on adding to the example files which I use as "poor man's tests." The real
> thing (Selenium or similar) would be far better. If you could help with that
> issue (or others), that'd be great!
While I haven't tried out Selenium, my impression is that it's better
for complex, multi-page, server-side applications, and is built to
test user interactions rather than the logic of the different
components. For TimeMap, I've been using jsUnit (http://
www.jsunit.net/), a unit-testing framework for JavaScript that seems
quite easy to work with. I'm a big fan of unit-testing, even though it
takes a certain amount of time to write the tests. This may be
something I can help with - but it may need to wait until I have some
more free time.
> We'd really really love your help with the project, at any level. Please let
> us know what parts are of most interest...
I'd like to be involved. I'm fairly busy at the moment - in the last
semester of a Master's program - but will keep in touch. Thanks for
the consideration!
-Nick
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"SIMILE Widgets" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/simile-widgets?hl=en
-~----------~----~----~----~------~----~------~--~---
