[kforge-dev] Error in kforge trunk related to creation of trac
service via web user interface
rufus.pollock at okfn.org
Sun Aug 27 13:25:12 BST 2006
John Bywater wrote:
> Rufus Pollock wrote:
> Yes, something is broken.
> getAssociat-ION-Object :-) I think you looked at the right code though....
>> is defined in dm.view.base.AbstractHasManyView where it is set to None
>> in the __init__ method. I can't see it being set anywhere else. John,
>> I know you wrote this section of the code so I wondered if you knew
>> what was going on here and what should be fixed (would be useful to
>> know what an associationObject was or was supposed to do -- some
>> documentation on that class might be useful ...).
> Some more tests would also be useful. That method is in the
Regarding the tests I agree 100%. Of course here the problem lay in the
web gui which is the hardest thing to test (and that whose
functionality/interface changes most rapidly). Furthermore in this case
a test would involve stepping through several stages of the web gui
(login, go to project services page, create service, create extension
object). Nevertheless I was just looking at webunit of (python)
mechanize to see if I could use them to automate the very set of
actions which resulted in this failure.
> ServiceExtnView, which I'll come back to. Firstly...
> ## Associate, Aquaintance, Associations ##
> In OO terminology, an object can have be associated with another. The
> association is sometimes an object.
> In KForge a Person can have an association with a Project. The
> association is called Member. The Project is then an associated object
> or an aquaintance of the Person.
> Likewise, a Service is an association between a Project and a Plugin.
> ## AbstractHasManyView ##
> The abstract HasMany view is the base class for CRUDing the register of
> objects held by a domain object within a HasMany attribute.
> The getAssociationObject() method is used to retrieve the object keyed
> by the hasManyKey (a string) in the domain object's HasMany attribute
> ## ServiceView ##
> For Service views, you get a Service domain object by calling the
> getAssociationObject method. This happens a lot in the Service views.
> ## ServiceExtnView ##
> The ServiceExtnView extends the Service view, and supportings CRUDing of
> service extentions, which is the mechanism to plugin the particular
> objects of plugin service instance into the domain model (such as the
> TracProject object which is needed to support associating a Trac Service
> with a Subversion Service).
> As such, this view always expects that the Service object is available.
> It isn't available. The service variable has a ref to None.
Very clear. Thanks for the the explanation.
> ## Diagnosis ##
> There is a problem with the trac Service object being located. Does it
> exist? Was it created with the previous page? Ie if you click back to
> the Project read view and refresh, does the object appear? It so, there
> is something wrong with finding a new trac Service in that ServiceExtn
Yes it was created. When I went back to the previous page the service
was there and I could delete it (and then could try again!)
> An exception reporting the non-existence of the Service object would be
> sufficient documentation for this error. Perhaps this could usefully be
> in a getService() method on the ServiceExtnView.
I don't think we necessarily need to document the error (that was
relatively easy to trace). What was difficult to know was what the
associationObject (which was None) was supposed to be and where it
should have been set. So, for example, a short comment in the class
docstring where associationObject is first defined giving some
information about its purpose might be useful.
> I'll try to replicate the problem. Will let you know what happens.
> In the meantime, can you write a test to reveal this problem?
Will try to (see above). Thanks for your detailed comments and
assistance in fixing this.
More information about the kforge-dev