formencode-discuss — General discussion list

[FE-discuss] Re: FormEncode and GenericTemplates

[Ian B. <ia...@co...>]

Carlos Ribeiro wrote:
> Ian,
> 
> Well, there seems to be no easy way to snip everything I would like to
> comment, so let's start from a clean sheet again.
> 
> Most of the stuff I've written about it's still experimental. Pure
> text talk doesn't make justice to the type of structure we're talking
> about here, but that's whats available now, so...
> 
> The overall application is structured as a tree, where nodes are
> always classes (not instances). 

I don't think that's a good restriction to put in place.  For instance, 
consider your user example -- /users/joeuser should probably be a 
User('joeuser') instance, no?  It might still be a factory object, 
however, like a class.

> It's a class hierarchy of sorts, but
> not in the inheritance sense -- it's a composition class hierarchy
> (I'm yet to find the correct name for it, maybe the GOF book or the c2
> wiki can help me here).

Nested classes are unusual, so I don't think it has a name.  If you 
think of the objects as factories instead of classes (where classes are 
also factories) then I think there might be a term for this.

> All nodes are classes, and act as templates for the functionality of
> the system. But nodes also can have different incarnations, depending
> upon the type of adaptation you need at some point. For example:
> 
> root.users is a node. Calling root.users(IPage) instantiates the IPage
> representation of that node. Upon instantiation, the page class
> traverses all child nodes of the page recursively, and builds a Page
> representation of the root.users subtree. In this process, some of the
> child nodes will be skipped - they do not belong to the IPage
> adaptation.

IPage(root.users) would be the typical way to phrase this now. 
PyProtocols added this recently, and Zope and Twisted have been using 
this syntax for a while, though I have yet to convert FormEncode to do this.

> root.users.default.body.content is also a node, and it points to the
> content area of the default user page. Calling
> root.users.default.body.content(IForm) creates the form, and that
> includes view, validation, data access, and business logic classes.
> For example, this statement:
> 
> user_form = root.users.default.body.content(IForm) 
> 
> userform is now a complete description of that part of the system, in
> all its aspects. It can be adapted, too. So if you need to validade
> the userform, you can ask for a validator object adaptor, or for a
> data entry form renderer:
> 
> user_form_validator = adapt(user_form, IValidator)
> user_form_renderer = adapt(user_form, IHtmlRenderer)
> 
> The interesting thing about this scheme is that you can always play
> with simple, specialized objects, but in fact everything is glued
> behind the scenes into a single framework.
> 
> All this is well, but there's still a big issue; it's easy to build a
> subset of a complex structure, but it's still hard to write the main
> structure. To solve this problem, I'm using two tools:
> 
> 1) Divide and conquer. Build parts of the tree, and only glue
> everything at the latest moment. I think that at any point there
> should be no more than three nesting levels being presented to the
> programmer.
> 
> 2) Use composition instead of single inheritance. One good example is
> the validator problem. A single data field may be seen as a composite
> structure:
> 
> class Username(DataField):
>     caption = 'Username'
>     default = ''
>     maxlength = 40
>     class edit(View):
>         size = 40
>     class valid_user_name(Validator):
>         def onvalidate(self, ...): pass
> 
> The validator and the view components are at the same level of the
> hierarchy.

I can see how this makes sense.  Without this abstract master object 
(DataField), you end up with a circle of objects, where each points to 
the others and none of them are clearly the "master".  I might try this 
with FormEncode.

  The constructor for username knows which kind of adaptation
> is required; it builds the entire instance, but only returns a proxy
> object with the desired functionality. It's something like this:
> 
> class DataField:
>     @classmethod
>     def __call__(cls, Protocol):
>         # instantiates the object, and returns a proxy that supports
>         # the protocol
>         ...

Can you actually make a classmethod out of __call__?  I'd think you'd 
have to override __new__.

