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