fluid-work IRC Logs-2010-08-26

[08:44:51 CDT(-0500)] <heidi> hey jamon where could i find a mouse?
[09:10:33 CDT(-0500)] <heidi> n/m jamon justin had one
[12:04:21 CDT(-0500)] <Justin_o> Bosmon2: hello... thanks for fixing that bug with the undo component and for all those other framework changes.
[12:04:54 CDT(-0500)] <Justin_o> I'm wondering though about backwards compatibility. I guess it sort of seems like the api for fluid.initView has now changed or at least for fluid.container
[12:04:58 CDT(-0500)] <Justin_o> is that correct?
[12:05:23 CDT(-0500)] <Bosmon2> Yes... an important difference is handling the case where the "container" selector does not match anything in the document
[12:05:39 CDT(-0500)] <Bosmon2> What we used to do in this case was rather vague and probably not correct
[12:05:55 CDT(-0500)] <Bosmon2> But there might be other people, like Undo, who depended on the particular effects that they got
[12:06:05 CDT(-0500)] <Bosmon2> THe new idiom is that "a missing container means a missing component"
[12:06:14 CDT(-0500)] <Bosmon2> That is, that the entire result of initView becomes a return of "null"
[12:06:29 CDT(-0500)] <Bosmon2> This is important to allow people to configure complex trees of components in a markup-driven way
[12:06:44 CDT(-0500)] <Bosmon2> For example, a pager that doesn't have markup configured for some of its subcomponents should simply "configure away" the subcomponents
[12:08:09 CDT(-0500)] <Justin_o> Bosmon2: okay... that makes sense... i guess i'm worried about having this change to the api, if other people are depending on this... kind of like some of the problems we had with the latest jquery update
[12:08:28 CDT(-0500)] <Bosmon2> Yes, there may be some "minor drift" of this kind
[12:08:35 CDT(-0500)] <Bosmon2> But hopefully nothing as big as what jquery inflicted on us
[12:08:39 CDT(-0500)] <Justin_o>
[12:09:14 CDT(-0500)] <Justin_o> is there anything we can do to prevent this, other than not implementing the new framework features, which isn't an options
[12:09:30 CDT(-0500)] <Bosmon2> Almost all the other changes shouldn't affect anyone who doesn't call "fluid.initDependents"
[12:09:44 CDT(-0500)] <Bosmon2> This is the new workflow entry point for people who want to enable IoC
[12:10:08 CDT(-0500)] <Bosmon2> Well... the old behaviour was never "specified" and it just wasn't right
[12:10:45 CDT(-0500)] <Bosmon2> I think in some cases where you have behaviour that previously wasn't defined or incorrectly implemented, you have no choice but to change the behaviour
[12:11:04 CDT(-0500)] <Bosmon2> The contract of fluid.initView in any case was never documented well enough to explain what should happen in this case
[12:12:06 CDT(-0500)] <Bosmon2> 1.3 will be a VERY LARGE framework update in any case... I don't think we have had such change to the framework perhaps since 0.8
[12:13:39 CDT(-0500)] <Justin_o> okay... well that should give us some leeway... i guess i'm a bit worried because i think that one the jquery changes may have been to an undocumented piece of functionality... and it still hurt us
[12:13:48 CDT(-0500)] <Justin_o> I think you're probably write about that...
[12:14:01 CDT(-0500)] <Justin_o> do you think these changes all fit within the scope of a 1.3 release
[12:14:30 CDT(-0500)] <Justin_o> i don't know the details of the changes well enough
[12:15:46 CDT(-0500)] <Bosmon2> Well, almost all the changes will be "sneak peek" for this release
[12:15:57 CDT(-0500)] <Justin_o> right
[12:16:01 CDT(-0500)] <Justin_o> forgot about that...
[12:16:03 CDT(-0500)] <Bosmon2> We can't really go from having functionality non-existent to being fully baked in the space of a single release
[12:16:33 CDT(-0500)] <Bosmon2> If you don't want it, you can just leave out FluidIoC.js and not call fluid.initDependents or fluid.demands
[12:16:50 CDT(-0500)] <Bosmon2> Although implementing these features has as you say caused lots of "tweaks" in the base framework to support them properly
[12:17:09 CDT(-0500)] <Bosmon2> In particular there have been very big changes to fluid.fetchResources to support CSpace work
[12:17:13 CDT(-0500)] <Bosmon2> And there are more down the pipe
[12:17:26 CDT(-0500)] <Bosmon2> But those should be backwards compatible
[12:17:32 CDT(-0500)] <Justin_o> Bosmon2: okay great...
[12:17:38 CDT(-0500)] <Bosmon2> There are simply more options recognised in the resourceSpecs structure than before
[12:17:59 CDT(-0500)] <Bosmon2> For example each resource can have individual success/failure callbacks, and there is a new "forceCache" flag as of last night
[12:18:05 CDT(-0500)] <Bosmon2> Although so far it works a bit erratically
[12:18:33 CDT(-0500)] <Justin_o> yes... i saw that in your commit log... so if it is cached by the browser it breaks?
[12:18:44 CDT(-0500)] <Bosmon2> I really don't understand what I observed
[12:19:10 CDT(-0500)] <Bosmon2> I saw a "Not modified" response by the browser to the first request... and then forever afterwards it would actually give a 404
[12:19:18 CDT(-0500)] <Bosmon2> Even if you navigate to the URL in question manually in the browser
[12:19:25 CDT(-0500)] <Justin_o>
[12:19:28 CDT(-0500)] <Bosmon2> You need to do a shift-refresh to make it ever work again
[12:19:39 CDT(-0500)] <Justin_o> where did you see this issue
[12:19:55 CDT(-0500)] <Justin_o> is there a demo or anything?
[12:19:56 CDT(-0500)] <Bosmon2> My only guess is that a 2nd AJAX request to the same URL before the first one has returned will make the browser "very angry"
[12:20:31 CDT(-0500)] <Bosmon2> Well, if you took out the "cache" parameter added in the middle of fluid.fetchResources, you could see it on every collectionSpace page
[12:20:43 CDT(-0500)] <Bosmon2> This is part of the new "autocomplete" component I implemented for that
[12:20:49 CDT(-0500)] <Justin_o> ah i see
[12:20:51 CDT(-0500)] <Bosmon2> So - this is a new kind of issue
[12:21:00 CDT(-0500)] <Bosmon2> Say you have multiple instances of the same component on the same page
[12:21:13 CDT(-0500)] <Bosmon2> But that each one of them is trying to load EXACTLY THE SAME markup template in order to render itself
[12:21:29 CDT(-0500)] <Bosmon2> Now previously in CSpace, this issue was hacked by turning such a component into some crazy kind of "singleton"
[12:21:37 CDT(-0500)] <Bosmon2> but really, all the components should believe themselves to be autonomous instances
[12:22:03 CDT(-0500)] <Bosmon2> So - you would think that all you need to do is "see if one of the components has requested the template" and then return it from the cache
[12:22:10 CDT(-0500)] <Bosmon2> But unfortunately it is not as simple as this
[12:22:28 CDT(-0500)] <Bosmon2> In the course of building up the page, you will typically INSTANTIATE ALL OF THE COMPONENTS BEFORE ANY AJAX REQUEST RETURNS
[12:22:49 CDT(-0500)] <Bosmon2> So it is impossible to see whether the markup has been returned yet by the time all the component duplicates start their request
[12:23:23 CDT(-0500)] <Bosmon2> So, this is why the implementation of "forceCache" is so baroque and strange
[12:24:04 CDT(-0500)] <Bosmon2> There are 3 separate conditions that a resource passes through
[12:25:19 CDT(-0500)] <Bosmon2> i) the first request by any component for the resource, ii) the "lost phase" where the first request is now in flight, but further requests are now coming in by components, iii) the phase where the request is satisfied physically, and so all requesters from phase ii) must be notified (may as well be synchronous) iv) further requests after this point can be satisfied from the cache
[12:25:25 CDT(-0500)] <Bosmon2> Ok, 4 conditions
[12:25:36 CDT(-0500)] <Bosmon2> Fear, surprise, and a fanatical devotion to the pope
[12:28:06 CDT(-0500)] <Justin_o>
[12:28:49 CDT(-0500)] <Justin_o> okay... so fetchresource actually caries around information about every resource that was fetched.. i guess it id's them based on resource url
[12:28:56 CDT(-0500)] <Bosmon2> yes
[12:29:02 CDT(-0500)] <Bosmon2> Well, it does now at least
[12:29:12 CDT(-0500)] <Bosmon2> There is a "breakout point" for a utility we need to backport from Engage
[12:29:23 CDT(-0500)] <Bosmon2> That canonicalises URLs in order to tell which ones of them are the same
[12:31:07 CDT(-0500)] <Justin_o> that's smart
[12:55:24 CDT(-0500)] <Bosmon2> Hi heidi - so my question from yesterday
[12:55:33 CDT(-0500)] <heidi> yes
[12:55:39 CDT(-0500)] <Bosmon2> I am trying to bring up a dialog that makes "some attempt" to size its width appropriate to its contents
[12:55:52 CDT(-0500)] <heidi> okay
[12:55:56 CDT(-0500)] <Bosmon2> I tried jquery with the "autosize" option but it didn't do anything very helpful
[12:56:10 CDT(-0500)] <Bosmon2> And ended up just throwing the dialog somewhere random on the page
[12:56:46 CDT(-0500)] <heidi> hmm, i don't know the jquery thing, but yeah you'll need javascript
[12:56:48 CDT(-0500)] <Bosmon2> It doesn't matter if it isn't perfectly accurate... but it is important to have some text which is in a <ul> to not flow across multiple lines if possible
[12:57:35 CDT(-0500)] <heidi> hm
[12:57:46 CDT(-0500)] <heidi> so you can check the value of a css property w/ jquery
[12:58:05 CDT(-0500)] <heidi> and then do something depending on that value .... change it
[12:58:19 CDT(-0500)] <heidi> let me read the autosize page...
[12:58:33 CDT(-0500)] <Bosmon2> Well
[12:58:34 CDT(-0500)] <heidi> what is the variable by which it should resize or not?
[12:58:54 CDT(-0500)] <Bosmon2> Won't this cause the thing to "flicker around" as it relays itself?
[12:59:03 CDT(-0500)] <anastasiac> jamon, are you available to help trouble-shoot a visitor's network connection?
[12:59:12 CDT(-0500)] <Bosmon2> Presumably the browser doens't bother trying to sort out layout for something which is not visible...
[13:00:44 CDT(-0500)] <anastasiac> jamon, armin is trying to help
[13:02:38 CDT(-0500)] <heidi> Bosmon2 - so what are the steps right now?
[13:02:48 CDT(-0500)] <heidi> when does it resize, and based on what
[13:03:25 CDT(-0500)] <heidi> is just when the page loads, you want it to fit relative to the current browser size ?
[13:03:34 CDT(-0500)] <Bosmon2> Well, not exactly
[13:03:44 CDT(-0500)] <Bosmon2> It is a dialog which shows a list of choices
[13:03:54 CDT(-0500)] <Bosmon2> And this may have a different width depending on the text in the rows
[13:04:10 CDT(-0500)] <heidi> okay
[13:04:16 CDT(-0500)] <Bosmon2> I would like it not to be "outrageously big" but generally big enough to show the longest choice without wrappin
[13:04:16 CDT(-0500)] <Bosmon2> g
[13:05:29 CDT(-0500)] <heidi> so you could get the size of a choice
[13:05:35 CDT(-0500)] <heidi> and then set a css value based on that
[13:05:39 CDT(-0500)] <Bosmon2> Yes
[13:05:48 CDT(-0500)] <Bosmon2> But how could I get its size before showing something?
[13:06:09 CDT(-0500)] <heidi> hide the div until you want to show it in its right size?
[13:06:42 CDT(-0500)] <Bosmon2> Isn't it likely that hiding it will cause it not to have a size allocated?
[13:07:18 CDT(-0500)] <heidi> you're going to set the size before you show it ?
[13:07:37 CDT(-0500)] <heidi> oh
[13:08:00 CDT(-0500)] <heidi> can you get the size of the choices
[13:08:35 CDT(-0500)] <heidi> and then just set the dialog width every time ?
[13:10:10 CDT(-0500)] <heidi> i'm not sure if i'm helpig you or making things more confusing :|
[13:11:51 CDT(-0500)] <Bosmon2> Well, I just want it to appear once
[13:12:04 CDT(-0500)] <Bosmon2> I don't want it to appear, think about itself for a while, and then appear narrower
[13:12:27 CDT(-0500)] <heidi> so set the div's initial value to hidden, set the width, then show it
[13:15:08 CDT(-0500)] <Bosmon2> Ok, I will give it a try, thanks