Re: optional policy

In article <[email protected]>, Dallas Johnston
<[email protected]> writes
.....
>As I said in my previous mail, this can be done easily by moving the import code 
>into the wrapperFactory method. Also, all the *.pyc bytecode files are created 
>at anygui *setup* time (byte compiling foo...), not at import.
>

I've not actually done a setup at all I'm using the CVS stuff directly.
I agree that the import should be lazy.

>>So let's just define an  anygui backend which implements everything that
>>isn't implemented by some other backend. I guess that's what I really
>>against here. The layers seem to be congealing together which I think
>>anygui is supposed to be against.
>
>I don't think that this is what I'm suggesting. I just simply recapitulated what 
>it was that had already been descussed concerning providing frontend versions of 
>certain widgets and dialogs that do not exist in some of the backends. This 
>keeps those backends from having to code it themselves.
>

I was pushing the argument to an extreme here, but since we have the
machinery for backends couldn't so called front ends widgets be done
that way.
.......
>
>Ok. I see your point. I'm assuming that you want to move the class selection 
>into the backendModule() function [not backend()], and then have the user 
>specify *Dialog(version='frontend') or *Dialog(version='backend'), the latter 
>being the default? But I don't think that this is all too different than 
>allowing them to instantiate the object specifically via Anygui*Dialog(), as 
>opposed to the backend version via *Dialog(), and having creation resort to the 
>Anygui*Dialog version when the native one doesn't exist.
>

yes, but allowing the version thing here seems wrong. I guess policy
implies something like an overall choice. I think these soft widgets
should be considered as plugins rather than being essential.

>>there are standard dialogs (indeed supposedly native ones) in Tk and in
>>ms they just haven't been implemented.
>>
>>I'm not against the possible generic things, I just think they shouldn't
>>be part of the default anygui only the abstract part should normally be
>>generic. That will encourage the backends to support the proper front
>>end.
>
>I believe this is exactly what I am talking about. Again, and forgive the 
>belabouring here, doing with *Dialogs as I did with ComboBox, only allowing the 
>user to choose dialog version via class name, not an __init__ parameter.  This 
>type of change would only literally take a few minutes to setup.
..... I am against special cases. If combobox is to be considered
special, why not label, textarea etc etc. I take the anygui version of
any supported widget to be that defined by anygui and the backend, by
introducing another case at the user level I believe we make things
harder to understand, by just having a fallback/preferred combobox you
don't change the architecture, just the implementation.
-- 
Robin Becker


-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html