formsess-devel Mailing List for Smarty based forms toolkit (Page 4)
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-04-24 11:33:21
|
> In the developement version (can be obtained from anon svn) you can use > smarty syntax within errormessages however, dunno if that might possibly > help you. > > - david > > ps: @katana: what do you think about that issue? I agree with what you said. There are also limits in several default error messages that make it impossible to use these messages in a real environnement. As you (David) said, they can be used for Q&D forms, but certainly not for something public. If you look at the syntax validator by instance, the message is something like "field does not match the given syntax", and I don't think we can do anything better... Using the new version, you can use Smarty config variables in your error messages, and imho this is the way to go. You separate the template logic, forms logic and text values in a perfect way. Katana |
|
From: Katana <ka...@ka...> - 2004-04-24 11:29:03
|
> 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.
> We should correct that before releasing 2.0, someone might have a look
> at the code and we don't want to scare people away, do we? ;)
Indeed :)
> 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 :)
As long as the coding style is consistent I don't think we HAVE to stick
to one CS, what do you think ? I could run PHPEdit's CodeBeautifier on
the files but there are a few details in the syntax that are not handled
properly :-(
Katana
|
|
From: David <da...@df...> - 2004-04-24 10:26:30
|
Hello,
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.
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}
(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)
What do you think about that?
- david
|
|
From: David <da...@df...> - 2004-04-24 10:15:11
|
Hello,
thanks for the report and sorry for the late response at first!
Which version did you use?
Large parts of the 2.0.0RC* versions have been rewriten and he
validation process was changed fundamentally.
From a quick look I'd say that it's been fixed in the developement
version but I'd appreciate if you can confirm that.
(if you don't want to check out the latest version from svn, there's
also a snapshot in the download section.)
- david
On Wed, 31 Mar 2004 15:56:30 +0100
"Joao Campos" <joa...@ho...> wrote:
> Or at least IE is. It seems that when you only have 1 radio button,
> you can't check if it's checked by using the same code as when you
> have several buttons. The following works (don't mind the
> errorMessages.push('$message') bit, I hacked formsess to display all
> error messages instead of breaking on the first one)
>
>
> var radiogroup = tf['$fname'];
> var itemchecked = false;
> if (!radiogroup.checked) {
> for(var j = 0 ; j < radiogroup.length ; ++j) {
> if(radiogroup[j].checked) {
> itemchecked = true;
> break;
> }
> }
> if(!itemchecked) {
> errorMessages.push('$message');
> }
> }
|
|
From: David <da...@df...> - 2004-04-24 10:05:53
|
Hello, I don't like the idea too much to be honest. Formsess is like a tool box that provides you with what you need to validate a form and display errors but it's not meant to provide 'content' like errormessages itself. This is rather done for testing purpose or if you need to create a quick'n dirty form. As an technical tool Formsess is totally language independent and providing error messages in a certain language somehow conflicts with that imho. In the developement version (can be obtained from anon svn) you can use smarty syntax within errormessages however, dunno if that might possibly help you. - david ps: @katana: what do you think about that issue? On Wed, 31 Mar 2004 15:46:03 +0100 "Joao Campos" <joa...@ho...> wrote: > Here's the thing... The default error message displayed is easy to > change into anything our hearts desire, but using the field name is > usually not the nicest way of putting it to the user - e.g. "Make sure > that field 'SomeFieldName' isn't empty". I would like it to print > something exactely like that but using a 'prettyer name', like 'Some > Field Name' (afterall, the user doesn't need to know how I name my > fields) for the field. Of course you may say, just use the > message="blablabla 'Some Field Name'". Sure that works nice... But the > day I decide to change my error message, I would like to change it in > 1 place instead of scavenging through all my templates manually > replacing the message. Here's what I suggest... if some tag has the > attribute prettyname, use it instead of the name. Oh and store this > somewhere, for validators that need to access other fields can use it. |
|
From: David <da...@df...> - 2004-04-24 09:42:59
|
The intendation of the code is rather inconsistent atm, there're some tabs and different numbers of spaces used. We should correct that before releasing 2.0, someone might have a look at the code and we don't want to scare people away, do we? ;) 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. - david |
|
From: Joao C. <joa...@ho...> - 2004-03-31 14:57:25
|
Or at least IE is. It seems that when you only have 1 radio button, you
can't check if it's checked by using the same code as when you have several
buttons. The following works (don't mind the errorMessages.push('$message')
bit, I hacked formsess to display all error messages instead of breaking on
the first one)
var radiogroup = tf['$fname'];
var itemchecked = false;
if (!radiogroup.checked) {
for(var j = 0 ; j < radiogroup.length ; ++j) {
if(radiogroup[j].checked) {
itemchecked = true;
break;
}
}
if(!itemchecked) {
errorMessages.push('$message');
}
}
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
|
|
From: Joao C. <joa...@ho...> - 2004-03-31 14:57:17
|
Here's the thing... The default error message displayed is easy to change into anything our hearts desire, but using the field name is usually not the nicest way of putting it to the user - e.g. "Make sure that field 'SomeFieldName' isn't empty". I would like it to print something exactely like that but using a 'prettyer name', like 'Some Field Name' (afterall, the user doesn't need to know how I name my fields) for the field. Of course you may say, just use the message="blablabla 'Some Field Name'". Sure that works nice... But the day I decide to change my error message, I would like to change it in 1 place instead of scavenging through all my templates manually replacing the message. Here's what I suggest... if some tag has the attribute prettyname, use it instead of the name. Oh and store this somewhere, for validators that need to access other fields can use it. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail |
|
From: Katana <ka...@ka...> - 2004-03-25 20:59:48
|
> Can you give me a time when i can expect an update? I need the fixed option, > and I'm not that well into the formsess code. Just get the CVS build that's available as a tarball on the website. It works and has lots of bugfixes. > In the distributed examples you create a form and save the values, but normaly > you would do somthing with those values and want the fetch them from the > formsess object, but no example shows me how to do that. I would expect an > function getFormValues() which gives me an hash array. Indeed, there is no such API at the moment. I intend to add such a feature, but I want to think about it correctly before I start implementing. As far as I'm concerned, I just access the form data using _POST and _GET arrays. It works perfectly of course :) > What about the current CVS state? Is it stable/usable? See above. I never commit non working code to the FORMSESS_V2_0_0 branch (the one you can download a tarball of on the site) > Another function I'm missing is a $fs->validated(), whicht tells me if a form > is submitted and validated without an error. $fs->hasErrors() tells you if errors were registered during the validation process. Katana |
|
From: Derk G. <d.r...@ob...> - 2004-03-25 20:21:22
|
> Hi Derk, > > > I realy would like to start using it, but there are some thing I want to > > know - What direction is the library going? Is there still some activity > > in developping it? The last update has been a while ago and I've got some > > obvious bug (option tag not working) > > It is still developped. Maybe not as actively at the moment than it used > to be, but it has not been and will not be abandonned ! Can you give me a time when i can expect an update? I need the fixed option, and I'm not that well into the formsess code. > > > - Do you have some better examples that i can use? > > Err... ask what you need, and I can provide an example. As usually, the > documentation is not as complete as it should be... In the distributed examples you create a form and save the values, but normaly you would do somthing with those values and want the fetch them from the formsess object, but no example shows me how to do that. I would expect an function getFormValues() which gives me an hash array. > > > - What if i start adding/changing a view thing so i can use it for my > > needs, are there any odds that you incorporate it in your version? > > Depends. Backward compatibility is something critical for me, but there > are always possibilities :) > > > Things I want to add are > > - functions to get all fields that are made in the template and functions > > to read those. You get the fields from the request and there are no ways > > to get the fields from de objects. > > I have something in mind for that. > > > - Error handling, or the error array in the formsess is growing when > > using it. > > Also in mind :) > > > - fix the option tag. > > Already fixed in the CVS version. I didn't release a new version, but > read the changelog on the website, and you'll see that lots of things > have been done. What about the current CVS state? Is it stable/usable? Another function I'm missing is a $fs->validated(), whicht tells me if a form is submitted and validated without an error. > > In fact I usually update formsess when I'm working with it. I'm using it > on about 20 sites at work, and every new site i'm doing uses it. But > when I don't work on a new form I usually don't have time to update it... > > > By the way, you should, when possible, use the formsess-general or > formsess-devel mailing lists for formsess related communication, so that > other users can benefit your questions. Done with this email :) |
|
From: David <da...@df...> - 2004-02-29 21:42:08
|
Hello, > > 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? > Because I think it's already used ? :) Anyway, a new release will also confirm people using the old api.. > The last thing i was attempting to fix in 2.0 was variables & > functions handling in any formsess tag, so that you can always use > them, always with the same syntax. Just apply the patch I sent to the HEAD branch and it will work there but doing that with 2.0 will be lots of work.. (just another argument for investing time in the HEAD branch instead of doing all work twice, for 2.0 and HEAD) ;) - david |
|
From: Katana <ka...@ka...> - 2004-02-29 20:50:44
|
> 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..
I don't think I want to port ALL the prefilter stuff to smarty
functions. In my opinion, when possible, as many operations as possible
should be part of prefiltering, since it improves performances a lot: at
the moment, JS validation is generated once, when the template is
compiled, and never again.
And I also think that "static forms" are quite common, so we should try
to keep formsess as efficient as possible when dealing with them.
There are still a few logical questions I have to test before I write
some real draft for that however. Like the order in which templates are
executed when using include, and so on. But yes, of course, the idea IS
to use smarty runtime functions in order to make js validation more
flexible. Server side validation already works with dynamic forms, so
there is no issue here.
> 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?
Because I think it's already used ? :)
Releasing the HEAD version (2.2, or 3.0, dunno) will take some time so I
think that 2.0 should be released ASAP, in order to show that formsess
developement is not dead.
The last thing i was attempting to fix in 2.0 was variables & functions
handling in any formsess tag, so that you can always use them, always
with the same syntax. I did not work on that for a few weeks, so I have
to make a personnal briefing first :)
> I'm willing to do some work, just tell me what to do.
Gotta think about it. Should be possible however :)
Katana
|
|
From: David <da...@df...> - 2004-02-28 22:03:49
|
Hello, my implementation to use smarty-vars & functions as attributes required some dirty extension of the different Formsess-Tag classes. I fixed that, so here's a new version of the patch. Still it only works with input tags but all other tags can easily be made working. It's only neccesary to change "return $this->smartyEmbed($string);" to "return $this->parseAttributes() . $this->smartyEmbed($string);" in all classes. I would be really happy if it could be applied soon. - david |
|
From: David <da...@df...> - 2004-02-28 11:35:58
|
On Sat, 28 Feb 2004 11:35:08 +0100 Katana <ka...@ka...> wrote: > Yes... but I want to support good old HTML too. So what should be done > ? I don't see how using 'id' conflicts with good old HTML. People still can assign a name attribute if the need it for other reasons but it would not be required by formsess. > Add an attribute to form in order to set the (X)HTML version used ? > Make it so that you have to path either name or id, and the one you > use is used in the form tag ? Yes, we could just use 'name' if no id is supplied and issue a warning (or notice?) that it's deprecated. - david |
|
From: David <da...@df...> - 2004-02-28 11:31:45
|
On Sat, 28 Feb 2004 11:33:34 +0100 Katana <ka...@ka...> wrote: > As far as I'm concerned I'm more a studlyCaps user. It is the pear > standard, and I like it better. I know it's not like that in smarty, > but there ARE a few things I don't like in Smarty :) Anyway, my big argument is, formsess should be as easy to use for smarty users as possible. Personal preferences have to stand back ;) > Anyway, how would you handle the backward compatibility problem ? > Create a method / function with the same name but the chosen > convention, and mark the old name as deprecated but keep it working ? Yes, that's what I am for. We could just issue a warning in the old functions and drop them after a while.. I think there're only a few, so the memory consumption shouldn't be that high. > Another solution could be a wrapper class with the old function names, > so that you can use the whole new ones without having the old ones > poluting your memory ? I think it's not so easy to handle, because people have to use different class names (FormsessBc?, FormsessNew?) - david |
|
From: Katana <ka...@ka...> - 2004-02-28 10:37:50
|
> the name attribute for the form tag is only allowed in XHTML 1.0 transitional. > (for backward compability) > > Starting with XHTML 1.0 strict, the attrbibute is not allowed anymore. > > We should use id instead of name to identify forms. Yes... but I want to support good old HTML too. So what should be done ? Add an attribute to form in order to set the (X)HTML version used ? Make it so that you have to path either name or id, and the one you use is used in the form tag ? Bertrand |
|
From: Katana <ka...@ka...> - 2004-02-28 10:36:23
|
> the subject with assign accepting arrays just made me start to thing > about api compability to smarty. > > Classes are named using studlyCaps but what about functions? > Still both ways can be found in formsess (get_value(), hasErrors()). > > Since smarty uses underscores in it's function names I vote for doing > that in formsess too. > (Everything else will confuse people, learning formsess is difficult enough) Yes, I know. I have partially fixed that issue, but the big problem now is Backward Compatibility... As far as I'm concerned I'm more a studlyCaps user. It is the pear standard, and I like it better. I know it's not like that in smarty, but there ARE a few things I don't like in Smarty :) Anyway, how would you handle the backward compatibility problem ? Create a method / function with the same name but the chosen convention, and mark the old name as deprecated but keep it working ? Another solution could be a wrapper class with the old function names, so that you can use the whole new ones without having the old ones poluting your memory ? Bertrand |
|
From: Katana <ka...@ka...> - 2004-02-27 12:47:53
|
> I think you've got me wrong, I don't want to change anything about the > fs:option tag. > > What I suggest is, transforming the two-part tags interally, at the > beginning of FormsessFilter to one-part tag, so they can be processed as > all other tags are. Ok, gotcha. Why not... gotta think about it but why not. > It's a problem in that way, that adding more two-part tags is really > difficult. Just take the fs:textarea tag. > It really should behave like the HTML-textarea-tag (you're talking about > sticking close to HTML yourself). That's another matter :) textarea has opening + closing in order to allow setting a value from the template. At the beggining I didn't want to allow that... but thinking about it why not. As said above I'll think about it, and I'll probably use your suggestion. Thanks a lot, Bertrand |
|
From: David <da...@df...> - 2004-02-27 11:15:26
|
On Fri, 27 Feb 2004 10:32:15 +0100 Katana <ka...@ka...> wrote: > Unfortunately, one of my goals with formsess is to stay as close as > possible from standard HTML code, so I really want to keep a syntax > similar to <option>...</option> I think you've got me wrong, I don't want to change anything about the fs:option tag. What I suggest is, transforming the two-part tags interally, at the beginning of FormsessFilter to one-part tag, so they can be processed as all other tags are. > I don't think that complexity in the Filter is really a problem since > it is only supposed to be called once when the template is compiled > and never again. It's a problem in that way, that adding more two-part tags is really difficult. Just take the fs:textarea tag. It really should behave like the HTML-textarea-tag (you're talking about sticking close to HTML yourself). Changing that takes just a seccond using my suggestion. - david |
|
From: Katana <ka...@ka...> - 2004-02-27 09:34:48
|
> <fs:option value="field1" selected="selected">value_1</fs:option> > <fs:option value="field2">value_2</fs:option> > <fs:option value="field3">value_3</fs:option> > === > gets > === > <fs:option value="field1" selected="selected" tagValue="value_1" /> > <fs:option value="field2" tagValue="value_2" /> > <fs:option value="field3" tagValue="value_3" /> Unfortunately, one of my goals with formsess is to stay as close as possible from standard HTML code, so I really want to keep a syntax similar to <option>...</option> I don't think that complexity in the Filter is really a problem since it is only supposed to be called once when the template is compiled and never again. Katana |
|
From: David <da...@df...> - 2004-02-27 08:29:01
|
Hello,
sorry, I forgot that the fs:select tags should not be parsed to one-part
tags.
So the expression should be
$string =
preg_replace('|<fs:(?!select)([\w]+)(.*?)>(.*?)</fs:\1>|xsmi',
'<fs:$1$2 tagValue="$3" />', $string);
- david
|
|
From: David <da...@df...> - 2004-02-26 20:14:43
|
Hello, a very useful formsess feature would be $fs->add_hidden($name, $value) for adding hidden fields to the form. Passing data from one form to another is a very common task and that feature would simplify it a lot. There's also a feature request on sf.net for that. What I suggest is adding a property _additional_fields and a method add_hidden(_field?))($name, $value) which saves key=>value pairs to that variable to the Formsess class and to loop through the array in the form-tag class and output the fields. What do you think about that? - david |
|
From: David <da...@df...> - 2004-02-26 19:53:32
|
Hello, I just had a look at the FormsessFilter class and how the open and closing option tags are handled. I think that can be simplified by replacing all two-part tags at the very beginning by one-part, selfclosing tags. After diving into php.net's regexp section I built that: $string = preg_replace('!<fs:([\w]+)?(.*)>(.*)</fs:\1>!Uxsmi', '<fs:$1$2 tagValue="$3" />', $string); Example: === <fs:option value="field1" selected="selected">value_1</fs:option> <fs:option value="field2">value_2</fs:option> <fs:option value="field3">value_3</fs:option> === gets === <fs:option value="field1" selected="selected" tagValue="value_1" /> <fs:option value="field2" tagValue="value_2" /> <fs:option value="field3" tagValue="value_3" /> === so the tags can be handled as usual. - david |
|
From: David <da...@df...> - 2004-02-26 10:10:21
|
Hello, the subject with assign accepting arrays just made me start to thing about api compability to smarty. Classes are named using studlyCaps but what about functions? Still both ways can be found in formsess (get_value(), hasErrors()). Since smarty uses underscores in it's function names I vote for doing that in formsess too. (Everything else will confuse people, learning formsess is difficult enough) - david |
|
From: David <da...@df...> - 2004-02-26 10:02:15
|
Hello, the name attribute for the form tag is only allowed in XHTML 1.0 transitional. (for backward compability) Starting with XHTML 1.0 strict, the attrbibute is not allowed anymore. We should use id instead of name to identify forms. - david |
