I’m developing a macro extension that gives the ability to embed some external content. Using YouTube as an example, the idea is to be able to easily embed a Youtube video.
I have the feeling that your macro is planned to do exactly the same, just that the video name suggest it display videos while your macro would display any type of content and not just videos. So once your macros exist, there would be no reason anymore to use the video macro and thus your macro is trying to oversede the video macro. Is that correct?
I find the proposed naming to be obscure and not easy to understand:
I have no idea what a widget is and everyone has a different definition of what is a widget
The connector terminology is technical
If I were doing it, I’d call the macro something like {{embed/}}. WDYT?
Are you sure that there’s never a need to provide parameters for all these connectors? For example, what is there are api keys to provide to use the service?
I didn’t know this extension but it’s interesting.
I have the feeling that your macro is planned to do exactly the same, just that the video name suggest it display videos while your macro would display any type of content and not just videos.
I’ll see if I can reuse this extension (instead of implementing it) for the video which is already supported. And maybe I’ll only implement the missing features from my list.
About the naming, I completely agree to name it the macro {{embed/}}. In this case we will also need find a name for the extension.
Are you sure that there’s never a need to provide parameters for all these connectors? For example, what is there are API keys to provide to use the service?
It’s a good question. In case of a need of a API key for some services maybe the best solution would be add it a new page on the administration to manage this.
features
Any limit to what can be embedded?
Well, for now I’ll implement the previously listed services, but I don’t mind to extend it to more services.
It’s not very easy to reuse a macro (it’s not meant to be extended). I think I’d prefer a more generic embed macro/project that would supersede the video macro (unless you see something in the video macro that cannot be implemented in the embed macro). And then we would deprecate the video macro. Ofc you could/should reuse the video macro code to implement the already supported services.
I’d use embed or embed-content or embed-service, and the project would offer both a java api (component-based) and a java macro (and also a XAR if there’s a need for an Admin UI).
Sure, but then you also need to associate it with an id and pass that id in the embed macro usage, so that’s a parameter anyway (unless you’re proposing to only support 1 account but that sounds restrictive).
Now maybe there’s no need to have any parameter and the api key can always be passed as part of the remote service URL?
I meant services for which the URL isn’t enough to describe it all and for which you’d need parameters for example.
I’ll investigate about the idea to reuse the current implementation of the video macro and depreciate it.
I’m ok for the name embed-content-macro for the extension name. And {{embed-content}} or just {{embed}} for the macro name.
For now I don’t really have a good overview of the requirement for all services. Since I’ve analysed all services, it might be easier to take a decision about the need on this side.
Did a first draft implementation. Finally I didn’t need any extra parameter to make it working. I was able to make all external services working without any API key.
But indeed, for some services having the possibility to pass some extra settings could be useful. In case of we want to give more flexibility to the user of how we integrate the external service and sometime pass extra parameter to the external service.
So, as it will really depends of the service and it can’t be generalised I suggest to use the same way we do to pass the parameter in the livedata. So we can optionally add a json in the content of the macro with more settings (related to the specific integration).
What do you think ?
And @commiters what do you think about the name embed or embed-content ?
And can you clarify what do you think about the API feature into this project ?
What I meant is that this could be a generic project for any embedding and it could offer a Java API to return the embedding data (right now, it would be some URL + some javascript to perform the embedding) for various services. Thus, another project/repo could use it (for example the video macro repo could use it - this would be useful only if we don’t deprecated the video macro ofc, but that’s the idea).
I don’t know if this is useful right now (probably not!), so we should probably do without it and refactor in the future if this is needed.
For now I developed the extension the same way than for the video macro. So I did it just in velocity. But I agree this can be improved in the future. Maybe also when we have a specific use case it might be easier to define the API.
Note that for the video macro I integrated in the project and updated the dependency so we should be able to depreciate the video macro when the new extension will be released.