Webware for Python

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

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  /  ianb@...  /  http://blog.ianbicking.org

Hmm, we have a very similar mechanism in Aquarium, so I'm going to
make a few comments:

On 5/25/05, Ian Bicking <ianb@...> 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.

Hum,

Sorry david, I think it was my fault, I forgot the update of the
formencode, I used the Validator package, it is outdated but I didn't
have a time to test it, I will do this test and conversion tomorrow...

> The FormEncode documentation and the FEComponent frequently state that we
> can call validators.to_python, which apparently returns a requestDict tha=
t
> we are in dire need of.   After looking at all the source, we noticed tha=
t
> validators.py doesn't have a to_python method but instead has a _to_pytho=
n()
> for each validator that inherits from FancyValidator.   We tried using th=
e
> to_python() in the api.py->FancyValidator class but the arguments are
> different.  For example:=20
>=20
>  =20
> The to_validator in api.py, FancyValidator.py, etc are all defined as:=20
>  =20
>     def to_validator(value, state):=20
>  =20
> The FEComponent.fecomponent.py tries to make a call to
> validators.to_python(NestedVariables, rawFields), which doesn't exist.  T=
he
> other problem is that NestedVariables is a class in variabledecode.py tha=
t
> is derived from api.FancyValidator() so the to_python here is doing
> something much different.  I guess what I'm trying to say is that this wa=
s
> doing some magic we are unable to reproduce.=20

rawFields is a dictionary like this:

{'name':'Michel', 'document.id':'415', 'document.date':'2005-02-26',
'action.ok':'Ok'}

Validating (converting) it with NestedVariables converts it to:

{'name':'Michel', 'document':{'id':'415', 'date':'2005-02-26'},
'action':{'ok':'Ok'}}

Undestand?

It comes from the variabledecode module, I don't know the problem
know, but maybe is the validator package I using is outdated...


> Do you know if we can find an older version of FormEncode or better yet,
> point us in a direction where we can see what the above to_python is real=
ly
> doing?=20

Take a look at the FancyValidator code:

   def to_python(self, value, state=3DNone):
      return self.attempt_convert(value, state, self.validate_other,=20
          self._to_python, self.validate_python)

If you take a look at the attempt_convert code you will understand the
usage, I'm not very clear about this but I think may use to_python on
your own validators or use the combination of validate_other,
_to_python and validate_python... Anyway, any validator extended from
FancyValidator has a to_python method.

I will upgrade the FEComponent to the last svn FormEncode tomorrow,
sorry any mistake :) I didn't have the time to update formencode, I
use validator package on a working project...

regards,

--=20
Michel Thadeu Sabchuk
Curitiba - Brasil

michelts wrote:
>>Do you know if we can find an older version of FormEncode or better yet,
>>point us in a direction where we can see what the above to_python is really
>>doing? 
> 
> 
> Take a look at the FancyValidator code:
> 
>    def to_python(self, value, state=None):
>       return self.attempt_convert(value, state, self.validate_other, 
>           self._to_python, self.validate_python)
> 
> If you take a look at the attempt_convert code you will understand the
> usage, I'm not very clear about this but I think may use to_python on
> your own validators or use the combination of validate_other,
> _to_python and validate_python... Anyway, any validator extended from
> FancyValidator has a to_python method.

.to_python() is the public API; FancyValidator adds some things like 
ifEmpty, notEmpty, and ifInvalid to that, and calls ._to_python() to do 
the real validation.

-- 
Ian Bicking  /  ianb@...  /  http://blog.ianbicking.org