> The proxy would hide the parts of the object that aren't needed; for
> example, if a validator is requested, only the validator methods would
> be visible. But the object could be re-adapted to return a different
> view of the same object. For example, the code below is valid:
> 
> edituser = Username(IHtmlRenderer)
> edituser.build_form() 
> ...
> edituser.get_form()
> validator = adapt(edituser, IValidator)
> ...
> 
> What does one get with the adaptation shown above? Well, it's clearly
> impossible to map all attributes of validators, entry forms, and
> potentially other representations into the same object. It's too
> confusing. A silly example:- the __repr__ method could be changed for
> each adaptation that's possible. A better example is that, in the
> situation above, the HtmlRenderer actually knows a little bit about
> validators, and thus it's able to render the Javascript code required
> for client-side validation.

Right, I've had in mind client-side validation as well.  Plus the 
validators knowing about the view, to apply view-specific validation.

Well, the validators in FormEncode actually do conversion in addition to 
validation, which is why the view adds validators -- it's really adding 
converters to the process.

> What happens, behind the scene, is that the true username object is
> much more complex, and is composed of other nested instances and
> attributes. But the programmer does not need to see it. This
> complexity is hidden by the adaptation layer, and the programmer works
> with a higher abstraction layer.

Right.  Except it's gets into that circular situation, where all the 
objects are peers, but they are also all (kind of) interchangeable. 
It's easier to think about if there's a single master object, and each 
of these interfaces is another face on that master object.  But it's 
unclear what the master object should be.  Maybe it shouldn't "be" 
anything -- it would be your domain object, up to the programmer to 
construct and name.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

[FE-discuss] Re: FormEncode and GenericTemplates

[Carlos R. <car...@gm...>]

Ian,

Well, there seems to be no easy way to snip everything I would like to
comment, so let's start from a clean sheet again.

Most of the stuff I've written about it's still experimental. Pure
text talk doesn't make justice to the type of structure we're talking
about here, but that's whats available now, so...

The overall application is structured as a tree, where nodes are
always classes (not instances). It's a class hierarchy of sorts, but
not in the inheritance sense -- it's a composition class hierarchy
(I'm yet to find the correct name for it, maybe the GOF book or the c2
wiki can help me here).

All nodes are classes, and act as templates for the functionality of
the system. But nodes also can have different incarnations, depending
upon the type of adaptation you need at some point. For example:

root.users is a node. Calling root.users(IPage) instantiates the IPage
representation of that node. Upon instantiation, the page class
traverses all child nodes of the page recursively, and builds a Page
representation of the root.users subtree. In this process, some of the
child nodes will be skipped - they do not belong to the IPage
adaptation.

root.users.default.body.content is also a node, and it points to the
content area of the default user page. Calling
root.users.default.body.content(IForm) creates the form, and that
includes view, validation, data access, and business logic classes.
For example, this statement:

user_form = root.users.default.body.content(IForm) 

userform is now a complete description of that part of the system, in
all its aspects. It can be adapted, too. So if you need to validade
the userform, you can ask for a validator object adaptor, or for a
data entry form renderer:

user_form_validator = adapt(user_form, IValidator)
user_form_renderer = adapt(user_form, IHtmlRenderer)

The interesting thing about this scheme is that you can always play
with simple, specialized objects, but in fact everything is glued
behind the scenes into a single framework.

All this is well, but there's still a big issue; it's easy to build a
subset of a complex structure, but it's still hard to write the main
structure. To solve this problem, I'm using two tools:

1) Divide and conquer. Build parts of the tree, and only glue
everything at the latest moment. I think that at any point there
should be no more than three nesting levels being presented to the
programmer.

2) Use composition instead of single inheritance. One good example is
the validator problem. A single data field may be seen as a composite
structure:

class Username(DataField):
    caption = 'Username'
    default = ''
    maxlength = 40
    class edit(View):
        size = 40
    class valid_user_name(Validator):
        def onvalidate(self, ...): pass

The validator and the view components are at the same level of the
hierarchy. The constructor for username knows which kind of adaptation
is required; it builds the entire instance, but only returns a proxy
object with the desired functionality. It's something like this:

class DataField:
    @classmethod
    def __call__(cls, Protocol):
        # instantiates the object, and returns a proxy that supports
        # the protocol
        ...

The proxy would hide the parts of the object that aren't needed; for
example, if a validator is requested, only the validator methods would
be visible. But the object could be re-adapted to return a different
view of the same object. For example, the code below is valid:

