From: deelan <de...@in...> - 2003-05-20 19:21:59
|
Ian Bicking wrote: > For the curious, I've just committed a bunch of changes to FormEncode > to the Sandbox, which now support actual interactive forms in > Webware. I'm still learning from the examples I'm writing, so it's > likely to flux some (though the foundation will probably not be > changed too heavily). (...) > > Anyway, too early to use, but if people are interested, I'm certainly > open to design and interface suggestions. i took a brief look and i find this stuff very interesting, cause one of the stronger points of ASP.NET (that i'm leaving behind in favor of python) is the form costruction/validation and i definitely would like to see some advanced form support in webware, better if coupled with cheetah templating, since from what i've seen the two examples given with formencode have inline html mark-up, which is a no-no, at least for me. :) later, deelan |
From: <zu...@zu...> - 2003-05-24 04:18:33
|
> From: Ian Bicking <ia...@co...> > > FWIW, that site is really slow with my modern browser, and not-so-old > computer. Probably to be blamed on overuse of CSS and DHTML. I like > snappiness, and I'm still not getting that from sites that use DHTML > extensively -- at least not on Mozilla, I don't know what Explorer is > like (but Explorer isn't snappy even on pages that it should be snappy > on). Would you please try my site? The home page is static, but all other pages are served up by Webware - I'm interested in the response times you see. James Phillips zu...@zu... |
From: Ian B. <ia...@co...> - 2003-05-24 05:09:58
|
On Fri, 2003-05-23 at 23:18, zu...@zu... wrote: > > From: Ian Bicking <ia...@co...> > > > > FWIW, that site is really slow with my modern browser, and not-so-old > > computer. Probably to be blamed on overuse of CSS and DHTML. I like > > snappiness, and I'm still not getting that from sites that use DHTML > > extensively -- at least not on Mozilla, I don't know what Explorer is > > like (but Explorer isn't snappy even on pages that it should be snappy > > on). > > Would you please try my site? The home page is static, but > all other pages are served up by Webware - I'm interested in > the response times you see. The performance problems I was noting weren't on the server, but on my client -- all the layers and whatnot that the page used caused my browser to render the page terribly slowly. Though I'm afraid (on Mozilla 1.3) that your site acts weird as well, with "Welcome to ZunZun.com" being rendered ontop of the drop-down boxes, making them inaccessible. Ian |
From: Tracy S. R. <tr...@re...> - 2003-05-24 12:50:11
|
On Saturday, May 24, 2003, at 12:02 AM, Ian Bicking wrote: > On Fri, 2003-05-23 at 23:18, zu...@zu... wrote: >>> From: Ian Bicking <ia...@co...> >>> >>> FWIW, that site is really slow with my modern browser, and not-so-old >>> computer. Probably to be blamed on overuse of CSS and DHTML. I like >>> snappiness, and I'm still not getting that from sites that use DHTML >>> extensively -- at least not on Mozilla, I don't know what Explorer is >>> like (but Explorer isn't snappy even on pages that it should be >>> snappy >>> on). >> >> Would you please try my site? The home page is static, but >> all other pages are served up by Webware - I'm interested in >> the response times you see. > > The performance problems I was noting weren't on the server, but on my > client -- all the layers and whatnot that the page used caused my > browser to render the page terribly slowly. Though I'm afraid (on > Mozilla 1.3) that your site acts weird as well, with "Welcome to > ZunZun.com" being rendered ontop of the drop-down boxes, making them > inaccessible. On Mac OS X, using Safari (the apple-made browser) I can't see the center content/text box that the pull-down menus push content into. I can see it on Camino (mozilla's apple-specific browser), but in strange overlapping ways that make it hard to tell what's going on. I wasn't able to do anything with either browser. --T |
From: jose <jo...@cy...> - 2003-05-24 06:14:44
|
The code really doesn't do anything, I had inially tried to task using the code similar to what you outlined, however when I tried to import the testrun class I got the can't import module error. So I'm not sure how to import the module that has the run function. Jose --__--__-- Message: 12 Date: Fri, 23 May 2003 20:45:50 -0400 From: Randall Randall <ra...@ra...> Reply-To: ra...@ra... Organization: RandallSquared Company To: WebWare Community <web...@li...> Subject: Re: [Webware-discuss] Help with TaskKit please jo...@cy... wrote: > Hi all, > > I have a project that I think taskkit might be helpful for, however I > am having alot of trouble understaning how it all works. this is what > I have > > in my __init__.py file for the context I have: > > # Task init > # __init__.py > > > from TaskKit import Task > from testrun import testrun > import time > > > > def contextInitialize(application, path): > print 'hello task' > print application > print path > task = testrun() > > Also in the same contecx I have a file called testrun.py: > om TaskKit import Task > from WebKit.ccm.ccmPage import ccmPage > > class testrun(ccmPage,Task): > def run(self): > print 'and now for something completely different' > > but when I start the appserver I get an error that says module is not > callable and it is refering to test=testrun() > > I'm not sure what I am doing work, this look right given the different > examples i've seen. Any and all help would be very much appreciated I'm not sure what you're trying to do, above, but the thing you probably want is: application.taskManager().addDailyAction(hour, minute, testrun(), testrun) and/or application.taskManager().addPeriodicAction(start_time, seconds_in_between_runs, testrun(), testrun) -- Randall Randall <ra...@ra...> "Not only can money buy happiness, it isn't even particularly expensive any more." -- Spike Jones --__--__-- _______________________________________________ Webware-discuss mailing list Web...@li... https://lists.sourceforge.net/lists/listinfo/webware-discuss End of Webware-discuss Digest |
From: jose <jo...@cy...> - 2003-05-24 07:20:49
|
I finally got it thanks its starting to make sense now jsoe jo...@cy... wrote: > Hi all, > > I have a project that I think taskkit might be helpful for, however I > am having alot of trouble understaning how it all works. this is what > I have > > in my __init__.py file for the context I have: > > # Task init > # __init__.py > > > from TaskKit import Task > from testrun import testrun > import time > > > > def contextInitialize(application, path): > print 'hello task' > print application > print path > task = testrun() > > Also in the same contecx I have a file called testrun.py: > om TaskKit import Task > from WebKit.ccm.ccmPage import ccmPage > > class testrun(ccmPage,Task): > def run(self): > print 'and now for something completely different' > > but when I start the appserver I get an error that says module is not > callable and it is refering to test=testrun() > > I'm not sure what I am doing work, this look right given the different > examples i've seen. Any and all help would be very much appreciated I'm not sure what you're trying to do, above, but the thing you probably want is: application.taskManager().addDailyAction(hour, minute, testrun(), testrun) and/or application.taskManager().addPeriodicAction(start_time, seconds_in_between_runs, testrun(), testrun) -- Randall Randall <ra...@ra...> "Not only can money buy happiness, it isn't even particularly expensive any more." -- Spike Jones --__--__-- _______________________________________________ Webware-discuss mailing list Web...@li... https://lists.sourceforge.net/lists/listinfo/webware-discuss End of Webware-discuss Digest |
From: jose <jo...@cy...> - 2003-05-24 07:41:21
|
Starting to get a handle on tasks, at least I can start one even if it doesn't do much, but now I have an other question. I want to use tasks to check for a particular session and do some clean up when the session ends, or if it has been set for to long, so my question, within a task how can I check for the presence of a session, and then get its attributes. I am starting my task via the context init if that makes any difference. Thanks for any and all help Jose |
From: Ian B. <ia...@co...> - 2003-05-20 20:39:13
|
On Tue, 2003-05-20 at 14:25, deelan wrote: > i took a brief look and i find this stuff very interesting, cause one of > the stronger points of ASP.NET (that i'm leaving behind in favor of > python) is the form costruction/validation and i definitely would like > to see some advanced form support in webware, better if coupled with > cheetah templating, since from what i've seen the two examples given > with formencode have inline html mark-up, which is a no-no, at least for > me. :) Well, all the significant form markup is in FormEncode.HTMLView.Layout, not in the servlet itself (the servlet just has page layout, but obviously that can be done with many different techniques). At one time I thought interfacing with a templating language would be a good idea. Now I'm much less sure -- I don't really see how to do it. I'm open to suggestions, but FormEncode's forms are more subtle than what you would easily handle in a template (though maybe if you don't use some of the features then a template interface might not be too bad). Maybe if the form could be rendered into a simple data structure, and that can be passed on to the template... Ian |
From: Aaron H. <aa...@me...> - 2003-05-20 21:42:16
|
> > >At one time I thought interfacing with a templating language would be a >good idea. Now I'm much less sure -- I don't really see how to do it. >I'm open to suggestions, but FormEncode's forms are more subtle than >what you would easily handle in a template (though maybe if you don't >use some of the features then a template interface might not be too >bad). Maybe if the form could be rendered into a simple data structure, >and that can be passed on to the template... > > Ian > Passing in a dict of list of form object that have a known __str__ or __repr__ would be great. From cheetah we should be able to: #for $item in FormItems: $item #end for or #for $item in FormItems: <$item.tag name=$item.name value=$item.value $extra> #end for Then the template coders could write functions to render form object any way they like Although for <textarea> and <select> it would be more difficult. -Aaron |
From: Tavis R. <ta...@re...> - 2003-05-20 22:30:51
Attachments:
FormLib.tgz
|
On Tuesday 20 May 2003 14:27, Aaron Held wrote: > >At one time I thought interfacing with a templating language would be a > >good idea. Now I'm much less sure -- I don't really see how to do it. > >I'm open to suggestions, but FormEncode's forms are more subtle than > >what you would easily handle in a template (though maybe if you don't > >use some of the features then a template interface might not be too > >bad). Maybe if the form could be rendered into a simple data structure, > >and that can be passed on to the template... > > > > Ian Take a look at the attached tarball if you want yet another approach to Forms with Webware that addresses this question of Controller/View separation and templates. This is the source to FormLib, something I wrote for http://patientwire.com/. Note that, at present, it's got a few dependencies to other parts of the PatientWire code and there's some other things I'd like to tidy up. Also, although my client has agreed to open source this code, we haven't decided on a license or copyright yet. So for the moment this code is for perusal only, not use or redistribution. We'll be packaging and documenting it later this year. I'll post some examples in a few minutes. Cheers, Tavis |
From: Ian B. <ia...@co...> - 2003-05-21 00:13:01
|
On Tue, 2003-05-20 at 16:27, Aaron Held wrote: > Passing in a dict of list of form object that have a known __str__ or > __repr__ would be great. > > From cheetah we should be able to: > #for $item in FormItems: > $item > #end for Well, it'd be more complicated than that. I guess I could imagine a simple case like: <table> #for $item in form.fields: <tr><td>$item.description:</td> <td># if $item.error: $item.error <br> #end if $item.html </td></tr> </table> And that's leaving out compound or repeating fields -- is form.fields going to be a flat list, or a compound list? And at each level there can be an error, like compound password/verification fields, they could individually have errors (like empty password, or weak password), or the combination has an error, i.e., they don't match. So it's not so clear how well you can flatten that list. What's really challenging is the recursive nature of the underlying data structures. I don't think you want recursive programming in a template -- it may be a valid way to describe the layout, but if you *ever* want non-programmers to handle the template, recursion won't work :) Of course, I am doubtful that a non-programmer will be able to usefully design forms without a programmer on hand anyway, at least on this sort of level. Though maybe there's something with nested forms that would be easier to understand. > #for $item in FormItems: > <$item.tag name=$item.name value=$item.value $extra> > #end for Right now the widget is largely opaque. I wouldn't ever expect it to be this transparent, i.e., that you could construct the tag by hand -- there might be something like: $item.html(onClick="something", class_="widget") But some form of separation would be nice, particularly with widgets like radio fields, where you might want to put them in a specially formatted table or something. I'm not sure how that would look either. > Then the template coders could write functions to render form object any > way they like > > Although for <textarea> and <select> it would be more difficult. As would a SecureHidden field, MD5Password, Ordering, Radio, Checkbox/MultiCheckbox, File, TextAreaFile, ImageFileUpload, FileUpload, and ColorPicker -- to name complex widgets already present in FunFormKit (and which I'll port to FormEncode once it's more stable). I'd like more, not less, complex widgets -- especially DHTML widgets, like rich text input, that are a pain to write and work with but would be nice to encapsulate. So in most cases the widgets will have to be quite opaque. Things like Radio would be the exception, if they were made to be taken apart. Ian |
From: Tavis R. <ta...@re...> - 2003-05-21 00:28:51
|
On Tuesday 20 May 2003 17:13, Ian Bicking wrote: > On Tue, 2003-05-20 at 16:27, Aaron Held wrote: > > Passing in a dict of list of form object that have a known __str__ or > > __repr__ would be great. > > > > From cheetah we should be able to: > > #for $item in FormItems: > > $item > > #end for > > Well, it'd be more complicated than that. I guess I could imagine a > simple case like: > > <table> > #for $item in form.fields: > <tr><td>$item.description:</td> > <td># if $item.error: > $item.error <br> > #end if > $item.html > </td></tr> > </table> That's only if you make the form responsible for handling the rendering of each Field (aka FormElement). I think it's better to do what Aaron suggests, and what FormLib implements: delegate the rendering. |
From: Ian B. <ia...@co...> - 2003-05-21 01:23:54
|
On Tue, 2003-05-20 at 19:28, Tavis Rudd wrote: > > Well, it'd be more complicated than that. I guess I could imagine a > > simple case like: > > > > <table> > > #for $item in form.fields: > > <tr><td>$item.description:</td> > > <td># if $item.error: > > $item.error <br> > > #end if > > $item.html > > </td></tr> > > </table> > > That's only if you make the form responsible for handling the rendering of > each Field (aka FormElement). I think it's better to do what Aaron suggests, > and what FormLib implements: delegate the rendering. I've tried to keep FormEncode decoupled, so if you want to use it purely to validate input, that is relatively easy to do. Once I have FormComponent working better, I also plan to do something with actions that does validation and unpacking without rendering (ala DictCall). But for at least 75% of the forms I create (maybe more depending on your definition of "form"), automatic form generation is very much what I want. It allows simple creation of complex forms. The nesting and such is also very much about making a smaller number of complex forms, instead of multiple simple forms that require navigation -- with complex forms you can edit an object and its component objects, instead of having a form to edit the object, and links to forms for editing the subobjects. These forms are mostly used for tasks that are more administrative than public, so delegating responsibility for the layout is not necessary -- i.e., a non-programmer accessible template is not necessary. Good UI *is* necessary, but I think that's better achieved by the richness and consistency of the form than by tweaking the exact layout. Ian |
From: deelan <de...@in...> - 2003-05-21 07:37:48
|
Ian Bicking wrote: > These forms are mostly used for tasks that are more administrative than > public, so delegating responsibility for the layout is not necessary -- > i.e., a non-programmer accessible template is not necessary. Good UI > *is* necessary, but I think that's better achieved by the richness and > consistency of the form than by tweaking the exact layout. after reading the whole thread i agree, adding support for templating complicate things, after all with CSS and when you have a bunch of generated HTML like this: input text: <label for="usernane">Your user name</label> <input tabindex="1" id="usernane" type="text" value="benny" name="username"> check box: <label for="rememberme">Remember my username and password</label> <input id="rememberme" type="checkbox" checked name="rememberme"> button: <button name="_action_login" type="submit">login<button> a <fieldset> and <legend> tags here and there you can style and apply some DOM javascriptin' to do pretty much everything. for example one could hide all <label> elements and put label's text as default text for each control. i've found this site and article very interesting: http://www.youngpup.net/?request=/articles/labels.xml later, deelan |
From: Ian B. <ia...@co...> - 2003-05-21 09:37:23
|
On Wed, 2003-05-21 at 02:37, deelan wrote: > Ian Bicking wrote: > > > These forms are mostly used for tasks that are more administrative than > > public, so delegating responsibility for the layout is not necessary -- > > i.e., a non-programmer accessible template is not necessary. Good UI > > *is* necessary, but I think that's better achieved by the richness and > > consistency of the form than by tweaking the exact layout. > > after reading the whole thread i agree, adding support for templating > complicate things, after all with CSS and when you have a bunch of > generated HTML like this: > > input text: > > <label for="usernane">Your user name</label> > <input tabindex="1" id="usernane" type="text" value="benny" name="username"> > > check box: > > <label for="rememberme">Remember my username and password</label> > <input id="rememberme" type="checkbox" checked name="rememberme"> > > button: > > <button name="_action_login" type="submit">login<button> > > a <fieldset> and <legend> tags here and there you can style and > apply some DOM javascriptin' to do pretty much everything. for example > one could hide all <label> elements and put label's text as > default text for each control. > > i've found this site and article very interesting: > http://www.youngpup.net/?request=/articles/labels.xml FWIW, that site is really slow with my modern browser, and not-so-old computer. Probably to be blamed on overuse of CSS and DHTML. I like snappiness, and I'm still not getting that from sites that use DHTML extensively -- at least not on Mozilla, I don't know what Explorer is like (but Explorer isn't snappy even on pages that it should be snappy on). So, I don't really like DOM or DHTML (or XSL for that matter). It's not unreasonable to fix up the HTML after it has been created, but that's terribly fragile, even when the fixup is implemented in a nice predictable language like Python. That said, normal CSS (without abolute positioning, hiding elements, or other fanciness) is good, and is the best way to do certain kinds of formatting, even if you do have the flexibility of a template available. Ian |
From: Tavis R. <ta...@re...> - 2003-05-20 23:22:43
Attachments:
samples.py
|
On Tuesday 20 May 2003 15:30, Tavis Rudd wrote: > I'll post some examples in a few minutes. Here's some sanitized samples. Parts of it might be a bit confusing as I'm using them with the MVC and FrontController patterns. However, for use with basic servlets just create a form object, call its awake() method from the servlet's awake, its render() or __str__() method from the servlet's respond(), and its sleep() method from the servlet's sleep(). |
From: Ian B. <ia...@co...> - 2003-05-20 23:57:02
|
On Tue, 2003-05-20 at 18:22, Tavis Rudd wrote: > Here's some sanitized samples. Parts of it might be a bit confusing as I'm > using them with the MVC and FrontController patterns. However, for use with > basic servlets just create a form object, call its awake() method from the > servlet's awake, its render() or __str__() method from the servlet's > respond(), and its sleep() method from the servlet's sleep(). Do you have any simpler examples? Without being able to run the sample, I have a hard time figuring out what's going on in it. Ian |
From: Tavis R. <ta...@re...> - 2003-05-21 00:07:32
|
On Tuesday 20 May 2003 16:57, Ian Bicking wrote: > On Tue, 2003-05-20 at 18:22, Tavis Rudd wrote: > > Here's some sanitized samples. Parts of it might be a bit confusing as > > I'm using them with the MVC and FrontController patterns. However, for > > use with basic servlets just create a form object, call its awake() > > method from the servlet's awake, its render() or __str__() method from > > the servlet's respond(), and its sleep() method from the servlet's > > sleep(). > > Do you have any simpler examples? Without being able to run the sample, > I have a hard time figuring out what's going on in it. Yeah, I thought that would be the case. Most of my modules using this library also use the FrontController pattern, which takes a while to grok, so I'll throw a simple servlet based example together. |