From: Geoffrey T. <gta...@na...> - 2003-09-16 22:14:01
|
Ian Bicking wrote: > On Tuesday, September 16, 2003, at 04:31 PM, deelan wrote: >>> Hi, if the code below is doing what I think it's doing, i.e. >>> unpickling that field, you're opening yourself up to arbitrary code >>> execution. Unpickle should never be used with strings that come the >>> user. > >> yes, i'm aware of the security issues, but i bet there a way >> to bundle to the base64 econded and serialized string some >> key/GUID/whatever to ensure that VIEWSTATE is genuine, i >> still have to look closely but i think ASP.NET does the same. > > You can do this pretty easily: > > key = str(random.random()) > def sign(value, key=key): > h = md5.new(value) > h.update(key) > return h.hexdigest() > def verify(value, signature, key=key): > h = md5.new(value) > h.update(key) > return h.hexdigest() == signature > > def signedPickle(obj, key=key): > value = dumbs(obj) > return value.encode('base64') + '^^^' + sign(value, key=key) > def signedUnpickle(s, key=key): > try: > value, signature = s.split('^^^') > except ValueError: > value = signature = '' > if not verify(value, signature, key=key): > raise ValueError, 'Invalid pickle input' > return loads(value.decode('base64')) > > > (Hmm... MiscUtils somewhere?) Check out Python's hmac module. It's designed for this sort of thing. There's some security reason why it's better to use HMAC instead of just using MD5, but I can't remember what the reason is. The same idea can also be used to store (small amounts of) pickled session data directly in cookies instead of using a session store on the server side. One of the many Python Web Frameworks uses this technique, I can't remember which one. - Geoff |
From: <rt...@sy...> - 2003-09-19 20:16:53
|
Hi there, What's the major difference between FormKit and FunFormKit? Which form kit should be used? Thanks, Richard |
From: Randall R. <ra...@ra...> - 2003-09-19 23:46:01
|
On Friday, September 19, 2003, at 10:58 AM, rt...@sy... wrote: > Hi there, > > What's the major difference between FormKit and FunFormKit? Which form > kit should be used? "FormKit" might refer to either dAlchemy's FormKit or another FormKit that I haven't used. Here I use it for the dAlchemy FormKit. One major difference seems to be that FFK expects you to use it to build your form layout as well as the tags and validation methods, whereas FormKit is less featureful, but (in my opinion) is more flexible with respect to using templating systems like tplCompiler. I haven't used FFK since February, and it may have changed since then. I currently use FormKit (you may have noticed my thrashing about in the list over the past coupla days). -- Randall Randall <ra...@ra...> "When you advocate any government action, you must first believe that violence is the best answer to the question at hand." -- Allen Thornton |
From: Matt F. <ma...@da...> - 2003-09-20 19:00:17
|
Randall Randall wrote: > On Friday, September 19, 2003, at 10:58 AM, rt...@sy... wrote: > >> Hi there, >> >> What's the major difference between FormKit and FunFormKit? Which >> form kit should be used? > > > One major difference seems to be that FFK expects you to use it to > build your form layout as well as the tags and validation methods, > whereas FormKit is less featureful, but (in my opinion) is more > flexible with respect to using templating systems like tplCompiler. What features would you say that FFK has that FK is missing, out of curiosity? |
From: Randall R. <ra...@ra...> - 2003-09-20 20:12:37
|
On Saturday, September 20, 2003, at 03:00 PM, Matt Feifarek wrote: > Randall Randall wrote: > >> On Friday, September 19, 2003, at 10:58 AM, rt...@sy... wrote: >> >>> Hi there, >>> >>> What's the major difference between FormKit and FunFormKit? Which >>> form kit should be used? >> >> >> One major difference seems to be that FFK expects you to use it to >> build your form layout as well as the tags and validation methods, >> whereas FormKit is less featureful, but (in my opinion) is more >> flexible with respect to using templating systems like tplCompiler. > > What features would you say that FFK has that FK is missing, out of > curiosity? Well, layout building and umpteen incredibly specific validators and field types. These things didn't seem very useful for what I wanted to do, and made FFK's learning curve steeper, so I gave it up in favor of building forms by hand. I had a deadline. :) FormKit is, as you know, what I'm using now. This is mostly because it takes less to set up, has less syntax (like colons and asterisks), and has fewer US-specific things like "PhoneNumber" fields that only accept phone numbers in North America, and "PostalCode" fields that only accept 5 or 9 digit postal codes... These are useful, I'm sure, for lots of people; just not me. So that's what I meant by "less featureful". There are some things that I'd like to see in future versions of FK, like handling unexpected lists and so on, but I haven't really come up with a FK specific resolution to that. My installation currently throws away all but the first entry in any lists in self.request().fields(), unless the field in question specifies a list, and then it makes any single inputs into a list. I'm not sure if anyone else wants to handle that in this way, though. -- Randall Randall <ra...@ra...> "When you advocate any government action, you must first believe that violence is the best answer to the question at hand." -- Allen Thornton -- Randall Randall <ra...@ra...> "When you advocate any government action, you must first believe that violence is the best answer to the question at hand." -- Allen Thornton |
From: Tripp L. <tri...@pe...> - 2003-09-21 09:42:47
|
On Sat, 20 Sep 2003, Randall Randall wrote: > Well, layout building and umpteen incredibly specific validators and > field types. These things didn't seem very useful for what I wanted > to do, and made FFK's learning curve steeper, so I gave it up in > favor of building forms by hand. I had a deadline. :) FWIW, I've built my forms without the "layout-building". Well, that is to say, I only used the layout-building to generate the field itself, but I placed the fields individually myself. That was actually more work in FFK can letting FFK do the heavy lifting, but I guess that's obvious :) > FormKit is, as you know, what I'm using now. This is mostly because > it takes less to set up, has less syntax (like colons and asterisks), > and has fewer US-specific things like "PhoneNumber" fields that only > accept phone numbers in North America, and "PostalCode" fields that > only accept 5 or 9 digit postal codes... This reminded me (and also distracted me :-) ) that I've got some various hacks to FunFormKit pieces that I made for a conference registration app that has an international audience. These are not "polished", and there are doubtless lots of I18N corner cases I totally don't handle, but at least I deal with a plus sign in phone numbers :-) I've posted excerpts here: http://perspex.com/hacks/python/funformkit/ Please understand that much of this is "incomplete" code, and should serve as something for you co "cut, paste, and curse" into your own code right now. Not unlike mkmodel.el, this is something I've got in my "eventual" queue to polish up and release formally :-) (PS: Ian, since FunFormKit is LGPL, if you want me to, I'll publish the tarball alongside these :-) ). |
From: Randall R. <ra...@ra...> - 2003-09-21 17:30:08
|
On Sunday, September 21, 2003, at 05:43 AM, Tripp Lilley wrote: > On Sat, 20 Sep 2003, Randall Randall wrote: > >> Well, layout building and umpteen incredibly specific validators and >> field types. These things didn't seem very useful for what I wanted >> to do, and made FFK's learning curve steeper, so I gave it up in >> favor of building forms by hand. I had a deadline. :) > > FWIW, I've built my forms without the "layout-building". Well, that is > to > say, I only used the layout-building to generate the field itself, but > I > placed the fields individually myself. That was actually more work in > FFK > can letting FFK do the heavy lifting, but I guess that's obvious :) Yeah, I was able to do that, too, but I didn't see the value in using FFK for only validation when I needed to build most of my validators myself anyway (most of them were db-based). Of course, I still have to do that with FormKit, but doing so with FormKit seems more natural to me (although that may well be a measure of my understanding of Python now vs. then). -- Randall Randall <ra...@ra...> "When you advocate any government action, you must first believe that violence is the best answer to the question at hand." -- Allen Thornton |
From: Ian B. <ia...@co...> - 2003-09-21 18:29:10
|
On Saturday, September 20, 2003, at 02:00 PM, Matt Feifarek wrote: >> One major difference seems to be that FFK expects you to use it to >> build your form layout as well as the tags and validation methods, >> whereas FormKit is less featureful, but (in my opinion) is more >> flexible with respect to using templating systems like tplCompiler. > > What features would you say that FFK has that FK is missing, out of > curiosity? I don't know FormKit very well, but as I remember it had less form widgets and less validators (though you should feel free to take FFK's validators -- or even better use FormEncode's validators which are only slightly different). Compound fields mean you can have something like a credit card field, which is actually three fields (type, number, expiration) together with validation (e.g., that the type matches the number). There are also some more sophisticated stand-alone widgets dealing with file uploads and other stuff, though I don't know if there's anything keeping you from making the same in FormKit. I think FFK's automatic form layout makes for nice forms for most situations, with fairly minimal description. Again, this is something that could be added on separately from the core package. For more general form tempating, I think something like this would be best: http://simon.incutio.com/archive/2003/06/17/theHolyGrail And of course there's the general issue of repeating and compound fields -- I think they are an important feature, but that's also been FFK's downfall, as adding it on to the design made FFK very hard to understand (even more myself). Which is to say, I don't think you can add that on to the design later, you have to build it in. Ian |
From: Aaron H. <aaron@MetroNY.com> - 2003-09-22 14:21:21
|
>> What features would you say that FFK has that FK is missing, out of >> curiosity? > I have used both in production settings. FFK is a little mode complete and rounded in terms of forms and validators. FFK adds the cocept of ORings validators so you can have isDate OR isEmpty. In FK you would have to build an empty case into the isDate validator. FFK is also stringly integrated into Webware. If you are doing a pure Webware/HTML project I think FFK is the way to go. FK is lighter and easier to customize. You can also use the form handing system outside of html servlets (for things like XML-RPC). They both are very easy to use w/ any templating system. They both have excellent documentation and support. -- -Aaron http://www.MetroNY.com/ "I don't know what's wrong with my television set. I was getting C-Span and the Home Shopping Network on the same station. I actually bought a congressman." - Bruce Baum |
From: Matt F. <ma...@da...> - 2003-09-23 19:53:43
|
Ian Bicking wrote: > On Saturday, September 20, 2003, at 02:00 PM, Matt Feifarek wrote: > >>> One major difference seems to be that FFK expects you to use it to >>> build your form layout as well as the tags and validation methods, >>> whereas FormKit is less featureful, but (in my opinion) is more >>> flexible with respect to using templating systems like tplCompiler. >> >> >> What features would you say that FFK has that FK is missing, out of >> curiosity? > > > I don't know FormKit very well, but as I remember it had less form > widgets and less validators (though you should feel free to take FFK's > validators -- or even better use FormEncode's validators I do mean to try and grok your new FormEncode library one of these days... and maybe steal some of your good validators, sure ;-) > which are only slightly different). Compound fields mean you can have > something like a credit card field, which is actually three fields > (type, number, expiration) together with validation (e.g., that the > type matches the number). There are also some more sophisticated > stand-alone widgets dealing with file uploads and other stuff, though > I don't know if there's anything keeping you from making the same in > FormKit. We've actually had compound fields all along; since our first release. They're slightly more complicated than a normal field, but they work pretty well. In fact, there are two examples in the Examples dir. We've also done file uploads all along. It's a bit of a hack, but then so is fild-uploading over http anyway. > I think FFK's automatic form layout makes for nice forms for most > situations, with fairly minimal description. Again, this is something > that could be added on separately from the core package. For more > general form tempating, I think something like this would be best: > http://simon.incutio.com/archive/2003/06/17/theHolyGrail He's not really doing templating that I can tell. Do you mean the way he handles error markup? Templating continues to be a thorn in our side, for all of our projects, not just form-related. It's a PITA. Our basic table dump isn't very pretty, but we had hoped that people would dig in and get the granular access to the labels and tags that we tried so hard to build. We don't seem to have communicated that very well... We're adding a divDump() coupled with some default css in the next small release. That may help. > And of course there's the general issue of repeating and compound > fields -- I think they are an I tried to read the Readme.txt in FormEncode to determine what a "repeating" field is... but I couldn't find it. Can you briefly explain? It sounds important. Thanks! Soon, maybe after our next small release, I'd like to get a discussion going with you and some of the other people who seem interested in forms, and find a way to get some library actually /built-in/ to Webkit. It seems like a glaring omission that it's not there, and between your library and ours, I'm sure that we can find a good candidate. I'll send in a note with some ideas and questions for discussion in the next week or so. -- Matt |
From: Ian B. <ia...@co...> - 2003-09-23 20:16:49
|
On Tuesday, September 23, 2003, at 02:54 PM, Matt Feifarek wrote: >> which are only slightly different). Compound fields mean you can >> have something like a credit card field, which is actually three >> fields (type, number, expiration) together with validation (e.g., >> that the type matches the number). There are also some more >> sophisticated stand-alone widgets dealing with file uploads and other >> stuff, though I don't know if there's anything keeping you from >> making the same in FormKit. > > We've actually had compound fields all along; since our first release. > They're slightly more complicated than a normal field, but they work > pretty well. In fact, there are two examples in the Examples dir. > > We've also done file uploads all along. It's a bit of a hack, but then > so is fild-uploading over http anyway. Some of the file uploading widgets I have save the file upload in case of an error, so you don't have to reupload when you correct other fields. And a couple little variations on that. I'm sure it wouldn't be that hard to add -- and indeed I worry that these little details in FFK are too hard to communicate so they wouldn't be likely to be used that often -- but that's the kind of things I've been thinking of. >> I think FFK's automatic form layout makes for nice forms for most >> situations, with fairly minimal description. Again, this is >> something that could be added on separately from the core package. >> For more general form tempating, I think something like this would be >> best: >> http://simon.incutio.com/archive/2003/06/17/theHolyGrail > > He's not really doing templating that I can tell. Do you mean the way > he handles error markup? It's kind of a pseudo-template. If you have something like: <input type="text" name="username"> In your template, the form library finds that tag and adds the appropriate value attribute according to your default or (when errors occurred) request value. Or if it finds a checkbox it might add a checked attribute (if appropriate). Or a selected attribute to a select box. It's not a great way to do more advanced DHTML widgets (in fact, I imagine they would be hard to do in this system), but it allows the template to be very flexible. > Templating continues to be a thorn in our side, for all of our > projects, not just form-related. It's a PITA. Our basic table dump > isn't very pretty, but we had hoped that people would dig in and get > the granular access to the labels and tags that we tried so hard to > build. We don't seem to have communicated that very well... > > We're adding a divDump() coupled with some default css in the next > small release. That may help. > >> And of course there's the general issue of repeating and compound >> fields -- I think they are an > > I tried to read the Readme.txt in FormEncode to determine what a > "repeating" field is... but I couldn't find it. Can you briefly > explain? It sounds important. Repeating fields are fields that can occur multiple times in the same form. If you try the FormEncode demo (umm... if it works right now ;) it has an example -- in that example you get a list of names (first and last?), plus phone numbers for that name (at least, I think that's the example I made...) So you can have an arbitrary number of names, and each name can have an arbitrary number of phone numbers, all in one form with validation and doing updates on all fields simultaneously. (You can do the same thing in FFK as well) With FormEncode you can even shortcircuit validation so that you can do operations like adding a phone number entry without requiring the entire form be valid at the time. If you look at the code, it gets pretty complex, but that was my first go and I should make some changes to FormEncode to make it easier (and I can't rule out rewriting the entire form rendering/processing stuff either). As you can imagine, this complicated form definitions somewhat, but it complicates form rendering and processing considerably, and makes arbitrary templates particularly hard, because you have to start supporting looping and various other combinations (even nested loops... ack!). > Soon, maybe after our next small release, I'd like to get a discussion > going with you and some of the other people who seem interested in > forms, and find a way to get some library actually /built-in/ to > Webkit. It seems like a glaring omission that it's not there, and > between your library and ours, I'm sure that we can find a good > candidate. I'll send in a note with some ideas and questions for > discussion in the next week or so. Yes, I'd certainly be interested in that. I think we could actually go beyond just Webware as well -- there's interest in this sort of thing in Python in general, and you can do a lot of this stuff without being tied to a framework. With FormEncode I used the component stuff I had played with earlier to provide the Webware integration. I think it worked reasonably well. That might be a way to be both framework-neutral but also tied into Webware nicely at the same time. (Though the components are tied to a class similar to Page, which I wonder might be the wrong level -- Page itself is a sort of mini-framework, and there are other possibilities that could live in Webware) Ian |
From: Luke O. <lu...@me...> - 2003-09-23 21:13:42
|
> As you can imagine, this complicated form definitions somewhat, but it > complicates form rendering and processing considerably, and makes > arbitrary templates particularly hard, because you have to start > supporting looping and various other combinations (even nested loops... > ack!). Indeed, props to the mad repeating compound fields. Layout... my two cents here are that FFK has always offered to do too much layout for me. During rough development, I do make use of the default layout dumps, but for anything beyond that I've found that I'd much rather use PSP or Cheetah or your_usual_templating_lib for layout. We're doing this on a large webapp (lots of repeating compounds here :) in PSP, which is working very nicely as far as letting designers layout the forms etc, but points to some of the limitations of a form lib not exposing enough (in this case, particularily with repeating/compound). I'd like to see FormEncode (or WebwareForms etc) make everything available as (getters/properties) for a form, and to expose repeating/compound in a simple list/named-attribute manner. For complex controls, I'm not sure where you draw the line; for instance, a MoveUpDownDynamicSelectBox or whatever it was called, do you give the end user the ability to reposition the buttons etc? Personally, I would say no, just give them reasonable class names and let CSS do the heavy lifting there. But for all controls, making (in PSP for example): <%=field.html%> <%=field.error%> <%=field.description%> and for those who don't care, <%=field%> and for repeating/compound: for field in aGivenField: field.subFieldName.html field.subFieldName.error ... field.anotherField.html field.anotherField.error field.anotherField ... etc (I know FFK has provided most of these in the past, probably FK has too) This puts the burden of looping etc in the existing layout engines. Now, where do something like the FFK htFormLayout layouts fit here? They're simply another layout system, more specialized (I took the htFormLayout nested list ideas and made a fairly ugly looping/conditional layout syntax that just used nested lists/tuples, for example) but still not directly tied to the Forms system. Am I missing something, is there a level of form layouts that doesn't fit here? - Luke |
From: Ian B. <ia...@co...> - 2003-09-20 00:15:32
|
On Friday, September 19, 2003, at 09:58 AM, rt...@sy... wrote: > Hi there, > > What's the major difference between FormKit and FunFormKit? Which form > kit should be used? > FunFormKit has more features, including repeating and compound fields, but it is more complicated to use (or maybe it's more that there's a specific way you have to use it, and FormKit is a bit looser). But I'm afraid I'm not actively developing FunFormKit, so I can't recommend it. Ian |
From: <rt...@sy...> - 2003-09-20 00:53:53
|
Ian Bicking wrote: > On Friday, September 19, 2003, at 09:58 AM, rt...@sy... wrote: > >> Hi there, >> >> What's the major difference between FormKit and FunFormKit? Which >> form kit should be used? >> > FunFormKit has more features, including repeating and compound fields, > but it is more complicated to use (or maybe it's more that there's a > specific way you have to use it, and FormKit is a bit looser). > > But I'm afraid I'm not actively developing FunFormKit, so I can't > recommend it. > > Ian Thanks for the input. Sounds like dAlchemy's FormKit is the way to go. For templating, would you recommend tplCompiler over Cheetah? |