Description: ------------ I'm using postgresql 8.x and there the table names as they are understood by the pear db layer and teh formbuilder are created like "public.tablename" This causes Problems, since form fields for crosslinked tables are created like __crossLink_public.siteuser_group_username_id The page receives this as __crossLink_public_siteuser_group_username_id in the post request though ( . --> _). The problem is solved, if in processForm the crosslink name is generated like: $crossLinkName = str_replace('.','_','__crossLink_'. $crossLink['table']. '_'.$crossLink['fromField']. '_'.$crossLink['toField']); (with the str_replace) Could that be put into mainstream ? Kind regards Joseph Wenninger

Could it be possible to generate them without the "public."?

I *could* put something like this in FB, but it would require a bunch of little calls all over the place and this could easily turn into a maintenance nightmare...if '.' is the only special char and this isn't fixable in any other way I'll consider adding it.

I don't think this needs a fix in the code. I'm using Postgres at work and I did not experience this problem - all the table names are reported back without the schema prefix. However a colleague of mine hat a similar(?) problem, and he solved it by changing (in the DataObject generator script): $this->tables = $__DB->getListOf('schema.tables'); To: $this->tables = $__DB->getListOf('tables'); And then re-genenerated the class files. I don't know why on some setups this seems different, but my guess is, it's some configuration issue.

If only the "public" schema is used there is no problem to put generator_strip_schema = true into the inifile for the generator since "tablename" equals to "public.tablename", but if a user uses schemas he has defined himself, he can't do that. I don't really see the problem, why it should be a nightmare to maintain. What about a function fixFieldNames or something like that, through which all generated field names are passed through before being put into the page or before being checked for in post/get requests, which filters anything but a-zA-Z0-9_ away and replaces the bad characters by "_" A disadvantage would be a performance penalty ofcourse.

Take a look at the size of the codebase, this is why it's a maintenance problem. That said, I suppose this does need to be handled somehow.... It looks like either HTML_QuickForm is altering the element names or the browser is. Your solution makes some sense and, actually, is pretty much what DB_DataObject already does when dealing with class and field names. We'll try to get something like this into FormBuilder...

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.