edituser = Username(IHtmlRenderer)
edituser.build_form() 
...
edituser.get_form()
validator = adapt(edituser, IValidator)
...

What does one get with the adaptation shown above? Well, it's clearly
impossible to map all attributes of validators, entry forms, and
potentially other representations into the same object. It's too
confusing. A silly example:- the __repr__ method could be changed for
each adaptation that's possible. A better example is that, in the
situation above, the HtmlRenderer actually knows a little bit about
validators, and thus it's able to render the Javascript code required
for client-side validation.

What happens, behind the scene, is that the true username object is
much more complex, and is composed of other nested instances and
attributes. But the programmer does not need to see it. This
complexity is hidden by the adaptation layer, and the programmer works
with a higher abstraction layer.


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

[FE-discuss] Re: FormEncode and GenericTemplates

[Ian B. <ia...@co...>]

Carlos Ribeiro wrote:
> On Fri, 08 Oct 2004 11:57:56 -0500, Ian Bicking <ia...@co...> wrote:
> 
>><lots of interesting stuff snipped>
>>
>>Folding all these together is probably a mistake, as it's just too hard
>>to keep them sorted out.  Maybe views and validation schemas need to be
>>kept entirely separate.  Or the validation has to be chained in a more
>>explicit way.  Or something.
> 
> 
> The problem is that you just can't properly map multidimensional
> dependency structures into a simple, one dimensional class hierarchy.
> In this case you can't map _two_ hierarchies -- validators and form
> definitions -- into the same hierarchy. For simple forms, the two
> hierarchies overlap, but even so, the adaptation seems forced --
> either it's a validation tree with data-entry definitions dangling
> from the leafs, or it's a data-entry definition with validators
> dangling.

Now that I think about it, it's even more complicated.  Because in an 
actual form definition you are also folding in the default values for 
the form, potentially some values that precede conversion (e.g., from a 
failed form submission), and in FormEncode's case a set of nested 
options; the options are so you can do things like hide a field, without 
hiding the field from all users of that form schema.

In some ways this was mitigated by the fact that (a) default, request, 
and option values all came from a single source, and were never 
modified, just read, and (b) validators can be composed.  Since 
validators can be composed, you can construct one validator from the 
view (and validators tacked onto the view) and compose it with a 
validator from an external source.

> I am facing a similar problem, but it involves site structure vs page
> structure. It goes like this pseudo-code:
> 
> 1) This is the page structure. A page knows how to render itself, and
> the class definition maps the semantic structure of the XHTML that is
> generated:
> 
> class MainPage:
>     class head:
>     class body:
>         class pageheader...
>         class menu...
>         class content...

Hmm... seems very complicated.  Elegent UI data structures always end up 
breaking for me in the end, because there's always (valid) requests for 
exceptions to the structure.  Also, I wouldn't want to use anything 
HTML-based as a front-facing object; instead a control object (or 
function) should be front-facing, and it delegates to the template.

> 2) This is the site structure. The class hierarchy defines the site map.
> 
> class root(MainPage):
>     about = AboutPage  Zope's traversal, for instance, 
>     class users(AllUsersPage):
>         default = SingleUserPage

That seems complex too.  I'm not sure what you gain here?  It seems 
easier to make traversal a function call.  But then, I don't like object 
publishing, I like URL translation to be much more explicit.  Having 
worked with Zope, I find its traversal to be rather scary -- things 
should only be accessible through a URL if you've explicitly asked them 
to be.  In part because the objects you are publishing have all sorts of 
other functionality, and lots of that isn't public.  In your case, the 
objects have functionality related to their HTML layout (or form 
submission, or whatever), and you're finding a conflict between that and 
URL traversal.  And really URL traversal just isn't interesting enough 
to warrant messing up your namespace.

But then, I also think lots of people have URL fetishes -- it's a nice 
idea for public URLs, but interactive applications have a limited number 
of public URLs, and it's unreasonable to expect those to be long-lived.

> URLs are mapped to classes as follows:
> 
> / -> root
> /about -> root.about
> /users -> root.users
> /users/joeuser -> root.users.default

