[Ur] Grabbing focus

[Adam Chlipala]

Edward Z. Yang wrote:
> Excerpts from Adam Chlipala's message of Thu May 17 08:50:51 -0400 2012:
>> What about a pseudo-attribute (of type [bool] or [unit]) for focus-able
>> elements, asking to give them focus upon creation?  Maybe this is your
>> first suggestion above.
> Unfortunately, it's not clear if "on creation" is well defined or
> has the desired semantics.  If I generate an XML fragment but don't
> put it on the page, it shouldn't grab focus.

I think it's easy to give it the right semantics.  A value of [xml] type 
doesn't have any side effects on its own; it's just code, much like an 
'IO' value in Haskell.  I can play all sorts of groaty tricks in 
rendering these values into HTML, since Ur/Web enforces a convention of 
executing all code appearing in <script> tags (and then deleting those 
tags) each time HTML is added to the DOM.

> Playing with this a little, I realized this FFI code is a round about
> way of implementing (it does use some internal Ur/Web functions though.)
>
> function addOnload(contents, func) {
>      // func is a string function name; there's probably a better way of doing it
>      nid = fresh();
>      return cat(cat("<div id=\"" + nid + "\">", contents),"</div><script type=\"text/javascript\">" + func + "(\"" + nid + "\");</script>");
> }
>
> Note that when<script>  runs, the node hasn't actually been inserted into
> the document yet, so getElementById won't work; but if you do a setTimeout
> things work well.
>
> So, I think what I want is the ability to put<script>  sections in
> documents, and the ability to uniquely reference fragments of xml.

You already get the ability to associate ID's with tags, without needing 
to use the FFI.

I could, easily enough, add a basis function with a type like 
[transaction {} -> xbody], with the semantics that loading of a page 
fragment triggers execution of all these computations, in the natural order.

However, I'm a bit wary of that general direction.  It's sort of like 
changing Haskell to allow side effects anywhere, regardless of types.  
Suddenly any piece of XML produced by a library (that someone else 
wrote) might cause side effects when rendered.  For instance, it might 
display alert dialogs over and over!  It seems much nicer to think of 
XML fragments as inert.

For your concrete case, it really does sound like a simple static 
pseudo-attribute, for "give this focus when it appears in the DOM," 
ought to get the job done.  To dynamically change focus, you can just 
regenerate the suitable piece of the document.  Am I missing something 
about the use case?

Alexei Golovko wrote:
> Can this be the second source of<ctextbox>?.. (The first one contains text, and the second holds focus state and also text selection begin and end — it may be convenient to have simple access to caret position, for example when implementing autocompletion.)

Certainly the handling of state like caret position has been a bit of a 
nuisance so far.  Your suggestion might be a good direction to go in.