AW: AW: AW: AW: [Zope3-Users] z3c.form - howto ignore the contextfor singlewidgets in an Edit form?

[Roger Ineichen]

Hi Christophe

> Betreff: Re: AW: AW: AW: [Zope3-Users] z3c.form - howto 
> ignore the contextfor singlewidgets in an Edit form?

[...]

> > PS;
> > I really like to get the memory usage for a single zope 
> server below 
> > of 30 MB in the near future.
> 
> Hi Roger
> 
> Some thoughts on this topic (hoping this has not been already 
> deeply discussed and concluded)
> 
> I see that what I called the "worst case" (1 egg per widget) 
> is exactly what you would like to see. Actually I don't 
> understand the reason, unless you're working on an embedded 
> zope that must fit in a really small system, which is not the 
> most common case.

Yes, I'm working on a small as possible zope instance.
The reason is that we need a fast and low memory using
zope3 base.

> I don't see a problem in having some unused code. If this 
> code is not import(ed) in python, or include(d) in zcml, it 
> will not be used nor loaded in the memory (or am I wrong?) I 
> find that having to wonder which tens of eggs to import and 
> whether they really work with each others or not is more pain 
> than just having fewer eggs, and searching inside them what 
> they offer, while being sure they are consistent.
> I find it great to create an interface with several fields 
> (all available in one egg), then to be able to have the 
> system generate predefined forms automatically, without 
> looking in the pypi for missing widgets. If some provided 
> widget is not ok for my use, then I can search alternative 
> widgets in separate eggs, or implement mine.

For one of our application our customer a swiss bank, reviews
the code we use and write. It's a realy pain to split existing
unused code for this project. And we don't like to document
code which we don't use.

> This is particularly true for newcomers, that don't know how 
> (and why) components are separated, and must understand a 
> whole lot of things before knowing they must seek a 
> particular egg for the micro-feature they want.

I guess it's better to learn what's going on then to
develope for newcommers. I guess Grok is the right place
for them. Not that Grok is bad, but the target of Grok, 
as far as I can see, is the ability to develop with minimal
effort and everything should just work.

I guess this is not true for zope as "the component system".
There you really have to know what's going on. Or at least
you need to learn that if it comes to speedup optimisation.
There is no Zope3 which fits for everything and z3c packages
which most of them are base libraries are not the level to
blow them up. I realy like to have small independent packages
with minimal dependencies which I can assamble to the right
thing for each project. 

> Feature separation can be made at different levels: an egg 
> contains several packages that contain several modules that 
> contain several classes, and I think you will always have 
> unused classes in a module, unused modules in a package and 
> unused packages in an egg, unless there is one egg per class...
> What you really want is having control on what is eventually 
> loaded. Isn't it already possible with zcml?

The exclude directive form zc.configuration helps a lot
to exlude configuration loading. But independent eggs
make it more explicit and let people think one more 
time about their dependencies which is allways a good thing.

> Or maybe all this would be easier with meta-eggs?

Yes, you are right, we can provide a egg with battery included.
This let us include one egg which includes different 
packages with one single include.


Regards
Roger Ineichen
_____________________________
END OF MESSAGE

> regards,
> Christophe
> 
> > 
> > Regards
> > Roger Ineichen
> > 
> > 
> >> Best Regards,
> >> Hermann
> >>
> >> --
> >> hermann at qwer.tk
> >> GPG key ID: 299893C7 (on keyservers)
> >> FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
> >>
> > 
> > 
> > 
> 
> _______________________________________________
> Zope3-users mailing list
> Zope3-users at zope.org
> http://mail.zope.org/mailman/listinfo/zope3-users
>