With the WSGI URL traverser I wrote 
(svn://colorstudy.com/trunk/WSGI/urlparser.py), the idea is that you 
only get one object at a time, so you'd plug in root to the server.  But 
(in something analogous to your model) root would look at PATH_INFO when 
it was run; if PATH_INFO=='/', then it would use itself.  If not, then 
it'd pull off the first part, find a subobject, and return that.  How it 
found a subobject -- or if it found one at all -- was entirely up to the 
implementation of root.  So '/users/joeuser' would call root.users with 
a PATH_INFO of '/joeuser', and it would be up to root.users to figure 
out what to do with '/joeuser'.  This way you don't get a look using 
getattr; instead each segment of the URL delegates completely to the 
subobject, and you haven't programmed in any limits.

> When I glue (1) and (2) together, what I have is a superstructure that
> is like this:
> 
> root.users.body.content -> points to the content div of the webpage
> root.users.default -> point to a entire page
> 
> I'm at odds at how to represent this structure in a clean and
> incompromising way. One option is to use two different objects -- one
> for the site structure level, and another one for the pages. In this
> case, I would need to bind 'pages' to URL mapping spots. Another
> option is to use the same object with two interfaces, one for each
> level of the structure. In the later case, adaptors can be used to
> select which version of the object will be used while traversing the
> tree for URL mapping (site structure) or for page rendering (page
> structure).
> 
> ---
> BTW, I'm having a kind of deja-vu feeling... because I was active in
> the Python community three years ago, and at the time I actively
> participated in PEP246 discussions, which in turn led to PyProtocols.
> I wrote virtually _no_ code for more than two years (a sabbatical of
> sorts), and now I'm back... to the same kind of problem again. It's a
> sort of unfinished job -- something that I feel I _must_ do ;-)

I think the problem is that we (the community of programmers) don't 
really understand adaptation yet.  It's easy enough to understand it 
mechanically, but there's little clear rules for *how* to use it.  I 
think it's kind of like OO that way -- when it first came around, the 
mechanics were simple and any good programmer could understand those 
mechanics, but the important ideas of OO were much more subtle than the 
mechanics, and it took a while for the programming community to 
understand how best to use those ideas.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

[FE-discuss] Re: FormEncode and GenericTemplates

[Carlos R. <car...@gm...>]

On Fri, 08 Oct 2004 11:57:56 -0500, Ian Bicking <ia...@co...> wrote:
> <lots of interesting stuff snipped>
>
> Folding all these together is probably a mistake, as it's just too hard
> to keep them sorted out.  Maybe views and validation schemas need to be
> kept entirely separate.  Or the validation has to be chained in a more
> explicit way.  Or something.

The problem is that you just can't properly map multidimensional
dependency structures into a simple, one dimensional class hierarchy.
In this case you can't map _two_ hierarchies -- validators and form
definitions -- into the same hierarchy. For simple forms, the two
hierarchies overlap, but even so, the adaptation seems forced --
either it's a validation tree with data-entry definitions dangling
from the leafs, or it's a data-entry definition with validators
dangling.

I am facing a similar problem, but it involves site structure vs page
structure. It goes like this pseudo-code:

1) This is the page structure. A page knows how to render itself, and
the class definition maps the semantic structure of the XHTML that is
generated:

class MainPage:
    class head:
    class body:
        class pageheader...
        class menu...
        class content...

2) This is the site structure. The class hierarchy defines the site map.

class root(MainPage):
    about = AboutPage
    class users(AllUsersPage):
        default = SingleUserPage

URLs are mapped to classes as follows:

/ -> root
/about -> root.about
/users -> root.users
/users/joeuser -> root.users.default

When I glue (1) and (2) together, what I have is a superstructure that
is like this:

root.users.body.content -> points to the content div of the webpage
root.users.default -> point to a entire page

I'm at odds at how to represent this structure in a clean and
incompromising way. One option is to use two different objects -- one
for the site structure level, and another one for the pages. In this
case, I would need to bind 'pages' to URL mapping spots. Another
option is to use the same object with two interfaces, one for each
level of the structure. In the later case, adaptors can be used to
select which version of the object will be used while traversing the
tree for URL mapping (site structure) or for page rendering (page
structure).

