Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher Lozinski wrote:
> It is very very hard to find anyone who both appreciates TTW
> development, and understands the multiple layers of ZTK and Grok.
>

Guess why? Because it is technology of the last decade and everybody
moved on?!

- -aj

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQGUBAEBAgAGBQJT2NLQAAoJEADcfz7u4AZjFuYLvR5aokf1m9Knxfte1FZGZDnE
PbiyOrQuMcKgzs0AXn7QtYBvMfeELc/FUZRC9T8O5jnadpwhm5hmry+HhyAU+RJk
ht0izl85K2TU+eG7zLJUYtqF81I3zHof/n/Enb85+s/r8dHi5ODW9IoJ17iJp5GI
kmeT8Jz8hRIfqdkFcLDViSxFGri9OpNinIEu+vTHm04831hacyLy+03dpKQyo1Pe
tSwv2d24+Fp7ZoqVzGC1EkRKr+B6Ms9duhQ4hBDZxW0bGndno/bBtw49Vqtw7g7/
Q8I884dITLUE2SN4pbBOIguc7bbs0PLGaC+W/Y6s8CXUad8bRMaGdqu7VS4oUOaT
PVa1UMDhhX/+ADfDFReFJpPonKl5vTLjC99Y0UvxvzQfudmKvRr4JwjxUw68HsHT
jVdrslv9m5I2eQ9Jk1DiC9o/m41iNIQfD4eUoKFeL5IBOtXpoO2ZYhHliXxH4db7
Tu6zjjrxqfmIqxvsnLDT7wcpbp+OJBQ=
=Lm0c
-----END PGP SIGNATURE-----
_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )

Hello,

Did you have a look to Substance D ?
http://substanced.readthedocs.org/en/latest/
It is based on Pyramid, it uses a ZODB for storage, and it provides a ZMI
like management interface.
And you can use all the good ZCA stuff if you want to.

Eric


On Wed, Jul 30, 2014 at 12:56 PM, Christopher Lozinski <
lozinski@freerecruiting.com> wrote:

> I have a basic version of Zopache running internally. It is a zope-2
> like ZMI running on top of
> grok on top of ZTK. ZTK is really very nicely written.
> Grok makes it so much easier to use the ZTK.
> I an focused on using it to build my next generation recruiting website,
> but it would be good to have someone to talk to about this stuff. It
> is very
> very hard to find anyone who both appreciates TTW development, and
> understands
> the multiple layers of ZTK and Grok.
>
> Anyhow if you are curious I am clozinski on skype.
>
> Regards
> Chris
> _______________________________________________
> Zope maillist - Zope@zope.org
> https://mail.zope.org/mailman/listinfo/zope
> ** No cross posts or HTML encoding! **
> (Related lists -
> https://mail.zope.org/mailman/listinfo/zope-announce
> https://mail.zope.org/mailman/listinfo/zope-dev )
>

On 7/30/14, 3:59 PM, Eric Bréhault wrote:
> Hello,
>
> Did you have a look to Substance D
> ? http://substanced.readthedocs.org/en/latest/

Yes I did. Thank you. Someone on the Grok mailing list mentioned it.
My understanding is that Pyramid is based on ZTK, but not on Grok.
Personally I find ZTK way too painful to use. In contrast Grok is
really quite easy to use.

Regards
Chris
_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )

On 7/30/14, 2:11 PM, Andreas Jung wrote:
> Guess why? Because it is technology of the last decade
Maybe, but Unix file system development is at least 36 years old.
Is that what you are still using? Technology from the last century?

http://www3.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1905.pdf

Regards
Chris
_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )

On 7/30/14, 6:32 PM, zopyxfilter@gmail.com wrote:
> Pyramid uses _some_ ZTK modules internally however the ZTK stuff
> is not exposed to Pyramid.
Thank You. That is why I love Grok and ZTK. It is this rich library
of extensible python components conforming to ZCA.

Maybe Pyramid is closer to a framework, very stripped down, the ZCA is
hidden. Pyramid uses ZCA, but does not encourage it. Grok is really a
rich library of reusable components.

I am only sorry that more people are not actively developing on Grok and
ZCA.

Chris
_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )

