[FE-discuss] Re: FormEncode and GenericTemplates

On Thu, 07 Oct 2004 16:41:51 -0500, Ian Bicking <ia...@co...> wrote:
> Sure.  I've also copied the FormEncode list, small though it might be.
> I should warn you that FormEncode is a little delapidated at the moment
> -- there's a bunch of cleanup because of changed interfaces in
> PyProtocols, and generally the use of adaptation was confusing and fragile.

I joined the list today. Coincidently (or not?) I'm also checking
PyProtocols, but I may end up using my own home baked solution. I'm
trying to keep things small and modular, so let us see what is better
in this case.
 
> In what ways do you see your goals as different?

My work started with a broader, and more ambitious goal to be able to
write interface declarations that could be used to generate native GUI
applications and Web applications. I was not concerned with full
featured GUI apps, but only with the data entry forms; I still think
this goal is feasible. But as time goes by, I'm getting closer to the
FormEncode  & SQLobject approach. In my opinion this convergence is
significant because it shows where the problem really lies.

> Some of the basic logic of declarative classes in FormEncode is in the
> declarative module, which might relate to your nested class declaration
> code.

Yes, I see the parallels. But right now, my templating package is much
simpler. I don't know whether I'll be able to keep it as simple as I
add more functionality. I sincerely hope so; I believe in keeping
modules simple and small, with as little internal dependencies as
possible.
 
> Probably where we diverged is that I chose not to dynamically make
> classes.  Lots of code is just going to get terribly confused with
> dynamic classes, e.g., pickle or ZODB.  Also, it becomes confusing to
> the user whether they need to add class methods or instance methods for
> a particular functionality.  There's other confusions -- for instance,
> classes have names, but if you dynamically create a class you'll have to
> make up a name, because the class has to be created before it is bound
> to a name.

That's still bothering me a lot. And you're right about the naming
issue, which becomes particularly bothersome when you're debugging and
can't trust the class name in the logging output.

> Sure.  Maybe this can get me back in the mind of FormEncode as well.

As I said, I've just joined the FormEncode list. Over this weekend
there will be a huge holiday here in Brazil (October 12, Holy Mary,
it's a national holiday). I'll be travelling with family & kids, and
I'll only be back the following week. I may be able to keep in touch
but I'll probably not be able to work on the code. But it'll be a good
oportunity to have some of the ideas to settle down.

Regards,

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...