---
BTW, I'm having a kind of deja-vu feeling... because I was active in
the Python community three years ago, and at the time I actively
participated in PEP246 discussions, which in turn led to PyProtocols.
I wrote virtually _no_ code for more than two years (a sabbatical of
sorts), and now I'm back... to the same kind of problem again. It's a
sort of unfinished job -- something that I feel I _must_ do ;-)

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

[FE-discuss] Re: FormEncode and GenericTemplates

[Ian B. <ia...@co...>]

Carlos Ribeiro wrote:
>>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.

My intention with FormEncode has been to support multiple input 
mechanisms as well.  But in reality I've only worked with HTTP/HTML, so 
that's where I filled it out.

The validation system in FormEncode is input-neutral, and I've tried to 
keep it separate from the way you declare views.  The intention being 
that each view would be bound to a particular mechanism -- e.g., you'd 
define the HTML view entirely separately from the a GUI view.  Also, I 
want to make a separate HTML view where you write an HTML template that 
is parsed to create the view object (htmlfill; unfinished), so even with 
a single output mechanism there could be multiple mechanisms to define 
the look and layout of the form.

One of the parts of FormEncode that I've struggled with was defining 
view and validation at the same time.  I probably should just give up on 
that and make it more rigid; better rigid than unpredictable.  I wanted 
to allow things like:

class FormView(schema.Schema):
     htmlview = htmlview.TableLayout
     # or htmlview = htmlview.TableLayout()
     # or class htmlview(htmlView.TableLayout): ...

     # then we can reverse things, and define a view with a validator
     fname = htmlview.Text(validator=validators.String(notEmpty=True))
     # or the equivalent...
     lname = validators.String(notEmpty=True, htmlview=htmlview.Text)


On top of that, views can add validators.  E.g., there's a credit card 
input "widget", which is actually a set of fields with validators.  Or, 
there's widgets which are more compound than they would seem on the 
outside -- e.g., a hidden field that is signed, and that signature is 
checked when the form is submitted.  That signature and signature check 
are really part of the view, and specific to the HTML form, they aren't 
part of the general form schema.

Folding all these together is probably a mistake, as it's just too hard 
to keep them sorted out.  Maybe views and validation schemas need to be 
kept entirely separate.  Or the validation has to be chained in a more 
explicit way.  Or something.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

[FE-discuss] Re: FormEncode and GenericTemplates

[Carlos R. <car...@gm...>]

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...

[FE-discuss] Re: FormEncode and GenericTemplates

[Ian B. <ia...@co...>]

Carlos Ribeiro wrote:
> Ian,
> 
> I've read your comments at my blog, and decided to reply by email. I
> hope you don't mind, and I look forward to this conversation.

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've downloaded FormEncode. I don't know why didn't I think about it
> at first - I'm not even sure if I saw it when I downloaded sqlobject.
> I've checked a few implementations details, and I can tell you that
> we're surely trying to solve the same problem, albeit with different
> short-term goals.

In what ways do you see your goals as different?

> It's also worth to note that you code is much more
> mature than mine; I'm still learning how to do web app development,
> and it shows in some of my decisions.

FormEncode is a rewrite (of FunFormKit), and both before and after the 
rewrite there was a fair amount of refactoring, so there are a number of 
paths I went down and then backed out of.

> As for my own library, I decided to break up my effort in steps. I've
> now released the first version of GenericTemplates, a pretty small
> library that handles the nesting of classes, with ordered and typed
> attributes. On top of that, there are other libraries: htmltemplate,
> forms, and inifile (the simplest one, and a great way to introduce the
> concept). I've had to work around several of the issues that you've
> mentioned, but made different decisions.

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

> At first, I though about making everything instances -- pretty much
> like you did. But as the design evolved, I kept thinking that it was
> best to make classes classes, and instances, well, instances. 

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.

> As it
> stands now, this identity is clear -- declarative classes have nested
> classes that are automatically instantiated when the containing class
> is instantiated, There are still some convenience class factory
> functions that decide dinamically what to do -- for example, the one
> that builds new buttons and editboxes still does some simple-minded
> checking to decide whether it's being called from inside a instance or
> from inside a class declaration, and returns the correct object
> accordingly.
> 
> There is a lot of stuff that I would like to talk about, but I'm not
> going to waste your time with it now. If you are interested, please
> drop me a note. I'm now in a situation where I have too much time in
> my hands, and too few people to talk about design issues, and I'm
> really looking for it.

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

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