Christopher Lozinski wrote:
> On 7/30/14, 6:32 PM, zopyxfilter@gmail.com wrote:
>> Pyramid uses _some_ ZTK modules internally however the ZTK stuff
>> is not exposed to Pyramid.
> Thank You. That is why I love Grok and ZTK. It is this rich library
> of extensible python components conforming to ZCA.
>
> Maybe Pyramid is closer to a framework, very stripped down, the ZCA is
> hidden. Pyramid uses ZCA, but does not encourage it. Grok is really a
> rich library of reusable components.
>
> I am only sorry that more people are not actively developing on Grok and
> ZCA.

This is your annual complaint for 2014?

Andreas
_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )

On 7/30/14, 8:01 PM, Andreas Jung wrote:
>> > I am only sorry that more people are not actively developing on Grok and
>> > ZCA.
> This is your annual complaint for 2014?
It is not a complaint. It is really more of a question. Let me spell
it out in detail.

I would think that the world has to move to massive class libraries of
reusable software components, maybe not on the client side, because it
takes time to download, but certainly on the server side. Not in
statically bound languages like Java or C++, but in dynamically bound
languages, like like python or C#. The only significant python
component architecture I know of is ZCA. Maybe there is one in C# So I
would expect lots of people to be using
ZCA, most easily in Grok. And Grok is quite easy to use. And yet
that is not happening.

Why not i wonder?

There is one prominent blogger who explained he just got too frustrated,
but mostly people do not post their stories
of failures. They just disappear, so it is hard to abstract what the
problems are.


Chris

_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )

On 07/30/2014 12:56 PM, Christopher Lozinski wrote:
> I have a basic version of Zopache running internally. It is a zope-2
> like ZMI running on top of
> grok on top of ZTK. ZTK is really very nicely written.
> Grok makes it so much easier to use the ZTK.
> I an focused on using it to build my next generation recruiting website,
> but it would be good to have someone to talk to about this stuff. It
> is very
> very hard to find anyone who both appreciates TTW development, and
> understands
> the multiple layers of ZTK and Grok.
I am a quite happy user of zope 2.9.x, although most likely my
application will have to be ported to tomcat (using jython) in the short
term.

I keep data in MySQL, I had to replace most products with Extensions for
lack of support, didn't use the TTW classes. I use little of the zope
API and no roles (I use my own security roles in the database) .

I like the ZMI, error_log, Zope DB Adapter, ZSQL, and Python Scripts
which hide the web machinery from me. I like the easy access to the
running environment for testing and maintenance purposes. I love the ZPT
and Python.

I have a nice UI/BusinessRules/DataAccess architecture that makes it
easy to do maintenance at minimal cost. It is very easy to jump in and
fix/improve code, especially considering I only do it on occasion.

There are of course limitations to this environment, in particular for
developers that need all the file system tools for development and
collaboration. But has it stands, it is very cost effective for some use
cases.

I don't know about ZTK, Grok.

Fernando Martins
> Anyhow if you are curious I am clozinski on skype.
>
> Regards
> Chris
> _______________________________________________
> Zope maillist - Zope@zope.org
> https://mail.zope.org/mailman/listinfo/zope
> ** No cross posts or HTML encoding! **
> (Related lists -
> https://mail.zope.org/mailman/listinfo/zope-announce
> https://mail.zope.org/mailman/listinfo/zope-dev )
>

_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )

On 7/30/14, 10:50 PM, Fernando Martins wrote:
> I don't know about ZTK, Grok.
Well let me start of by describing them, and some history, so that we
are all on the page. At the risk of overloading the term, so that we
share the same context.

First there was Zope 2. It was pretty cool for its time. Lots of
people jumped on board, and created many products. That is when the
trouble started.
If Zope 2 did not meet the needs of the product developers, it was
monkey patched. Meaning people would replace a python method at
run-time. This was fine until two products would monkey patch the same
method. This caused trouble. Something better was needed.

So they moved to the Zope Comjponent Architecture (ZCA). Really they
should have called it the python component architecture. Huge marketing
error.
ZCA manages adaptors. An adaptor is a small python object that points
to the original object. The adaptor can have the new needed method on
it. All other methods are dispatched to the original object. If two
users of the same object want to replace the same method, they just use
two different adaptors.

