formsess-devel

[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] 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] 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.

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

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

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

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

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

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

> 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

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

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

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