Re: [Repoze-dev] Deform 0.1 released
On Sun, 2010-05-09 at 17:10 +0200, Charlie Clark wrote: > >> I guess it should be "pstruct" in the second sentence. > > Yes. Fixed, thanks. > > This leads to the following definitions: > > "Usually, when used in deform, a pstruct is composed entirely of lists, > dictionaries, strings, and file objects." > "Usually, when used in deform, a cstruct is composed entirely of lists, > dictionaries, strings, and file objects." > > Clearly additional explanation is required otherwise pstruct and cstruct > seem equivalent where they may only be analogous. Yes. I should just remove the definitions in the glossary because they are actually defined better in the chapter I linked to. > Looking at the "data trip" I am vaguely reminded of mathematical > transformations and wonder if that metaphor might not be useful in this > context - putting the various representations/structures in the CAST > quadrants. OTOH I never really understood it back then! ;-) > > Would we have 4 quadrants? Storage, Application, Network and Browser? No idea, I about flunked math. > Another area where I find the semantics getting in the way: > > "For each schema node in the schema provided by the application developer, > Deform creates a field. This happens recursively for each element in the > schema. As a result, a tree of fields is created, mirroring the nodes in > the schema." > > Elements and nodes are interchangeable? If so I would suggest sticking > with one term in general and using metaphors consistently: graphs have > nodes, trees have leaves and compounds are made up of elements. So that "a > tree of fields is created which mirrors the tree of elements in the > schema" or some such as I'm not too happy with that either. I think the > important thing is the ability to nest elements of the schema. I've replaced all uses of "element" with "node". > > And finally "form controls" refers to "A sequence of form fields". I find > this definition misleading but possibly only because it is too brief. I > think form controls were the representation of the fields by the browser, > but that this definition comes from GUI-programming as isn't directly > relevant here. The distinction I'm trying to make is the raw data given to us as the result of a form submission (currently "controls" vs. the data that peppercorn returns (pstruct)). > But that wouldn't fit in the sentence "Deform passes a set > of form controls to the parse method". Why doesn't it just pass the set of > form fields? Because we use the word "field" elsewhere. I was trying to not overlap the vocabulary. I probably failed in places. > Sorry, if this is all to picky at the level of the language. I'll try and > provide some more useful feedback with a test application this week as > this suits my needs for my planned port of begeistert.org to BFG. Cool. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] does BFG have some cache mechanism or cache middleware?
Please keep correspondence on the list. On Sun, 2010-05-09 at 22:59 +0800, Litao Wei wrote: > Does BFG have other cache solution except Beaker? Sorry, the question doesn't make much sense if asked literally. Caching isn't a problem that only BFG has, and BFG doesn't try to solve it. If you're asking "does the Python web community have any cache solution except Beaker", then the answer is "I'm not sure"; there doesn't seem to be much competition: http://stackoverflow.com/questions/1427255/is-there-a-python-caching-library - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Deform 0.1 released
Am 09.05.2010, 16:16 Uhr, schrieb Chris McDonough : >> just flipping through the documentation and things are looking good. I >> like the fact that schemas avoid the confusion that Zope "interfaces as >> schemas" can cause. Nevertheless, it can be convenient to be able to tie >> them together. > I'll definitely be working on a system at some point that generates > forms from the definition of a "content type". I don't know if those > definitions will be done in terms of a Zope interface or not yet. So at > this point my attitude is "it can be convenient to generate forms from > content", which may or may not turn out to be the same thing as "it can > be convenient to generate forms from Zope interfaces". To make myself clear on this - I agree that convenience is great. Anything that means that schema and interface definition do not have to be duplicated. However, the current elision of the difference that is possible in Zope is not a good thing. >> As with all libraries of this kind the necessary abstraction requires >> some >> new concepts or terminologies. I think I understand and like the >> appstruct, cstruct and pstruct things (if not the names) but only >> working >> with them will let me know. However, the definition of pstruct is either >> incorrect or misleading: >> >> "pstruct >> Data deserialized by Peppercorn to a representation suitable for >> consumption by a deform deserializer. Usually, when used in deform, a >> cstruct is composed entirely of lists, dictionaries, strings, and file >> objects." >> >> I guess it should be "pstruct" in the second sentence. > Yes. Fixed, thanks. This leads to the following definitions: "Usually, when used in deform, a pstruct is composed entirely of lists, dictionaries, strings, and file objects." "Usually, when used in deform, a cstruct is composed entirely of lists, dictionaries, strings, and file objects." Clearly additional explanation is required otherwise pstruct and cstruct seem equivalent where they may only be analogous. Looking at the "data trip" I am vaguely reminded of mathematical transformations and wonder if that metaphor might not be useful in this context - putting the various representations/structures in the CAST quadrants. OTOH I never really understood it back then! ;-) Would we have 4 quadrants? Storage, Application, Network and Browser? Another area where I find the semantics getting in the way: "For each schema node in the schema provided by the application developer, Deform creates a field. This happens recursively for each element in the schema. As a result, a tree of fields is created, mirroring the nodes in the schema." Elements and nodes are interchangeable? If so I would suggest sticking with one term in general and using metaphors consistently: graphs have nodes, trees have leaves and compounds are made up of elements. So that "a tree of fields is created which mirrors the tree of elements in the schema" or some such as I'm not too happy with that either. I think the important thing is the ability to nest elements of the schema. And finally "form controls" refers to "A sequence of form fields". I find this definition misleading but possibly only because it is too brief. I think form controls were the representation of the fields by the browser, but that this definition comes from GUI-programming as isn't directly relevant here. But that wouldn't fit in the sentence "Deform passes a set of form controls to the parse method". Why doesn't it just pass the set of form fields? Sorry, if this is all to picky at the level of the language. I'll try and provide some more useful feedback with a test application this week as this suits my needs for my planned port of begeistert.org to BFG. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Deform 0.1 released
Hi Charlie, Thanks for checking it out... On Sun, 2010-05-09 at 15:00 +0200, Charlie Clark wrote: > Am 09.05.2010, 07:50 Uhr, schrieb Chris McDonough : > > > This piece of software will be an important piece of any new CMS-ish > > systems I develop going forward, so it's important to me that I get it > > right. Therefore, as always, and even more so, feedback on the > > documentation and demo software is appreciated. Tryouts are even more > > appreciated. > > Hi Chris, > > just flipping through the documentation and things are looking good. I > like the fact that schemas avoid the confusion that Zope "interfaces as > schemas" can cause. Nevertheless, it can be convenient to be able to tie > them together. I'll definitely be working on a system at some point that generates forms from the definition of a "content type". I don't know if those definitions will be done in terms of a Zope interface or not yet. So at this point my attitude is "it can be convenient to generate forms from content", which may or may not turn out to be the same thing as "it can be convenient to generate forms from Zope interfaces". > As with all libraries of this kind the necessary abstraction requires some > new concepts or terminologies. I think I understand and like the > appstruct, cstruct and pstruct things (if not the names) but only working > with them will let me know. However, the definition of pstruct is either > incorrect or misleading: > > "pstruct > Data deserialized by Peppercorn to a representation suitable for > consumption by a deform deserializer. Usually, when used in deform, a > cstruct is composed entirely of lists, dictionaries, strings, and file > objects." > > I guess it should be "pstruct" in the second sentence. Yes. Fixed, thanks. > What happens to > data going through a form and back is key to understanding what any form > library has to do. There's a chapter about that: http://docs.repoze.org/deform/serialization.html Further critical eye on documentation appreciated. Thanks! - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] does BFG have some cache mechanism or cache middleware?
On Sun, 2010-05-09 at 14:33 +0800, Litao Wei wrote: > what I need is filesystem based and pre view based. Maybe using > beaker with BFG is a good choice? I've never used Beaker caching, but I've heard that other folks like it, and it seems to be platform agnostic, so there should be no problem using it in BFG. - C ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Deform 0.1 released
Am 09.05.2010, 07:50 Uhr, schrieb Chris McDonough : > This piece of software will be an important piece of any new CMS-ish > systems I develop going forward, so it's important to me that I get it > right. Therefore, as always, and even more so, feedback on the > documentation and demo software is appreciated. Tryouts are even more > appreciated. Hi Chris, just flipping through the documentation and things are looking good. I like the fact that schemas avoid the confusion that Zope "interfaces as schemas" can cause. Nevertheless, it can be convenient to be able to tie them together. As with all libraries of this kind the necessary abstraction requires some new concepts or terminologies. I think I understand and like the appstruct, cstruct and pstruct things (if not the names) but only working with them will let me know. However, the definition of pstruct is either incorrect or misleading: "pstruct Data deserialized by Peppercorn to a representation suitable for consumption by a deform deserializer. Usually, when used in deform, a cstruct is composed entirely of lists, dictionaries, strings, and file objects." I guess it should be "pstruct" in the second sentence. What happens to data going through a form and back is key to understanding what any form library has to do. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
