expression language - or how to access HashMap contents

[mhaupt]

Hello -

how do I access the values stored in a HashMap using Medusa expressions?

For example, with $mymap being a HashMap:

[$foreach $keys]
<li>[$mymap[$each]]</li>
[$end for]

This won't work.

Simplified, even this won't work:

[$mymap['key']]

This also won't work, because the $mymap part of the expression will evaluate to a toString() on the HashMap, and the entire expression will be rendered as {...contents of the map...}['key']. This is apparently handled in Medusa's ExpressionEval.interpretValue() method.

Now for some naïve musing. It seems that supporting HashMap access (and others, e.g., lists, arrays, ...) would make sense in the Medusa expression language. I'm wondering whether the "proprietary" expression language used by Medusa will prove helpful though, as covering all the possible cases will add considerable complexity. Could Medusa rely on plain SpEL?

Best,

Michael

[kevindeyne]

Hi Michael,

Happy New Year! Thanks for checking out Medusa! I don't often get people interacting with my open source projects, so it's kind of exciting to get some feedback.

I've tried a little setup myself (with the new XSD implementation): https://github.com/medusa-ui/medusa/blob/feature/maps-arrays/medusa-sample-implementation/src/main/resources/pages/integration-tests/maps.html#L13-L16

And yup, it does not seem like there's a good way to work with Maps yet in the main branch, as you mentioned.

In fact, other things might break in the same way: Arrays as variables come to mind. It would make sense to be able to do something like my-array[0]. So far I think any deeper object resolving we've done with the '.' notation. Something like 'person.name'. Bracket notation hasn't come up yet, but your example is a good one. This seems like a very basic kind of functionality we should support.

I'll use the feature/maps-arrays branch to do some work on this. Thanks for pointing it out to us! I think I got the basics of it working, but I'll need to check how this works in things like foreaches and click events.

Side note: I did just merge in a big refactor I've been working on from this holiday week, so notation wise you'll see a big difference with the latest main branch. I've gotten rid of my own notations and switched to custom HTML tags. Hopefully, that's not too confusing! It's something @dirkdeyne and myself had been talking about for a while and I finally had time to implement it.

--

And yes, I agree that creating an expression language has been more complex than I initially figured. As much as possible, I do try to rely on existing systems like SpEL. We do this in several places for the rendering of initial HTML, in fact.

But there's always a second side to consider at all times for this project. Rendering the initial HTML is only the first step, after that we need to make sure the JS side can continue to interact with it as well.

In a simplified example, what we generally do is something like:

• Set up the page with variable "myMap"
• We render the initial HTML
• We add to the HTML page a javascript variable "myMap"
• Upon a change on the serverside, we trigger a notification over the websocket connection to the browser. For example, "myMap" has changed to a new value.
• The JS then needs to find the respective value in the DOM and update it.

I try to stay away from re-rendering HTML and instead just rely on the new value being passed in the notification. The WebSocket connection is already there, so all I would ideally need to do to keep communication minimal, is let the browser know the new value. On the JS side, we should be smart enough to figure out where that value is used and apply changes as necessary.

I know which values to find in the DOM due to an attribute I've set on there. Something like: Actual value. So I can find all those places and replace the new value. With more complex objects (including arrays and maps), I want this to also work - it should just be a matter of traversing the object properly on JS side.

So in short, I can only partially rely on SpEL or complex operations like Thymeleaf handles. As much of the logic as possible should really be pushed to the Java side. On the HTML side, I wouldn't want anything more complex in there than some object traversal, some condition expressions, or basic math, I think.

[mhaupt]

Hi Kevin,

happy new year to you too - and thanks for your elaborate reply.

The XML expressions look and feel a lot more natural, not to mention the well-formedness and validity checkability. Thank you for these changes.

I've taken the liberty and looked into HashMap lookups a bit (please see this PR). What worries me about this approach is that it will, if followed, lead to an implementation of the proverbial "inner Lisp" with all the glorious complexity this usually brings about. Arrays (and lists!) will add some more complexity.

What do you have in mind, ultimately? How "rich" an expression language do you envision?

(As a sidenote, it seems the iteration with <m:foreach> is currently broken, or is it not? I didn't have time to look into this part of the implementation, but my own local experiment just wouldn't iterate over the collection.)

Best,

Michael

[kevindeyne]

Thanks for the PR, I will try to find some time this week to have a further look at this functionality. There are quite a few things still to check out that new branch. I'm keeping a list of them here, just for reference: #102

--

I don't want it to become too involved beyond the basics of object traversal. From my perspective, HTML is only meant for structure.
Any logic or complexity really belongs on the Java side. By the time I get to the HTML, I just want to have some objects available and build a UI from that. If the WebSockets notice the objects change, I want to rebuild those parts of the UI.