[FE-discuss] PyProtocols 0.9.3 gives DeprecationWarning

[Hamish L. <hb...@st...>]

When calling protocols.apply, validators.py encounters the following 
warning in PyProtocols 0.9.3rc2:

"DeprecationWarning: The 'factory' argument to 'adapt()' will be removed 
in 1.0"

Information on preparing for PyProtocols 1.0 can be found at:

http://peak.telecommunity.com/protocol_api/UPGRADING.txt.html


Hamish Lawson

[FE-discuss] chainedValidators and errorDict

[Joseph K. <jko...@ma...>]

Is there any particular reason that most validators in a schema put 
Invalid exceptions into errorDict while exceptions raised from 
chainedValidators only put in the msg attribute? I can just subclass 
Schema and get the behavior I'm expecting, but it seems inconsitent to 
me and I'm curious if Schema ought to be patched. I'd also like the 
chainedValidators to run even if other validation fails, although that 
seems a little more app specific.

Thanks
Joseph

[FE-discuss] Have a nice day! ...//you are going out into a world of temptations. But though

[Raspier K. C. <md...@gm...>]

Keep your money! 
http://keepyourmoney.da.ru/?rtarGobQ

---
vengeance; the Lord Jesus Christ saw the sword ready to be 

[FE-discuss] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

Re: [FE-discuss] HTML generation submit button

[Greg U. <gr...@ga...>]

Thanks Tracy. That is what Ian ended up telling me to do as well.

Tracy S. Ruggles wrote:
> I'm adding a submit button before processing, i.e.,
> 
>     class MySchemaTemp(MySchema):
>         submit = SubmitButton(...)
> 
>     processor = formprocessor(MySchemaTemp)
> 
> I'm not sure of another way to do it...
> 
> --Tracy
> 
> On May 13, 2004, at 10:46 AM, Greg Unrein wrote:
> 
>> I have started learning FormEncode and I am really impressed. Thank you
>> for creating this tool. I was unable to figure out one thing, though:
>> how to get a submit button (or reset button) generated along with the
>> rest of the form when creating a view from a Schema. For example,
>>
>> processor = formprocessor.FormProcessor(MySchema)
>> ...
>> processor.renderForm(formData, action = '/', errors = errors)
>>
>> The return of the renderForm call is the form I want, but it has no
>> submit button. I can add one by subclassing htmlview.SchemaLayout and
>> inserting the button, but I thought there might be another way that I
>> just couldn't figure out.
> 
> 
> 
> 

Re: [FE-discuss] HTML generation submit button

[Tracy S. R. <tr...@re...>]

I'm adding a submit button before processing, i.e.,

	class MySchemaTemp(MySchema):
		submit = SubmitButton(...)

	processor = formprocessor(MySchemaTemp)

I'm not sure of another way to do it...

--Tracy

On May 13, 2004, at 10:46 AM, Greg Unrein wrote:

> I have started learning FormEncode and I am really impressed. Thank you
> for creating this tool. I was unable to figure out one thing, though:
> how to get a submit button (or reset button) generated along with the
> rest of the form when creating a view from a Schema. For example,
>
> processor = formprocessor.FormProcessor(MySchema)
> ...
> processor.renderForm(formData, action = '/', errors = errors)
>
> The return of the renderForm call is the form I want, but it has no
> submit button. I can add one by subclassing htmlview.SchemaLayout and
> inserting the button, but I thought there might be another way that I
> just couldn't figure out.

[FE-discuss] HTML generation submit button

[Greg U. <gr...@ga...>]

I have started learning FormEncode and I am really impressed. Thank you
for creating this tool. I was unable to figure out one thing, though:
how to get a submit button (or reset button) generated along with the
rest of the form when creating a view from a Schema. For example,

processor = formprocessor.FormProcessor(MySchema)
...
processor.renderForm(formData, action = '/', errors = errors)

The return of the renderForm call is the form I want, but it has no
submit button. I can add one by subclassing htmlview.SchemaLayout and
inserting the button, but I thought there might be another way that I
just couldn't figure out.

