When returning items that don't necessarily have a body (or a view!) i.e. a temporary redirect from a controller, rather than error'ing out in kill the output (but still send the headers) if no view is available.

Some initial thoughts on fix for this:

• a change in the default policy
• a back-up view that takes lower priority than all other views but traps specific response codes (i.e. ones that typically involve the browser redirecting)

Reproduce by calling a static method on a class that does not exist in a view template / layout.

Is there anyway around this?

When trying to return Response Object.
Then controller raises:

Object of class WelcomeHomeController could not be converted to string

In Controller.class.php file, error exists at line 197

$response->data['controller'] = $this;

I did a quick fix by

if(is_string($response->data)) $response->data = "";

[Submitted by zdk]

/* !BelongsTo person, Key: person_id / class Post extends Model {}

/* !HasMany post / class Person extends Model {}

$person->post();

It works if I use PersonId instead

Can I use Key: some_custom_id_field?

[Originally posted by zdk]

The "Big 4" GET, POST, PUT, DELETE are first-class and well supported. There are many more, though and some important ones remaining to have better support: HEAD, OPTIONS, TRACE

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

TRACE

The TRACE method is used to invoke a remote, application-layer loop- back of the request message. The final recipient of the request SHOULD reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the

origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see section 14.31). A TRACE request MUST NOT include an entity.

TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via header field (section 14.45) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.

If the request is valid, the response SHOULD contain the entire request message in the entity-body, with a Content-Type of "message/http". Responses to this method MUST NOT be cached.

Return only the headers of a GET request, with no message-body.

From the HTTP spec...

The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.

You can use isNull('column') but it makes more sense to use equal('column', null), it's should be coded with a simple if like this:
if ( comparedValue == null )
return isNull($column);

Currently the Request class has a property $meta of type Meta.
The Response class however also has a property $meta but is of type array (at least at initialization it gets overwritten with the Meta from $request tough).

As Meta is used as a simple key->value container I suggest just making it an array instead.

If you are trying to use a class which has an error (like $blah = new ClassWithANastyError()), you'll get an error message stating "ClassWithANastyError has not been imported". This only occurs if you Library::import() a class which Library::import()s the erroneous class file. (think of an erroneous *Input.class.php which is indirectly imported via Form.class.php).
If you directly Library::import() the erroneous file, you'll get the right error message (like a PHP parse error message).

If one of your annotations refer to a non-existing Model it will create a fatal error inside recess/diagnostics/output/exception_report.php
It says that printType cannot be re-declared.
Wrapping it with:
if (!function_exists('printType')) { /function here/ }
propagates the error to the next function.
After wrapping all functions the exception_report.php file works and returns an error from printCodeSnippet() that says that the $file parameter is empty instead of notifying that the Model does not exist.
Fixing the misspelled Model fixes the problem.

Re: http://forums.recessframework.org/topic/50-changing-the-default-applications/pageviewfindpostp275

It might be a good idea to remove the explicit "/" for the !Route annotation of the WelcomeHomeController->index(). I found this very confusing as I expected to change the $app->routingPrefix and have everything work. It is confusing to have something lower down stepping on the toes of something higher up like that. Especially in the default install.

When creating model from existing table, after choosing a table name, if the given table has a double unsigned column, a fatal error will be thrown and fields are not updated or become blank.

URL accessed by AJAX:
http://localhost/recess/apps/model/gen/getTableProps/Default/table_name.json

Error:
Fatal error: Call to undefined function double unsigned() in D:\wamp\www\recess\recess\database\pdo\MysqlDataSourceProvider.class.php on line 109

Column in question:
column_name double unsigned DEFAULT NULL

I'm using the edge version from github. Lines with problem:

108: if( ($spacePos = strpos($mysqlType,' '))) {
109: $mysqlType = substr($mysqlType(0,$spacePos));
110: }

When you have two models, e.g. Foo and Bar, and you have a '!HasMany Bar' annotation on model Foo, it will return objects when calling bars() on a newly created Foo object.
Steps to reproduce:
create a model Foo with annotation '!HasMany Bar', create a model Bar with a '!BelongsTo Foo'.
1. Create a Foo object with one related Bar object and save it (i.e. it will be stored in te DB).
2. Create a new Foo object without any Bar object (so it doesn't have an 'id' yet).
3. Now, when you call:
$foo1 = new Foo(); $barSet = $foo1->bars();

variable $barSet contains the Bar object created in the first step.