So Zope 3 was born. It had a nice ZMI, but no acquisition, and this
weird registration stuff. Worse yet file system development in Zope 3
with ZCML registrations was just too painful. And the security was way
too tight. Everything was forbidden until explicitly permitted.

So along came Grok. Without going into detail it made it quite
reasonable to do file system development. And it simplified security.
Everything is possible, unless forbidden. Much closer to what I want.

So that was progress. But it was still too complicated. And there were
too many circular dependencies. And there is a huge community who did
not like the ZMI, and so they split Zope 3 into two parts. Zope.* and
zope.app.* The later had all the GUI stuff. The zope.* part without
the GUI they called ZTK.

Okay so that tells you what ZTK and Grok are. Back to your application.


On 7/30/14, 10:50 PM, Fernando Martins wrote:
> (I use my own security roles in the database) .

Well that is very interesting. One of my biggest complaints about Zope
2 was the security model. Security was on the instances. Not possible
to just make security declarations on the classes, without having to
also declare it on the instances. So I am hugely curious about your
security model. The grok security model, while better than ZTK, still
leaves a lot to be desired. Fortunately it is quite easy to replace.



On 7/30/14, 10:50 PM, Fernando Martins wrote:
> although most likely my application will have to be ported to tomcat
> (using jython) in the short term.

Why tomcat? I would think that there would be many native python web
servers you could use. Have you considered Pyramid.
It also uses the ZODB and traversal.








_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )

On 7/30/14 6:07 AM, Christopher Lozinski wrote:
> On 7/30/14, 2:11 PM, Andreas Jung wrote:
> Maybe, but Unix file system development is at least 36 years old.

Heheh, touché.

Some reasons many Zope developers may have moved on, with a tear in
their eye:

- fashion

- community

- maintaining large projects written in a dynamic language gets very
costly (think of the number of runtime errors you've run into while
working with zope projects). Today's newer & better statically typed
languages help quite a lot.






_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )

On 07/31/2014 06:33 AM, Christopher Lozinski wrote:
> On 7/30/14, 10:50 PM, Fernando Martins wrote:
>> I don't know about ZTK, Grok.
> ...
> Okay so that tells you what ZTK and Grok are. Back to your application.
I never needed it directly and I wonder if it was not a case of
over-engineering that helped zope's community fragmentation.

I don't know why grok did not succeed.
>
> On 7/30/14, 10:50 PM, Fernando Martins wrote:
>> (I use my own security roles in the database) .
> Well that is very interesting. One of my biggest complaints about Zope
> 2 was the security model. Security was on the instances. Not possible
> to just make security declarations on the classes, without having to
> also declare it on the instances. So I am hugely curious about your
> security model. The grok security model, while better than ZTK, still
> leaves a lot to be desired. Fortunately it is quite easy to replace.
it's just an application specific security "model". some pages (or parts
of it) are merely for admin roles (which have a group of people
associated). In other cases, it is the data (records, which belong to
the creator, or corresponding team, or related maintainers. Has it
happens, the roles are part of the data of the application and naturally
used to manage the data or pages or parts of it. For the pages, it is
hard-coded. Each page has associated a single Python script (business
rules) that produces all data as a single class which includes
attributes like isAdmin, isEditor. Nothing general purpose.
>
>
> On 7/30/14, 10:50 PM, Fernando Martins wrote:
>> although most likely my application will have to be ported to tomcat
>> (using jython) in the short term.
> Why tomcat? I would think that there would be many native python web
> servers you could use. Have you considered Pyramid.
> It also uses the ZODB and traversal.
politics. it is supported by IT. zope is not. nothing wrong with zope
itself.

_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )

On 7/31/14, 9:13 PM, Fernando Martins wrote:
> I wonder if it was not a case of over-engineering that helped zope's
> community fragmentation.
That is correct. You know the famous saying by P.J. Eby

Those who do not study Zope, are condemned to reinvent it.

Well that is because every concept known to software developers is in
there.
There is no clear directory into the concepts/software libraries.
And worse yet, when I want to use any of those concepts it does not have
a clear human interface, documentation and mental model,
so that I have to go and read the source code. It is a human factors
disaster. Particularly if your boss is on your back
asking what you have done today. "I just spent two days trying to
understand the zope security model.
Turns out I do not need it" Is not an acceptable reply. Which is
literally how I spent my last two days.
I had to understand it before I could decide to toss parts of it out.
Fortunately I do not have a boss.