Thanks in advance,

Greg

[FE-discuss] HTML generation submit button

[Greg U. <gr...@ga...>]

Hi Ian,

I have started learning FormEncode and I am really impressed. Thank you 
for creating this tool. I was unable to figure out one thing, though: 
how to get a submit button (or reset button) generated along with the 
rest of the form when creating a view from a Schema. For example,

processor = formprocessor.FormProcessor(MySchema)
...
processor.renderForm(formData, action = '/', errors = errors)

The return of the renderForm call is the form I want, but it has no 
submit button. I can add one by subclassing htmlview.SchemaLayout and 
inserting the button, but I thought there might be another way that I 
just couldn't figure out.

Thanks in advance,

Greg

[FE-discuss] howdy

[Shannon --jj B. <jj...@ya...>]

Hey, Ian,

I'm new to this list.  I'm looking into using FormEncode with Aquarium.
 You asked for ideas, so here they are:

o The validation stuff looks pretty good.

o Data::FormValidator (for Perl on CPAN) rules.  I *really* liked using
it when I was using Perl Mason.  It's got a long developers list, so
you might consider stealing some ideas.  On the other hand, it looks
like you're already pretty far long.

o Your input "API" is a dictionary, whereas Aquarium standardized on
cgi.FieldStorage thinking it would be a well-known, standard data
format.  I guess I'll write a (trivial) conversion function.

o You might want to consider just dropping the idea of a form
generation library.  "Macros" are always nice, but they're usually
different for each app (i.e. they contain app specific CSS tags as well
as app specific logic).  It's difficult for a form generation library
to be both as flexible as hand-generated HTML yet as convenient as an
app specific set of macros.  Alternatively, you might want to put it in
a separate project.  I got a lot of resistance toward using your
project because of the fact that there was a form generation library
attached to it.

o The "names-1.fname" feature reminds me of a really cool feature in
PHP where if you name a field "$names[]['fname']", it would implicitly
do what you're doing.  Having form fields implicitly sorted into arrays
(lists and dicts are the same in PHP) is a really convenient feature. 
As a matter of asthetics, I'd be tempted to use "[]" instead of "-".

Best Regards,
-jj

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

[FE-discuss] active work w/ formencode?

[Tracy S. R. <tr...@re...>]

Hi all,

I've been playing around with formencode and have done some great work 
using the validation and conversion system, but now I'm heading into 
trying to work with the htmlview and formprocessor part of the code.  
I've had to patch/change some of the code in there to get parts of it 
working.  Is anyone working on the html generation side of things, so 
as not to duplicate work?  Or, does anyone have working examples of how 
to use a validator's htmlView attribute successfully?

Thanks!
--Tracy

[FE-discuss] Form Encode Use

[Voidspace <mi...@pc...>]

Sorry if my question here dulplilcate previous questions - I have a 
censored internet connection and am unable to browse the archives.

I am interested in creating CGI utilities to help me access various 
internet protocols - like NNTP, FTP etc  - via http. I would also like 
to write desktop applications (in Tkinter) to handle the http 
communication with the CGI script.

I would also like the CGI to generate a standard HTML form so that it 
can be accessed by web browser.

I can generate the form from html templates and spoof 'form entry' using 
URLs..... but a package that automates creating forms for the CGI and 
creating form requests from the desktop application would be great - and 
it looks like formencode might do that ?

I also wonder if anyone can *email* me the current (alpha I guess...) 
docs package to see if it's suitable ?

Thanks

Fuzzyman

-- 

http://www.Voidspace.org.uk 
The Place where headspace meets cyberspace. Online resource site - covering science, technology, computing, cyberpunk, psychology, spirituality, fiction and more. 

---
http://www.atlantibots.org.uk
http://groups.yahoo.com/group/atlantis_talk/
Atlantibots - stomping across the worlds of Atlantis.
Building with Python - programming language that rules the world.
---
http://www.fuchsiashockz.co.uk   
http://groups.yahoo.com/group/void-shockz
---

Everyone has talent. What is rare is the courage to follow talent
 to the dark place where it leads. -Erica Jong
Ambition is a poor excuse for not having sense enough to be lazy.
         -Milan Kundera