> On Jan 4, 2022, at 8:48 AM, Yishay Weiss <yishayj...@hotmail.com> wrote: > > I understand this isn’t strictly PAYG but I consider it to be part of > UIBase’s lifecycle. One advantage is that MVC (and layout for containers) > beads can be injected without changing code. So if, for instance, you want to > add a controller that checks permissions and enables or disables a text area > accordingly you can do that without changing your code, except to add > controller (and possibly a view) that checks for that and acts on your text > areas. You can even do that in your css files without having to extend > existing classes. > >> There’s now a function needsView() and needsController() in UIBase. It >> defaults to true > > I think it should stay that way for the reason I stated above. Note that > adding this function in UIBase is a PAYG compromise in itself.
OK. Yes. It’s a compromise due to the fact that MVC is baked into UIBase (which wasn’t really PAYG to start with). >> not a great way to get a model int he first place because you’re looping >> through the beads to find the model every time you access it > > There was a discussion in the past about making getBeadByType more performant > through caching or whatever. I haven’t profiled to see how significant that > is though. If type checks are expensive then it probably is. I was seeing it in the profiler before I made my changes. Now I have to search really hard to find any calls to that in my app. Spectrum is now REALLY performant. Currently the most obvious place to improve performance is getting rid of the goog event system. The other component sets will need profiling to see what other improvements can be made. >> I changed models to only be loaded the first time it was actually requested. > > Our implementation is a bit mixed, but the initial design was to assume beads > were loaded in a certain order. Beads loaded after model should work on the > assumption that it already exists (and has possible been initialized). I > would be careful to introduce lazy loading for models for that reason. > > Thoughts? In general, I would usually suggest to only have bead-to-bead access on beadsAdded or later. That way order makes no difference. That said, making model lazy-loading will not change anything. The model will always be available when it’s needed. The only case where things might be weird is where: 1. You have a bead which expects a model when it’s loaded. 2. You declare the bead in #1 BEFORE a custom model bead in mxml (not css). The above is a mistake. and you’ll get the default model as" the model” and the custom model as an additional model but will not be accessible using the model getter. FWIW, I just searched through the code again and found a few model getters that I missed the first time around. That should be fixed now. My $0.02, Harbs
