Comments on: Alfresco User Interface: What are my options? http://ecmarchitect.com/archives/2009/04/20/971 Jeff Potts on ECM, portals, search, collaboration, and a bunch of personal stuff Mon, 06 Feb 2012 17:48:37 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: jpotts http://ecmarchitect.com/archives/2009/04/20/971/comment-page-1#comment-88607 jpotts Tue, 29 Nov 2011 00:15:44 +0000 http://ecmarchitect.com/?p=971#comment-88607 Tyrus, I'm realizing I never answered your follow-up question about using the JavaScript API on top of Alfresco. The Alfresco Share interface uses the approach you've outlined. It takes YUI and wraps it with its own set of client-side JavaScript objects (documented <a href="http://sharextras.org/jsdoc/share/community-4.0.b/" rel="nofollow">here</a> for Community 4.0b). Those client-side objects are talking to the repository tier via web scripts. The web script controllers are written in server-side JavaScript (mostly, some are Java) and those use the JavaScript API you've referenced. Share wasn't built on YUI alone. It also needed a framework for doing page layout and for making remote calls back to the repo tier. For that, Share relies on Spring Surf which also happens to use web scripts. But instead of returning data from the repo tier, they return markup on the presentation tier. So, if your use case is very close to Alfresco Share's, you could start with Alfresco Share and have your AJAX-y interface ready to customize. If it isn't close to your use case or requires too much customization to get the UI close to what you need, start with a custom app using the framework of your choice and hit the repo tier using web scripts. You might try to use the out-of-the-box repo tier web scripts as much as possible to try to reduce your coding and maintenance burden. You can always knock out custom repo-tier web scripts when the out-of-the-box web scripts don't meet your needs. Jeff Tyrus,

I’m realizing I never answered your follow-up question about using the JavaScript API on top of Alfresco. The Alfresco Share interface uses the approach you’ve outlined. It takes YUI and wraps it with its own set of client-side JavaScript objects (documented here for Community 4.0b). Those client-side objects are talking to the repository tier via web scripts. The web script controllers are written in server-side JavaScript (mostly, some are Java) and those use the JavaScript API you’ve referenced.

Share wasn’t built on YUI alone. It also needed a framework for doing page layout and for making remote calls back to the repo tier. For that, Share relies on Spring Surf which also happens to use web scripts. But instead of returning data from the repo tier, they return markup on the presentation tier.

So, if your use case is very close to Alfresco Share’s, you could start with Alfresco Share and have your AJAX-y interface ready to customize. If it isn’t close to your use case or requires too much customization to get the UI close to what you need, start with a custom app using the framework of your choice and hit the repo tier using web scripts. You might try to use the out-of-the-box repo tier web scripts as much as possible to try to reduce your coding and maintenance burden. You can always knock out custom repo-tier web scripts when the out-of-the-box web scripts don’t meet your needs.

Jeff

]]> By: Tyrus http://ecmarchitect.com/archives/2009/04/20/971/comment-page-1#comment-78505 Tyrus Fri, 02 Sep 2011 02:41:01 +0000 http://ecmarchitect.com/?p=971#comment-78505 No worries man! I just want to make sure credit is given where credit is due. Either way, I'm intrigued as to your opinion on the topics of customizing Alfresco interfaces. We have a client that wants a knowledge management solution as well as a CMS. Alfresco solutions seems like a perfect fit. However, being an agency the interface that Alfresco gives you OOTB needs some work. I'm curious as to your opinion on using the Javascript API: http://wiki.alfresco.com/wiki/3.4_JavaScript_API and then building an AJAX type interface that simply makes calls into Alfresco via such methods. I also saw your post here: http://ecmarchitect.com/archives/2010/09/07/1212 which frankly deterred me some more :) Any thoughts? No worries man! I just want to make sure credit is given where credit is due.