So, for some concrete examples, I don't want inline functions anywhere - just references to which Java functions to call on 'actions' (button click, on input, ...). I don't want too complex conditions in iterations or conditions - I'd rather people write a little POJO that has data pre-formatted in an easier way for the UI to handle. I don't really want security tags in the HTML either. If someone's not allowed some data, then that should be filtered out at the Java level.

I think object traversal, however, is a common enough use case that I want to explore further.

My pie-in-the-sky goals with Medusa are:

1. If I want to set up a simple, straightforward web app with a UI in Java: Some buttons, maybe a table with some data, a few buttons that do something. Think business apps, not Google Maps. To do this right now with existing technologies, the simplest way I can think of is setting up a serverside renderer like Thymeleaf, exposing some REST services, writing my HTML to provide structure and then either writing some javascript to provide the interactivity or make every interaction an old-school request/response (like a form POST).

So I think that's too involved. I want to have a framework where I can write a page in HTML and say, 'this button corresponds with this action'. Effectively that's what <button m:click="increaseMyCounter(increase)">Increase my counter by <m:text item="increase" /></button> does!

So the goal here is not to provide a lot of functionality on the HTML side. Instead, the goal is just to provide less friction between HTML and Java interactivity. If I have to look at the HTML side for some piece of logic, that's probably too much already. That said, some use cases like conditionals and iterations are common enough that they are pretty much must-haves. For example: want to write a table? You'll need a List variable and then build your rows out of each element in the list.

A further (even pie'er-in-the-sky'er) idea I had around simplicity is badly documented here: medusa-ui/phanes#1. I would love it if I got to the point where setting up a Medusa UI (with Hydra support) is as simple as start.spring.io, where you select some basic components and it delivers you a zip with those built-in as examples. All you'd have to do is tailor it to your own needs, but no need to learn the entire language just to build common stuff; at least functionality-wise.

2. I want bi-directionality. This is what WebSockets can provide. Setting up something as simple as notifications for a user is kind of a nightmare in your average request/response codebase. The simplest way I can think of is a pulling mechanism that checks every so often to see if something has changed. That's a lot of requests and a lot of queries that are mostly not going to do anything. WebSockets are nothing new, but setting them up is a pain. Especially if you want to target specific users. I also believe that the increasing maturity of Spring Reactive's non-blocking way of handling requests eases a lot of/any potential scaling issues with this. (I also anticipate Java's upcoming Project Loom could be beneficial too, but I don't know enough about that yet).

We kind of have this already with https://medusa-ui.gitbook.io/docs/medusa/additional-functions#send-your-own-event-from-anywhere-in-the-backend-code. Likely more work to be done to make this more user friendly, though.

3. And this is kind of my ultimate goal and why the Hydra project is important to me: I have yet to see an elegant solution to micro-frontends in Java. UI, as I have seen it, is mostly a monolith. I have nothing against monoliths, but they come with their drawbacks. UI as microservices should at least be an option. I would like to have a UI that can deal with parts of the UI coming online/offline. A/B testing of new UI solutions. WebSockets, I think, provide a decent way here to stream changes in UI coming in.

For me, this is the ultimate purpose of Medusa - to provide just enough functionality in medusa tags to have it be workable for your average business app and have it feel like a modern app. Then provide hydra tags to allow interactivity between UI microservices. For example: A menu where the items are dynamically populated by whatever service is online. Or a link to another microservice, which is only available when that microservice is online.

Hope that kind of gives you an idea of where my head's at and what my goals are for the project(s).

--

Finally, you mentioned iterations don't work for you. I have integration tests in the sample-impl that should at least check that it does in fact iterate, and does so in nested form as well: https://github.com/medusa-ui/medusa/blob/main/medusa-sample-implementation/src/main/resources/pages/integration-tests/nested-each.html

So if you have a use case where it doesn't work, I'd love to see it - because that means I haven't covered something in those tests.

That said, I do know of one issue at least with the most recent implementation, which is a foreach with no child node but only direct text entries.

This has issues:

<m:foreach collection="myList" item="listItem">
   <m:text item="listItem" /> - <m:text item="listItem" />
</m:foreach>

This should work fine:

<m:foreach collection="myList" item="listItem">
   <p><m:text item="listItem" /> - <m:text item="listItem" /></p>
</m:foreach>

I have that on my 'todo' list if that's the issue.

[mhaupt]

Hi Kevin,

thanks again for all the information and details! I've updated the PR and added an integration test for the already existing maps.html. The test doesn't pass when run via mvn test, and it might be because of one of the issues you mentioned still exist. However, this also means that iteration does work thanks to your changes, to a degree. :-)

I appreciate the clarity on your rationale for how far to take the expression language - that makes sense.

Best,

Michael

[kevindeyne]

A first implementation of this has now been merged to the main branch. You can check out the things we've tested for here: https://github.com/medusa-ui/medusa/blob/main/medusa-sample-implementation/src/main/resources/pages/integration-tests/maps.html

No doubt we'll stumble over some bugs here and there, but at least now I have a basic answer to your original question on how to use hashmaps or arrays in the medusa tags. :)