Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

embed tile improvements #13

Open
simahawk opened this issue May 23, 2015 · 11 comments
Open

embed tile improvements #13

simahawk opened this issue May 23, 2015 · 11 comments

Comments

@simahawk
Copy link
Member

We should add main metadata fields (like title, description, whatever) to be extracted from noembed results.
We should also add options for showing/hiding these fields on demand.

The best thing to do would be to load the content of the tile on the fly instead of saving it, so that you can edit metadata on the fly.

@datakurre is there any documented way to reach this? We could have a "load" button beside the url field and by clicking all the other fields get loaded as well as the preview of the media.

@datakurre
Copy link
Member

@simahawk Customizing add and edit form for the tile so that if URL changes, it does not accept save, but shows the form one more time. Customizing "nextUrl" could be enough.

Yet, I think, usually you add your own title and description around the embed with text tiles, I think.

@simahawk
Copy link
Member Author

@datakurre but that function is called when the tile is rendered, too late :)
You get the form inserted as tile content :)

@gforcada
Copy link
Member

@datakurre @simahawk I would say that this could be a killer feature, just paste a link, be it youtube, vimeo, a tweet, etc and another form shows up with the content (a video player, etc) and the metadata, with checkboxes or so you can select what do you want to show and you have another tile to drag and drop around.

Another approach would be to create all the tiles together (i.e. click on add tile -> paste link -> 4/5/6 tiles are created which you can remove/update, etc).

@datakurre
Copy link
Member

@simahawk The modal should show the form as long as there is a form (and not X-Tile-Url header).

Yet, I like the latter option from @gforcada. What kind of metadata there is and how much? Could the tile just render all metadata as -tags and then Mosaic Editor could add editable text tiles from those meta tags?

@simahawk
Copy link
Member Author

@datakurre no way to get the form rendered after add in a modal. I cannot even traverse to it before "nextURL" gets called:

I get always the tile...

(Pdb) self.context.restrictedTraverse('/Plone/front-page/@@edit-tile/plone.app.standardtiles.embed/8060880b55f94db994578758b97ad52d')
<Products.Five.metaclass.EmbedTile object at 0xa5da950>

If I pick just the edit view it works:


(Pdb) self.context.restrictedTraverse('/Plone/front-page/@@edit-tile/')
<Products.Five.metaclass.EditTile object at 0xa5da850>

(Pdb) self.context.restrictedTraverse('@@edit-tile')()
*** KeyError: 'Please traverse to @@edit-tile/tilename/id'

And the path is correct because if I got to http://localhost:8080/Plone/front-page/@@edit-tile/plone.app.standardtiles.embed/9452b68f66a74cb092d608ce1c45e496 via browser it works.

Can we have a chat/call/hg to check this together?

@datakurre
Copy link
Member

@simahawk Could it be that add form POST data affects that traverse to edit form? Shouldn't it also be enought that it works from browser? (So that returning redirect to edit form would show the edit form – similarly how portlets work.)

Still, would it be possible to just render all metadata as tags into tile ? Then we could later fix the editor to create editable & removable text tile from them.

@simahawk
Copy link
Member Author

it doesn't work: if you return the url of the edit form you get the form added instead of the content of the tile :)

@datakurre
Copy link
Member

@simahawk It's not your fault then :) That's how it should work. Could you branch that work and then we'll fix editor to stay on that form?

@datakurre
Copy link
Member

@simahawk Checked the modal code. It only stays on the form if there are errors. So, setting a portal message error would "fix" it :-P

We could configure the modal to check any other selector also, but which?

@simahawk
Copy link
Member Author

hmm what about making the add form return json data so that we could be more flexible on client side?

@datakurre
Copy link
Member

@simahawk I'd consider that only after Plone has the new JSON api with practices to follow. And even then, it should be restricted to request explicitly requesting JSON output. Just changing the format does not necessarily fix so much issues (like when Blocks was refactored to use data-attributes instead of link-tags, it didn't solve much, but mainly delayed the project).

And JSON would not solve this issue, which is about modal configuration. You should be able fix the modal behavior temporarily by settings error-level portal message before redirect (that should keep the modal open). Then branch the work in stdtiles and I could fix the modal configuration (probably add there extra selector like form[action~="@@edit-tile"]).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants