<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://www.eiffelroom.com" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>eiffelroom - Advanced - Comments</title>
 <link>http://www.eiffelroom.com/taxonomy/term/9</link>
 <description>Comments for &quot;Advanced&quot;</description>
 <language>en</language>
<item>
 <title>It won&#039;t be collected until</title>
 <link>http://www.eiffelroom.com/article/protecting_objects#comment-461</link>
 <description>&lt;p&gt;It won&#039;t be collected until eif_wean() is called.&lt;/p&gt;

</description>
 <pubDate>Wed, 11 Jun 2008 20:19:54 -0700</pubDate>
 <dc:creator>ted_eiffel</dc:creator>
 <guid isPermaLink="false">comment 461 at http://www.eiffelroom.com</guid>
</item>
<item>
 <title>When you eif_protect()</title>
 <link>http://www.eiffelroom.com/article/protecting_objects#comment-460</link>
 <description>&lt;p&gt;When you eif_protect() something in C, is this considered a reachable reference to the GC? i.e. if the Eiffel side of code loses reachability to an object that was passed to C and eif_protect&#039;ed, will it ever be collected?&lt;/p&gt;

</description>
 <pubDate>Wed, 11 Jun 2008 13:52:26 -0700</pubDate>
 <dc:creator>clemahieu</dc:creator>
 <guid isPermaLink="false">comment 460 at http://www.eiffelroom.com</guid>
</item>
<item>
 <title>Will update tutorial</title>
 <link>http://www.eiffelroom.com/article/creating_a_web_application_with_goanna#comment-374</link>
 <description>&lt;p&gt;Thanks Neal,&lt;/p&gt;

&lt;p&gt;I will integrate this info in the tutorial on Goanna&#039;s Origo page too.&lt;/p&gt;

</description>
 <pubDate>Sun, 04 Nov 2007 09:26:40 -0800</pubDate>
 <dc:creator>bayt</dc:creator>
 <guid isPermaLink="false">comment 374 at http://www.eiffelroom.com</guid>
</item>
<item>
 <title>Great Tutorial</title>
 <link>http://www.eiffelroom.com/article/creating_a_web_application_with_goanna#comment-373</link>
 <description>&lt;p&gt;Thank you for doing this, Till. One thing I&#039;d like to add is that the parameter collections are for validating the semantics of a submitted form, not for validating user input.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Mandatory Parameter Collection&lt;/strong&gt; - These are mandatory at the form processing level, not required fields in the form the user sees.  Typically, these are a html hidden elements used to verify that some system state is the same at form processing time as it was at form generation time.  For example, it might contain the user name of a logged in user to prevent them from submitting a form, logging out, logging in as a new user, and then using the back button to resubmit the previously generated form for the previous user.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Required Parameter Collection&lt;/strong&gt; - These are html elements which must be present in the form for correct processing to occur or whose absence indicates a serious bug in the form generation routine or an attack on the web site. This doesn&#039;t necessarily mean that the user must provide a value for the element. &amp;quot;address_line_2&amp;quot; on a registration page might be an example of a required parameter for which no user input would be required.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Optional Parameter Collection&lt;/strong&gt; - These are elements whose absence from a submitted form is expected sometimes. No processing for this parameter will occur if they are not present in the form.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Add If Absent Parameter Collection&lt;/strong&gt; - These are elements whose absence from a form has meaning.  html checkbox elements provide a typical example. If they are not present in the form submittal, a PARAMETER_PROCESSING_RESULT for them is added so that the appropriate processing for their unchecked state will occur.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Validating User Input&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Each GOA_REQUEST_PARAMETER is responsible for validating the input it receives from the user.  Since receiving invalid input is expected, this does not interrupt request processing. Typically, invalid user input produces&lt;/p&gt;

&lt;p&gt;&amp;quot;not PARAMETER_PROCESSING_RESULT.is_value_valid&amp;quot;&lt;/p&gt;

&lt;p&gt;which in turn triggers the redisplay of the form with an error message.  Several GOA_REQUEST_PARAMETER descendents implement this behavior for common data types.&lt;/p&gt;

</description>
 <pubDate>Sun, 04 Nov 2007 09:19:52 -0800</pubDate>
 <dc:creator>neallester</dc:creator>
 <guid isPermaLink="false">comment 373 at http://www.eiffelroom.com</guid>
</item>
<item>
 <title>Ok.  I would have thought</title>
 <link>http://www.eiffelroom.com/article/daemon_howto#comment-199</link>
 <description>&lt;p&gt;Ok.  I would have thought that when detach returned, after the call to fork, that execution would have continued within the if-then, and then fallen through bypassing the call to execute.  I was confused, I guess, so I&#039;ll have to study it some more.&lt;/p&gt;

</description>
 <pubDate>Mon, 16 Apr 2007 06:28:33 -0700</pubDate>
 <dc:creator>Neitsdelf</dc:creator>
 <guid isPermaLink="false">comment 199 at http://www.eiffelroom.com</guid>
</item>
<item>
 <title>No. Detach, forks and then</title>
 <link>http://www.eiffelroom.com/article/daemon_howto#comment-196</link>
 <description>&lt;p&gt;No. Detach, forks and then calls execute in the new process.&lt;/p&gt;

</description>
 <pubDate>Sun, 15 Apr 2007 23:46:34 -0700</pubDate>
 <dc:creator>patrickr</dc:creator>
 <guid isPermaLink="false">comment 196 at http://www.eiffelroom.com</guid>
</item>
<item>
 <title>Correction?</title>
 <link>http://www.eiffelroom.com/article/daemon_howto#comment-192</link>
 <description>&lt;p&gt;Shouldn&#039;t the call to &amp;quot;execute&amp;quot; be outside of the if-then conditional?&lt;/p&gt;

</description>
 <pubDate>Fri, 13 Apr 2007 07:13:56 -0700</pubDate>
 <dc:creator>Neitsdelf</dc:creator>
 <guid isPermaLink="false">comment 192 at http://www.eiffelroom.com</guid>
</item>
</channel>
</rss>
