Portal Approach

[Derek Rendall <ri...@gmail.com>]

Hi

I have downloaded the binary, and even checked out from SVN - both working fine. My question now, as a newbie to portal development (but not architecture), is what is the best way to implement what I need in a portal. Here is what I'm after:

1) I need the ability to have public as well as private widgets (I have designed similar approach for Liferay before with public and private communities). There will be anonymous access to a few key capabilities, but external users will need to signup/login to extract full value from the site. Internal users will log into the sight to access a different set of widgets etc. I presume that I will need to create my own version of the home page, but I don't know if it's best to edit directly in the downloaded code or if its best to treat Rave as a black box and create a separate project with a dependancy upon Rave (and if so, hints on how would be appreciated). My preference is to keep an ability to upgrade Rave as a separate component without introducing too many changes that require complicated merging.
2) I need to create my own private/public widgets (with some social integration as an enhanced capability). I'm not familiar with Shindig or Wookie, so I can't tell which approach would be best, or whether its something I create "within" the Rave development or outside and deploy to a runtime?
3) Not at the moment, but I believe an aspect of content management will be useful in the near term - I note the presentations on Spring HMVC extension, and was wondering what is the state of the content-services sandbox?

Thanks

Derek

Re: Portal Approach

[Matt Franklin <m....@gmail.com>]

Hi Derek,

Sorry for the delay, many of us have been at ApacheCon and therefore a
little busy with the events there.  I have responded inline below:

On Fri, Feb 22, 2013 at 6:21 AM, Derek Rendall
<ri...@gmail.com> wrote:
> Hi
>
> I have downloaded the binary, and even checked out from SVN - both working fine. My question now, as a newbie to portal development (but not architecture), is what is the best way to implement what I need in a portal. Here is what I'm after:
>
> 1) I need the ability to have public as well as private widgets (I have designed similar approach for Liferay before with public and private communities). There will be anonymous access to a few key capabilities, but external users will need to signup/login to extract full value from the site. Internal users will log into the sight to access a different set of widgets etc. I presume that I will need to create my own version of the home page, but I don't know if it's best to edit directly in the downloaded code or if its best to treat Rave as a black box and create a separate project with a dependancy upon Rave (and if so, hints on how would be appreciated). My preference is to keep an ability to upgrade Rave as a separate component without introducing too many changes that require complicated merging.

There is an open issue to support anonymous views.  If I understand
correctly, this would be what you are looking for as well.  JIRA is
not responding for me now, but I will follow up with a link.

If you have thoughts or experience on how to tackle this issue, please
feel free to start or join the conversation on the dev@ list.

> 2) I need to create my own private/public widgets (with some social integration as an enhanced capability). I'm not familiar with Shindig or Wookie, so I can't tell which approach would be best, or whether its something I create "within" the Rave development or outside and deploy to a runtime?

Shindig & Wookie are implementations of OpenSocial and W3C Widget
Family specifications, respectively.  Each of the frameworks has its
tradeoffs, and it really depends on what you would like to do with the
widgets.  If you want activity stream integration and social data,
OpenSocial might fit best.  If you want to package your widgets and
upload them to the widget server, wookie might be a better choice.  In
both cases, the development of widgets is something unrelated to Rave.
 Rave just references them by URL.

> 3) Not at the moment, but I believe an aspect of content management will be useful in the near term - I note the presentations on Spring HMVC extension, and was wondering what is the state of the content-services sandbox?

The lessons learned in that sandbox are driving a new, simpler
architecture in the core Rave application.  We are working toward a
much more loosely coupled system and stronger separation between the
"core" widget management and portal functionality.  Hopefully, we can
reintegrate the concepts, if not the code directly, once we have
re-architected the services.

>
> Thanks
>
> Derek
>
>