Page 1 of 1

Noob (Mis)adventures

PostPosted: Wed Feb 23, 2011 9:31 am
by RobLewis
Below I am repeating, in chronological order, comments I left yesterday on the wiki Tutorial:

Trying Method 1, after looking unsuccessfully in the Dataface directory for the makesite file, I finally found it in the xataface directory, one level up. The instructions are wrong, at least for this version.
----
Went through the Method 1 steps and the site was created and seems to be somewhat functional, but the layout is a complete mess: all the graphics are missing (question marks) and almost all the text is in blue underlined type with a few bullets and checkboxes scattered here and there. Obviously something isn't quite right, but what?
----
Tripped up again by the fact that when the instructions say "dataface", they apparently actually mean "xataface". Finally figured it out and got it to work.
----
My new app is for a database with 5 tables: simple flat data tables—nothing fancy or unusual. Four of them display OK, but when I click the tab for the fifth (which happens to be in the middle of the pack) the browser window goes completely white and the only way to recover is to hit the browser's Back arrow. This table displays fine in phpMyAdmin.

Re: Noob (Mis)adventures

PostPosted: Wed Feb 23, 2011 10:19 am
by shannah
White screen means there's an error. See this page for some troubleshooting tips for this:
http://xataface.com/wiki/Troubleshooting

Re: Noob (Mis)adventures

PostPosted: Wed Feb 23, 2011 11:46 am
by RobLewis
OK, here's the error message when I click on the tab for the troublesome table (I replaced the actual path with <mypath>):

Fatal error: Cannot use object of type PEAR_Error as array in /Library/WebServer/Documents/<mypath>/xataface/Dataface/Table.php on line 3001

Line 3001 in Table.php is the "return" line in this function:

function isPassword($fieldname){
$field =& $this->getField($fieldname);
//if ( !is_array($field) ) return false;
return ($field['widget']['type'] == 'password');
}

As I said, there is nothing particularly unusual about this one table that I can figure out.

Re: Noob (Mis)adventures

PostPosted: Wed Feb 23, 2011 11:48 am
by shannah
Have you implemented any custom config for this table? (e.g. fields.ini, relationships.ini, valuelists.ini, delegate class, actions.ini, etc..?)
Can you post the table schema (e.g. column names and types)?

-Steve

Re: Noob (Mis)adventures

PostPosted: Wed Feb 23, 2011 12:17 pm
by RobLewis
1. No. I haven't done anything to modify the configuration as generated by the makesite program (except insert the debugging statements in index.php).

2. Schema:
Device -- varchar(32)
Host_Name -- varchar(24)
MAC -- varchar(17)
Address_3 -- char(3)
.
.
Address_0 -- char(3)
Address_type -- enum(3 text values)
Bonjour_name -- varchar(24)
Connection -- enum(2 text values)
WiFi_channel -- char(2)
Comment -- varchar(255)
Host_alias -- varchar(16)
Serial No. -- varchar(16) Hmm: this is the only field name that contains a blank and a period
Firmware -- varchar(16)
Remote Access Port -- mediumint(5) This field name contains blanks
Spare_1 -- varchar(32)
Spare_2 -- varchar(32)

I'm surprised to find blanks in those field names (I haven't looked at this table in quite a while). I didn't even know MySQL could have blanks in field names, but that's how they're displayed in phpMyAdmin. Also I believe that the period has special use.

Re: Noob (Mis)adventures

PostPosted: Wed Feb 23, 2011 12:20 pm
by shannah
Xataface unfortunately doesn't like spaces or periods in column names. If you can possibly rename the columns that contain spaces or periods it should fix the problem.

Re: Noob (Mis)adventures

PostPosted: Wed Feb 23, 2011 12:40 pm
by RobLewis
OK, done, thanks. Had a few other little issues to correct, too, but it seems to work now. I note that you convert underscores to blanks in the field name headers.

Re: Noob (Mis)adventures

PostPosted: Wed Feb 23, 2011 12:48 pm
by RobLewis
Question: is there any big performance hit or other downside to leaving those 2 lines of debugging code in index.php?

Re: Noob (Mis)adventures

PostPosted: Wed Feb 23, 2011 1:10 pm
by shannah
No. But it is recommended to not display errors to the browser for production sites as error reports and stack traces could potentially be used to give clues about your server and application structure - which could potentially be exploited in some way.

No performance issues though.