[Zope-dev] BannerFolder (Re: [Zope-dev] TIP: Must enable 'new' for FreeBSD Python 1.5.2 port to install PythonMethods)

[Bill Anderson]

Lalo Martins wrote:
> 
> On Fri, Feb 18, 2000 at 02:54:13PM -0700, Bill Anderson wrote:
> >
> > What Counters? Are you talking about the hits, views, or remaining_views
> > ?
> > Inguiring minds need to know. :)
> 
> All of them. It's a known, hmm, ``TODO item'' :-) for
> BannerFolder.
> 
> > FWIW, I am in the middle of a 'rewrite' of that product. I am adding the
> > ability to 'weight' banners, view reports, and track click-throughs.
> 
> This is very good. I was trying to figure out a way to implement weighting.

You'd love how simpleand  elegant it is (in Python) :)

I've also got a new type of banner. Well, actually I made two types,
'local' and 'remote'. Local banners are the stock banner, and remote are
the kind you get from other sites. The remote banners are good for where
you do't actually store the image, but rather you get 'code' from the
remote site, and the code contains the image url.
 
> > Other changes are that it is being written in Python instead of
> > ZClasses.
> 
> This is _not_ good, please reconsider. ZClasses are the ``new''
> and ``right'' way to extend Zope. Restarting the server each
> time you make a minor modification is bad. ZClasses are more
> maintanable too.

Well, I am looking at two methods, one would have Base Classes in
Python, that the ZClasses would inherit from. The management would all
be done inside of Zope. I am implementing a "BannerManager" that would
determine the defaults, etc.. 

One advantage of Python is that it could be independant, as opposed to
being dependant on other products. Perhaps the mix of ZClasses and
Python would be the best.
 
> What is important is to abstract out the counters; perhaps, let
> the BannerFolder decide how they are stored, or use acquisition
> (because BannerAd objects are often useful outside a
> BannerFolder - I use one for my ``hosted by GFDigital''
> button). Something like calling
> ``get_counter (this(), _, counter_name)'' and set_counter
> likewise. So all you have to do is drop a SQLMethod or
> something in the acquisition path.

Hmmm... an interesting thought.
 
> If you keep it ZClass-based, I'd be glad to make you the
> official maintainer of the Product for the next few versions
> (in short, as long as you're interested).

Well, I originally started modifying the ZClasses, but found certain
issues I haven't been able to get around. Namely the remote banner data
interference message I posted earlier. :(
 

If I could get that resolved, I would not mind having an 'interim' where
the new features were implemented in the ZClasses.

-- 
In flying I have learned that carelessness and overconfidence are 
usually far more dangerous than deliberately accepted risks. 
          -- Wilbur Wright in a letter to his father, September 1900