From: michelts <mic...@gm...> - 2005-04-17 05:08:52
|
Hi guys! I glad to tell you I done a FormEncode Component, I called it FEComponent. This is an old idea, I using it today in my projects (even before change it to a component). Maybe you Ian remember this thread, I create a FormServlet to handle the form processing, it trigger the final writing of the page, well, with your idea of components, the system is more stable I think... The package could be found in http://www.ebanda.com.br/fecomonent.tgz, there is the component itself, a formpage (like the ZPTPage on the zptkit example) and a Test.py, this is a servlet using the fecomponent... I tryed to comment as most as possible of the source code but i'm here for any questions ;) The system is triggering the final writing of the page yet, but now I don't need to worry the inheritance hierarchy ;) I will be glad to see your comments, is this useful for the community? Thanks for the Component idea Ian, it is really cool... --=20 Michel Thadeu Sabchuk Curitiba - Brasil |
From: michelts <mic...@gm...> - 2005-04-17 12:07:54
|
Hi again, I create a kit to be inserted in Webware, there is a working example too (you can see it working in the Examples of Webware)... The package can be dowloaded in http://www.ebanda.com.br/fecomonent.tgz, I don't know if I must call it FEComponent or FEKit (the package). thanks and enjoy :) On 4/17/05, michelts <mic...@gm...> wrote: > Hi guys! >=20 > I glad to tell you I done a FormEncode Component, I called it > FEComponent. This is an old idea, I using it today in my projects > (even before change it to a component). Maybe you Ian remember this > thread, I create a FormServlet to handle the form processing, it > trigger the final writing of the page, well, with your idea of > components, the system is more stable I think... >=20 > The package could be found in http://www.ebanda.com.br/fecomonent.tgz, > there is the component itself, a formpage (like the ZPTPage on the > zptkit example) and a Test.py, this is a servlet using the > fecomponent... >=20 > I tryed to comment as most as possible of the source code but i'm here > for any questions ;) >=20 > The system is triggering the final writing of the page yet, but now I > don't need to worry the inheritance hierarchy ;) >=20 > I will be glad to see your comments, is this useful for the community? > Thanks for the Component idea Ian, it is really cool... >=20 > -- > Michel Thadeu Sabchuk > Curitiba - Brasil >=20 --=20 Michel Thadeu Sabchuk Curitiba - Brasil |
From: Ian B. <ia...@co...> - 2005-05-25 16:24:29
|
Hi Michel -- sorry I've been so slow to look at FEComponent. I noticed you added in Action. That's something that was built into FormEncode before, but got lost in the shuffle when form generatino (and Submit) went away. I think it's probably correct to put it in at this level instead of directly in FormEncode. It might be better to use Webware actions instead of another action system, but I don't know if there's any conflict there. There shouldn't be, really -- components can add new actions. Though, looking at it, there's no documentation for this. Anyway, you'd do (in the Component subclass): _servletMethods = ['submit_action', ...] def actions(self): return ['submit_action'] Is there a default action? For instance, when the user hits Enter without hitting a button, no submit button will be triggered. Is the first action listed in actionList the default? It looks like processForm() calls on*Click. So the flow typically goes: def writeHTML(self): self.processForm() --> calls on*Click if form is submitted and valid do stuff to write the form then in sleepEvent parseDocument loads the page that was written and rewrites the form with htmlfill. But anyway, it looks pretty easy to use, and I like parseDocument is very output-neutral. It would be good to get this in a public repository. I can't remember if I ever set you up with svn access for FormEncode? This could also go in svn.w4py.org. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: michelts <mic...@gm...> - 2005-05-25 17:10:10
|
Hi Ian, > It might be better to use > Webware actions instead of another action system, but I don't know if > there's any conflict there. There isn't any conflict with webware actions and the fecomponent actions, fecomponent actions look like this: def someaction(self, fields): pass I don't know if I can merge it with the webware actions and still be a plug-in component. > Is there a default action? For instance, when the user hits Enter > without hitting a button, no submit button will be triggered. Is the > first action listed in actionList the default? Sorry, I doesn't documented it yet, I will do it tomorrow, the actions should use like this: class MyServlet(SitePage): actionList =3D ['ok', 'cancel'] def onOkClicked(self, fields): pass def onCancelClicked(self, fields): pass and the html code should have: <form> <input type=3D"submit" name=3D"action.ok" value=3D"Ok"> <input type=3D"submit" name=3D"action.cancel" value=3D"Cancel"> </form> I didn't do a way to specify the method name, maybe it is a TODO :), If you don't want to specify the actions, you can use: <form> <input type=3D"submit" value=3D"Ok"> </form> def processFormData(self, fields): pass # this is the default action handler > It looks like processForm() calls on*Click. So the flow typically goes: >=20 > def writeHTML(self): > self.processForm() --> calls on*Click if form is submitted and valid > do stuff to write the form >=20 > then in sleepEvent parseDocument loads the page that was written and > rewrites the form with htmlfill. You doesn't need to use self.processForm (unless a special case), the processForm is called automatically in the sleepEvent by the parseDocument. the special case is if you want to output some data from the on*Clicked, this way you may call processForm when you want your method called (like in FunFormKit). I send a example to the list with a site I doing, the "Contato" page (to Contact) made use of FEComponent... > But anyway, it looks pretty easy to use, and I like parseDocument is > very output-neutral. Yes, I use it with zptkit, but you can use another component compatible template system or you can write direct from scratch, I use a variant of fecomponent with cheetah, but it is a servlet while there isn't a way to use components with cheetah. > I can't remember if I ever set you up with svn access for > FormEncode? This could also go in svn.w4py.org. Where do you prefer? Sorry about anything I done wrong, the fecomponent make use of validator package, I didn't have time to update it, I will update it tomorrow... regards, --=20 Michel Thadeu Sabchuk Curitiba - Brasil |
From: Ian B. <ia...@co...> - 2005-04-18 16:37:08
|
michelts wrote: > Hi guys! > > I glad to tell you I done a FormEncode Component, I called it > FEComponent. This is an old idea, I using it today in my projects > (even before change it to a component). Maybe you Ian remember this > thread, I create a FormServlet to handle the form processing, it > trigger the final writing of the page, well, with your idea of > components, the system is more stable I think... Thanks, I'll give this a close look soon. I had a FormEncode component, which is now rather out of date: http://svn.colorstudy.com/trunk/FormEncode/experimental/FormEncodeKit/ Hmmm... actually I'm getting a 404 from this URL: > The package could be found in http://www.ebanda.com.br/fecomonent.tgz, > there is the component itself, a formpage (like the ZPTPage on the > zptkit example) and a Test.py, this is a servlet using the > fecomponent... -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: michelts <mic...@gm...> - 2005-04-18 17:45:40
|
On 4/18/05, Ian Bicking <ia...@co...> wrote: > michelts wrote: > > Hi guys! > > > > I glad to tell you I done a FormEncode Component, I called it > > FEComponent. This is an old idea, I using it today in my projects > > (even before change it to a component). Maybe you Ian remember this > > thread, I create a FormServlet to handle the form processing, it > > trigger the final writing of the page, well, with your idea of > > components, the system is more stable I think... >=20 > Thanks, I'll give this a close look soon. I had a FormEncode component, > which is now rather out of date: > http://svn.colorstudy.com/trunk/FormEncode/experimental/FormEncodeKit/ I will see this code too... > Hmmm... actually I'm getting a 404 from this URL: Sorry, the url is http://www.ebanda.com.br/fecomponent.tgz (i forgot the letter p :) thanks --=20 Michel Thadeu Sabchuk Curitiba - Brasil |
From: michelts <mic...@gm...> - 2005-04-19 11:40:31
|
Hi Ian, I look at your FormEncodeKit, you are using formencode package instead of validator, should I use this package? Is validator depreacted? thanks On 4/18/05, Ian Bicking <ia...@co...> wrote: > michelts wrote: > > Hi guys! > > > > I glad to tell you I done a FormEncode Component, I called it > > FEComponent. This is an old idea, I using it today in my projects > > (even before change it to a component). Maybe you Ian remember this > > thread, I create a FormServlet to handle the form processing, it > > trigger the final writing of the page, well, with your idea of > > components, the system is more stable I think... >=20 > Thanks, I'll give this a close look soon. I had a FormEncode component, > which is now rather out of date: > http://svn.colorstudy.com/trunk/FormEncode/experimental/FormEncodeKit/ >=20 > Hmmm... actually I'm getting a 404 from this URL: >=20 > > The package could be found in http://www.ebanda.com.br/fecomonent.tgz, > > there is the component itself, a formpage (like the ZPTPage on the > > zptkit example) and a Test.py, this is a servlet using the > > fecomponent... >=20 > -- > Ian Bicking / ia...@co... / http://blog.ianbicking.org >=20 --=20 Michel Thadeu Sabchuk Curitiba - Brasil |
From: Ian B. <ia...@co...> - 2005-04-19 15:44:23
|
michelts wrote: > Hi Ian, > > I look at your FormEncodeKit, you are using formencode package instead > of validator, should I use this package? Is validator depreacted? Like I said, that package is *very* out of date; I just thought I'd note it in case it had any interesting differences. The validator package is correct. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: michelts <mic...@gm...> - 2005-04-19 16:57:22
|
Hi again... > Like I said, that package is *very* out of date; I just thought I'd note > it in case it had any interesting differences. The validator package is > correct. Ok, let me understand :) The validator is reasonabily stable and the other funcionality are not (like htmlview). I done the validation over the page content, triggering the page final writing, so doesn't matter the way the form is generated... I done a example of use (it goes in webware examples)... Thanks for help... --=20 Michel Thadeu Sabchuk Curitiba - Brasil |
From: Ian B. <ia...@co...> - 2005-05-25 17:27:31
|
michelts wrote: >>It might be better to use >>Webware actions instead of another action system, but I don't know if >>there's any conflict there. > > > There isn't any conflict with webware actions and the fecomponent > actions, fecomponent actions look like this: > > def someaction(self, fields): > pass > > I don't know if I can merge it with the webware actions and still be a > plug-in component. If you can list all the actions up front, you should be able to using the actions() method of the component itself (which is added to the servlet's actions()). >>Is there a default action? For instance, when the user hits Enter >>without hitting a button, no submit button will be triggered. Is the >>first action listed in actionList the default? > > > Sorry, I doesn't documented it yet, I will do it tomorrow, the actions > should use like this: I don't think this is what I meant. If you have an action.ok and an action.cancel, I believe when you hit Enter in the form (instead of clicking a button) that neither of these fields will show up in the request fields -- in that case, one of the actions should be considered clicked by default. >>It looks like processForm() calls on*Click. So the flow typically goes: >> >>def writeHTML(self): >> self.processForm() --> calls on*Click if form is submitted and valid >> do stuff to write the form >> >>then in sleepEvent parseDocument loads the page that was written and >>rewrites the form with htmlfill. > > > You doesn't need to use self.processForm (unless a special case), the > processForm is called automatically in the sleepEvent by the > parseDocument. > > the special case is if you want to output some data from the > on*Clicked, this way you may call processForm when you want your > method called (like in FunFormKit). To me it would make more sense if processForm was called on awake or respond -- sleep seems much too late in the cycle. Hrm... I don't think there's a way to call an event just *after* the servlet's awake is processed (in Wareweb I added this), but that's where I think it belongs. Maybe cpage should be extended to add another event. >>But anyway, it looks pretty easy to use, and I like parseDocument is >>very output-neutral. > > > Yes, I use it with zptkit, but you can use another component > compatible template system or you can write direct from scratch, I use > a variant of fecomponent with cheetah, but it is a servlet while there > isn't a way to use components with cheetah. Yeah, that's too bad. I'd really like if there was a Cheetah component -- I don't think it would be hard to write, and would look very similar to ZPTKit.zptcomponent. >> I can't remember if I ever set you up with svn access for >>FormEncode? This could also go in svn.w4py.org. > > > Where do you prefer? > Sorry about anything I done wrong, the fecomponent make use of > validator package, I didn't have time to update it, I will update it > tomorrow... Maybe svn.w4py.org is better; colorstudy.com has been having problems. If you want to send me a username and password (offlist ;), or a line for htpasswd, I can add you. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Shannon -jj B. <jj...@gm...> - 2005-05-25 18:40:21
|
Hmm, we have a very similar mechanism in Aquarium, so I'm going to make a few comments: On 5/25/05, Ian Bicking <ia...@co...> wrote: > michelts wrote: > >>It might be better to use > >>Webware actions instead of another action system, but I don't know if > >>there's any conflict there. > > > > > > There isn't any conflict with webware actions and the fecomponent > > actions, fecomponent actions look like this: > > > > def someaction(self, fields): > > pass > > > > I don't know if I can merge it with the webware actions and still be a > > plug-in component. >=20 > If you can list all the actions up front, you should be able to using > the actions() method of the component itself (which is added to the > servlet's actions()). Do you really need to make the list explicit? Just look for everything in self matching your naming convention. > >>Is there a default action? For instance, when the user hits Enter > >>without hitting a button, no submit button will be triggered. Is the > >>first action listed in actionList the default? > > > > > > Sorry, I doesn't documented it yet, I will do it tomorrow, the actions > > should use like this: >=20 > I don't think this is what I meant. If you have an action.ok and an > action.cancel, I believe when you hit Enter in the form (instead of > clicking a button) that neither of these fields will show up in the > request fields -- in that case, one of the actions should be considered > clicked by default. Yes, we had to deal with the deadly enter key as well. We do this by having a hidden form field with the default action to be executed. If the user submits the form, that action gets executed. If he clicks a different button, you can change which action gets executed (either via server side code or via JavaScript that changes the value of the hidden variable). I won't send the code because it's not very interesting. Hopefully you get the idea. > >>It looks like processForm() calls on*Click. So the flow typically goes= : > >> > >>def writeHTML(self): > >> self.processForm() --> calls on*Click if form is submitted and val= id > >> do stuff to write the form > >> > >>then in sleepEvent parseDocument loads the page that was written and > >>rewrites the form with htmlfill. > > > > > > You doesn't need to use self.processForm (unless a special case), the > > processForm is called automatically in the sleepEvent by the > > parseDocument. > > > > the special case is if you want to output some data from the > > on*Clicked, this way you may call processForm when you want your > > method called (like in FunFormKit). >=20 > To me it would make more sense if processForm was called on awake or > respond -- sleep seems much too late in the cycle. Hrm... I don't think > there's a way to call an event just *after* the servlet's awake is > processed (in Wareweb I added this), but that's where I think it > belongs. Maybe cpage should be extended to add another event. >=20 > >>But anyway, it looks pretty easy to use, and I like parseDocument is > >>very output-neutral. > > > > > > Yes, I use it with zptkit, but you can use another component > > compatible template system or you can write direct from scratch, I use > > a variant of fecomponent with cheetah, but it is a servlet while there > > isn't a way to use components with cheetah. >=20 > Yeah, that's too bad. I'd really like if there was a Cheetah component > -- I don't think it would be hard to write, and would look very similar > to ZPTKit.zptcomponent. >=20 > >> I can't remember if I ever set you up with svn access for > >>FormEncode? This could also go in svn.w4py.org. > > > > > > Where do you prefer? > > Sorry about anything I done wrong, the fecomponent make use of > > validator package, I didn't have time to update it, I will update it > > tomorrow... >=20 > Maybe svn.w4py.org is better; colorstudy.com has been having problems. > If you want to send me a username and password (offlist ;), or a line > for htpasswd, I can add you. Best Regards, -jj --=20 I have decided to switch to Gmail, but messages to my Yahoo account will still get through. |