Jan 02, 2025</h2> Global on nodes: IF the matching error code is triggered, THEN they will display, with no concern for what other on nodes have done. They will only display once. No errors will display if we have any <code>200 success</code>. <h2>Jan 01, 2025 END OF SESSION</h2> So I'm in the midst of reworking <code><on></code> nodes. I think I've fixed the bugs, BUT i have yet to address how global on nodes are handled. Currently, the global on node is attached to the last p-data node, which is generally the <code>default</code> data node. This is unacceptable. I need to decide IF i even want to support global on nodes. I'm slightly leaning NO, because it introduces complexity and the solutions I have in mind ... well the outcome is not necessarily intuitive. IF I keep global on nodes, I have decisions to make: <ol> <li>When global is declared, but data node's is not, does the global get COPIED TO the data node? (if yes, then the global could end up getting displayed multiple times, once for EACH data node it is copied to) (If no, then Global can only be displayed ONCE)</li> <li>If global is declared AND one of the data nodes displays its <code><on></code> node, BUT another data node lacks an on node ... will the global data node still be displayed? (i.e. does the global data node ONLY display when NO OTHER on nodes are displayed? Or does the global data node display when ANY other data nodes lack an on node?)</li> </ol> I'm really strongly leaning toward just disabling global on nodes. It would save a lot of complexity for me as the developer of PHAD, but it would also remove a lot of "wait, how does that work again?" Once I've made my decisions I need to modify the main template as well as compiler code to accomodate it. <h2>Jan 01, 2025</h2> The <code><on></code> node situation is a FREAKING MESS dude. Mentally, I had this concept of "global" on nodes. (i.e. defined under the item, but not under a p-data node). Well, it turns out the "global" on nodes get linked to the LAST data node. Which typically is the DEFAULT data node. BUT if you declare the default as the first data node, then the "global" is STILL linked to the LAST data node, NOT to the default one. So I think I need to describe what I'm expecting of the on nodes. Then look at modifying the code to do what I actually want. When multiple data nodes, and a named data node is used (<code>[":data" => 'name']</code>), and no data is found: <ul> <li>If the named node has a declared <code><on s=404></code>, it's own <code><on></code> should be displayed</li> <li>No <code><on></code> nodes of ANY OTHER data nodes should EVER be displayed</li> <li>If the named node does NOT have a declared <code>404</code> error, AND there is a global <code><on s=404></code>, then display the global</li> <li>If there is no declared <code><on></code> node then just no data is displayed (the view is not loaded).</li> </ul> When there are multiple data nodes, and each of them has an <code><on s=404></code> AND a global <code><on s=404></code> is declared AND data is not found for any of them: <ul> <li>The global <code><on s=404</code> should NEVER be displayed because every data node has its own <code>404</code> message (what about the default? NO)</li> <li>Display every <code><on s=404></code> (except DON'T display the global)</li> </ul> Multiple data nodes, no data found, all but one have <code><on s=404></code> and a global <code><on s=404></code> is declared: <ul> <li>Display every <code><on s=404></code>, INCLUDING the global.</li> </ul> <hr /> Okay, so. When an item is processed, each of its data nodes are processed in order. If one of them returns data, then processing stops. If a data node is named, then NO OTHER data nodes are processed. But then I loop over all data nodes looking for response codes and if I should be printing on nodes. I want to add a <code>$_processed_nodes</code> array, then after processing, we will only loop over <code>$_processed_nodes</code> instead of all data nodes. Further, the <code>if</code> feature will no longer be "is access allowed?" and will instead become "Is this node allowed to be processed?" That means if <code>if="whatever"</code> returns false, then no <code><on></code> nodes will be printed for that node. It is not producing a 404 or 403 response, it is simply NOT BEING PROCESSED. <h2>Dec 31, 2025</h2> HAPPY NEW YEAR! <code>pt StatusBasedContent</code> ... in integration/StatusCodes.php ... there are two subtests that need to be written still. I reworked how the <code><on></code> code works to fix an error. The status-code printing part references <code>$_node</code>. <code>$_node</code> is the last-processed data node. WELL, with NAMED data nodes, the last processed node should always be the named node. So this was causing breakage. But I fixed it. There might still be issues with how <code><on s=*></code> stuff works, but idk. <h2>Dec 30, 2025</h2> Fully support <code>_object</code> in args array, add tests, add enum for data types, improve data loading docs <h2>Dec 29, 2025</h2> documented <code>if=""</code> attribute on data nodes and made a test about it. Added support for <code>fn:some_php_function_name</code> on access attribute. Added tests. Documented it in LoadingData. DONE I think I want to start using <code>type</code> on data nodes and have type be <code>null</code> by default, in which case it becomes either <code>data_loader</code> or <code>mysql</code> type (auto-determined by phad). Other types could be added and supported in the future. <h2>Dec 12, 2025</h2> I'm thinking about abolishing the default data node. It is ... confusing. I'm trying to explain how it works and it ... is hard to explain. I realized that we do require at least one data node present in order to get any data for a view - including explicitly passed-in data. So that makes me lean toward keeping the default data node. Idk. I just kind of hate ittttt. I don't like the auto-query based on <code>$_GET['id']</code>. I do like the ability to return a black hole object for forms, but then I'm all blah about the access stuff. IDUNNO. Today is not the day for alla this heady stuff. <h2>Dec 11, 2025</h2> Decision: a default data node will never perform an SQL query. Tests updated accordingly, all tests are passing. (TODOs used to be right here)<

Jan 02, 2025

Global on nodes: IF the matching error code is triggered, THEN they will display, with no concern for what other on nodes have done. They will only display once. No errors will display if we have any 200 success.

Jan 01, 2025 END OF SESSION

So I'm in the midst of reworking <on> nodes. I think I've fixed the bugs, BUT i have yet to address how global on nodes are handled.

Currently, the global on node is attached to the last p-data node, which is generally the default data node. This is unacceptable.

I need to decide IF i even want to support global on nodes. I'm slightly leaning NO, because it introduces complexity and the solutions I have in mind ... well the outcome is not necessarily intuitive.

IF I keep global on nodes, I have decisions to make:

When global is declared, but data node's is not, does the global get COPIED TO the data node? (if yes, then the global could end up getting displayed multiple times, once for EACH data node it is copied to) (If no, then Global can only be displayed ONCE)
If global is declared AND one of the data nodes displays its <on> node, BUT another data node lacks an on node ... will the global data node still be displayed? (i.e. does the global data node ONLY display when NO OTHER on nodes are displayed? Or does the global data node display when ANY other data nodes lack an on node?)

I'm really strongly leaning toward just disabling global on nodes. It would save a lot of complexity for me as the developer of PHAD, but it would also remove a lot of "wait, how does that work again?"

Once I've made my decisions I need to modify the main template as well as compiler code to accomodate it.

Jan 01, 2025

The <on> node situation is a FREAKING MESS dude. Mentally, I had this concept of "global" on nodes. (i.e. defined under the item, but not under a p-data node). Well, it turns out the "global" on nodes get linked to the LAST data node. Which typically is the DEFAULT data node. BUT if you declare the default as the first data node, then the "global" is STILL linked to the LAST data node, NOT to the default one.

So I think I need to describe what I'm expecting of the on nodes. Then look at modifying the code to do what I actually want.

When multiple data nodes, and a named data node is used ([":data" => 'name']), and no data is found:

If the named node has a declared <on s=404>, it's own <on> should be displayed
No <on> nodes of ANY OTHER data nodes should EVER be displayed
If the named node does NOT have a declared 404 error, AND there is a global <on s=404>, then display the global
If there is no declared <on> node then just no data is displayed (the view is not loaded).

When there are multiple data nodes, and each of them has an <on s=404> AND a global <on s=404> is declared AND data is not found for any of them:

The global <on s=404 should NEVER be displayed because every data node has its own 404 message (what about the default? NO)
Display every <on s=404> (except DON'T display the global)

Multiple data nodes, no data found, all but one have <on s=404> and a global <on s=404> is declared:

Display every <on s=404>, INCLUDING the global.

Okay, so. When an item is processed, each of its data nodes are processed in order. If one of them returns data, then processing stops. If a data node is named, then NO OTHER data nodes are processed.

But then I loop over all data nodes looking for response codes and if I should be printing on nodes.

I want to add a $_processed_nodes array, then after processing, we will only loop over $_processed_nodes instead of all data nodes.

Further, the if feature will no longer be "is access allowed?" and will instead become "Is this node allowed to be processed?"

That means if if="whatever" returns false, then no <on> nodes will be printed for that node. It is not producing a 404 or 403 response, it is simply NOT BEING PROCESSED.

Dec 31, 2025

HAPPY NEW YEAR!

pt StatusBasedContent ... in integration/StatusCodes.php ... there are two subtests that need to be written still.

I reworked how the <on> code works to fix an error. The status-code printing part references $_node. $_node is the last-processed data node. WELL, with NAMED data nodes, the last processed node should always be the named node. So this was causing breakage. But I fixed it.

There might still be issues with how <on s=*> stuff works, but idk.

Dec 30, 2025

Fully support _object in args array, add tests, add enum for data types, improve data loading docs

Dec 29, 2025

documented if="" attribute on data nodes and made a test about it. Added support for fn:some_php_function_name on access attribute. Added tests. Documented it in LoadingData.

DONE I think I want to start using type on data nodes and have type be null by default, in which case it becomes either data_loader or mysql type (auto-determined by phad). Other types could be added and supported in the future.

Dec 12, 2025

I'm thinking about abolishing the default data node. It is ... confusing. I'm trying to explain how it works and it ... is hard to explain. I realized that we do require at least one data node present in order to get any data for a view - including explicitly passed-in data. So that makes me lean toward keeping the default data node.

Idk. I just kind of hate ittttt. I don't like the auto-query based on $_GET['id']. I do like the ability to return a black hole object for forms, but then I'm all blah about the access stuff.

IDUNNO. Today is not the day for alla this heady stuff.

Dec 11, 2025

Decision: a default data node will never perform an SQL query. Tests updated accordingly, all tests are passing.

(TODOs used to be right here)

Taeluf.com