Either way, I’m intrigued as to your opinion on the topics of customizing Alfresco interfaces. We have a client that wants a knowledge management solution as well as a CMS. Alfresco solutions seems like a perfect fit. However, being an agency the interface that Alfresco gives you OOTB needs some work. I’m curious as to your opinion on using the Javascript API: http://wiki.alfresco.com/wiki/3.4_JavaScript_API and then building an AJAX type interface that simply makes calls into Alfresco via such methods. I also saw your post here: http://ecmarchitect.com/archives/2010/09/07/1212 which frankly deterred me some more :) Any thoughts?

]]> By: jpotts http://ecmarchitect.com/archives/2009/04/20/971/comment-page-1#comment-78487 jpotts Thu, 01 Sep 2011 23:26:18 +0000 http://ecmarchitect.com/?p=971#comment-78487 You are quite right. Except I worked for Optaros at the time I wrote the post, so technically I guess it wasn't ripped off but borrowed. While I worked there it was common for me to write something on this blog and then re-post it on the Optaros blog. What's weird is since I did work for Optaros at the time, we would have put my name on it. I'm not sure why Marc's name is on it. I hope that person asking questions isn't hoping for an answer. Marc's a Marketing guy who doesn't even work for Optaros any more! Sorry for the confusion it may have caused. Jeff You are quite right. Except I worked for Optaros at the time I wrote the post, so technically I guess it wasn’t ripped off but borrowed. While I worked there it was common for me to write something on this blog and then re-post it on the Optaros blog. What’s weird is since I did work for Optaros at the time, we would have put my name on it. I’m not sure why Marc’s name is on it. I hope that person asking questions isn’t hoping for an answer. Marc’s a Marketing guy who doesn’t even work for Optaros any more!

Sorry for the confusion it may have caused.

Jeff

]]> By: Tyrus http://ecmarchitect.com/archives/2009/04/20/971/comment-page-1#comment-78479 Tyrus Thu, 01 Sep 2011 22:38:49 +0000 http://ecmarchitect.com/?p=971#comment-78479 Dude, I think this guy ripped off your article: http://www.optaros.com/blogs/alfresco-user-interface-what-are-my-options Dude, I think this guy ripped off your article: http://www.optaros.com/blogs/alfresco-user-interface-what-are-my-options

]]> By: jpotts http://ecmarchitect.com/archives/2009/04/20/971/comment-page-1#comment-46942 jpotts Wed, 20 Jan 2010 14:53:18 +0000 http://ecmarchitect.com/?p=971#comment-46942 Ivano, I haven't looked at that particular style of integration in a long time. Honestly, I would avoid it if possible. Running Alfresco and Liferay in the same JVM is not the best idea. Alfresco's direction with portal integration is to use Spring Web Scripts from within a portlet to make remote calls to the Alfresco repository. You might have better luck in the forums. Jeff Ivano,

I haven’t looked at that particular style of integration in a long time. Honestly, I would avoid it if possible. Running Alfresco and Liferay in the same JVM is not the best idea. Alfresco’s direction with portal integration is to use Spring Web Scripts from within a portlet to make remote calls to the Alfresco repository.

You might have better luck in the forums.

Jeff

]]> By: Ivano http://ecmarchitect.com/archives/2009/04/20/971/comment-page-1#comment-46896 Ivano Mon, 18 Jan 2010 16:20:43 +0000 http://ecmarchitect.com/?p=971#comment-46896 I Jeff, as you teach there are many method to integrate Alfresco web client into Liferay portal framework, but in fact the most natural (Alfresco as a 168 portlet) is not usable at all!! I'm using Liferay Portal 5.1.2 and Alfresco ECM 3.2r2 deployed as portlets, using Tomcat 5.5.26. Tomcat, Liferay and Alfresco starts up ok, no errors. 6 Alfresco portlets are deployed onto liferay (registered successfully). But there is a big problem: You can't add/upload content in Alfresco's folders. You can add the Alfresco client portlet to a portal page, but when you try to 'add a content' - you get the error: ([org.alfresco.web.ui.common.Utils] A system error happened during the operation: null java.lang.NullPointerException at org.alfresco.repo.content.filestore.FileContentReader.(FileContentReader.java:123)) This is a problem since a long time, also using previous Alfresco version. Please, could you help on this? Thank you in advance! Ivano I Jeff, as you teach there are many method to integrate Alfresco web client into Liferay portal framework, but in fact the most natural (Alfresco as a 168 portlet) is not usable at all!!

I’m using Liferay Portal 5.1.2 and Alfresco ECM 3.2r2 deployed as portlets, using Tomcat 5.5.26.

Tomcat, Liferay and Alfresco starts up ok, no errors. 6 Alfresco portlets are deployed onto liferay (registered successfully).

But there is a big problem: You can’t add/upload content in Alfresco’s folders.

