RFC: WebComponents integration/conversion?

[belisoful]

in researching the HTML5 tags (like dialog, which should get a proper Prado support and tag), I came across WebComponents. It is relatively new and its custom HTML tags are similar to Prado tags. It almost seems like PRADO was doing WebComponents before WebComponents.

That said, this new technology (WebComponents) is nearly universally supported now. It is browser based technology, so no custom frameworks and [should] work with all the modern JS frameworks like React, etc.

What are peoples' thoughts on integrating or converting PRADO to WebComponents?

[ctrlaltca]

It almost seems like PRADO was doing WebComponents before WebComponents.

Imho every single framework made an attempt at this, with the result of having dozens of different, incompatible implementations. It's good to have a standard that is supported by every browser now.

What are peoples' thoughts on integrating or converting PRADO to WebComponents?

I don't think webcomponents can completely replace prado's webcontrols with serverside properties, validation, etc..
Still, they can surely implement the clientside js part of each component.

In prado terms, some new javascript will implement a new html tag for each component (eg: <prado-completer />) and the server-side php will render the controls using this new tag instead of plain old <div />s.

I can see 2 possible approaches:

1. add a new set of controls in their own namespace (after WebControls, ActiveControls, JuiControls, ... WebComponentsControls?)
2. reimplement existing prado controls using webcomponents: by rewriting prado's controls.js to make use of webcomponents and each control's php class to make use of the new tags.

The first approach is probably easier to play and test. The second approach would be nicer in the long term.
It would be also nice to drop all the duplicate controls (the normal and the active counterpart, eg. TButton, TActiveButton), making all the controls "ajax-enabled" by default and letting the user control if they should use postbacks or callbacks.
Why this has not been already made in the past? Because it's a bit of a hell to maintain backwards compatibility with old code. Still, i would love to see it in the future

[belisoful]

The is attribute, eg. <div is='prado-completer' would also work, it would maintain more backward compatibility in someone's existing code, that is to say: adding the "is" attribute rather than changing the whole tag. maybe change to the whole tag in a major revision.

[belisoful]

It would be relatively easy to start baking in some WebComponent support into PRADO. I think that may be a good idea. I'm not sure what exactly that code needs to do. Basic support would add the Prado client side WebComponents into page HTML custom controls. Given the dynamic nature of html, we should include all PRADO WebComponents rather than just the ones on the page.

eg. #777 TTimeDelta may be better with a WebComponent than just a Prado WebControl.

But that makes me think: maybe the Prado TTemplate parser should include looking not just for <com: but also Prado custom HTML tags. This would make the WebComponent more seamlessly integrated on the server side.

I'm considering that if the TTimeDelta didn't use a <span/> but was its own custom WebComponent tag <time-ago>. The template parser may need to instance a server side control as well.

This identifies three aspects to be more inclusive of WebComponents:
1- Javascript for attaching new/converted PRADO WebComponents to a page custom Element list.
2- Dynamically creating a PRADO Web Component in HTML via JS and DOM should instance its php class equivalent in the page and page view state. General (automated?) synchronization from JS to serve side page?
3- Prado Template parsing reads "(Prado) registered" custom html tags and maps to the proper Prado class.

I am JS environment agnostic. In integrating WebComponents, I think looking at existing frameworks is a good idea. I suggest that during the evaluation process, we look at Lit as maybe an example to draw good ideas from for WebComponents. see this:

https://lit.dev

They have a WebComponent already doing the "time-ago" as an example https://lit.dev/tutorials/async-directive

[ctrlaltca]

2- Dynamically creating a PRADO Web Component in HTML via JS and DOM should instance its php class equivalent in the page and page view state. General (automated?) synchronization from JS to serve side page?

I see a big security issue here. Creating a control in js, inject some serialized state and then let php unserialize() it leads to remote code execution (https://owasp.org/www-community/vulnerabilities/PHP_Object_Injection).

The page viestate is being validated using HMAC exactly to avoid js messing with php object state

[belisoful]

I wasn't thinking of doing a full serialization/unserialization. The class name, properties, and only string values may be enough? strings only?

You have a very good point though.

[ctrlaltca]

As long as values coming from clientside are sanitized, it's safe. After all, the same applies to all the values coming from POST/ajax calls.

[belisoful]

here is the use case I was thinking: a new <time-ago> element is instanced and it retrieves the globalization settings and text from a new TTimeAgo Web Control. This is just some imagineering as it may have security consequences as you pointed out.