From: Edmund L. <el...@in...> - 2003-01-22 18:58:57
|
On 01/22/2003 10:47:59 AM Max wrote: >What bothers me is the need of patching FFK (Ian, would you accept this >patch?). Is there a better way to do what I want? You need to check out a copy of FFK from CVS, which has some bug fixes I put in. Then, use mutable forms as: formDef = FormDefinition(...).mutable() Then, use the methods defined for class MutableFormDefinition to add/replace/delete fields. ...Edmund. |
From: Stuart D. <st...@as...> - 2003-01-22 19:35:54
|
Speaking of FFK, I have not been paying attention to the discussion on it lately, but seem to recall that some changes possibly in architecture have been considered, or are taking place. But it looks like the docs haven't been updated in a while, are they still accurate? Are there any changes that someone should be aware of before looking into FFK for the first time? Also, this may have been discussed before I started paying attention, but should we consider rolling FFK into Webware? It looks like it depends on Webware, and it seems like most of the discussion regarding FFK takes place in the Webware-discuss list. Also, I wonder if it wouldn't add more to Webware as a package if it was delivered with added functionality such as FFK. -Stuart- |
From: Ian B. <ia...@co...> - 2003-01-22 19:55:04
|
On Wed, 2003-01-22 at 13:35, Stuart Donaldson wrote: > Speaking of FFK, I have not been paying attention to the discussion on > it lately, but seem to recall that some changes possibly in architecture > have been considered, or are taking place. But it looks like the docs > haven't been updated in a while, are they still accurate? Are there any > changes that someone should be aware of before looking into FFK for the > first time? No, the instructions are pretty much accurate. I haven't committed any of the larger changes, and I'm still not sure about whether I'll make those changes. > Also, this may have been discussed before I started paying attention, > but should we consider rolling FFK into Webware? It looks like it > depends on Webware, and it seems like most of the discussion regarding > FFK takes place in the Webware-discuss list. Also, I wonder if it > wouldn't add more to Webware as a package if it was delivered with added > functionality such as FFK. I don't know, perhaps -- right now FFK isn't released in sync with Webware. If I was confident that the interface would remain the same over time I'd be more inclined to include it. There's also DAVKit and EmailKit -- neither of which necessarily has to be an actual separate kit, that's just how I distributed them. EmailKit is basically just a single adapter, while DAVKit is analogous to XMLRPC support. There might also be other kits by people that I'm forgetting. I know there's a FormKit. I can't remember anything else at the moment, though. -- Ian Bicking Colorstudy Web Development ia...@co... http://www.colorstudy.com PGP: gpg --keyserver pgp.mit.edu --recv-keys 0x9B9E28B7 4869 N Talman Ave, Chicago, IL 60625 / (773) 275-7241 |
From: Stuart D. <st...@as...> - 2003-01-22 20:15:34
|
Ian Bicking wrote: >>Also, this may have been discussed before I started paying attention, >>but should we consider rolling FFK into Webware? It looks like it >>depends on Webware, and it seems like most of the discussion regarding >>FFK takes place in the Webware-discuss list. Also, I wonder if it >>wouldn't add more to Webware as a package if it was delivered with added >>functionality such as FFK. >> >> > >I don't know, perhaps -- right now FFK isn't released in sync with >Webware. If I was confident that the interface would remain the same >over time I'd be more inclined to include it. > >There's also DAVKit and EmailKit -- neither of which necessarily has to >be an actual separate kit, that's just how I distributed them. EmailKit >is basically just a single adapter, while DAVKit is analogous to XMLRPC >support. > >There might also be other kits by people that I'm forgetting. I know >there's a FormKit. I can't remember anything else at the moment, >though. > > Synchronization definately can be an issue, but from an end-users perspective, it would be really nice to have a single package to download and install to get the functionality of FFK (and other kits.) Perhaps it is something to consider when the kit seems to stabilize. The other kits would definately get more usage if they were bundled. If bundling isn't the right answer currently, then there should be a link off of the Webware HomePage to additional kits for use with Webware. Has anyone got a good list we can use? Short of that, I could see pulling several items from Ian's page: http://www.colorstudy.com/software/webware/ which lists the packages he mentioned here. Maybe if we had a "contrib" directory in a Webware release that included these other kits? We wouldn't need to maintain the kits in Webware's CVS, but just include updated copies in a release. -Stuart- |
From: Ian B. <ia...@co...> - 2003-01-22 20:27:19
|
On Wed, 2003-01-22 at 14:15, Stuart Donaldson wrote: > If bundling isn't the right answer currently, then there should be a > link off of the Webware HomePage to additional kits for use with > Webware. Has anyone got a good list we can use? Short of that, I > could see pulling several items from Ian's page: > http://www.colorstudy.com/software/webware/ which lists the packages > he mentioned here. There's: http://webware.sourceforge.net/ThirdParty.shtml Which needs some of my stuff added at least, and could stand to be linked more prominently. I put an extra call out for more packages. > Maybe if we had a "contrib" directory in a Webware release that > included these other kits? We wouldn't need to maintain the kits in > Webware's CVS, but just include updated copies in a release. My experience with contrib directories from a user perspective has been very inconsistent -- they're full of strange stuff, or sometimes just empty; I now tend to ignore them. Organizationally I think we should stick to listing the packages, and if we want to do one better we'd have a single page that links directly to the packages with brief install instructions (many of them can be installed very easily, just by unpacking into the Webware/ directory). We could certainly include some more packages in Webware, though probably only for the next release. Maybe we can do that as soon as we're through with the beta. -- Ian Bicking Colorstudy Web Development ia...@co... http://www.colorstudy.com PGP: gpg --keyserver pgp.mit.edu --recv-keys 0x9B9E28B7 4869 N Talman Ave, Chicago, IL 60625 / (773) 275-7241 |
From: Max I. <ma...@ma...> - 2003-01-23 06:23:30
|
> You need to check out a copy of FFK from CVS, which has some bug fixes I > put in. Then, use mutable forms as: Where is FFK's CVS? Would next stable version of FFK be release soon? Or may be it would be included in Webware 0.8 release? I it bothers me a bit to use CVS checkout on production site. ;) > formDef = FormDefinition(...).mutable() > Then, use the methods defined for class MutableFormDefinition to > add/replace/delete fields. Aha, thanks! -- Bst rgrds, M.A.X.: Mechanical Artificial Xenomorph. |
From: Max I. <ma...@ma...> - 2003-01-27 09:14:31
|
> >What bothers me is the need of patching FFK (Ian, would you accept this > >patch?). Is there a better way to do what I want? > put in. Then, use mutable forms as: > formDef = FormDefinition(...).mutable() > Then, use the methods defined for class MutableFormDefinition to > add/replace/delete fields. Could someone explain what's the point of using MutableFormDefinition at all? Why coudn't I just modify FormDefinition directly (like with setFields method in my patch)? I assume there _should_ be a reason for MutableFormDefinition. -- ((lambda (foo) (bar foo)) (baz)) |
From: Ian B. <ia...@co...> - 2003-01-27 14:26:01
|
On Mon, 2003-01-27 at 03:14, Max Ischenko wrote: > Could someone explain what's the point of using MutableFormDefinition at > all? Why coudn't I just modify FormDefinition directly (like with > setFields method in my patch)? If you change the form you have to save that changed form so you know what form definition the user submitted. I.e. the changes aren't global, they only apply to that transaction (the three-part process of form generation, validation and possible regeneration and resubmission, and then final processing). So the new mutated form gets its own ID which is recorded in the form, and gets stored for when the user submits it. Ian |
From: Max I. <ma...@ma...> - 2003-01-27 14:35:59
|
Ian Bicking wrote: [...] > If you change the form you have to save that changed form so you > know what form definition the user submitted. I.e. the changes > aren't global, they only apply to that transaction (the three-part > process of form generation, validation and possible regeneration and > resubmission, and then final processing). So the new mutated form gets > its own ID which is recorded in the form, and gets stored for when the > user submits it. OK, thanks. -- Bst rgrds, M.A.X.: Mechanical Artificial Xenomorph. |