June Update

[JoernT]

This month we've been working on fx-connection that will bring websocket support to Fore.

<fx-connection> can optionally being bound to data or be interacted with by using events.

As formats we plan to support 'xml', 'json' and 'text' and messages will automatically be converted from/to these.

Some first demos are basically working and the base implementation is already stable but it needs a bit more refinement and testing before rollout.

In the course of doing this, i wondered if we should also consider to wrap other APIs like webworker or WebRTC. If somebody shows interest in this please speak up and let us know about your potential use case.

Beyond that we have refined some demos a bit more and started also to work on the upload support. Connection and upload are considered main priorities for now.

a glimpse towards Fore 3.0

Maybe there will another 2.x release but i started some work towards 3.0.

This release will be breaking by removing some <fx- elements where a better, native HTML alternative exists. For instance we've discussed the <fx-instance> element before as being unluckily named - it always requires extra explanation to say it's a data-container. Further HTML already defines the <data> element. Though it's purpose is to define key/value pairs mainly it does not prohibit child content and would be a more natural match for the purpose. This means that <fx-instance> will just be replaced with the native HTML element.

Example:

<fx-fore>
    <fx-model>
         <!-- instead of ... -->
         <fx-instance id="mydata" src="mysource.xml"></fx-instance>
         <!-- use data element instead -->
         <data id="mydata" data-src="mysource.xml"></data>
    </fx-model>
...
</fx-fore>

This comes to the price to use data- prefixes for the attributes (as the standard requires for custom attributes) but otherwise is more expressive than the old syntax and builds directly on an already existing element.

This is probably only one change that will go into 3.0. The <fx-dialog> is another candidate as HTML defines this also in the meantime. - we'll critically review other candidates. The rationale behind it is to give already existing elements priority over custom elements and simplify either the codebase and the usage of Fore by building upon the common ground.

drop it or keep it

Of course the question arises if we should just keep the <fx-instance> element and add the use of <data> as an additional option. However i decided against it:

• it takes much more effort to keep them both as it requires some code-branching and duplicate functionality
• it would encourage a mixed use of both elements not doing clarity and maintainability a favor
• it would also lead to a mix in the demos likely leading to confusion for users
• the documentation would also take this into account
• just deprecating now and removing later does only push the problem into the future and cost us precious dev-time not being spend elsewhere

Enough reasons i hope to justify a 'hard' break requiring users to update their pages when upgrading to 3.0

Making these changes is still a pile of work but at least will shrink the codebase and bring us closer to the platform.

That's it for this month. Comments and thoughts welcome.

[DrRataplan]

I think it's critical that we do not change the behaviour (or our behaviour) with data or dialog elements that are not meant by developers to be interesting to Fore.

For data that's OK: just make instance resolution (or data resolution now) as lazy as we can. So if a <data/> element occurs in the HTML, just ignore it until we see it's actually used.

w.r.t. dialogs, yeah! makes total sense! Dialogs here we go!

One thing though: what about the instance() functions? Rename them to data? That conflicts with fn:data. Can we develop this alongside exposing instances (data now) as variables?

[DrRataplan]

I take back my hesitance with data not always being ours. As long as we restrict ourselves to data in fx-model, we're fine.

still leaves the data function.

[JoernT]

in the meantime ...

@DrRataplan and me discussed and simply renaming from 'Instance()' to 'data()' clashes with XPath data function and should be avoided

Leaves us with these options:
a. have a function with a different name. Not too nice as it involves some name mismatch -> e.g. fx-data() to access
b. create a variable for each data element with it's id used as the name -> $default. This option however blurs distinction (if we really need it) to 'usual' variables create by element.
e. missed a candidate?

I like the terseness of b. much less typing and easy to read but of course we need to make sure then that these variable resolve correctly when data get exchanged etc.

For the concern raised about blurry distinction between 'data' vars and vars created by i guess we can easily forget about it if we consider the fact the author still decides:

<fx-model>
    <data id="_default"></data>
    <data id="_results"></data>

     ...
    <fx-var name="myVar"></fx-var>
</fx-model>

The author can simply use a convention to make a distinction if wanted.

In the end both types are not really different - a var always points to some nodes and this applies for whole data as well as any other XPath expression.

My vote is for just creating variables for all data elements using their id as name.

[JoernT]

hm - what do we do for instance() - of course we can use $default but we loose the shortcut

[JoernT]

Replying myself on that topic:

After discussing with Lars i came to the conclusion that it will be just $default for the default data and no predefined shortcut as Lars argued that the user can always define another fx-var to define a shortcut but that would be explicit in the page.

<fx-fore>
    <fx-model>
         <data>
             <foo>bar</foo>
         </data>
        <fx-var name="_" value="$default"></fx-var>
    </fx-model>
   {$_/foo}
</fx-fore>