I now understand that my arguments on the mailing list were really about
software engineering vs Human Factors.
My training was in industrial engineering, rather than computer
science. Using last centuries technologies is an unmitigated human
factors disaster. Sure the future is giant libraries of reusable
components, but there is no viable way to get there from here.
There needs to be a graceful path.

So the Zopache user mental model starts with 4 simple TTW classes.
HTML, CSS, Javascipt, and Images. It will be easy for people
to put up their HTML resumes on my next generation recruiting website
PrivaCV.com. And from there the next branch of the hierarchical menu
will have some more options for them to explore and learn. One step at
a time.

Thank you so much for helping me to understand the context of the work I
am doing.

Okay back to work.

Regards
Chris










_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher Lozinski wrote:
> On 7/31/14, 9:13 PM, Fernando Martins wrote:
>> I wonder if it was not a case of over-engineering that helped
>> zope's community fragmentation.
> That is correct. You know the famous saying by P.J. Eby
>
> Those who do not study Zope, are condemned to reinvent it.
>
> Well that is because every concept known to software developers is
> in there. There is no clear directory into the concepts/software
> libraries. And worse yet, when I want to use any of those concepts it
> does not have a clear human interface, documentation and mental
> model, so that I have to go and read the source code. It is a human
> factors disaster. Particularly if your boss is on your back asking
> what you have done today. "I just spent two days trying to
> understand the zope security model. Turns out I do not need it" Is
> not an acceptable reply. Which is literally how I spent my last two
> days. I had to understand it before I could decide to toss parts of
> it out. Fortunately I do not have a boss.
>
> I now understand that my arguments on the mailing list were really
> about software engineering vs Human Factors. My training was in
> industrial engineering, rather than computer science. Using last
> centuries technologies is an unmitigated human factors disaster.
> Sure the future is giant libraries of reusable components, but there
> is no viable way to get there from here. There needs to be a graceful
> path.
>
> So the Zopache user mental model starts with 4 simple TTW classes.
> HTML, CSS, Javascipt, and Images. It will be easy for people to put
> up their HTML resumes on my next generation recruiting website
> PrivaCV.com. And from there the next branch of the hierarchical
> menu will have some more options for them to explore and learn. One
> step at a time.
>
> Thank you so much for helping me to understand the context of the
> work I am doing.

You are arguing and blathering every other year the same nonsense
without any outcome. Do you have a mission? Do you have a goal?
Have we seen any contribution, any code from you side of the last decade?

- -aj

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQGUBAEBAgAGBQJT3wdwAAoJEADcfz7u4AZj8scLviX4qBif/JCanLWCCg64tm8y
mADE8Co/XcaIR1p44rkVWPuJhE6c/RtJzdqg/sxhk8TCF1xxv4NO7bEeSix6mfgo
ccUJ3TdKpF/PubwTjLPgHEt7WXqHI5g/enqWYQwvdqmMl/w6T2Ww9QQhoZ/8HEtp
hyM9a7fTHE3TkexUPP3up1dtDNumyzORnMKyy32DGd41x1/merlXqFlGvleKIeeu
V8N2WE0090oedI+jOZGJvT+5vgKYEfg51YE5BmnKr8Nns63xt5FFptc1GZkWXD81
44Sc7IVLMZpdkOzLyGk9AZu8gi1scU8tBRwcNvZolyaDyKSDgyfuzPqCCCtflxUX
4zoxnqB3K6hlq8fk5/IH2iu1h0XIby8dPNZ9i8XOC2SXXuArhcOWsv+L8of+dmzE
fYKjepk8qUzbzh4coL0KaQiT6lxa06lfSZLrW7+llH1RXV4kxv/lHCu/Hq0Vljqg
RHd7HnE02trdhFCfxWYaTgMGR+z84TI=
=WFJl
-----END PGP SIGNATURE-----
_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )

On 8/4/14, 7:09 AM, Andreas Jung wrote:
> You are arguing and blathering every other year the same nonsense
> without any outcome.
>
There has been a huge outcome. I now recognize that grok and ZTK are a
human factors disaster. It is way too complex for an ordinary mortal to
begin using. I was privileged to be able to watch it for many years and
figure out what to do with this mammoth piece of code. Those of us who
do manage to use it, do not get simple user interfaces. I still do not
quite understand Zope security. Really the whole Grok/ZTK ecosystem
needs to be rewritten with an eye to Human Factors. You need an
industrial engineer in charge, not a computer scientist.

I have also increased my self confidence. I am perhaps the only one of
the once numerous TTW developers to have mastered the Grok/ZTK
platform. I am now able to do what I need. The rest just faded away.
That is quite an impressive accomplishment on my part.

I have a first release of Zopache running internally.

More importantly I now have a possible Beta user I met through this
mailing list, we
are in discussions on how to work together. Mission accomplished.
Thank you sir.

>Have we seen any contribution, any code from you side of the last decade?
Well I have written 90% of the ZTFY wiki. And I wrote the entire
Zopache Wiki.
I laid out exactly what is needed to be done. I gave huge end user
feedback to the mailing lists over the years. Sadly people like you
quite ignored it, and the whole community consequently died. Don't
blame me for that. I did my part.

But your hostility on this mailing list has been so huge, that I am now
unlikely to release Zopache to open source. In any case,
open source is the wrong model from a Human Factors point of view. Then
they have to mess with last century's unix file system. And they are
scared of no support. People want a free hosted Zopache TTW. Something
like PythonAnywhere. And that is high on my list of things to do.

Open Source is also the wrong model for getting people to invest their
time and effort in the project. Unlike Linux there is not a huge user
demand. Maybe two of us to contribute. Maybe I need to give out shares
to anyone who wants to work on this project. I have to figure out the
details.

With Zopache running as a free supported hosted solution, even a
neanderthal like you could use it.

I do appreciate your provoking an interesting conversation.






_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<lol/>

Christopher Lozinski wrote:
> On 8/4/14, 7:09 AM, Andreas Jung wrote:
>> You are arguing and blathering every other year the same nonsense
>> without any outcome.
>>
> There has been a huge outcome. I now recognize that grok and ZTK are
> a human factors disaster. It is way too complex for an ordinary
> mortal to begin using. I was privileged to be able to watch it for
> many years and figure out what to do with this mammoth piece of code.
> Those of us who do manage to use it, do not get simple user
> interfaces. I still do not quite understand Zope security.
> Really the whole Grok/ZTK ecosystem needs to be rewritten with an eye
> to Human Factors. You need an industrial engineer in charge, not a
> computer scientist.
>
> I have also increased my self confidence. I am perhaps the only one
> of the once numerous TTW developers to have mastered the Grok/ZTK
> platform. I am now able to do what I need. The rest just faded
> away. That is quite an impressive accomplishment on my part.
>
> I have a first release of Zopache running internally.
>
> More importantly I now have a possible Beta user I met through this
> mailing list, we are in discussions on how to work together. Mission
> accomplished. Thank you sir.
>
>> Have we seen any contribution, any code from you side of the last
>> decade?
> Well I have written 90% of the ZTFY wiki. And I wrote the entire
> Zopache Wiki. I laid out exactly what is needed to be done. I gave
> huge end user feedback to the mailing lists over the years. Sadly
> people like you quite ignored it, and the whole community
> consequently died. Don't blame me for that. I did my part.
>
> But your hostility on this mailing list has been so huge, that I am
> now unlikely to release Zopache to open source. In any case, open
> source is the wrong model from a Human Factors point of view. Then
> they have to mess with last century's unix file system. And they
> are scared of no support. People want a free hosted Zopache TTW.
> Something like PythonAnywhere. And that is high on my list of things
> to do.
>
> Open Source is also the wrong model for getting people to invest
> their time and effort in the project. Unlike Linux there is not a
> huge user demand. Maybe two of us to contribute. Maybe I need to
> give out shares to anyone who wants to work on this project. I have
> to figure out the details.
>
> With Zopache running as a free supported hosted solution, even a
> neanderthal like you could use it.
>
> I do appreciate your provoking an interesting conversation.
>
>
>
>
>
>


- --
Regards
Andreas Jung
andreas@andreas-jung.com
about.me/andreasjung

