formsess-devel — Developpement suggestions, bug reports...

[Formsess-devel] assign() accepting arrays

[David <da...@df...>]

Hello,

I just posted a feature request on sf.net that assign() should support
arrays.

I know there's assignArray() but people using formsess already know
smarty, so why confusing them with another method?

All that needs to be done is renaming assign() (maybe to assignValue()?)
and build a wrapper similar to assignArray:

  function assign($field, $value = '', $force = false) {
    if (is_array($field)) {
         foreach ($array as $key => $value) {
            $this->assignValue($key, $value, $force);
         }
     } else {
         $this->assignValue($field, $value, $force);
     }
  }


- david

[Formsess-devel] client side validators and dynamic forms, release

[David <da...@df...>]

Hello,

> how would you approach the problems of client side validators 
> and dynamic forms (e.g. fields located in a control structure / loop)
> ?

I think the easiest solution is just straight forward:
The <fs:validate..> tags should be parsed to {fs_validate..} function
calls.
The smarty_fs_validate function should add the validator to a stack.
The javascript code for validation should be generated at the end of the
form from that stack.

That would work for the client side but we need to change the handling
of the server side too, don't we?
Otherwise checks for fields which are conditionally displayed would
return errors if the fields are not displayed.
(But the checks would be executed anyway.)

Basically that would end up in porting all the prefilter stuff to smarty
functions..


Anyway, what I suggest is making the HEAD branch ready for release what
means finishing the new OO model and cleaning up the api.
The new api (eg getValue() instead of get_value()) will break
compability anyway, so why make people use the old incompatible 2.0
version?

I'm willing to do some work, just tell me what to do.


> Since Client Side validation is handled by a prefilter, no logic is
> when the JS code is generated, making it impossible to generate proper
> code. I have a little idea about how to implement it, but it's still a
> dirty draft, with nothing even written down, only ideas in my head.
> Another critical topic is "splitting forms in several files". How many
> times didn't I answer "no, formsess can't do that" when I'm asked why 
> strange error messages appear when a template contains something like
> <fs:form...>{include file="_form.tpl"}</fs:form>
> For this one I don't have an accurate idea yet but I'm sure it's
> possible :)

Wouldn't my suggestion porting the prefilter- to smarty-function fix that
as well?
I like the idea, that the xhtml tags are just a wrapper for the smarty
function, so why not move all functionality away from the prefilter?
(So one could even use the smarty-functions directly which is not that
nice but more flexible.)

But as the dynamic form thing form above, I would schedule that after
the release of the current HEAD branch.


- david

ps: I'm using a modified version of the 2.0 branch in many of my
projects but that's really dirty so I would like to have a stable
fullfeatured release as soon as possible.

[Formsess-devel] Feature: $fs->getAllFields, Security: password fields are kept

[David <da...@df...>]

Hello,

while using formsess I noticed that with bigger forms you get a long list
of

$var1 = $fs->get_value('var1');
$var2..

I would like to have a function to return all saved fields in an array.
(It only has to return $this->_sess_space['values']).

I can implement it, I just need to know how to call it, then I'll send a
patch..

