On Apr 20, 4:43 pm, Remy Blank <[email protected]> wrote: > 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...
There is no such thing - there may be some similarities in the Trac code based on the model code originally sharing some common patterns, but I don't have an 'exists' property/method for my FullBlog model for blog posts (as one example). For Bitten this is different as a resource in the 'build' realm can be either a configuration or a specific build number - meaning you can also get completely different type of model objects back depending on ID. Nothing can or should be assumed about what it represents. > > 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. The major selling point for 'resources' as a concept was that we needed lots of them when dealing with the new security system for 0.11, and generally needed a cheap way to create and mutate something to identify a Trac resource without instantiating them. We create resources all over the place, mutate and shape them as we need for the use-cases we need - not to mention the big unknown quantity of plugins using, reusing or mutating resources as they fly by. Thinking back, we had some heated discussion about what they should look like. IIRC, Christopher argued for using a tuple (cheap and easy), I argued for using a plain path string (identification identical to what we use in URL), and we ended up on thin Object structure suggested by Christian as it provided the possibility to add some nifty tweaks for efficient usage. I was fine with that then, and generally I think the resource system has worked well. Regardless of design discussed and chosen, the idea was that resource and model should be very loosely coupled - no actual coupling in fact as nothing can be inferred about the underlying model implementation. So, we have ended up with lots of code that create resources. We have a lot of code that create half-baked resources that we mutate. If these resources also could contain references to model objects of unknown state and origin, that would in my opinion be a recipe for disaster - certainly when developers started to use that as an entry point to the model objects, and the resource and model somehow persisted or was cached. The 'convenience' we have generally used so far has in fact been the other way around as we have attached a Resource object to the Model in order to have it at hand. That then causes intermingled and possibly circular references. Each added layer, and each feature added to each layer, increases the complexity. We'd get all kinds of hard-to-debug errors that sporadically arise due to some strange combination of circumstances. "Explicit is better than implicit" as the zen says, and I cringe each time I offer support on IRC pointing people to formatter.context.resource as location of this very important information in macro code. Let 10 able coders stare at the Trac code and see if any of them come up with formatter.context.resource.model as the obvious starting point to access properties they need... If something is important and needed, then pass it explicity. Complex objects that reference other known and unknown objects in ways that are hard to detect, literally caused me months of sleepless nights while trying to figure out the rare circumstance why my site went down at irratic intervals: http://trac-hacks.org/changeset/4366 The only way these new suggestions makes sense is if the resource (and user of the resource) could make some general assumptions about the underlying model. Which I suppose is GenericTrac again... Personally I'm not in favour of this, and enjoy the flexibility currently enjoyed. As one example against the #8834 ticket (generic resource change listening/notification), my FullBlog needs to notify when comments are added. Comments are not resources, and they do not create a new version of the blog post itself which is separately editable for new versions. Still, for notifications, comments are just as important as the resource itself. Shoe-horning all features into common model-, manipulator- and listener infrastructure is contrary to the general "feel" of the code base that has made Trac successful and enabled the great variety of plugins that we actually have. I know, at one stage I actually championed accessing model through resource, but that was in the name of "security" and not "convenience". My idea was that the resource system could be the gateway to accessing data in a new abstracted "business layer" that worked regardless of entry point (commandline, request, ++) and where security was included for free - the developer need not be concerned with security directly as that would be gated through the resource system. We won't be getting there (it has been a few years since we discussed this), and now I have a strong preference for simple and explicit. Accessing or inferring anything about models through resources is -1 from me. :::simon https://www.coderesort.com http://www.ohloh.net/accounts/osimons -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
