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

Proposal: behavior aliases #330

Closed
vangheem opened this issue Aug 29, 2018 · 12 comments
Closed

Proposal: behavior aliases #330

vangheem opened this issue Aug 29, 2018 · 12 comments
Assignees
Labels
GIP Guillotina Improvement Proposal

Comments

@vangheem
Copy link
Member

Instead of needing to reference complete behavior interfaces names, be able to register a behavior with an alias.

For example, a PATCH like this:

"guillotina.behaviors.dublincore.IDublinCore": {
                    "title": "foo",
                    "description": "bar",
                    "tags": ["one", "two"]
                }

Could be changed to:

"dublincore": {
                    "title": "foo",
                    "description": "bar",
                    "tags": ["one", "two"]
                }

Registering behavior would change to add "alias" option for the configurator.

@bloodbare
Copy link
Member

What aproach would be then for the serialization ? The goal is to reduce the payload ?

@bloodbare bloodbare added the GIP Guillotina Improvement Proposal label Aug 31, 2018
@ebrehault
Copy link
Member

It would make the object nicer on the frontend (always painful to write res['guillotina.behaviors.dublincore.IDublinCore'])

@bloodbare
Copy link
Member

Agree that is painful to write the interfaces to access the subschemas, the question is how we normalize on serialization the different interfaces, I mean, if we define guillotina.behaviors.dublincore.IDublinCore to dublincore and there is a field on top called dublincore, how we will be deterministic about where the content belongs.

What about a definition of how a field that is a subschema is serialized and deserialized. Something like no option to have fields with 'b.' at the begining so we can use: b.dublincore ?

@vangheem
Copy link
Member Author

vangheem commented Sep 3, 2018

@bloodbare conflicts would be rare I think but yes, produce a situation with unclear behavior.

I'm not sure about "b.dublincore" though.. hmmm. Also could do @behavior.dublincore...

I'd prefer just simple alias though.

@vangheem
Copy link
Member Author

vangheem commented Sep 3, 2018

Another question: do we serialize with alias or with full dotted name?

@vangheem
Copy link
Member Author

vangheem commented Sep 3, 2018

and is "alias" the right term. Should it just be "name"?

@vangheem
Copy link
Member Author

vangheem commented Mar 9, 2019

I think I still want to do this. Any more thoughts on this? What about configuration validation so you can't have an alias that is a field or something like that?

@iham
Copy link
Member

iham commented Mar 23, 2019

doesn't plone have something thats called a "named behavior" to make life easier with theses dotted names?

maybe i am missing the point, but a "guillotina.dublincore" or "g.dublincore" similar would be nice. way nicer then the whole dotted name.

@vangheem
Copy link
Member Author

@iham I'm not aware of anything like this in plone. I'd prefer an alias over some sort of g.dublincore shortened version though.

@jensens
Copy link
Sponsor Member

jensens commented Mar 25, 2019

For Plone we introduced behavior shortnames a while ago and use them. plone.dublincore is a bad example (because composite behaviors are a bad idea, but thats different topic).

Look at https://docs.plone.org/external/plone.app.dexterity/docs/reference/standard-behaviours.html for a list of the names.

Using a namespace prefix like plone. is a good idea, but using the dotted name not. Refactoring, moving interfaces around and so on becomes painful then. Also its very difficult to remember those long names.

@vangheem
Copy link
Member Author

awesome! thanks @jensens !

@vangheem vangheem added this to the Toulouse Sprint milestone May 24, 2019
@vangheem
Copy link
Member Author

closing, not doing for now.

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

No branches or pull requests

5 participants