> osimons wrote:
>> 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.
>
> Ok, that's the current state of things in FullBlog and Bitten, but in
> both cases, a .exists attribute would make sense, wouldn't it? It
> answers a very simple, very general question: does this resource exist?
>
>> 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.
>
> Passing the environment when creating the resource (or the resource
> manager) would indeed slow down instantiation, but adding a
> get_model(env) method wouldn't have an impact on performance.
Even a Resource.get_resource_manager(env) would have little impact on the
system, provided that there is a general broker for resource managers, for
example Environment, which then would provide a get_resource_manager(
realm ) method.
Furthermore, extending the IResourceManager interface so that it will
+does_resource_exist( resource )
would allow Resource to also implement the exists property.
In all, this would be just two to three indirections, and, based on the
implementation of the resource manager in charge, a simple query to the
database or a fetch of the underlying model and a query on its exists
property.
Basically this would be defined so
IResourceManager
+does_resource_exist( resource_or_resource_id ) : boolean //new method
Resource
+get_resource_manager( env ) : IResourceManager // new method
exists = property( fget = lambda self: self.get_resource_manager(
self.realm ).does_resource_exist( self ) )
In Resource#get_resource_manager( env ) then
def get_resource_manager( env ) :
return env.get_resource_manager( self.realm )
and in Environment then we would have both the central component manager
and the central broker for resource managers that would provide us with
instances of the resource managers for specified realms, e.g.
Environment
+get_resource_manager( realm ) : IResourceManager
Would that make any sense? Or would it be performant enough to satisfy all
parties involved?
Regards,
Carsten
--
Carsten Klein
Mobil +491 577 666 256 5
[email protected]
axn software UG (haftungsbeschränkt)
Wipperfürther Str. 278, 51515 Kürten
Geschäftsführung Carsten Klein
HRB 66732, Gerichtsstand Amtsgericht Bergisch Gladbach
Steuernr. 204/5740/0835, USt-IdNr. DE 266 540 939
Telefon +492 268 801 285, Telefax +492 268 801 285
www.axn-software.de, [email protected]
--
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.
