formsess-devel Mailing List for Smarty based forms toolkit (Page 3)
Status: Beta
Brought to you by:
mrkatana
Menu
▾
▴
formsess-devel — Developpement suggestions, bug reports...
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(9) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(24) |
Mar
(4) |
Apr
(15) |
May
(41) |
Jun
(16) |
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(2) |
| 2005 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Katana <ka...@ka...> - 2004-05-15 18:37:08
|
> we've been talking about not keeping values in password fields for > security reason time ago. > > I'll change that in the next days. I'll also add an attribute to tell if > the value should be kept (default no). How should it be called? I'm for > keepvalue. This attribute would only exist for password fields right ? Maybe we could add it for all fields but default it to yes for all the fields but password. what about autoSave=(bool) ? The only thing I don't like about autoSave is that it is not auto since you have to run a validator on the field first... Any better idea ? Bertrand |
|
From: David <da...@df...> - 2004-05-15 17:10:16
|
Hello, we've been talking about not keeping values in password fields for security reason time ago. I'll change that in the next days. I'll also add an attribute to tell if the value should be kept (default no). How should it be called? I'm for keepvalue. - david |
|
From: David <da...@df...> - 2004-05-14 21:05:51
|
Alright, I added the "optional" attribute to the email, isbn, syntax and url validators. I also replaced the checIfEmpty attribute of the size validator (was broken anyway) by the optional attribute. This breaks bc but also the break of the other validators which accepted empty values before is not very grave, makes sense and is better done now. - david On Fri, 14 May 2004 17:03:53 +0200 Katana <ka...@ka...> wrote: > > I think in most cases people don't want to allow empty strings > > entered in email fields. Always adding two checks is very anoying > > and likely to be forgotten. > > Furthermore most of the users won't really read the manual that > > carefully to notice that empty string are accepted. > > If I hear about an email validator I expect it to reject empty > > string as they are not a valid email address. > > > > Also if you want to allow empty values and forget to add the > > acceptEmpty(or whatever) attribute people will complain because they > > get errormessages but if you don't want to allow empty values and > > don't know that the email check does you will run into problems with > > empty fields in your database, email without sender and maybe not > > even notice it. > > > > I strongly vote for an additional attribute to allow empty values > > but to reject them by default. They're just not an email address, > > it's that easy... (same for url) ;) > Yeah, thinking about it, I agree, now. An "optionnal" attribute should > > do the trick. But we will have a BC issue since with the old versions > optionnal had a default value of true, now it would be false... > > In order to implement it, I suppose it will be easy to add it properly > > to FormsessValidator main classes :) > > Katana > > > ------------------------------------------------------- > This SF.Net email is sponsored by: SourceForge.net Broadband > Sign-up now for SourceForge Broadband and get the fastest > 6.0/768 connection for only $19.95/mo for the first 3 months! > http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click > _______________________________________________ > Formsess-devel mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formsess-devel > |
|
From: Katana <ka...@ka...> - 2004-05-14 14:59:01
|
> I think in most cases people don't want to allow empty strings entered > in email fields. Always adding two checks is very anoying and likely to > be forgotten. > Furthermore most of the users won't really read the manual that > carefully to notice that empty string are accepted. > If I hear about an email validator I expect it to reject empty string as > they are not a valid email address. > > Also if you want to allow empty values and forget to add the acceptEmpty > (or whatever) attribute people will complain because they get > errormessages but if you don't want to allow empty values and don't know > that the email check does you will run into problems with empty fields > in your database, email without sender and maybe not even notice it. > > I strongly vote for an additional attribute to allow empty values but to > reject them by default. They're just not an email address, it's that > easy... (same for url) ;) Yeah, thinking about it, I agree, now. An "optionnal" attribute should do the trick. But we will have a BC issue since with the old versions optionnal had a default value of true, now it would be false... In order to implement it, I suppose it will be easy to add it properly to FormsessValidator main classes :) Katana |
|
From: David <da...@df...> - 2004-05-14 14:12:01
|
I think in most cases people don't want to allow empty strings entered in email fields. Always adding two checks is very anoying and likely to be forgotten. Furthermore most of the users won't really read the manual that carefully to notice that empty string are accepted. If I hear about an email validator I expect it to reject empty string as they are not a valid email address. Also if you want to allow empty values and forget to add the acceptEmpty (or whatever) attribute people will complain because they get errormessages but if you don't want to allow empty values and don't know that the email check does you will run into problems with empty fields in your database, email without sender and maybe not even notice it. I strongly vote for an additional attribute to allow empty values but to reject them by default. They're just not an email address, it's that easy... (same for url) ;) For the syntax validator it's even more obvious ihmo. People who build regexps will know how to make them match empty values as well. (but still we could add the acceptEmpty attribute) - david On Fri, 14 May 2004 13:23:41 +0200 Katana <ka...@ka...> wrote: > > I just noticed that the email js validator accepts empty fields as > > valid email addresses. I don't think this is the wanted behaviour in > > most cases. > > In some it might be however, so I suggest to add an optional > > parameter like acceptEmpty to the email and url validators. > > > > What do you think? > It works the way I wanted it to... In my opinion, to make a field > mandatory you use the empty validator, and to check its content you > use another validator. So checking if an an email field has been > filled would require empty then email validators. Maybe we should add > a note to all the validators that check a field content (syntax, > email...) saying that these validators do not check if the field has > been filled; what do you think ? > > Katana > > > ------------------------------------------------------- > This SF.Net email is sponsored by: SourceForge.net Broadband > Sign-up now for SourceForge Broadband and get the fastest > 6.0/768 connection for only $19.95/mo for the first 3 months! > http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click > _______________________________________________ > Formsess-devel mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formsess-devel > |
|
From: David <da...@df...> - 2004-05-14 13:50:41
|
> It allows to post SVN commits to a CVS repository. It can also convert > a repos from SVN to CVS. We can integrate it as a post-commit hook in > order to push any SVN commit to sf.net's CVS Server ! Amazing :-D > Don't you think it would be good if we could still develop with SVN > but benefit sf.net CVS server for statistics purpose ? Users could > browse the CVS repos' from the website, and so on... > > What do you think about that ? I totally agree, that'd be great! It would also solve the problem to update the homepage automatically from svn without an svn client at sf. |
|
From: Katana <ka...@ka...> - 2004-05-14 13:10:57
|
David, while browsing http://scm.tigris.org/, I stumbled upon that project: http://svn2cvs.tigris.org/ It allows to post SVN commits to a CVS repository. It can also convert a repos from SVN to CVS. We can integrate it as a post-commit hook in order to push any SVN commit to sf.net's CVS Server ! Don't you think it would be good if we could still develop with SVN but benefit sf.net CVS server for statistics purpose ? Users could browse the CVS repos' from the website, and so on... What do you think about that ? Bertrand |
|
From: Katana <ka...@ka...> - 2004-05-14 11:18:53
|
> I just noticed that the email js validator accepts empty fields as valid > email addresses. I don't think this is the wanted behaviour in most > cases. > In some it might be however, so I suggest to add an optional parameter > like acceptEmpty to the email and url validators. > > What do you think? It works the way I wanted it to... In my opinion, to make a field mandatory you use the empty validator, and to check its content you use another validator. So checking if an an email field has been filled would require empty then email validators. Maybe we should add a note to all the validators that check a field content (syntax, email...) saying that these validators do not check if the field has been filled; what do you think ? Katana |
|
From: David <da...@df...> - 2004-05-14 09:12:38
|
Hello, I just noticed that the email js validator accepts empty fields as valid email addresses. I don't think this is the wanted behaviour in most cases. In some it might be however, so I suggest to add an optional parameter like acceptEmpty to the email and url validators. What do you think? - david |
|
From: David <da...@df...> - 2004-05-13 13:00:49
|
Hello, the output of formsess isn't fully XHTML compatible yet. There is no name attribute for the form tag. Therefore I suggest to use id as the identifier of a form and fallback to the name attribute when id is not found. There is no language attribute for the script tag. I think it can simply be removed. Another problem is that even hidden input tags must only occur inside of block elements. The automatically added field fsSubmitCheck which is placed right after the form tag must not be there actually. I don't have an idea how to solve that however. (Suggestions are welcome!) What do you think about that? - david |
|
From: David <da...@df...> - 2004-05-12 19:12:16
|
Hello, I just tried to generate some docs from the phpdoc comments using the pear phpDocumentor. It spit out lots of errors and warnings which I'll try to fix the next days. Just one thing: atm there are a few packages (@package) specified for the different classes though not really consequent. I'm not sure if it makes sense to divide formsess in more than one package at all. What do you think? - david |
|
From: David <da...@df...> - 2004-05-12 19:06:02
|
Hello,
I changed the field saving & reading a little bit to support field names
that contain array keys better.
The key methods are Formsess::_parse_field_name and
Formsess::_dig_into_array. (I added the latter)
Just in case you want to have a closer look.
You can now have a textfield named "myfield[testindex]" and either do
$fs->getValue('myfield') which returns array(testindex => enteredValue)
or $fs->getValue('myfield[testindex]') which returns the entered value
directly.
Getting the values of an array of checkboxes (all named "box[]") without
the brackets works as well ($fs->getValue('box')) and returns an array
of all checked boxes.
Everything seems to work for me, but this really needs some testing!
(@Katana: and a review ;) )
- david
ps: i made that changes to the trunk, they have nothing to do with the
tag-parsing issue.
|
|
From: David <da...@df...> - 2004-05-08 15:38:11
|
Hello, I just renamed Formsess::setType to addField because this is what it actually does. (I'm gonna make some more changes to the data handling, this is only the first step). I also removed the docs about setType() and the wrapper set_type because I think it doesn't make _any_ sense at all for the user to call that function, not even for some tweaking or whatever (that's what the docs said) because it does not change the type of a field, it only affects the internal processing. - david |
|
From: David <da...@df...> - 2004-05-08 08:20:12
|
Hello, atm only smarty comments are stripped before and readded after the tag parsing. Shouldn't html comments be stripped too? - david |
|
From: Katana <ka...@ka...> - 2004-05-07 15:43:52
|
> I fixed the small problems with line numbers and tag names in error > reporting and verything works fine now with my new implementation. > > A good thing I forgot to mention is that I was able to remove the many > ugly > wrapper functions in the tag class that call a private(!) method of the > filter class by moving lots of stuff to the tag class. > (though some are still left). > > As it's an overall clean up and simplification I suggest to merge the > changes back into the trunk but please have a critical look at it and > tell me what you think! That's great news ! I am ashamed to admit that the first implementation of tag parsing was quite poor, and i'm sure it's much better now. Unfortunatly, I'll be away until next thursday, but be sure I'll check your changes when I come back, since I'll have a long week end for me :-) Katana |
|
From: David <da...@df...> - 2004-05-07 14:55:54
|
I fixed the small problems with line numbers and tag names in error reporting and verything works fine now with my new implementation. A good thing I forgot to mention is that I was able to remove the many ugly wrapper functions in the tag class that call a private(!) method of the filter class by moving lots of stuff to the tag class. (though some are still left). As it's an overall clean up and simplification I suggest to merge the changes back into the trunk but please have a critical look at it and tell me what you think! - david |
|
From: David <da...@df...> - 2004-04-30 16:10:46
|
Hello, I create a new branch (david_refactor_tagparsing) yesterday and refactored the tag parsing a little bit. The basic idea was not only to handle the generation of the smarty tags by FormsessTag and the extending classes but also the parsing of the <fs: > xml tags. That means that stuff like the tag attributes, whether the tag is an opening, closing or inline closing tag, the name of the tag and so is stored in the FormsessTag class instead of the FormsessFilter class now. There are some smaller issues with the line numbers and tagnames when an error is triggered but basicly it's working. What do you think about my changes? (i have to think about it myself but my head is almost bursting by now..) - david |
|
From: David <da...@df...> - 2004-04-30 15:59:04
|
Fixed. (a few days ago) The regexp that matches the <fs:option> tag matched also the <fs:options> tag. (which was used in that template). That messed up everything and produced that weird error. - david On Tue, 27 Apr 2004 00:07:56 +0200 Katana <ka...@ka...> wrote: > David, > > it looks like there is an issue with selects counting in the HEAD > version: if I have 2 selects in the same template, I get an error > about nested select not permitted, and I'm pretty sure there are no > nested selects there :) > > Are you sure that with your method, selects that are counted as opened > > (<fs:select>) are still counted as closed (that was done at > </fs:select> as far as I remember) ? > > Katana |
|
From: Katana <ka...@ka...> - 2004-04-26 22:07:58
|
David, it looks like there is an issue with selects counting in the HEAD version: if I have 2 selects in the same template, I get an error about nested select not permitted, and I'm pretty sure there are no nested selects there :) Are you sure that with your method, selects that are counted as opened (<fs:select>) are still counted as closed (that was done at </fs:select> as far as I remember) ? Katana |
|
From: David <da...@df...> - 2004-04-24 16:02:36
|
Ok, I modified it a little bit to only include the smarty class file if the class doesn't exist yet. (if it's not in the inlcude path, people have to include it manually) On Sat, 24 Apr 2004 17:24:35 +0200 Katana <ka...@ka...> wrote: > > I just renamed the Smarty_formsess class to SmartyFormsess. > > > > What do you think about moving it to libs/ ? > > I think it's not really a sample (they are not required to use > > formsess), but _the_ smarty class that has to be used, it should not > > be changed in anyway. > > > > If people need to change anything else in the smarty class they > > should simply inherit a new class from SmartyFormsess. > Agreed :) > > Katana > > > ------------------------------------------------------- > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek > For a limited time only, get FREE Ground shipping on all orders of $35 > or more. Hurry up and shop folks, this offer expires April 30th! > http://www.thinkgeek.com/freeshipping/?cpg=12297 > _______________________________________________ > Formsess-devel mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formsess-devel > |
|
From: Katana <ka...@ka...> - 2004-04-24 15:22:41
|
> I just renamed the Smarty_formsess class to SmartyFormsess. > > What do you think about moving it to libs/ ? > I think it's not really a sample (they are not required to use > formsess), but _the_ smarty class that has to be used, it should not be > changed in anyway. > > If people need to change anything else in the smarty class they should > simply inherit a new class from SmartyFormsess. Agreed :) Katana |
|
From: David <da...@df...> - 2004-04-24 13:43:56
|
I just renamed the Smarty_formsess class to SmartyFormsess. What do you think about moving it to libs/ ? I think it's not really a sample (they are not required to use formsess), but _the_ smarty class that has to be used, it should not be changed in anyway. If people need to change anything else in the smarty class they should simply inherit a new class from SmartyFormsess. - david |
|
From: Katana <ka...@ka...> - 2004-04-24 12:59:17
|
> Guess mainly I messed up the intendation, I didn't even know we use 2 > spaces.. ;) > (the pear standard says 4, personally I'm fine with 2, though it's > somehow inconvenient..) 4 is too much imho... if you're fine with 2 spaces it's cool :) Katana |
|
From: David <da...@df...> - 2004-04-24 12:04:08
|
On Sat, 24 Apr 2004 13:30:59 +0200
Katana <ka...@ka...> wrote:
> > The intendation of the code is rather inconsistent atm, there're
> > some tabs and different numbers of spaces used.
> As far as I'm concerned, I always use 2 spaces for 1 tab. But it is
> posisble that I've edited a few files with an editor that was not
> properly configured.
Guess mainly I messed up the intendation, I didn't even know we use 2
spaces.. ;)
(the pear standard says 4, personally I'm fine with 2, though it's
somehow inconvenient..)
> > Except of the intendation, that we don't use the one-true-brace
> > convention for functions and some naming issues the code follows the
> > pear cs, I guess. It won't be a bad idea to run it through some code
> > beautifier to see if everything's fine however.
> Hmmm there are parts of the PEAR CS I don't appreciate, and
> one-true-brace is one of them. Err one true brace is
> function foo()
> {
> ...
> }
> right ? I never remember if it's that or the other way around, but
> whatever :)
Yes.
> As long as the coding style is consistent I don't think we HAVE to
> stick to one CS, what do you think ?
Yes I agree, I didn't want to say it has to be changend I justed wanted
to mention that we differ in that way..
(though renaming the internal stuff using studlyCaps would be nice,
someday..)
> I could run PHPEdit's CodeBeautifier on
> the files but there are a few details in the syntax that are not
> handled properly :-(
Maybe you can let it just correct the intendation, then see what else
it suggests and decide whether it makes sense or not.
- david
|
|
From: Katana <ka...@ka...> - 2004-04-24 11:37:58
|
> regarding the proposal for a <fs:ifErrors> tag.
>
> Handling of errormessages in the template is rather inflexible atm.
> There's no possibility to loop all messages for example.
Yeah, I had that in mind in the beggining, but it has never been
implemented since I didn't stumble upon a proper syntax yet...
> Hooking in to smarty somehow and having a $smarty.formsess variable with
> at least two keys 'values' and 'errors' would be great.
>
> Then you could simply do
> {foreach from=$smarty.formsess.errors item="error"}
> ..
> {/foreachelse}
> Form doesn't have any errors
> {/foreach}
Hmmm of course that's a possibility, but I don't think we should mix
formsess syntax and smarty syntax, what do you think ? Of course it
would be totally useless to rewrite loops code and all that stuff for
formsess itself but I'm not sure it is the way to go... I have to think
about it.
> (I just don't know how that would work when you want to use that var
> before the form tag is openend and you don't create a formsess object in
> the php code, because that object would only be createt with the opening
> of the form tag)
Theorically, if you do something like $smarty.formsess.formname.errors
(or any similar syntax), it can be done, since formsess uses a kind of
singleton pattern. Not properly implemented yet, though _ has to be done
for 2.0.0 _ but it should work. We would have to write a wrapper with
our own syntax though... since calling that from outside a form would
require to create a formsess instance if it was not created before, the
way it's done in the fs:form tag.
Katana
|