EuroPython 2014 Organization Team - Communications

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQGUBAEBAgAGBQJT4QCAAAoJEADcfz7u4AZjmP4LwN+z2qFRRlhISf9X3Br4Z4M6
O5kVpPpodyYfHyu4orhYYkwOpEiSeWEhwNUuS6gowptKmOxIqrODjLrjordqFEfF
ft/Py5VgiqtBdlZGFoRI+idKh5YKHyaA4t41hSsh9wOO0Vo/pMR0JjxRKOyJmetH
kno8HuZkcRArhJz3z6AcJh9jF9NLK1OxJUNPt1cGNYMJlnLU2yP6kQiG2hBcd0rk
rH+ljfvUHXQyf3Wkie0P200KJ5u2DA+WYyjcWz4+f04fq3Y+yCAlMHxnqCnM8rVs
QL4DIZ6++C38Bbzt/NdS/H31PPj5q7PoqNgWooH7oT1vbhtChjPOzeQfotqTdgYD
ytLqNdOKdVyUzJ6LIoP3P7ymlj4TMpwel4nsHSPnhvDJphtveT1o+cFFkVL/W11k
QO7ZC6bFBWzhal2wYUhAi9PxYTiN4FgCcB7LFD9HTgQ82eYXUL6nHAv15n//oMuq
aeXmFdr79mXvmSFSxfB5GEgPoGirmT8=
=iHuO
-----END PGP SIGNATURE-----
_______________________________________________
Zope maillist - Zope@zope.org
https://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope-dev )

On Wed, Jul 30, 2014 at 7:22 PM, Christopher Lozinski <
lozinski@freerecruiting.com> wrote:

> I would think that the world has to move to massive class libraries of
> reusable software components, maybe not on the client side, because it
> takes time to download, but certainly on the server side. Not in
> statically bound languages like Java or C++, but in dynamically bound
> languages, like like python or C#. The only significant python
> component architecture I know of is ZCA. Maybe there is one in C# So I
> would expect lots of people to be using
> ZCA, most easily in Grok. And Grok is quite easy to use. And yet
> that is not happening.
>
> Why not i wonder?
>
>
That certainly is a very interesting question.

And the answer is that components generally aren't particularly reusable,
as they tend to be too tightly integrated with each other. Components are
for making plugins to frameworks, and hence you can use a component
architecture when you build a framework. (Zope3 tried building the
framework OF components, but that IMO proved to be too complex).

Reusability comes in the forms of libraries, services and frameworks.
Hence, in your case, as you are building a new web site, you need a good
website framework. There are many good Python web framework to choose
between to get things done quickly. ZTK is not one of those. Neither in my
opinion is Grok, which was a valiable attempt to make Zope 3 development
less complex.

//Lennart

Wops. I have no idea why this thread popped up in my inbox today. Sorry.

On Wed, Oct 22, 2014 at 8:51 AM, Lennart Regebro <regebro@gmail.com> wrote:

> On Wed, Jul 30, 2014 at 7:22 PM, Christopher Lozinski <
> lozinski@freerecruiting.com> wrote:
>
>> I would think that the world has to move to massive class libraries of
>> reusable software components, maybe not on the client side, because it
>> takes time to download, but certainly on the server side. Not in
>> statically bound languages like Java or C++, but in dynamically bound
>> languages, like like python or C#. The only significant python
>> component architecture I know of is ZCA. Maybe there is one in C# So I
>> would expect lots of people to be using
>> ZCA, most easily in Grok. And Grok is quite easy to use. And yet
>> that is not happening.
>>
>> Why not i wonder?
>>
>>
> That certainly is a very interesting question.
>
> And the answer is that components generally aren't particularly reusable,
> as they tend to be too tightly integrated with each other. Components are
> for making plugins to frameworks, and hence you can use a component
> architecture when you build a framework. (Zope3 tried building the
> framework OF components, but that IMO proved to be too complex).
>
> Reusability comes in the forms of libraries, services and frameworks.
> Hence, in your case, as you are building a new web site, you need a good
> website framework. There are many good Python web framework to choose
> between to get things done quickly. ZTK is not one of those. Neither in my
> opinion is Grok, which was a valiable attempt to make Zope 3 development
> less complex.
>
> //Lennart
>
>