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

Consider migration to dl-repository-shared layer #15

Open
izaera opened this issue Feb 2, 2015 · 6 comments
Open

Consider migration to dl-repository-shared layer #15

izaera opened this issue Feb 2, 2015 · 6 comments

Comments

@izaera
Copy link

izaera commented Feb 2, 2015

Hi @topolik:

I didn't know you had created this connector. Looks good and it's a great idea.

I was wondering if you could be interested in looking at dl-repository-shared layer, which is a JAR file I wrote to make implementation of connectors much easier and maintainablec.

It's in here: https://github.com/liferay/liferay-plugins/tree/master/shared/dl-repository-shared
You can see how it is used in Documentum and Sharepoint connectors in liferay-plugins-ee.

If some day you consider to migrate to this new layer don't hesitate to ask me for any advice.

Cheers,
Ivan

@topolik
Copy link
Owner

topolik commented Feb 2, 2015

HI @izaera

Looks promising, thanks!

@izaera
Copy link
Author

izaera commented Feb 2, 2015

If you finally decide to apply it, ask me and I will give you a brief introduction on how it is supposed to work. Basically what I did is separating the portal stuff from the external repository stuff, so that you only have to deal with the external repository and not with Liferay portal.

For example, when using dl-repository-shared you don't need to work with Liferay ids, only with the ones from your external repo. You don't even need to manipulate the RepositoryEntry table because it is not referenced anywhere in the interfaces you need to implement. You just provide an implementation for the file, folder and version object, and another one with the operations the repository support and that's all.

@topolik
Copy link
Owner

topolik commented Feb 2, 2015

+100

This looks very very good. I had to implement that myself, all the mapping.

Btw. does it support DL permissions? Once the IDs are on the framework side the implementation cannot work with resource permissions.

@izaera
Copy link
Author

izaera commented Feb 2, 2015

I'm not sure of what you mean. There's a place where you have to map
"Liferay permissions" to "your repo permissions". See this file:

https://github.com/liferay/liferay-plugins/blob/master/shared/dl-repository-shared/src/com/liferay/repository/external/ExtRepositoryObject.java

method containsPermission() receives an ExtRepositoryPermission, which
is an enum defined at the end of that class. Those are based on
Liferay's ones, but it's only a subset of what is needed. For example I
removed CREATE_SHORTCUT because there's no support for shortcuts in
external repos.

On 2/2/15 11:42, Tomáš Polešovský wrote:

+100

This looks very very good. I had to implement that myself, all the
mapping.

Btw. does it support DL permissions? Once the IDs are on the framework
side the implementation cannot work with resource permissions.


Reply to this email directly or view it on GitHub
#15 (comment).

@topolik
Copy link
Owner

topolik commented Feb 2, 2015

I mean - portal admin creates custom role that is able to create DL
folders. Does it check that permission and make sure it cannot reach my
code when user doesn't have the permission?

-- tom +

On Mon, Feb 2, 2015 at 11:47 AM, Ivan Zaera notifications@github.com
wrote:

I'm not sure of what you mean. There's a place where you have to map
"Liferay permissions" to "your repo permissions". See this file:

https://github.com/liferay/liferay-plugins/blob/master/shared/dl-repository-shared/src/com/liferay/repository/external/ExtRepositoryObject.java

method containsPermission() receives an ExtRepositoryPermission, which
is an enum defined at the end of that class. Those are based on
Liferay's ones, but it's only a subset of what is needed. For example I
removed CREATE_SHORTCUT because there's no support for shortcuts in
external repos.

On 2/2/15 11:42, Tomáš Polešovský wrote:

+100

This looks very very good. I had to implement that myself, all the
mapping.

Btw. does it support DL permissions? Once the IDs are on the framework
side the implementation cannot work with resource permissions.


Reply to this email directly or view it on GitHub
#15 (comment).


Reply to this email directly or view it on GitHub
#15 (comment).

@izaera
Copy link
Author

izaera commented Feb 2, 2015

No idea :-(. I would have to check it in the code. I suppose the answer
is yes, but I cannot give you the answer off the top of my head.

On 2/2/15 11:52, Tomáš Polešovský wrote:

I mean - portal admin creates custom role that is able to create DL
folders. Does it check that permission and make sure it cannot reach my
code when user doesn't have the permission?

-- tom +

On Mon, Feb 2, 2015 at 11:47 AM, Ivan Zaera notifications@github.com
wrote:

I'm not sure of what you mean. There's a place where you have to map
"Liferay permissions" to "your repo permissions". See this file:

https://github.com/liferay/liferay-plugins/blob/master/shared/dl-repository-shared/src/com/liferay/repository/external/ExtRepositoryObject.java

method containsPermission() receives an ExtRepositoryPermission, which
is an enum defined at the end of that class. Those are based on
Liferay's ones, but it's only a subset of what is needed. For example I
removed CREATE_SHORTCUT because there's no support for shortcuts in
external repos.

On 2/2/15 11:42, Tomáš Polešovský wrote:

+100

This looks very very good. I had to implement that myself, all the
mapping.

Btw. does it support DL permissions? Once the IDs are on the
framework
side the implementation cannot work with resource permissions.


Reply to this email directly or view it on GitHub
#15 (comment).


Reply to this email directly or view it on GitHub
#15 (comment).


Reply to this email directly or view it on GitHub
#15 (comment).

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

2 participants