Christian Boos wrote: > Not good. But once you know you can call things like `model.exists`, or > you can do other useful things with a model object then it will make > sense. But maybe you had some other use cases in mind?
I had a lowest common denominator in mind, which indeed does seem to consist solely of `.exists`. That... > The other related use cases I can think of are the > IResourceChangeListener (discussed in > http://trac.edgewall.org/ticket/8834) ... and the IResourceChangeListener, yes. > In this situation what's problematic is not > so much the possibility to create a model from a resource in a generic > way, but the fact that this creation has to be *repeated* over and over > again. Exactly, it would be a convenience functionality, and an optimization in the case of IResourceChangeListener, as every listener would get the same Resource object (with the same model object associated). > a) and b) together might fit > the bill: when accessing resource.model the first time, a call to > `resource_get_model` could be made, binding the model to the resource. I'm not too keen on caching, actually. Model objects are mutable (e.g. the version of a WikiPage increases when saving), so this would be tricky to get right. However, if we attach the model object to the resource on first lookup, without any caching, we should already have all the convenience we need. > Not to mention that if we would store the resource > manager itself instead of the env, we would avoid a component lookup > each time one of these helper is called... This sounds like a good plan, yes. -- Remy
signature.asc
Description: OpenPGP digital signature