(I submitted a feature request at sf for that:
http://sourceforge.net/tracker/index.php?func=detail&aid=891899&group_id=65793&atid=512273)


I also noticed that values of password fields are kept.
I think thats a security problem and should be changend.

We could introduce an optional paramenter (s.th. like keepValue) for the
password-input to keep it..

Same like above: I can fix that and add the new parameter, just tell me
how you want it to be called..

(I submitted a bug report on fs for that:
http://sourceforge.net/tracker/index.php?func=detail&aid=891894&group_id=65793&atid=512270)


-david

Re: [Formsess-devel] Bug: input.class.php

[Katana <ka...@ka...>]

David,

> I just noticed, that all value attributes for textfields got lost.
> That's the problem:
Could you create a bug report on sf.net's bugtracker ? It's easier for 
me to keep track of the project evolution that way.

Thanks,

Katana

Re: [Formsess-devel] Bug: FormsessFilter.class.php

[Katana <ka...@ka...>]

> just noticed a bug in FormsessFitler.class.php:
> When using _one_ script for form validation and processing
> FormsessValidator.class.php is included twice.
> (Once in Formsess.class.php and once in FormsessFilter.class.php)
> 
> Line 388:
> require FS_ROOT . '/FormsessValidator.class.php';
> 
> should be changed to:
> require_once FS_ROOT . '/FormsessValidator.class.php';
Thanks, fixed.

Katana

[Formsess-devel] Bug: FormsessFilter.class.php

[David <da...@df...>]

Hello,

just noticed a bug in FormsessFitler.class.php:
When using _one_ script for form validation and processing
FormsessValidator.class.php is included twice.
(Once in Formsess.class.php and once in FormsessFilter.class.php)

Line 388:
require FS_ROOT . '/FormsessValidator.class.php';

should be changed to:
require_once FS_ROOT . '/FormsessValidator.class.php';

-david

Re: [Formsess-devel] Fix: Smarty-vars & functions as tag-attributes:

[David <da...@df...>]

Hello,

just tried the latest CVS version, couldn't believe it, it's really
working. :-D

Found a few serious bugs in my implentation, so here's the second
version of the patch, forget the first one.

I had to change getAttributeValue(). It must not use
smartyVariableRemoveDelimiter() because that prevents glueAttrbibutes()
from handling the smarty vars & functions correctly..

It might not be the cleanest way, we could probably move some stuff from
glueAttributes() to getAttributeValue() but it works and lets you do
things like:

<fs:input name="whatever" value="{$myvar|myModifier}" />

greets
David

[Formsess-devel] Bug: input.class.php

[David <da...@df...>]

Hello,

I just noticed, that all value attributes for textfields got lost.
That's the problem:

input.class.php:49
 // create the string with the smarty delimiters and all attributes
    $string = 'fs_input_' . $this->getAttributeValue('type') . ' name="' . $this->getAttributeValue('name') . '"';
    $this->deleteAttribute('type'); $this->deleteAttribute('value');

The value attribute is deleted without being added to the string..

Is there any reason not just to change it to
 // create the string with the smarty delimiters and all attributes
    $string = 'fs_input_' . $this->getAttributeValue('type');

and handling the name & value attribute later with all the others?
(That way, my fix to use smarty vars & functions would also apply to
that two attributes.)


-david

Re: [Formsess-devel] Patch: Smarty-vars & functions as tag-attributes

[Katana <ka...@ka...>]

David,

> here's a patch that completes my attempt to make it possible to use
> smarty-vars & functions as tag-attributes.
> What do you think about it?
> (It requires changes in all FormsessTag/* files, I changed only
> input.class.php, if you like it I can modify the others too..)
With a small delay I finally answer your message...
Thanks a lot for the patch. I gave it a quick look, but I guess it's too 
late for my brain to automatically transform diff output to real code; 
anyway I think what I've gathered from the approach is ok.
I'll dig more into it asap (tomorrow hopefully) and keep you informed 
about the results.

> @Katana: is there anything I can help you to get the CVS version
> working soon?
Not yet. But guess what ? It's almost working ! Most tags are ok, even 
if I know ther are a few bugs (I've found one or two while porting the 
validators), and several validators were already ported to the new OO model.
The following validators are working, on both server & client sides:
  - checked
  - empty
  - hasExtension
  - identical
  - size
  - syntax
In 2.0.0 there are 25 files: 10 client + server side validators, and 5 
server side only. At the moment we have 6 server + client side 
validators converted, which makes 4 c + s side validators and 5 s side 
only validators to convert. Not much as far as I can say :)

There are still a few inconsistencies in the OO model, but nothing huge.

Whatever, here is the big word: you can checkout the HEAD version and 
attempt to run it, you should not get any BIG surprise. I guess it's a 
nice step forward.

By the way, while I'm writing another long email, here is a question / 
remark: how would you approach the problems of client side validators 
and dynamic forms (e.g. fields located in a control structure / loop) ? 
Since Client Side validation is handled by a prefilter, no logic is when 
the JS code is generated, making it impossible to generate proper code. 
I have a little idea about how to implement it, but it's still a dirty 
draft, with nothing even written down, only ideas in my head.
Another critical topic is "splitting forms in several files". How many 
times didn't I answer "no, formsess can't do that" when I'm asked why 
strange error messages appear when a template contains something like
<fs:form...>{include file="_form.tpl"}</fs:form>
For this one I don't have an accurate idea yet but I'm sure it's possible :)

Anyway, any idea / suggestion / slap about these improvements is welcome :)

Yours,

Katana

[Formsess-devel] HEAD version: fresh news

[Katana <ka...@ka...>]

Hello,

at last, I managed to get something out of the HEAD CVS version of 
formsess, which had been broken for a few weeks.

First, the facts:
  - tags parsing is working
  - client side validation is working, but I didn't port all the 
validators to the new API yet
  - server side validation is not working yet


Now, what has been done.

A major cleanup, first. All classes and files are prepended with 
Formsess: Formsess.class.php, FormsessFilter.class.php, and so on, in 
order to get a clean API.

Tags parsing is now OO. A base class FormsessTag provides the API for 
all the tags parsing classes, which can be found in libs/FormsessTag/.
As far as I've seen, they are working correctly.

Validators are also OO.
A base class FormsessValidator provides a common API for 2 subclasses: 
FormsessValidatorPHP, and FormessValidatorJavascript.
As explained above, I didn't work on the "new" server side validation 
model yet. But it is not gonna require much work to get it to work again.
The Javascript ones are much more advanced, on the other hand.
Each validator is placed in a file named as follows:
libs/FormsessValidator/<validatorname>.class.php, containing 2 classes:
FormsessValidatorJavascript<validatorname>
and
FormsessValidatorPHP<validatorname>
these classes inherit the base classes of the same names.
They use the API method provided by the base class, and new validators 
implementation is now quite easy.
Mandatory fields are automatically handled by changing a class property, 
and the same goes for valid field types and the default error message.


Now, what's gonna be done.
  1) move Smarty_Formsess.class.php to libs. In the beggining it was 
intended to be a suggestion on how to implement formsess in your 
application, but it looks like almost everyone is using that class, so I 
guess it's better to complete it.
  2) move the *smarty* methods in FormsessFilter to Smarty_Formsess (the 
class name is supposed to change as well). These methods extend smarty 
so I don't see why they're still in FormsessFilter :)
  3) port all the client side validators to the new API
  4) implement the required methods in FormsessValidatorPHP
  5) Update the Formsess class in order to run validation using the new 
validation API

I also have ideas regarding two classes:
  - FormsessControler: this one would use a singleton pattern, in order 
to provide a way to customize any Formsess operation running in your 
application: add custom validators path, enable / disable js validation, 
and so on
  - FormsessContainer (or Storage): an API used to access the form data 
instead of these ugly properties in Formsess.

That's all for now.

You can checkout the HEAD version and see the result.
On your existing templates, you will probably run into issues with 
validators that were not yet reimplemented using the new API, and of 
course server side validation will not work, but it will allow you to 
get a quick overview of what is planned in the next release.

Oh, and I also intend to release Formsess 2.0.0 final :)
So if you have anything in mind i should fix before that, send an email 
on that mailing list, and if you don't mind post a bug report on sf.net :)

Thanks in advance for any comment you like,

Katana

[Formsess-devel] Patch: Smarty-vars & functions as tag-attributes

[David <da...@df...>]

Hello,

here's a patch that completes my attempt to make it possible to use
smarty-vars & functions as tag-attributes.
What do you think about it?
(It requires changes in all FormsessTag/* files, I changed only
input.class.php, if you like it I can modify the others too..)

@Katana: is there anything I can help you to get the CVS version
working soon?

greets
David

Re: [Formsess-devel] smarty-vars/functions in fs-tags

[Katana <ka...@ka...>]

David,

just about our little {capture}'s, I just stumbled (again) upon smarty 
backticks syntax: don't you think it would be good to implement them as 
long as only variables are used as formsess tags parameters ?

http://smarty.php.net/manual/en/language.syntax.quotes.php

For functions, of course, capture is required.

--
  Katana

Re: [Formsess-devel] smarty-vars/functions in fs-tags

[David <da...@df...>]

On Wed, 10 Dec 2003 09:22:40 +0100
Katana <ka...@ka...> wrote:

> glueAttributes just returns a string with arguments ready to be used
> in a smarty function call. If another smarty function call (capture)
> is inserted in that string, we will probably end up with a parse error
> 
> won't we ?

You're right.. I should have looked a little closer to the context..

> {fs_input_text name="foo" {capture ...
> We probably need to
>   - keep in a property the list of captures
>   - return from glueAttributes with a string containing the capture 
> names when needed

Yes, what do you think about that:

adding another property 'captures' to FormsessTag
	var $captures;

initialising it onthe constructor:
	$this->captures = array();

and accessing it via glueAttributes:
===
function glueAttributes() {
    $string = '';
    $atts = getAllAttributes();
    foreach ($atts as $name => $value) {

      if (!$value or ($value == 'false')) {
        $format = ' %s=%s';
      } elseif ($this->_fs_filter->_isSmartyVar($value)) {
      	//we can use a single var directly
      	$value = $this->smartyVariableRemoveDelimiters($value);
      	$format = '%s=%s';
      } elseif (strpos($value, $this->_fs_filter->smarty_ldelim) !== false) {
      	//we need to capture the value
      	$value = 'fs_capture_' . count($this->captures);
      	$this->captures[] = $value;      	
      	$format = '%s=%s';
      } else {
      	//value is a simple string
        $format = ' %s="%s"';
      }
      $string .= sprintf(' %s="%s"', $name, $value);
    } 
    return $string;
  }
===


>   - prepend the captured captures (ahaha.. ahem, right) to the tag 
> string before it is returned.

I'm not sure how to accomplish that.
One solution is building a function adCaptures($string) that simply adds
the capture-tags to the given smarty-function and is called by the
extending function at the very end.
like

function addCaptures($string) {
    $tmp = '';
    foreach($this->captures)
	//add capturetag tp $tmp
   return $tmp . $string;
}

And in the extending functions for example:
return addCaptures($this->smartyEmbed('fs_html_select_date' . $this->glueAttributes()));

I'm not very happy with that, maybe you have a better idea..


Another thing: the input.class.php does that:
    $string = 'fs_input_' . $this->getAttributeValue('type') . ' name="' . $this->getAttributeValue('name') . '"';
    $this->deleteAttribute('type'); $this->deleteAttribute('value');

Which prevents the name and type attribute from beeing captured.
Is there any reason not to handle them like the other attributes?


David

[Formsess-devel] A few things I noticed

[Katana <ka...@ka...>]

 > - in input.class.php the parent constructor is called with passing
 > $fs_filter by ref:
 >     parent::FormsessTag(&$fs_filter);
 > Doesn't make sense since the argument is defined to be passed by ref.

Fixed

 > - in validate.class.php in the definition of the constructor $fs_filter
 > is NOT defined to be passed by ref:
 >     function FormsessTagValidate($fs_filter) {

Fixed

 > - defining FS_INC_FORMSESS_TAG in FormsessTag.class.php and checking for
 > being defined in the extending classes can be replace by a check using
 > class_exists('FormsessTag').

Yes, indeed. However, both work and I don't feel like editing all the 
files at the moment :)

 > - names of variables differ, most of them use underlines and some studly
 > caps f.e. $_enableJSValidation

Yes. In the beggining I was using underscore as a separator but I'm no 
longer using it. I'll work on refactoring all property names but it's a 
bit useless at the moment since big parts of the code are gonna get 
modified soon. I am and will be using the caps method.

-- 
  Katana

Re: [Formsess-devel] smarty-vars/functions in fs-tags

[Katana <ka...@ka...>]

 > I modified _glueAttributes in FormsessTag a little bit and now using
 > smarty vars, functions or whatever you want should be possible.

I have added your implementation to the method in CVS. However, I fear 
that something might be wrong:
glueAttributes just returns a string with arguments ready to be used in 
a smarty function call. If another smarty function call (capture) is 
inserted in that string, we will probably end up with a parse error 
won't we ?
{fs_input_text name="foo" {capture ...
We probably need to
  - keep in a property the list of captures
  - return from glueAttributes with a string containing the capture 
names when needed
  - prepend the captured captures (ahaha.. ahem, right) to the tag 
string before it is returned.
What do you think about that ?

 > I did not use getAttributesNames() and getAttributeValue, accessing
 > $this->attributes directly is much easier.

Sorry but I have removed that. I'd rather avoid as much as possible to 
access properties directly. Accessors are in my opinion better, 
especially here, since I intend to change the way attributes are handled 
later on. However it's just the same :)

 > ps: I don't understand the purpose of the first check, if (!$value or
 > ($value == 'false')), why passing empty parameters unquoted to the
 > smarty-functions? ($format = ' %s=%s';)

In fact, "false" to smarty does not work with a few functions, so It was 
necessary to use a different format in order to pass something that 
smarty really understands as !true.

--
  Katana

[Formsess-devel] smarty-vars/functions in fs-tags

[David <da...@df...>]

Hello,

I modified _glueAttributes in FormsessTag a little bit and now using
smarty vars, functions or whatever you want should be possible.

This is the modified function:
===
  function glueAttributes() {
    $captures = '';
    $string = '';

    foreach ($this->attributes as $name => $value) {

      if (!$value or ($value == 'false')) {
      	//don't know what that means..
        $format = ' %s=%s';
      } elseif ($this->_fs_filter->_isSmartyVar($value)) {
      	//we can use a single var directly
      	$value = $this->smartyVariableRemoveDelimiters($value);
      	$format = '%s=%s';
      } elseif (strpos($value, $this->_fs_filter->smarty_ldelim) !== false) {
      	//we need to capture the value
      	$captures .= $this->smartyEmbed('capture assign="fs_capture_' . $name . '"')
      	. $value . $this->smartyEmbed('/capture');
      	$value = "fs_capture_{$value}";
      	$format = '%s=%s';
      } else {
      	//value is a simple string
        $format = ' %s="%s"';
      }
      $string .= sprintf(' %s="%s"', $name, $value);
    }
    return $captures . $string;
  }
===

That should work, however because the current version doesn't work I
didn't test it at all..

The basic thing is capturing everything that contains a smarty-delimiter
and is "more" than a simple variable.
Btw: I'm not sure if _isSmartyVar works the way it should here since it
allows whitespace before and after a var.

I did not use getAttributesNames() and getAttributeValue, accessing
$this->attributes directly is much easier.

Just tell me what you think about it..

David

ps: I don't understand the purpose of the first check, if (!$value or
($value == 'false')), why passing empty parameters unquoted to the
smarty-functions? ($format = ' %s=%s';)

[Formsess-devel] A few things I noticed

[David <da...@df...>]

Hello,

here are just a few thing I noticed while browsing through formsess:

- in input.class.php the parent constructor is called with passing
$fs_filter by ref:
	parent::FormsessTag(&$fs_filter);
Doesn't make sense since the argument is defined to be passed by ref.

- in validate.class.php in the definition of the constructor $fs_filter
is NOT defined to be passed by ref:
	function FormsessTagValidate($fs_filter) {

- defining FS_INC_FORMSESS_TAG in FormsessTag.class.php and checking for
being defined in the extending classes can be replace by a check using
class_exists('FormsessTag').

- names of variables differ, most of them use underlines and some studly
caps f.e. $_enableJSValidation


david

Re: [Formsess-devel] working CVS version

[David <da...@df...>]

On Tue, 09 Dec 2003 09:08:48 +0100
Katana <ka...@ka...> wrote:

> > when will the CVS version be working again?
> > I'ld like to try a few things but for that I need a working version.
> I do not have any better answer than "as soon as possible"...
> I'll try posting a working version today.

It's not that urgent I'm just interested..

> FormsessFilter classes are working, FormsessValidator classes are 
> broken, as well as FormsessFilter.
> 
> By the way, in order to harmonize filenames, I think about renaming 
> fs_filter.class.php to FormsessFilter.class.php, and the fs_filter
> class to FormsessFilter.
> What do you think about it ? For HEAD of course, V2_0_0 would remain
> as it is.

I think thats a good idea, as you say, things get more consistent with
that. (classes and file named Formsess..., smarty plugins named fs_...)
Renaming the formsess class itself to Formsess might also simplify
things since all other classes begin with an
upper case letter.

david

Re: [Formsess-devel] working CVS version

[Katana <ka...@ka...>]

> when will the CVS version be working again?
> I'ld like to try a few things but for that I need a working version.
I do not have any better answer than "as soon as possible"...
I'll try posting a working version today.

FormsessFilter classes are working, FormsessValidator classes are 
broken, as well as FormsessFilter.

By the way, in order to harmonize filenames, I think about renaming 
fs_filter.class.php to FormsessFilter.class.php, and the fs_filter class 
to FormsessFilter.
What do you think about it ? For HEAD of course, V2_0_0 would remain as 
it is.

--
  Katana

[Formsess-devel] working CVS version

[David <da...@df...>]

Hello,

when will the CVS version be working again?
I'ld like to try a few things but for that I need a working version.

david

[Formsess-devel] Non-default smarty delimiters

[Katana <ka...@ka...>]

Hello,

I  have  modified formsess in order to support non-default smarty
delimiters.

If  you  have  some  spare time, could you give it a try ? It has
only been updated on the CVS Version.

-- 
 Katana                          mailto:ka...@ka...

[Formsess-devel] test

[Katana <ka...@ka...>]

test, please ignore

[Formsess-devel] (no subject)

[Paolo N. P. <pn...@it...>]