Proposal to merge public and private pages in one single set

Message Boards

Jorge Ferrer, modified 16 Years ago.

Proposal to merge public and private pages in one single set

Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts

Hey all,

This is something that I've been thinking for a long time and have talked about it with several core developers before. But after a conversation with Ray that we just had I'm now more convinced than ever to do it. Here are the benefits and drawbacks of doing it:

Benefits

Simpler to understand. We know that people often have problems undertanding the principle of public vs private pages
Don't confuse the user thinking that it's actually two separate websites. It's actually not, they share the content (because there is only one groupId).
Remove one level from the My Places menu (wouldn't you love that?)
Remove the need to want to move pages from one layout set to the other. You would just change the permissions.
Many permission checks would be simplified. See LEP-4790 for an example of the problems that our current system gets us into.
I'm sure there are other benefits based on the simplification and we'll find them as soon as this is applied

Drawbacks

Migration: migration might be an issue, but at the end is just about setting the right permissions
Making a page private would be slightly harder because of the complexity of our permissions UI. This could be solved by offering a quick way to set private/public permissions just by clicking a button or something like that. We have to keep thinking about how to make the permissions UI simpler anyway, so this is a great excuse to do it.

Thoughs?

Michael Young, modified 16 Years ago.

RE: Proposal to merge public and private pages in one single set

Liferay Master Posts: 846 Join Date: 8/5/04 Recent Posts

I think that this is a great idea. I've thought about this several times before and I think the biggest benefit is that I think it will reduce complexity and really just simplify the whole interface.

There is really no need to have public vs private when we have a permission system as flexible as it is.

Ray Augé, modified 16 Years ago.

RE: Proposal to merge public and private pages in one single set

Liferay Legend Posts: 1197 Join Date: 2/8/05 Recent Posts

I think it might be clearer to have everyone answer this question:

What values does a Community gain by having two distinct sets of pages?

While thinking about that question, consider these points:

1 - Permissions can already be used to prevent an non-authenticated user from seeing a "public" page (just remove the VIEW permission).
2 - Virtual host definition is more complex to understand and work with, because as with no other software I've ever seen... you need TWO domain names... this means double the proxy issues... renaming rules... etc.. more places to screw up.
3 - As Jorge mentioned the menu is over complex...
4 - We have tones of logic in place to actually handle this.

So what is the gain? Is it worth the complexity?

atul patel, modified 16 Years ago.

Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge public a

Regular Member Posts: 192 Join Date: 11/18/06 Recent Posts

This is interesting. For ease of use for customers, I've been
creating an Admin Page/sub pages as part of the public site and
removing the guest view permissions on those pages.

The only potential benefit I see of keeping it the current way is if
one wanted to provide a completely different admin site and not have
to worry about friendly url conflicts. We should really get some
information from the user base about how they are using public vs
private.

--Atul

On Feb 19, 2008, at 10:26 AM, Ray Augé at Liferay's Community Forums
wrote:

> I think it might be clearer to have everyone answer this question:
>
> What values does a Community gain by having two distinct sets of
> pages?
>
> While thinking about that question, consider these points:
>
> 1 - Permissions can already be used to prevent an non-authenticated
> user from seeing a "public" page (just remove the VIEW permission).
> 2 - Virtual host definition is more complex to understand and work
> with, because as with no other software I've ever seen... you need
> TWO domain names... this means double the proxy issues... renaming
> rules... etc.. more places to screw up.
> 3 - As Jorge mentioned the menu is over complex...
> 4 - We have tones of logic in place to actually handle this.
>
> So what is the gain? Is it worth the complexity?
> --
> Liferay Community Forum
> mb.308691.495540@events.liferay.com
> http://www.liferay.com/web/guest/community/forums/message_boards/
> message/495540

Michael Young, modified 16 Years ago.

RE: Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Liferay Master Posts: 846 Join Date: 8/5/04 Recent Posts

atul patel:

This is interesting. For ease of use for customers, I've been
creating an Admin Page/sub pages as part of the public site and
removing the guest view permissions on those pages.

This brings up another topic that can be part of another thread. We're planning to implement a Control Panel with this very same thing in mind -- the idea is to set aside a few preconfigured admin pages for each community that has the most common components on it.

Joel Kozikowski, modified 16 Years ago.

RE: Proposal to merge public and private pages in one single set

Expert Posts: 405 Join Date: 6/28/06 Recent Posts

Ray Augé:

I think it might be clearer to have everyone answer this question:

What values does a Community gain by having two distinct sets of pages?

While thinking about that question, consider these points:

1 - Permissions can already be used to prevent an non-authenticated user from seeing a "public" page (just remove the VIEW permission).

Well, I can tell you the model I'm using, which for the moment, the current "separate sites" model fits well:

I'm using Liferay in an ASP type environment. Each of MY customers gets a location: it has a "public" site that is used to advertise services (your typical brochure type web site), but I use the "private" side to run an "intranet" - multiple pages, each with a custom portlet that is an "application" to perform some business related task.

In my application, the two "sides" serve different purposes, and the separation is actually welcome. I can tell MY customers that "The public side is for YOUR customers, and the private side is for you and your employees."

That being said, I added some code a while ago to do things like "syncrhronize the themes" so when you change the theme of one "side", the theme for the "other" side is automatically changed. I did that to avoid confusion.

Now, its true that with permissions, I could "hide" the "intranet" pages from users until they log in. But, I have plans for expanding the model: allowing my customers' customers to log in, and do customer interactions with the business. In this instance, the "public" side would be reserved for customers. Authenticated customers would have more "stuff" they could do. The "private" side would still be reserved for the employees of MY customers.

With the above model but the functionality removed for public/private sites, I see large numbers of menu options, lots of cascading menus, etc. We all know that to simplify an application, fewer menu options are better, menus should not be nested too deep, etc. I also see some confusion on my customers' parts: setting up permissions properly to allow the "right" authenticated user to use a portlet, for example.

I also have some reservations about refactoring OUT existing code. Major changes like that always affect the stability of the product, and make migrations more difficult. I have no idea if I'm the ONLY one using Liferay with the above model, or if there are LOTS of people doing it.

One question I have: Ray, you mentioned there is TONS of code to support the two sides. As new functionality is developed, does that code need to be modified? Does the NEW functionality have to support it also? Or, is it just a lot of code there, but now sets are part of the kernel? If its the former, I understand the desire to ditch the functionality. If its the latter, whats the harm (other than confusion to end users). If that is the case, I'd vote for some portal.properties configuration options that hide the "extended" functionality of the private site.

Brian Chan, modified 16 Years ago.

Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge public a

Liferay Master Posts: 753 Join Date: 8/5/04 Recent Posts

The model Joel is mentioning is the one it was originally designed for,
basically: extranet vs. intranet. Although that division is getting
hazy, I'm a bit scared of moving away from it. So I think we just need
to list out the benefits and the costs (migration, etc). And then think
through, are there are other ways to get the same benefits without the
costs, etc.. (ie control panel?)

atul patel, modified 16 Years ago.

Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge public a

Regular Member Posts: 192 Join Date: 11/18/06 Recent Posts

I did forget that aspect... The "admin pages" I was referring to
were for administering the public website... The private set being
used as an intranet is perfectly sound.

The way I see it is that a community should be able to define one or
more sites. In the current model, 2 sites are pre-defined, public /
private, but I only see them as different in the sense of default
permissions. So should it need to be that way?

I do see it as being very useful to share "private" site information
with the public and the current design is very supportive of that. I
think it would be nice if users could label their sites instead of
being forced to call them public / private.

Does any see how a 3rd "site" / additional sites would be used for a
community? I see the ability to publish additional sites for a
given community very useful in allowing people to create multiple
marketing sites...

On Feb 19, 2008, at 2:32 PM, Brian Chan at Liferay's Community Forums
wrote:

> The model Joel is mentioning is the one it was originally designed
> for,
> basically: extranet vs. intranet. Although that division is getting
> hazy, I'm a bit scared of moving away from it. So I think we just need
> to list out the benefits and the costs (migration, etc). And then
> think
> through, are there are other ways to get the same benefits without the
> costs, etc.. (ie control panel?)
> --
> Liferay Community Forum
> mb.308691.496835@events.liferay.com
> http://www.liferay.com/web/guest/community/forums/message_boards/
> message/496835

Ray Augé, modified 16 Years ago.

Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge public a

Liferay Legend Posts: 1197 Join Date: 2/8/05 Recent Posts

> Well, I can tell you the model I'm using, which for the moment, the current "separate sites" model fits well:

I'm glad someone at least is using it... I think that most "make it fit" rather that using it because it's the best way to do things.

> I'm using Liferay in an ASP type environment. Each of MY customers gets a location: it has a "public" site that is used to advertise services (your typical brochure type web site), but I use the "private" side to run an "intranet" - multiple pages, each with a custom portlet that is an "application" to perform some business related task.

I think that Communities could have suited this scenario... and if they
didn't suite it... then it was a flaw in their design and we should fix
THAT rather that make Public/Private behave as Communities should...

In fact, for a given Location (now sub-Organization) you really should
have the ability the have as many of these "individually restricted
areas" as you want... rather than hammering the Private/Public model
into place.

> With the above model but the functionality removed for public/private sites, I see large numbers of menu options, lots of cascading menus, etc. We all know that to simplify an application, fewer menu options are better, menus should not be nested too deep, etc. I also see some confusion on my customers' parts: setting up permissions properly to allow the "right" authenticated user to use a portlet, for example.

I think that properly handled Communities could easily resolve the menu
issues... if you are a logged in Customer.. you have this Community...
with these pages... If you are a Employee you have this community with
these pages... but now you could have X of these different areas... all
respective the a given Organization (Client).

> I also have some reservations about refactoring OUT existing code. Major changes like that always affect the stability of the product, and make migrations more difficult. I have no idea if I'm the ONLY one using Liferay with the above model, or if there are LOTS of people doing it.

This is true, and I see your point... but is it a reason not to make a
product better... this is the same reason some very well know applications
have 10 year old flaws in their design.

> One question I have: Ray, you mentioned there is TONS of code to support the two sides. As new functionality is developed, does that code need to be modified? Does the NEW functionality have to support it also? Or, is it just a lot of code there, but now sets are part of the kernel? If its the former, I understand the desire to ditch the functionality. If its the latter, whats the harm (other than confusion to end users). If that is the case, I'd vote for some portal.properties configuration options that hide the "extended" functionality of the private site.

Tones... may have been a stretch, and was an appeal to
sympathy... the code isn't so much tones.. but it certainly feels like
tones... when you consider the data model involved for a given
Community, and the lengths to which we go to manage it.

Though you are correct that it is pretty much stable and untouched right now... we've had it for a very long time at this point.

Joel Kozikowski, modified 16 Years ago.

RE: Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Expert Posts: 405 Join Date: 6/28/06 Recent Posts

Ray Augé:

I'm using Liferay in an ASP type environment. Each of MY customers gets a location: it has a "public" site that is used to advertise services (your typical brochure type web site), but I use the "private" side to run an "intranet" - multiple pages, each with a custom portlet that is an "application" to perform some business related task.

I think that Communities could have suited this scenario... and if they
didn't suite it... then it was a flaw in their design and we should fix
THAT rather that make Public/Private behave as Communities should...

In fact, for a given Location (now sub-Organization) you really should
have the ability the have as many of these "individually restricted
areas" as you want... rather than hammering the Private/Public model
into place.

Funny you should say that. When I first started working w/ Liferay (back in 2006, I think 4.0 had just been released), I could see that the entity model supported a public and private layout set associated with each organizational entity: organization, location, and user. At the time, however, the CODE did not. So, I had to "roll my own"...

Up until about 1 month ago when I started my migration to 4.4, I had code in place that would basically create a community for every location. Basically, you'd create a location, defined a "web site" url for it, and the system would generate a community with the same name as that location.

What I ended up with was basically two indentical lists of "things" (and that was not a good thing). If I needed to modify "Customer X", SOME times I needed to go to the enterprise admin, and SOME times I'd need to go to the Community Admin.

When I moved to 4.4, I was delighted to see that Locations could actually have their own layout sets, as I had originally hoped for. I JUST refactored my code to DROP the creation of the community in favor of the "internet/extranet" being the pages associated with the Location. That makes it MUCH easier for me to administer.

Now, that being said, my dislike for the separate communities and locations was one of user interface and not data model. If the UI could be changed, and one could have zero OR MORE communities assoicated with a location, and EACH of those could be considered public and/or private individually, that'd be great! So, the idea that instead of any given group having EXACTLY TWO layout sets, each group would have ZERO OR MORE, then that would be wonderful. For my model, I coudl then actually give EACH of the stakeholders of MY customers: prospects, customers, and employees, their own site to work with. Things like articles and message boards would still be "owned by the group."

That'd be cool emoticon

Joel Kozikowski, modified 16 Years ago.

RE: Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Expert Posts: 405 Join Date: 6/28/06 Recent Posts

Joel Kozikowski:

Now, that being said, my dislike for the separate communities and locations was one of user interface and not data model. If the UI could be changed, and one could have zero OR MORE communities assoicated with a location, and EACH of those could be considered public and/or private individually, that'd be great! So, the idea that instead of any given group having EXACTLY TWO layout sets, each group would have ZERO OR MORE, then that would be wonderful. For my model, I coudl then actually give EACH of the stakeholders of MY customers: prospects, customers, and employees, their own site to work with. Things like articles and message boards would still be "owned by the group."

For clarification of the above (I've incorrectly mixed some terminology):

We have a "layout set" that is in effect a single "web site". If any GROUP could have zero or more layout sets (a.k.a. web sites) associated with it, that would be cool.

A "group" is in turn an ancestor class of the other entities: organizations, locations, users, communities. So, each of those COULD potentially have zero or more layout sets.

For the model I originally described, if the above were possible, I'd have virtually ZERO communities - they'd all be "sites" associated with locations.

Now, I said "virtually" zero. I'd have ONE community that is for all of my customers. That way, I could have a forum, for example, for interacting with the entire user base (and users could help each other). Actually, now that I think about it, it may make more sense to have that "community group" assoicated with the top level organization that is the parent of all the locations (a.k.a my company).

So, I guess the REAL question is, "what good is a community"? emoticon

atul patel, modified 16 Years ago.

Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Regular Member Posts: 192 Join Date: 11/18/06 Recent Posts

I totally agree with Joel. It seems the public / private model was
created out of convenience and works well but by moving to a group
with zero or more sites would give a great deal of flexibility.

The question fore is how much of an impact would this change be?

Atul Patel
+1-310-880-3574

On Feb 19, 2008, at 3:32 PM, Joel Kozikowski at Liferay's Community
Forums <no-reply@liferay.com> wrote:

> [quote=Joel KozikowskiNow, that being said, my dislike for the
> separate communities and locations was one of user interface and not
> data model. If the UI could be changed, and one could have zero OR
> MORE communities assoicated with a location, and EACH of those could
> be considered public and/or private individually, that'd be great!
> So, the idea that instead of any given group having EXACTLY TWO
> layout sets, each group would have ZERO OR MORE, then that would be
> wonderful. For my model, I coudl then actually give EACH of the
> stakeholders of MY customers: prospects, customers, and employees,
> their own site to work with. Things like articles and message
> boards would still be "owned by the group."
>
> For clarification of the above (I've incorrectly mixed some
> terminology):
>
> We have a "layout set" that is in effect a single "web site". If
> any GROUP could have zero or more layout sets (a.k.a. web sites)
> associated with it, that would be cool.
>
> A "group" is in turn an ancestor class of the other entities:
> organizations, locations, users, communities. So, each of those
> COULD potentially have zero or more layout sets.
>
> For the model I originally described, if the above were possible,
> I'd have virtually ZERO communities - they'd all be "sites"
> associated with locations.
>
> Now, I said "virtually" zero. I'd have ONE community that is for all
> of my customers. That way, I could have a forum, for example, for
> interacting with the entire user base (and users could help each
> other). Actually, now that I think about it, it may make more sense
> to have that "community group" assoicated with the top level
> organization that is the parent of all the locations (a.k.a my
> company).
>
> So, I guess the REAL question is, "what good is a community"? emoticon

> --
> Liferay Community Forum
> mb.308691.496997@events.liferay.com
> http://www.liferay.com/web/guest/community/forums/message_boards/message/496997

Joel Kozikowski, modified 16 Years ago.

RE: Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Expert Posts: 405 Join Date: 6/28/06 Recent Posts

Ray Augé:

I also have some reservations about refactoring OUT existing code. Major changes like that always affect the stability of the product, and make migrations more difficult. I have no idea if I'm the ONLY one using Liferay with the above model, or if there are LOTS of people doing it.

This is true, and I see your point... but is it a reason not to make a
product better... this is the same reason some very well know applications
have 10 year old flaws in their design.

There is an old joke in the software development world that "the only reason God was able to create the universe in 7 days is because He didn't have an installed base."

End users of products factor hugely into development decisions. It is a well known fact in business that it costs signifcantly more (in both time, money, and resources) to get a new customer than it does to profit from an existing customer. So, to keep the installed base from getting frustrated and simply abandoning you altogether, you HAVE to think about minimizing the pain for someone to migrate from old versions to new ones. Otherwise, people may decide to just not migrate at all (or, signifcantly delay). That means old versions hang around longer. Or, "customers" just plain switch to something else. "Respecting the installed base" is the frequently the reason "well known applications have 10 year old flaws." At least, this is certainly true in the commercial software world.

I'm sure these same issues affect the Open Source world: a signifcant change from one version to another that prevents a migration could mean the loss of a community member (who decides to "go it alone"), a fork of the project, or something else.

In the ideal world, changes can be made that would minimize the pain for both the development team and the end users.

For this issue specifically, the idea of having zero or more layoutSets associated with any one group gives an easy migration path. You are in effect defining "sub-groups." Each "Group" can have zero or more "Sub-groups" associated with them, and each sub-group has EXACTLY ONE web site (i.e. the "layoutSet"). The update/conversion program can simply create a sub-group for each layoutSet record that has a pageCount greater than zero. Its backward compatible. You've made the product better, but have not abandoned end users who may have made a significant investment in the "old model"

My recommnedation is to make these changes at the "Group" level, since that functionaltiy would be inherited by organizations, locations, Communities, and users.

Brian Chan, modified 16 Years ago.

RE: Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Liferay Master Posts: 753 Join Date: 8/5/04 Recent Posts

Going from:

Group -< 2 Layout Sets

to:

Group -< Infinite Layout Sets

is actually an easy upgrade path...

Going to:

Group - 0 Layout Sets would be much more difficult.

Yes, we definitely need to respect the install base emoticon

Joel Kozikowski, modified 16 Years ago.

RE: Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Expert Posts: 405 Join Date: 6/28/06 Recent Posts

Brian Chan:

Going to:

Group - 0 Layout Sets would be much more difficult.

Actually, simply having the UI hide a layoutSet that has a zero page count would be enough. So, the model needing to support "zero" is not really a necesitiy. I actually can't think of a use case, other than in the name of "simplicity and understandability".

When I look at Jorge's original list of "Benefits", I really only see "UI issue, UI issue, UI issue" and not data model or business logic issues. The "simplified permissions" is really the only thing that may perhaps benefit the coding.

Joel Kozikowski, modified 16 Years ago.

RE: Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Expert Posts: 405 Join Date: 6/28/06 Recent Posts

Joel Kozikowski:

Brian Chan:
Going to:

Group - 0 Layout Sets would be much more difficult.

Actually, simply having the UI hide a LayoutSet that has a zero page count would be enough. So, the model needing to support "zero" is not really a necesitiy. I actually can't think of a use case, other than in the name of "simplicity and understandability".

Thinking about this issue in the context of the original post (and the desire for easier understandablity), I think the most important usability enhancement as far as "understandability" to come from refactoring would be the "less than 2" LayoutSets.

Zero LayoutSets not needed. Three or more LayoutSets nice to have, and while use cases exist, since the system doesn't do it now, that doesn't get us any closer to the original goal. Being able to define "one and only one" for a given group DOES help the problem.

From a UI perspective, I think the illusion of "one and only one" could be done right now with just a little programming effort. For example, in the "My Places" menu, just hide any community with a page count of Zero. If only one of the two places have a pageCount > 0, display JUST the community name, and have a click on that name go to the LayoutSet in question. The same could be done for every place except perhaps the "Manage Pages" portlet (you've got to be able to define that first page SOMEWHERE).

I'd still love to see "3 or more" LayoutSets supported. But, until then, hiding the "zero" page count ones gives the illusion of "only one" for the large majority of users who understand and need only that.

Joel Kozikowski, modified 16 Years ago.

RE: Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Expert Posts: 405 Join Date: 6/28/06 Recent Posts

Joel Kozikowski:

From a UI perspective, I think the illusion of "one and only one" could be done right now with just a little programming effort. For example, in the "My Places" menu, just hide any community with a page count of Zero.

I was browsing through the portal.properties configuration file today, and low and behold, saw several entries like this:

    #
    # Set this to true to show organization public sites with no layouts.
    #
    my.places.show.organization.public.sites.with.no.layouts=true

So, it looks like it is ALREADY possible to hide entries on the "my places" menu if no layouts exist.

Michael Young, modified 16 Years ago.

RE: Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Liferay Master Posts: 846 Join Date: 8/5/04 Recent Posts

Joel Kozikowski:

When I look at Jorge's original list of "Benefits", I really only see "UI issue, UI issue, UI issue" and not data model or business logic issues. The "simplified permissions" is really the only thing that may perhaps benefit the coding.

Which is why I'm glad we solicited the community first emoticon

Ray Augé, modified 16 Years ago.

RE: Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Liferay Legend Posts: 1197 Join Date: 2/8/05 Recent Posts

Yup very good points!

Thought in my defence... I never suggested that this change be made in a
single wave of the hand, or that it was never my intention of ever
abandoning anyone. I've merely been questioning the value of the
"LayoutSet" paradigm and whether it continues to hold benefits which
outweigh it's encumbrance.

Atul and you have illustrated that it does continue to hold value, and
that it could probably be made even more valuable.

That's what I wanted to hear! Now, that being said, how do YOU use
Communities? And, is there a disjunction between how Liferay imagined it
being used and how it is really being used in the real world?

Can we make it better?

As data is concerned, and specifically with regard to it's scope, how
does this affect the uses of N "LayoutSets" all in the same data
scope... because I know it can become difficult issue with regard to
managing content, permissions. Is there an issue there already?

My concern ultimately is with the complexity of our data model... the
larger it becomes, the slower the portal.

It concerns me more having MANY less complex objects, than FEWER
more complex objects... because in reality you simply don't load
more complex objects as often, and I mean statistically.
So, I had imagined that if we could make Communities more useful...
perhaps by making them more complex so that they handle more cases...
then we could eliminate a layer of data "LayoutSet" and all the logic
associated with handling it. This would significantly reduce the
overhead of data already...

Thoughts?

Joel Kozikowski, modified 16 Years ago.

RE: Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Expert Posts: 405 Join Date: 6/28/06 Recent Posts

Ray Augé:

Now, that being said, how do YOU use
Communities? And, is there a disjunction between how Liferay imagined it
being used and how it is really being used in the real world?

Can we make it better?

I don't know - possibly?.

When I first started working with Liferay, to help my understanding, I created a UML diagram of the LR data model so I could get a better understanding of how it all fits together. That diagram is a little out of date, but most of it is still valid, especially for this conversation.

If you look over on the far right, you'll see the area relevant to this discussion.

In my model, I created several "implied" entities: entities that were not really separate tables, but were implied entities by the state of the data. The way I saw it, we have three types of "Groups" - a "user", a community group, and an organization group (and the organization, in turn, has two implied types - a location, and an "regular" organization.

Separate from that, we have a "LayoutSet", which is a single web site.

So, the question becomes, can those ideas be combined in some way? The discussions on this thread says "no" - its not enough to have ONLY ONE LayoutSet associated with each Group, but on the other hand, there is no reason to REQUIRE TWO LayoutSets with each group.

For me, a "Community" is just another organizational option. It allows me to manage a web site and group users together without the need to create a "Location." For my model, however, I don't really need them at all. The "Location", on the other hand, fits my ASP model nicely. Each customer is a "Location", and I am the top level organization.

An individual setting up a web site for a specific purpose (like to host an ecommerce site) may not really need the full blown "Enterprise" model of organizations and locations. They could either set up a single Community, OR, they could create a single Location.

With Liferay 4.4, the difference between a "Community" and a "Location" I think has blurred significantly. In previous versions, a "Location" (or any other organization for that matter) didn't have the "Manage pages" option, thus you couldn't create "web sites" for them (though the data model supported it, even back in LR 4.1). Now that you CAN manage pages for an arbitrary organization, I'm not sure what the advantage of the indivdual "Community" is, other than it just gives you more options.

In the end, however, if you look at the data model, it doesn't matter. Dropping "Communities" altogether and merging them into "Locations" or visa versa doesn't really change anything. Its the "Group" entity that represents all the "hard stuff", and that needs to be there regardless. We've already determined that "one LayoutSet per Group" isn't enough. So, I don't know.

Question: As of Liferay 4.4, what IS the difference between a Location and a Community (other than conceptual in describing the enterprise). From a coding standpoint (permissions, etc.), can one do anything with a Community that they CAN'T do with a Location or visa versa?

Brian Chan, modified 16 Years ago.

Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Liferay Master Posts: 753 Join Date: 8/5/04 Recent Posts

The similarities between an org and community:

both have pages
both have users
both have scoped roles

The differences:

orgs are hierarchical, communities are not
orgs have the idea of users that are a part of it, vs. just joining it.

So, user Bob joins community Basketball. The admin of community
Basketball can NOT modify the users who belong to that community.

User Bob also belongs to organization City of Los Angeles. The admin of
City of Los Angeles can modify his user profile.

Because orgs are hierarchical, if you are the admin of org A, you also
have the rights to modify users all the way down the tree.

atul patel, modified 16 Years ago.

Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Regular Member Posts: 192 Join Date: 11/18/06 Recent Posts

Thanks Brian.. That is helpful emoticon

On Feb 20, 2008, at 11:45 AM, Brian Chan at Liferay's Community
Forums wrote:

> The similarities between an org and community:
>
> both have pages
> both have users
> both have scoped roles
>
> The differences:
>
> orgs are hierarchical, communities are not
> orgs have the idea of users that are a part of it, vs. just joining
> it.
>
> So, user Bob joins community Basketball. The admin of community
> Basketball can NOT modify the users who belong to that community.
>
> User Bob also belongs to organization City of Los Angeles. The
> admin of
> City of Los Angeles can modify his user profile.
>
> Because orgs are hierarchical, if you are the admin of org A, you also
> have the rights to modify users all the way down the tree.
> --
> Liferay Community Forum
> mb.308691.501334@events.liferay.com
> http://www.liferay.com/web/guest/community/forums/message_boards/
> message/501334

atul patel, modified 16 Years ago.

Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Regular Member Posts: 192 Join Date: 11/18/06 Recent Posts

If I recall the evolution correctly, I used communities because
Location did not have the functionality that communities do.
Ideally, I wanted to use the "Location" for organizing folks. That
said, and given the current system functionality, I would
definately like to hear more from others around how they use
communities instead of locations.

Speaking of locations, we should really call them sub organizations
instead allow the end user to somehow label what that level meant.
So a particular level could represent a department, or a location, or
something else.

On Feb 20, 2008, at 11:26 AM, Joel Kozikowski at Liferay's Community
Forums wrote:

>

Ray Augé:

Now, that being said, how do YOU use
> Communities? And, is there a disjunction between how Liferay
> imagined it
> being used and how it is really being used in the real world?
>
> Can we make it better?
>

>
> I don't know - possibly?.
>
> When I first started working with Liferay, to help my
> understanding, I created [url=http://wiki.liferay.com/index.php/
> Entity_model]a UML diagram of the LR data model so I could
> get a better understanding of how it all fits together. That
> diagram is a little out of date, but most of it is still valid,
> especially for this conversation.
>
> If you look over on the far right, you'll see the area relevant to
> this discussion.
>
> In my model, I created several "implied" entities: entities that
> were not really separate tables, but were implied entities by the
> state of the data. The way I saw it, we have three types of
> "Groups" - a "user", a community group, and an organization group
> (and the organization, in turn, has two implied types - a location,
> and an "regular" organization.
>
> Separate from that, we have a "LayoutSet", which is a single web site.
>
> So, the question becomes, can those ideas be combined in some way?
> The discussions on this thread says "no" - its not enough to have
> ONLY ONE LayoutSet associated with each Group, but on the other
> hand, there is no reason to REQUIRE TWO LayoutSets with each group.
>
> For me, a "Community" is just another organizational option. It
> allows me to manage a web site and group users together without the
> need to create a "Location." For my model, however, I don't really
> need them at all. The "Location", on the other hand, fits my ASP
> model nicely. Each customer is a "Location", and I am the top level
> organization.
>
> An individual setting up a web site for a specific purpose (like to
> host an ecommerce site) may not really need the full blown
> "Enterprise" model of organizations and locations. They could
> either set up a single Community, OR, they could create a single
> Location.
>
> With Liferay 4.4, the difference between a "Community" and a
> "Location" I think has blurred significantly. In previous
> versions, a "Location" (or any other organization for that matter)
> didn't have the "Manage pages" option, thus you couldn't create
> "web sites" for them (though the data model supported it, even back
> in LR 4.1). Now that you CAN manage pages for an arbitrary
> organization, I'm not sure what the advantage of the indivdual
> "Community" is, other than it just gives you more options.
>
> In the end, however, if you look at the data model, it doesn't
> matter. Dropping "Communities" altogether and merging them into
> "Locations" or visa versa doesn't really change anything. Its the
> "Group" entity that represents all the "hard stuff", and that needs
> to be there regardless. We've already determined that "one
> LayoutSet per Group" isn't enough. So, I don't know.
>
> Question: As of Liferay 4.4, what IS the difference between a
> Location and a Community (other than conceptual in describing the
> enterprise). From a coding standpoint (permissions, etc.), can one
> do anything with a Community that they CAN'T do with a Location or
> visa versa?
> --
> Liferay Community Forum
> mb.308691.501288@events.liferay.com
> http://www.liferay.com/web/guest/community/forums/message_boards/
> message/501288

Joel Kozikowski, modified 16 Years ago.

RE: Re: [Liferay Forums][Liferay Core Developers]RE: Proposal to merge publ

Expert Posts: 405 Join Date: 6/28/06 Recent Posts

Ray Augé:

As data is concerned, and specifically with regard to it's scope, how
does this affect the uses of N "LayoutSets" all in the same data
scope... because I know it can become difficult issue with regard to
managing content, permissions. Is there an issue there already?

My concern ultimately is with the complexity of our data model... the
larger it becomes, the slower the portal.

It concerns me more having MANY less complex objects, than FEWER
more complex objects... because in reality you simply don't load
more complex objects as often, and I mean statistically.

I'm sitting here staring at that UML diagram, and trying to see if I'm "missing" something important in this discussion.

Up to this point, I've been thinking "I need more than one "web site" associated with each Location (and/or Community), so you can't do away with the "LayoutSet" concept. To me, a LayoutSet and "web site" are synonomous.

But now I'm looking at this "Group" entity in the diagram. Due to the way the data was (and currently still is), I've got Group diagramed as a super class to three "implied" Group sub-classes - the user's group, the Community, and the group assoicated with an organization.

Missing from that diagram (but a concept that I now understand since it was created) is that "data" such as forum posts, articles, blog entries, etc. is associated with the Group. The implication is that each organization or community has one and only one set of "data" associated with it.

Now that I think about it, I think what Jorge and Ray are suggesting in the original post is that we merge the concept of "LayoutSet" and "Group". For arguments sake, let's call this new merged entity a "Community" (since at the moment, there is not actually a table named "Community"). A "Community" now can have one and only one "web site" (it IS the old LayoutSet, as well as the old "Group"). Now, if we create a join table that allows a user OR an organization to be associated with "zero or more" Community records, we would have the simplification that Jorge is asking for. So, what do we lose? I see one and only one thing: shared data amongst the sites.

If we had the ability to have zero or more of these new Communties directly associated with the Location, that would suit my use case just fine. Provided that I could assign permissions so the "admin" of the location could create content and manage pages for each of the sites, MY use case doesn't call for that data to actually be shared. I don't have a need to have an article created on the "public" site to be available on the "private intranet" site of visa versa. I DO have a need to have permissions and users be associated with the location, and for those users to have access to one or more of the individual sites. But, if I had a forum in the intranet, I don't know if I would need the forum posts to be available on the "public" side or not. Given enough time, I may be able to come up with a scenario.

So, it looks to me like the real issue at hand is "shared data" and not "multiple sites per location", no?

Now, what would be the gain? We've simplified Group+LayoutSet, but we've complicated slightly the relationship between Organization, User, and this new "Community" record.

So, that brings me back full circle. Making the above mod would lose functionality (shared data), with no net gain in ease of maintenance or programability. Right?

Ed Shin, modified 16 Years ago.

RE: Proposal to merge public and private pages in one single set

Junior Member Posts: 71 Join Date: 3/24/05 Recent Posts

Sounds great! Simplifying things is always good, and it was a lot nicer to just click on a community and have it come up vs. having to click on the community and then select public or private.

Alexander Chow, modified 16 Years ago.

RE: Proposal to merge public and private pages in one single set

Liferay Master Posts: 518 Join Date: 7/20/05 Recent Posts

I like where you are going with this Jorge. The most important concern, as you have already pointed out, is usability. It is hard enough to use Permissions as is. If we cannot accomplish a simple UE to substitute in, I don't think the benefits would be worth the confusion.

Jorge Ferrer, modified 16 Years ago.

RE: Proposal to merge public and private pages in one single set

Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts

Hey guys,

Thanks everybody for your feedback, I sure wasn't expecting so many opinions but I'm glad you all jumped in.

My conclusion so far is that we should not merge the two layout sets. At least not for now, since there are use cases. One of my (not spoken out loud) reasons for this proposal was to ease the design of the new Control Panel. But maybe, as Brian mentions, we'll find a way to make to make the current model easier to use through that same Control Panel. (In other words we're leaving this in the hands of Nate ;) )

Just one important note, thought. As Joel mentioned in one of his last posts the public and private layouts share the data of their portlets. If we decide to keep them we definitely have to fix this limitation.

Joel Kozikowski, modified 16 Years ago.

RE: Proposal to merge public and private pages in one single set

Expert Posts: 405 Join Date: 6/28/06 Recent Posts

Jorge Ferrer:

Just one important note, thought. As Joel mentioned in one of his last posts the public and private layouts share the data of their portlets. If we decide to keep them we definitely have to fix this limitation.

Is it a limitation? Or a feature?

Just because in my specific use case I don't "need" the shared data concept, that doesn't mean its not valid in others. I could easily see something like a "Community Calendar" that one would want published to the outside world (i.e on the "public" side), but administered on the intranet (on the "private" side).

You may want to float THAT question out there (i.e. is there a need/desire to continue to have shared data).

I'd use extreme caution making such a low level behavioral change. Just because someone doesn't respond on the forum that they use it doesn't mean there aren't THOUSANDS of users out there using it that way. I saw LR has reached 1,000,000 downloads. I don't think there are near that many people participating on the forums emoticon

Jorge Ferrer, modified 16 Years ago.

RE: Proposal to merge public and private pages in one single set

Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts

Hi Joel,

Fully agreed. Now that we have this "feature" we have to keep it. So the way to "fix" it would imply letting the administrator choose the scope of the portlets in the private pages to be either public (and shared with the public pages) or private.

What worries me about the current model is that I think many people may not be aware of the shared scope of data (it happened to me) and thus make private information unknowingly public.

Tarkan Corak, modified 15 Years ago.

RE: Proposal to merge public and private pages in one single set

Regular Member Posts: 141 Join Date: 10/7/08 Recent Posts

Hi,

I'm new to the Liferay portal and indeed at the beginning I was very confused about the usage of public and private pages. To have one pubic site for internet and one private site for Intranet and both sites can share (portlet) data, that's fine! But I think the way you have access to these sites is confusing. Even when there is no community site and no organization site, you have at least four site navigations. Sure, you can use the drop down (welcome) menu to switch, but it would be great when each page could show where (which place / public or private) you currently are and to have quick access to each site.

In the next weeks and monthsI will go on working on my portal and hope to gain experiences to see which way is the best for me and my users. At the moment I prefer merging the navigation for public and private pages. At least I will do it for the "My Community" pages. But I have to find a way to avoid the user of creating one private page and to forget to remove the view permission for guest users.

Rajesh Nivrutti Ugale, modified 14 Years ago.

RE: Proposal to merge public and private pages in one single set

New Member Posts: 15 Join Date: 1/16/09 Recent Posts

Hello All,
I want to merge public and private pages in one single set , so that user can view his public and private pages at the same time.
Currently after login user needs to select which type of page he need to use either public OR private.
I want to display public and private together.
How can I achieve this ?

Snehal Wani, modified 14 Years ago.

RE: Proposal to merge public and private pages in one single set

New Member Posts: 10 Join Date: 10/22/09 Recent Posts

Hi,

The Current working Scenario in liferay is ,
When user clicks on My Places ->My Community

he gets two links 1.Public Pages 2.Private Pages
User clicks on any one of the links and moves to that particaular pages.

AND what I want to achieve is ,
When user clicks on My Places ->My Community
the two links 1.Public Pages 2.Private Pages should be removed and
after clicking on 'My Community' , the PUBLIC as well as PRIVATE pages ,BOTH should get displayed .

I am using Liferay-5.2.3. and UBUNTU 8.10
If any one has any idea about this issue plz let me know immediately !

Thanks in Advance!

Karthik Punnam Juluri, modified 7 Years ago.

RE: Proposal to merge public and private pages in one single set

New Member Posts: 8 Join Date: 9/28/16 Recent Posts

Jorge Ferrer:

Hey all,

This is something that I've been thinking for a long time and have talked about it with several core developers before. But after a conversation with Ray that we just had I'm now more convinced than ever to do it. Here are the benefits and drawbacks of doing it:

Benefits
Simpler to understand. We know that people often have problems undertanding the principle of public vs private pages
Don't confuse the user thinking that it's actually two separate websites. It's actually not, they share the content (because there is only one groupId).
Remove one level from the My Places menu (wouldn't you love that?)
Remove the need to want to move pages from one layout set to the other. You would just change the permissions.
Many permission checks would be simplified. See LEP-4790 for an example of the problems that our current system gets us into.
I'm sure there are other benefits based on the simplification and we'll find them as soon as this is applied

Drawbacks
Migration: migration might be an issue, but at the end is just about setting the right permissions
Making a page private would be slightly harder because of the complexity of our permissions UI. This could be solved by offering a quick way to set private/public permissions just by clicking a button or something like that. We have to keep thinking about how to make the permissions UI simpler anyway, so this is a great excuse to do it.

Thoughs?

Hi,
I got your Point, but i need to display Private & Public pages of a site in Public Site Navigation Menu, How could i do this?

Jorge Ferrer, modified 7 Years ago.

RE: Proposal to merge public and private pages in one single set

Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts

Hi Karthik,

My proposal above was discarded for 7.0 so you still have both public and private pages with separate navigations in that version (and all prior since 3.5 I think)

If you want a mix of public and private pages in the same navigation menu use only "Public Pages" and use the individual permissions of each page.

Karthik Punnam Juluri, modified 7 Years ago.

RE: Proposal to merge public and private pages in one single set

New Member Posts: 8 Join Date: 9/28/16 Recent Posts

Jorge Ferrer:

Hi Karthik,

My proposal above was discarded for 7.0 so you still have both public and private pages with separate navigations in that version (and all prior since 3.5 I think)

If you want a mix of public and private pages in the same navigation menu use only "Public Pages" and use the individual permissions of each page.

Hi Jorge,
Thanks for the update!

Karthik Punnam Juluri, modified 7 Years ago.

RE: Proposal to merge public and private pages in one single set

New Member Posts: 8 Join Date: 9/28/16 Recent Posts

Hi Jorge,
Can you explain me, how to make permissions at Page Level to a user?

Jorge Ferrer, modified 7 Years ago.

RE: Proposal to merge public and private pages in one single set

Liferay Legend Posts: 2871 Join Date: 8/31/06 Recent Posts

You need to do it through roles, not at the user level (although you could of course create one role per user if you really need that)

Regarding how to configure the permissions see: https://dev.liferay.com/discover/portal/-/knowledge_base/7-0/creating-and-managing-pages#changing-page-permissions

Karthik Punnam Juluri, modified 7 Years ago.

RE: Proposal to merge public and private pages in one single set

New Member Posts: 8 Join Date: 9/28/16 Recent Posts

Hi Jorge,
Thanks for the info.