cancel
Showing results for 
Search instead for 
Did you mean: 

Displaying uploaded content from a portlet

rsfeir
Champ in-the-making
Champ in-the-making
Hi,

We're evaluating Alfresco, love the ease of installation and the UI is very clear and usable.

The one thing that was not immediately obvious is how to perhaps implement the follow usecase:

We have a portal, JBoss Portal, and in this portal we have content.  Right now the content sits in plain html and txt files and we need to edit them manually.  When I tested the JBoss CMS portlet, which doesn't compare at all to this product (and as a matter of fact JBoss pointed me to Alfresco), they had a portlet which allowed me to display the content that I had uploaded or created in their CMS.

Is there a way to do this in Alfresco?

Basically:

1- Upload or add a new document and edit
2- Add a portlet to a page in my portal and configure the portlet to display a specific piece of content from the Alfresco CMS.

So is there such a portlet already created?

if no, is there an API which would allow me to create one which will do what I need?

Thanks in advance.
12 REPLIES 12

gavinc
Champ in-the-making
Champ in-the-making
Hi,

Yes, there is a way to do this with Alfresco but not out of the box, you will need to do some customization.

We have a servlet that can display content. You could create a separate portlet that just consists of an iframe and make the source of the iframe the URL to the download servlet.

To get the URL you can either use the helper method on the sevlet if you have the Node object to hand…

DownloadContentServlet.generateBrowserURL(node.getNodeRef(), node.getName());

…or you could find out the id of the content you want to show and build up the URL manually. An example of the URL you'll need have a look at the "View in Browser" link in the document details screen.

Hope that helps.

rsfeir
Champ in-the-making
Champ in-the-making
Excellent thanks for the prompt reply, this is the answer.  I think my approach will be to front your servlet with a portlet, don't really want to use an iFrame, and then pass to the portlet via a request parameter the page I want to see.  This simplifies a lot of things for us thanks.

R

rsfeir
Champ in-the-making
Champ in-the-making
Hi,

I wrote a simple portlet to try to prove the concept that things will work well, but I've hit a snag and I can't seem to find a way around it.

I've chosen, for reason of simplicity, to go with building the URL for the portlet like the one we see on the preview page.  With that I've written the following sample code:

public class CMSViewPortlet  extends GenericPortlet {
     @Override
    protected void doView(RenderRequest renderRequest, RenderResponse renderResponse)
            throws PortletException, PortletSecurityException, IOException {

        //Set the required content type.  We're expecting to render text/html in this case.
        renderResponse.setContentType("text/html");
        //setup the request dispatcher and pass it the URL init parameter value found in portlet.xml
        final URL url = new URL(getPortletConfig().getInitParameter("url"));
        final BufferedReader in = new BufferedReader(new InputStreamReader(url.openStream()));
        final PrintWriter out = renderResponse.getWriter();
        while(in.readLine() != null) {
            out.append(in.readLine());
        }
        in.close();
        out.close();

    }
}


Well I definitely get information back from Alfresco, the problem is that I get the login page, not the content.  So the content is protected, which is fine in some cases, but we need to have the content be public and not have anyone need to log in to see this particular content we're working on.

Further if there is protected content, how do we get around having users sign in to our portal and yours?

I'm using a base jboss portal install with our own theme, so I'm not doing anything way out of the ordinary.

Any clues and help would be greatly appreciated.

Thanks
R

rdanner
Champ in-the-making
Champ in-the-making
Hi,

I wrote a simple portlet to try to prove the concept that things will work well, but I've hit a snag and I can't seem to find a way around it.

I've chosen, for reason of simplicity, to go with building the URL for the portlet like the one we see on the preview page.  With that I've written the following sample code:

public class CMSViewPortlet  extends GenericPortlet {
     @Override
    protected void doView(RenderRequest renderRequest, RenderResponse renderResponse)
            throws PortletException, PortletSecurityException, IOException {

        //Set the required content type.  We're expecting to render text/html in this case.
        renderResponse.setContentType("text/html");
        //setup the request dispatcher and pass it the URL init parameter value found in portlet.xml
        final URL url = new URL(getPortletConfig().getInitParameter("url"));
        final BufferedReader in = new BufferedReader(new InputStreamReader(url.openStream()));
        final PrintWriter out = renderResponse.getWriter();
        while(in.readLine() != null) {
            out.append(in.readLine());
        }
        in.close();
        out.close();

    }
}


