schooltool-developers team mailing list archive

[Justas <justas@xxxxxx>]

Hey,

> I made the two changes we discussed at the meeting, fixing evolve7 and
> fixing updatePersonsResponsible while adding test update views for
> better test coverage.  Additionally, I made a couple more quick fixes
> that involved re-organizing the code and zcml files in line with what
> you had suggested at the sprint and moving all the templates into a
> templates directory.  I like how much easier it is to find things this
> way, and it was timely, too, because Filip will be building a similar
> package in schooltool.courseinfo.  This way he has a better example in
> schooltool.intervention.

Cool :)

> Please take a close look at my most recent commit because I'd like to
> fix anything you find wrong before the weekend is out.  The commit is
> for removing dependency on schooltool.gradebook.  It involves three
> packages being merged at the same time, the intervention branch and
> two new branches I pushed,
> lp:~aelkner/schooltool/independent_activities  and
> lp:~aelkner/schooltool.gradebook/independent_activities.  This
> requires changing buildout.cfg temporarily to point to a checkout of
> my new core branch, so my sandbox has all three branches side by side,
> and I tested adding and removing schooltool.gradebook from
> buildout.cfg.

  I noticed you committed your sandbox buildout.cfg versions for 
gradebook and intervention.  Please fix!

> The way I removed the dependency was by defining an interface in
> schooltool core called IIndependentActivites.  The intervention views
> that used to look for IActivities(section), a gradebook dependency,
> now adapt to IIndependentActivites.  If schooltool.gradebook is not in
> the build, the adapter lookup will fail, returning None which the
> intervention views will be able to handle.  If schooltool.gradebook is
> in the build, it will supply the requested adapter, returning
> IActivities(section) which is what the intervention views need.

  Sorry, a very firm no for IIndependentActivities going into core.
  At the moment we don't have a built-in way to define a "soft" 
dependency on another plug-in.

  Ideally, there should be zcml files in the intervention package, that 
include certain python modules (say, 
schooltool/intervention/gradebook_integration.py) only if 
schooltool.gradebook is included.

  Basically, in gradebook's main zcml file, there should be a line:
<meta:provides feature="plugin-schooltool.gradebook" />
  And of course a namespace definition at the top of the file, next to 
others:
   xmlns:meta="http://namespaces.zope.org/meta";

  Then, in intervention package, configure.zcml, there should be an 
conditional include:
<include zcml:condition="have plugin-schooltool.gradebook"
      file="schooltool.gradebook-integration.zcml" />

  And the namespace definition again:
      xmlns:zcml="http://namespaces.zope.org/zcml";

  This way schooltool.gradebook-integration.zcml will be included only 
if schooltool.gradebook is included.  Classes and methods that depend on 
imports from schooltool.gradebook should be moved to separate files that 
are used from schooltool.gradebook-integration.zcml.

  As a simplest step, you can do this:
  - keep the IIndependentActivities, but define it in 
schooltool/intervention/interfaces.py.
  - put an adapter to IIndependentActivities to 
intervention/gradebook_integration.py
  - define the adapter in schooltool.gradebook-integration.zcml and
  - do the include with zcml:condition in intervention/configure.zcml

  As far as the testing of integration goes... It's a deeper issue.  
Let me think over it and get back at you on Monday.

  For now you could keep your tests that register the stub adapter to 
IIndependentActivities and show that when such adapter exists, the views 
show pull correct gradebook information.  Keep gradebook_integration.py 
and schooltool.gradebook-integration.zcml untested.  Just check 
manually, that when gradebook is included, interventions work.

  To sum up:
  - few small changes for gradebook that provide the feature
  - moving the interface and adapter from core to the intervention package
  - a small check that provides the adapter when gradebook is included 
in intervention package

  This would be a great step forward to standardized plugin 
interoperability.  I'd really appreciate that.

> I created stubs for this in ftests.py, only registered via
> ftesting.zcml, that deliver a fake IActivities(section) heirachy,
> allowing for more complete coverage of the views that formerly had the
> gradebook dependency but didn't have any test coverage.  For this, I
> created a functional test file, independent_activities.txt which, in
> chosing the section title, is able to test how those views would
> handle schooltool.gradebook presense or absense.
>
> One last thing had to change, and it has been long overdue.  Until
> now, schooltool.gradebook had a view for ISchooltoolApplication that
> simply gives a message telling the user to set up a term.  I know that
> you may have some ideas for what the view should say, so now would be
> a good time for that.  In any event, I needed to move that view out of
> schooltool.gradebook and into core so that the intervention package
> could get at it.  Again, this is a reason that all three of my
> branches have to merged at the same time.

  I still strongly oppose that view getting into core.  There are too 
many things I don't like about it, and if you need to duplicate code, 
then code duplication it is.

  - it's our software design issue in general that we can access stuff 
that is not configured
  - it is not good that when users create the term and refresh the view 
- it still shows "please create a term"
   - it's also bad that after creating the term you need to reload all 
pages that have, say, "Intervention" top navigation links - or else they 
get a message "please create a term" if they click them

  So please either make a duplicate view with a different name in 
intervention package, or better - modify the relevant intervention views 
to display the message (say, render different template).

  In the end there should be no changes in core, 1 small change in 
gradebook to provide "plugin-schooltool.gradebook" feature and the rest 
of the changes done in schooltool.intervention.

Hope this helps,
Justas