<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<span style="white-space: pre-wrap">
</span>
<blockquote type="cite"
cite="mid:c96f7af9-a034-411d-9cd0-6903d5e66b3b@3nsoft.com">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">{as a follow up to SQLPage presentation}
</pre>
</blockquote>
</blockquote>
...<br>
<blockquote type="cite"
cite="mid:c96f7af9-a034-411d-9cd0-6903d5e66b3b@3nsoft.com">
<pre class="moz-quote-pre" wrap="">I think I am writing commands specifically to expose data flow, as an
important aspect of business logic that can't be hidden be the framework.
</pre>
</blockquote>
<p>Imagine the following user experience scenario, laid in steps,
which can turn into demo with product that uses extended SQL
parser.</p>
<p>1. User writes some markdown.</p>
<p>2. Added text displays as a web page.</p>
<p>3. User want to add data, writes SELECT in triple back quotes
(```).</p>
<p>4. Added text shows as preformated section.</p>
<p>5. User remembers to add $ character to have ```$.</p>
<p>6. Server has no rendering instructions, so it renders tabulated
result in a table, or whatever components are around for defaults.</p>
<p>7. User may not even notice. But displayed table might be dull,
or needing links, or it should be list instead of a table, so,
user looks into docs, and appends his own SELECT with new
RENDERING sections.</p>
<p><br>
</p>
<p>The further first RTFM moment, the better.</p>
<p>Ophir's comments, public on github discussion, feel like her is
already fed with user support. So, the less unexpected code is,
the better. Overloading doesn't help cause messes with existing
notions, while addition of new gets easily absorbed.</p>
<p><br>
</p>
<p>8. User wants to get data? Gotta read about RENDER -> COLLECT
-> DO -> user's own db query -> TRIGGERING something for
page/site. May be it should be COLLECT -> DO -> user's own
db query -> TRIGGERING something, focusing on data flow, with
rendering detail inside, e.g. COLLECT x FROM HTML input WITH type
= 'date', etc. </p>
<p>Wait! Defaults can be used inside. So, user types COLLECT x DO
... user own db query</p>
<p>9. Default input shows on a page.</p>
<p>10. User scans docs again, and adds detail for input.</p>
<p>11. Input is nice, but nothing happens.</p>
<p>Etc.<br>
</p>
<p><br>
</p>
<p>All of this can be sprinkled with warnings about defaults into
browser's console log, cause it is always available.</p>
<p>"Using default ... to render data. You can add ..."</p>
<p>"You can add form/button to send data from page ..."</p>
<p>This lovely helping communication in a style of better modern
compilers can be given to beginners.</p>
<p><br>
</p>
<p>And this is what mix/match can mean, when that sqlparser is
extended. I kinda like this direction. Does anyone have free time
to start this sooner?<br>
</p>
</body>
</html>