<p class="MsoNormal" style="margin-bottom: 12pt;"> </p>
<p class="MsoNormal"><span class="gmailquote">On 8/31/06, <b>Gerhard Killesreiter</b>
<<a href="mailto:gerhard@killesreiter.de">gerhard@killesreiter.de</a>> wrote:</span></p>
<p class="MsoNormal"><br>
> Unless it is for development purposes, I cannot imagine why my<br>
> programmatically created nodes shouldn't be validated as any other nodes.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">I'll give you one of many examples I have. Every morning a
web based application I created and manage imports a large fixed length flat file
from a legacy mainframe system. The mainframe app that generates this data is
fed by people typing into un-validated form fields on terminals. My application
needs to know about this data as soon as it shows up because it tracks a
variety of metrics that are date sensitive. The data import routines clean up "nodes"
as they come in externally and try to intelligently correct them for a variety
of missing or incomplete elements. There is a level at which an imported "node"
will be discarded because it just lacks too much information. The data is then
inserted into the web app. For the most part this data would pass through the,
now irrelevant, form validation routine. But not always, we let data in from
the import that is missing elements that a user would be required to enter if
they were typing data into the web app directly. We force users to enter this
info, but can't force it from the mainframe. But, we can't throw this node out
because we need to track it and know that the next day the missing info will
most likely be included in the export file. In our application the data object
are completely separate from the form elements, and in many cases we have
multiple forms that talk to a data object with different validation rules.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">This is, admittedly, an obscure example. But there are
countless scenarios like this. This particular app is not built in Drupal, but
I would like to think that it could be. </p>
<p class="MsoNormal"><br>
> Please stop right here. Read <a href="http://buytaert.net/the-pain-before-the-payoff">http://buytaert.net/the-pain-before-the-payoff</a><br style="">
<br style="">
</p>
<p class="MsoNormal">Yes, I have ready this and I agree with it in the context of
4.6-4.7. That said, if we keep radically changing the Drupal API for every release
without serious considerations for backwards compatibility there will never be
a pay-off, only pain. Your community will start dreaming of Plone or Rails.
Think of it like this, when PHP 5 came out with all the enhancements to object
oriented programming, they didn't eliminate people ability to program in a top
down fashion. That would certainly have been unnecessary and broken Drupal. Ok,
I won't go any further with this on this thread is it is off topic.</p>
<p class="MsoNormal"><br>
-Andrew</p>
<p class="MsoNormal"> </p>