Well I definitely get information back from Alfresco, the problem is that I get the login page, not the content.  So the content is protected, which is fine in some cases, but we need to have the content be public and not have anyone need to log in to see this particular content we're working on.

Further if there is protected content, how do we get around having users sign in to our portal and yours?

I'm using a base jboss portal install with our own theme, so I'm not doing anything way out of the ordinary.

Any clues and help would be greatly appreciated.

Thanks
R


MM….
you are tying to use a feature alfresco supports for content preview which is only available if you are logged in.

If you access alfresco through the web service, jcr, or repository api you wont hit this snag because you will need to pass authentication.

using the JCR mechanism will take you the most miles because it is a standard not an implementation.  (not that you would ever want to, but you could switch to jackrabbit or some other system in the future.)  I am sure alfresco will rule the universe in the future… so this may not be a concern Smiley Happy   

There are examples that ship with alfresco that can put you on the road to jcr glory.

give me some time over this holiday and I will share some of the toys i am building.

rsfeir
Champ in-the-making
Champ in-the-making
Excellent thanks.

I can handle either webservice or JCR, but since I'm new I didn't realize all this was already there.

I'd still like to see the toys you're working on.

thanks for the prompt reponse!

R

gavinc
Champ in-the-making
Champ in-the-making
Hi,

As Russ says you could go the JCR or webservice route if you want. Alternatively if you want to continue the route you are going you can just append a ticket parameter to the URL (this does mean though your user would have to be logged in).

In the logged in session you can retrieve the ticket (it's stored in a session variable called '_alfAuthTicket') and add it as a paramter to the URL you pass to the servlet.

Hope this helps,

rsfeir
Champ in-the-making
Champ in-the-making
I was trying to use commons-http to create a client to authenticate, but so far I'm missing something because it's not authenticating right.  I've got all 3 fields which look to be required, and pulled the name of the fields from the form.

That said, we're going to see today and discuss which avenue to take.  Personally I'd rather not keep going down this path, it's just 'ugly', and given the alternatives this path, at least in my opinion, shouldn't even be considered.

I'm leaning towards WS right now, but we'll see.  I'll keep you guys posted and thanks for the continued support.

R

rsfeir
Champ in-the-making
Champ in-the-making
Ok, I looked at the examples and that lead me to a couple of questions.  The example for JCR seems to presume that I am running this test in the same webapp since it's looking for the spring app context definition files in the classpath.

Our setup would be such that the webapps may or may not be on the same machine, or even same server container.  So Alfresco would be in one location and the jboss portal in another.

Given that possiblity, do I still use the JCR API?  From what I can tell right now, we'd need to run the portal and Alfresco integrated in the same web app to use the JCR because I don't see a way to get at the Repository object remotely (I'm still reading about JCR).

Any direction you can point me in would be extremely helpful.

Thanks
R

rdanner
Champ in-the-making
Champ in-the-making
Ok, I looked at the examples and that lead me to a couple of questions.  The example for JCR seems to presume that I am running this test in the same webapp since it's looking for the spring app context definition files in the classpath.

Our setup would be such that the webapps may or may not be on the same machine, or even same server container.  So Alfresco would be in one location and the jboss portal in another.

Given that possiblity, do I still use the JCR API?  From what I can tell right now, we'd need to run the portal and Alfresco integrated in the same web app to use the JCR because I don't see a way to get at the Repository object remotely (I'm still reading about JCR).

Any direction you can point me in would be extremely helpful.

Thanks
R

This is a good and pretty common question.   The JCR is just an API and doesn’t really address geography.  Therefore, you might have an implementation that is based on a local repository, one backed up by web services or RMI.  You might also have a hybrid approach of backing the system up by a local repository and integrating it with the master.

In terms of continuity… I have been thinking about this problem.  I don’t want my site to be dependant on a remote CMS system.  I want it to use it when it is there and continue to function when it is not.  There are many ways to skin this cat but one approach that will kill it is to back the app up with a direct remote connection to the repository (unless you plan on consuming cached content when the CMS is down.)