You can add the Alfresco client portlet to a portal page, but when you try to ‘add a content’ – you get the error:
([org.alfresco.web.ui.common.Utils] A system error happened during the operation: null
java.lang.NullPointerException
at org.alfresco.repo.content.filestore.FileContentReader.(FileContentReader.java:123))

This is a problem since a long time, also using previous Alfresco version.

Please, could you help on this?
Thank you in advance!

Ivano

]]> By: Is Alfresco Surf a portal alternative ? | blogs.contentreich.de http://ecmarchitect.com/archives/2009/04/20/971/comment-page-1#comment-43222 Is Alfresco Surf a portal alternative ? | blogs.contentreich.de Tue, 27 Oct 2009 09:17:34 +0000 http://ecmarchitect.com/?p=971#comment-43222 [...] Content-management can really cause headaches when you have a portal participating in the game (Our Experiences). Jeff Potts summarizes a few approaches integrating Alfresco (w/o Surf) with a portal in his blog. [...] [...] Content-management can really cause headaches when you have a portal participating in the game (Our Experiences). Jeff Potts summarizes a few approaches integrating Alfresco (w/o Surf) with a portal in his blog. [...]

]]> By: Flex for Enterprise 3.0 » Blog Archive » Liferay portlet for FlexSpaces http://ecmarchitect.com/archives/2009/04/20/971/comment-page-1#comment-40647 Flex for Enterprise 3.0 » Blog Archive » Liferay portlet for FlexSpaces Mon, 31 Aug 2009 01:03:57 +0000 http://ecmarchitect.com/?p=971#comment-40647 [...] Haven’t tried using SSO approaches yet: 1. Rivet Logic STAr (Secure Token Authentication rivet amp for Alfresco) used with AWPr 2. Jonas Yuan / Cignex LDAP ADS and SSO CAS  and also blog post on a combined install 3. Sourcesense Alfresco OpenSSO integration Other references 1. Luis Sala’s portlet dev wiki page and blog 2. Jeff Pott’s blog [...] [...] Haven’t tried using SSO approaches yet: 1. Rivet Logic STAr (Secure Token Authentication rivet amp for Alfresco) used with AWPr 2. Jonas Yuan / Cignex LDAP ADS and SSO CAS  and also blog post on a combined install 3. Sourcesense Alfresco OpenSSO integration Other references 1. Luis Sala’s portlet dev wiki page and blog 2. Jeff Pott’s blog [...]

]]> By: jpotts http://ecmarchitect.com/archives/2009/04/20/971/comment-page-1#comment-36357 jpotts Tue, 09 Jun 2009 14:05:27 +0000 http://ecmarchitect.com/?p=971#comment-36357 Yes, customizing Share is an option. I consider that to be Option 2, but I agree that when you start with Share it is different than writing a Surf app from scratch because your components already have pages where they can live. I do caution people, though, not to abuse the tool. It would be easy to take Share and make so many customizations to it you've taken it down a far different path than it was originally intended. What you have then is effectively your own fork of Share that may be difficult to maintain going forward. We've done some significant Share customizations and there some things to watch out for. If you are going the Share route, you might want to read this summary: http://ecmarchitect.com/archives/2009/04/22/976 Yes, customizing Share is an option. I consider that to be Option 2, but I agree that when you start with Share it is different than writing a Surf app from scratch because your components already have pages where they can live.

I do caution people, though, not to abuse the tool. It would be easy to take Share and make so many customizations to it you’ve taken it down a far different path than it was originally intended. What you have then is effectively your own fork of Share that may be difficult to maintain going forward.

We’ve done some significant Share customizations and there some things to watch out for. If you are going the Share route, you might want to read this summary:

http://ecmarchitect.com/archives/2009/04/22/976

]]> By: Coffman http://ecmarchitect.com/archives/2009/04/20/971/comment-page-1#comment-36354 Coffman Tue, 09 Jun 2009 11:58:57 +0000 http://ecmarchitect.com/?p=971#comment-36354 As usual, excelent article ... What about creating sites on Alfresco Share and develop dashlets for especific functionallity ? I think it's a nice approach . It's not like option 2, and you can use the Share UI. As usual, excelent article …
What about creating sites on Alfresco Share and develop dashlets for especific functionallity ? I think it’s a nice approach . It’s not like option 2, and you can use the Share UI.

]]>