| Strange Fillin Problem [message #5836] |
Sat, 06 May 2006 13:10  |
 flod
Messages: 20
Registered: January 2006 |
Junior Member |
|
|
Hey,
Just started using the form fillin filter and I've come across a strange problem. The form fields get pre-filled after a failed form validation, but the source code for all the elements printed by the symfony helpers stop being XHTML compliant.
I.e. <img ... /> becomes <img ...> and <input ... /> becomes <input ...>
Did anyone else come across this strange problem?
Should I submit a ticket?
BTW, this happens for both stable and beta symfony versions.
Thanks,
Florin.
|
|
|
| Re: Strange Fillin Problem [message #5841 is a reply to message #5836 ] |
Sat, 06 May 2006 18:40  |
tamcy
Messages: 222
Registered: February 2006
Location: Hong Kong |
Faithful Member |
|
|
I think so. Actually changing
$response->setContent($doc->saveHTML());
to
$response->setContent($doc->saveXML());
in sfFillInFormFilter.class.php will do the trick.
A side-effect would be a XML declaration in the first line, but I just found it's valid to have XML declaration in XHTML document. http://www.w3.org/TR/xhtml1/ reads
| Quote: |
An XML declaration is not required in all XML documents; however XHTML document authors are strongly encouraged to use XML declarations in all their documents.
|
Another option would be stripping out the first line entirly before output.
EDIT: Anyway I've just created a ticket for this issue. http://www.symfony-project.com/trac/ticket/512
[Updated on: Sat, 06 May 2006 19:19]
|
|
|
|
| Re: Strange Fillin Problem [message #11661 is a reply to message #5836 ] |
Thu, 07 September 2006 17:06 |
nicklocking
Messages: 17
Registered: May 2006
Location: London, UK |
Junior Member |
|
|
This is causing me a bit of trouble - I'm trying to automatically fill in a form and it's making a lot of strange modifications to the page, making the form submission itself stop working and a bit of other stuff. It's too complex to really go into, suffice to say I am a hairs' breadth away from joining the foreign legion.
Anyway, it seems like it'd make more sense in some cases performing auto-form-fillin a different way than running complex DOM analyses on the entire page like the current filter does, which seems prone to errors, very complicated, and CPU-heavy (although that's a minor concern I guess).
Wouldn't it make more sense to instead incorporate this functionality in the Symfony helper functions that spit out form input tags? So you'd call input_tag("name", "Nick"), and if the request object contained an entry for that variable it'd be overwritten (possibly indicated by a function parameter)? I understand this brings its own problems, like what if you have two form elements on the same page in two different forms with the same name, but it seems a lot simpler and easier than the hassle I've gone through trying to get the filter to work.
|
|
|
| Re: Strange Fillin Problem [message #12213 is a reply to message #11661 ] |
Fri, 15 September 2006 18:55 |
francois
Messages: 1636
Registered: October 2005 |
Faithful Member |
|
|
We've tried to have the helpers deal with repopulation on their own before, and it was a nightmare. Every particular case ended up in a hack and the code was unmaintainable. Have a look at previous versions of the code in the SVN repository if you're curious.
The Fillin filter is a much better and robust solution. Besides, if you explain us what exactly is your problem, we might even be able to help you solve it...
|
|
|
Members
Search
FAQ
Register
Login
Home
