FLUID-3399 request for preliminary review
Laurel A. Williams
laurel.williams at utoronto.ca
Tue Dec 15 17:36:33 UTC 2009
Thanks for the feedback Colin,
We should make sure we remove this directory from the release, since we
are not going to be using it. I can do that in the cleanup target, or
simply remove the files from the svn entirely. What is your preference?
Other thoughts below.
Colin Clark wrote:
> Hi Laurel,
>
> I took a look at your preliminary primer code. Here are some comments:
>
> * I'm not sure you should parameterize all your Ajax request options
> like you have. Here's a question to ask yourself when parameterizing
> things: If someone were to change any of these options, would the code
> still work? For example, changing the type of request from POST to
> GET; wouldn't that just be wrong?
>
Good point. Just got carried away with the fun of parameterizing!
> * It might be a better idea to chain Ajax requests asynchronously,
> rather than doing the requests synchronously in a loop. In some
> browsers, synchronous requests will cause things to lock until
> everything is done. To be more concrete, chaining Ajax requests will
> involve calling the prime() function in the success callback of the
> request.
>
I like this idea. I do know from my testing that performing two
asynchronous calls one right after the other caused my apache to
fail/hang. The synchronous solution solved that problem. Will try out
your idea next.
> * You've certainly got the mechanics of making Ajax requests in place,
> but I'll be interested to see how you'll do the bigger picture
> stuff--deciding on how to represent "profiles" of stuff to build, etc.
>
> * Your question about how to obtain the model: it seems to me that you
> can make a request to the Builder itself to get a model of all the
> available modules. Along with this, you'll probably want a separate
> model--perhaps defined in the component's options--to specify the list
> of "profiles" that will need to be built in order to prime the cache.
>
Michelle and I went through a list of ideas about what we might try to
"prime" if we were to do it manually, and had concluded that a first
step would be to simply recreate those profiles in the code by manually
listing the module combinations. The two examples I used and checked in
were not at all typical. I'm not exactly clear on the technique you
described above, but we can talk about it later.
> Minor, nitpicky details:
>
> * The primer() function should probably be named as a verb: prime(),
> maybe?
> * You need to run JSLint on this code: missing semicolons, whitespace
> issues, a few details.
> * Real minor: consider consistent use of quotation marks--use " or '
> appropriately
> * You might want to name your button in the dom binder a bit more
> clearly--maybe "primeButton" instead of "initiatePrime," for example
Will address these immediately.
>
> This is a good start, but I'm thinking that we probably won't have the
> primer in place for the Builder 1.1.2 release. I think that's probably
> fine for this release, it just means that we'll have to manually prime
> the cache. Thoughts?
>
> Colin
>
> On 14-Dec-09, at 9:48 PM, Laurel Williams wrote:
>
>> Would really appreciate your eyes on
>> http://issues.fluidproject.org/browse/FLUID-3399. I checked in
>> further code today and it seems to work...just need to figure out how
>> to populate the model. But any comments on the code and technique
>> would be appreciated.
>>
>> Laurel
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> http://fluidproject.org
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: laurel_williams.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20091215/fa2af136/attachment.vcf>
More information about the fluid-work
mailing list