Re: [Hypercontent-users] CASIFY Hypercontent - issue

[Alex V. <al...@bi...>]

On Oct 26, 2006, at 7:48 PM, tom tom wrote:

> Thanks Alex,
>
> I did not see your response in the forum
> (http://sourceforge.net/mailarchive/forum.php?forum_id=38700)
> hence I resent the question, sorry for the
> inconvenience.

No problem!

>
> Can you let me know the following.
>
> 1) From where can I download the latest Hypercontent
> from CVS, URL?

Instructions for CVS access are here

http://sourceforge.net/cvs/?group_id=101745

>
> 2)What about the authorization. Currently I do use the
> group model in uPortal,
>
> What am looking for is to introduce the WebProxy
> channel which renders Hypercontent pages, normal
> students will see the pages as if pages served from
> uPortal but publishers (staff) should be able to edit
> the content via uPortal WebProxy channel. If the
> uPortal group structure is not incooperated with
> Hypercontent, how can I achiveve the above two
> functionalities for students and publishshers/content
> editors

The groups and permissions structure in HyperContent are analogous to  
but separate from uPortal.  Here's some info:

http://hypercontent.sourceforge.net/help/project/permissions.html

>
> 3)Any reason to introduce this JSR 168 portlet, found
> any issues with WebProxy? anyway are there any
> instructions to deploy the Portlet,

You'll need the portlet version if you want users to be able to edit  
inside the portal.  This is working, at least the XML editor, I still  
have to tweak the others.

There are no portlet deployment instructions online yet, but its  
simple enough.  The portlet.xml file under /webapp/WEB-INF in CVS has  
some sample portlet configurations; you'll need to define one portlet  
in that file per portlet you want to publish from HC into uPortal.   
This is due to an unfortunate and known bug in uPortal.  The path to  
render can be configured in the portlet.xml or as a channel  
publishing parameter via the uPortal publishing UI, but each portlet  
has to have a unique name in portlet.xml in order for the portal to  
recognize them.  You then would follow the standard portlet  
publishing workflow, using the name for each portlet you define in  
the xml file.  Deployment is simply a matter of zipping up the webapp  
directory and feeding it to the uPortal "deployPortletApp" ant  
target.  You should point the "path" preference or parameter to an  
output you've configured for your XML files that generates markup  
with relative paths and portlet styles.  The portlet automatically  
rewrites links, images, and scripts, like WebProxy does.  You click  
the edit channel icon in uPortal to kick into edit mode, which gives  
you a miniaturized version of the regular HC UI, where you can switch  
between live preview and editing.

The advantages of this approach over WebProxy are mostly theoretical  
at this point, until further tuning is performed.  But by eliminating  
the HTTP bottleneck and leveraging HCs more sophisticated caching, it  
should be possible to scale as well or better than web proxy.

Cheers,
	Alex