Tag: Alfresco Surf

7 mistakes developers make when customizing Alfresco Share

I’ve seen more than my–ahem–fair share of Alfresco Share over the last several months. Many clients feel that their needs are so close to what Share provides out-of-the-box, that they can save time and money by starting with Share as the basis for their custom content-centric application. Whether or not that’s a good idea is the subject of another post. This post assumes that, for whatever reason, you find yourself customizing Alfresco’s Share client and wondering what are some of the common pitfalls to avoid. Here’s seven. Feel free to add to the list.

1. Ignoring client-side JavaScript minification

Here is a massive understatement for you: Alfresco Share has a lot of client-side JavaScript files. Most, if not all, of these are minified, or compressed, to reduce the size of a given page and increase client-side performance. If you’ve ever looked at the FreeMarker source for one of Alfresco’s pages, you may have seen something like this:

<@script type="text/javascript" src="${page.url.context}/components/blog/blog-common.js">

It looks like an everyday JavaScript reference but what’s up with that “@script” tag? It’s a FreeMarker macro. It switches out the JavaScript source file for the minified version when debug is turned off and uses the original uncompressed source when debug is turned on, which makes stepping through the client-side JavaScript much more pleasant.

There are two things you need to be aware of here. First, if you find yourself tweaking Alfresco’s client-side JavaScript, you’ll need to remember to deploy both the expanded and minified version of the file. Otherwise, when people turn debug on and off, they’ll see different results. Second, when you create your own client-side JavaScript, you need to minify your own code for the same reason.

You could turn debug on and leave it on (bad idea) or you could use a “normal” script tag and point to the non-minified versions of your JavaScript, but it is really easy to add minification as a part of your build, so you might as well set that up early in the project and you won’t have to worry about it later.

There are several JavaScript compressors out there. Here’s a link to the YUI Compressor. You can drop the JAR into your project and then invoke it from Ant quite easily. Ask Google for some examples.

2. Assuming Alfresco and Share are on the same host

When you install Alfresco it deploys a web application in the “/alfresco” context–that’s your repository and the old Alfresco Explorer client–and a second web application in the “/share” context. Depending on what you’re doing you might deploy numerous additional web apps based on Share or Surf.

Regardless of how you choose to deploy, you need to remember that there is no guarantee your app and Alfresco will be on the same machine, app server, or port number. One of the beauties of the Surf architecture is that you can scale it out across multiple app servers and they can all talk to the same (or multiple) Alfresco repository servers. The underlying Surf framework on which Share is based has configuration and helper variables you can leverage to deal with this. You should not be hardcoding “localhost” or any other hostname in your Share code.

3. Incomplete theme customization

Alfresco Share 3.3 has user-selectable themes. As part of your customization effort you can define your own theme and then configure that to be the default. An easy way to create your own theme is to copy one of the out-of-the-box themes and then modify it to suit your needs. The keys to cloning a theme successfully are:

  1. Copy one of the themes other than “Default”
  2. Search and replace references to the old theme name in the new CSS files (login.css, presentation.css, and yui/assets/skin.css)
  3. In the previous step, don’t forget yui/assets/skin.css!

4. Duplicating, rather than extending, Alfresco web scripts

Suppose you want to change something in one of Alfresco’s web scripts. You may be tempted to change the out-of-the-box controller JavaScript or FreeMarker views, but don’t do it. A nice thing about the web script framework is that you can override even just a single file that is part of a web script by placing your version of the file with the same name in the same folder structure under web-extension. This also works on the repository tier, but instead of web-extension you use the “extension” directory.

For example, maybe I want to extend the document-actions config XML in Share with my own settings. I will NOT copy my version over the top of Alfresco’s. Instead, I’ll put my copy in a file named “document-actions.get.config.xml” under WEB-INF/classes/alfresco/web-extension/site-webscripts/org/alfresco/components/document-details. When Alfresco loads the web script, it will use my version of the config.

5. Not using the web-extension directory

While we’re on the topic, all of your custom Share config files go in web-extension under the Share web application. Don’t put them in $TOMCAT_HOME/shared/classes and don’t put them in the Share web app’s classes/alfresco directory. Use the web-extension directory to keep your stuff separate from Alfresco’s. I also recommend doing the same with your client-side files–create a directory called “extension” for your client-side JavaScript, images, CSS, and so-on.

6. Using the same Tomcat server as the Alfresco repository during development

This one isn’t going to cause you problems, but it sure will slow you down. Even if your production Share web app will run on the same Tomcat as the Alfresco WAR, do yourself a favor: While you’re coding, use two Tomcats. On port 8080, you’ll run Alfresco and out-of-the-box Share. On some other port you’ll run a second Tomcat server with your custom Share- or Surf-based web app. That way, when you need to restart your custom Share app, you don’t have to wait for the repository to start back up. You’ll cut way down on the time you spend waiting for Tomcat to restart which, over time, can speed up your development cycle tremendously.

7. Failing to test on Alfresco’s supported browsers

Have I mentioned how much client-side JavaScript there is in Share? Every time you touch Alfresco’s JavaScript or create your own, you’ll need to test it on the browsers your client intends to use. So there are two recommendations here: First, make sure you are testing across Alfresco’s supported browsers. Second, make sure your clients only expect to use Alfresco’s supported browsers. Failure to do both of these can lead to some missed expectations on both sides. The browsers Alfresco supports for 3.3 are on the supported stacks page on the Alfresco web site.

What am I missing? Add a comment with your Alfresco Share street smarts.

Spring, Roo, and Alfresco Too: What Alfresco Gave to Spring and Why

Surf Logo

You’ll recall from my community event takeaways post in November that Alfresco announced plans around Surf, the Apache license, and Spring but the details were foggy at the time. This week, Alfresco and SpringSource announced that Surf, Web Scripts, and Web Studio have been donated to the Spring open source community under the Apache 2.0 license.

What is Surf?

Surf is a lightweight web application development framework. At a very high-level, Surf is essentially Alfresco Web Scripts (an MVC framework for binding URLs to server-side JavaScript/Java and Freemarker-based views) plus some page layout constructs and some built-in objects for connecting to and authenticating with remote HTTP end points, including Alfresco (See also “Alfresco UI Options” and “Surf Code Camp“).

Why Spring Surf Makes Sense

Alfresco’s team collaboration application, Alfresco Share, is built on top of the Surf framework and clients and partners, including Optaros, have built solutions on top of Surf. But so far, our experience has been that we probably could have built solutions faster using a different framework. One of the reasons is because you often can’t do everything you need to with Surf alone–it lacks services that would normally be provided by a broader framework. Your choice is either to re-create what’s missing or bolt on something that exists. So that’s the first reason why Surf becoming part of Spring makes sense. Spring is already a mature and widely-adopted framework. It’s much better to make Surf and Web Scripts part of an established framework (and community) than to try to grow Surf into a full-featured framework.

The second reason is more strategic. Alfresco sees a future dominated by CMIS (See “Getting Started with CMIS“). They want to be the go-to CMIS platform. From a repository perspective, they’ve been very active on this front. But development tools are going to be important, and although part of the beauty of CMIS is that it is tool-agnostic, I think SpringSource and Alfresco would obviously be pleased if their framework became a very natural and productive way to build CMIS apps.

Third, Alfresco doesn’t necessarily want to spend a lot of time on tools and frameworks if it doesn’t have to. Look at how much time Web Studio has languished in Community limbo–it’s clearly not a priority. If Surf catches on in the broader Spring community maybe Web Studio has a chance to turn into something. My guess is that SpringSource would prefer all development to take place within STS, its Eclipse-based IDE. Maybe Web Studio will get sucked into that somehow.

So what is Roo?

One of the things mentioned as part of the Spring Surf announcement is that Spring Roo integration is included. Spring Roo is pretty new so you might be wondering what that is. It’s pretty cool, actually. Basically, it’s a productivity tool for people who are building Spring apps. If you’ve ever worked with frameworks like Ruby on Rails, Grails, or Django, one of the first things you learn is how to use the command-line project scaffolding tools. Those tools make it easy for you to spin up and configure your project. Spring Roo is similar–it gives you a shell and a bunch of commands for things like setting up persistence, adding unit tests, and configuring security.

Spring Roo is extensible which is where Surf comes in. Let’s say you’ve created a Spring project and you want to use Surf as part of that project. All you have to do is go into your Roo shell and type “surf addon install”. No monkeying with the web.xml. No hunting for JAR files. It just happens. Next, suppose you want to add some Surf pages. Type “surf page create –id ‘SomeOtherPage’ –templateInstance home” and the XML is created for you in the right place (yes, the shell provides keyboard assist and hints so you don’t have to remember those commands).

Roo is definitely better appreciated by seeing it or trying it yourself. Michael Uzquiano did a short screencast showing the Spring Roo Surf extension. If you want to try Roo out yourself, go through Ben Alex’s “Getting Started with Spring Roo” posts.

Learn More

The bottom-line is that Surf becoming part of the Spring community is a good thing. You should check it out. The official Spring Surf page is the place to start. That’s where you’ll find the SVN URL, binary downloads, and links to other resources. There’s also going to be a webinar in January if you want to learn more.

Highlights from the Alfresco Meetup in Chicago

Other than the drenching I received between the blue line and the hotel (both coming and going) I thoroughly enjoyed my time in Chicago with the Alfresco crew last week. I ran into some Optaros customers, past colleagues, blog and book readers, and even some consultants from another firm who told me they came across some code I wrote for a client many years ago that they now support. (It was a custom Documentum WDK app for a certain carbonated beverage company that was actually pretty cool at the time, but I’d love to re-do it on an open stack).

The day was well-spent with Matt Asay kicking off with a state of the union, of sorts, followed by a couple of sessions from Michael Uzquiano, Alfresco product manager. I thought Uzi’s discourse on the macro- and micro-economic climate was interesting, but a bit arduous. Yes, we’re in some tough times and that’s good for open source. Check. Next slide. My favorite part of his talks were on the Alfresco roadmap (see Highlights, below).

Ed Wentworth, from Orbitz, gave a cool talk on how they’re using Alfresco. Ed’s team is implementing what I think is a best practice pattern: Services-Oriented Content Management. Orbitz has a lot of dynamic sites built on content chunks, not complete, fully-baked pages. So they leverage Alfresco’s strengths as a core repository, and then expose the repository as a service to the front-end (and to other services). They use the web client only for atypical or administrative interactions, and custom Share components and Surf apps for content authoring.

Orbitz also leverages an “Enterprise Content Bus” comprised of a ServiceMix ESB, BPM, and a rules engine (more info on ECB here and here). The ECB is primarily focused on orchestrating content-centric processes like content routing and delivery. Not everyone is going to need an ECB but if you’ve got anything that resembles a content production pipeline, it can really make your processes much more flexible with less code.

TSG did a cool demo on an open source solution for annotating attachments (screencast). It looks like it is still in dev mode but it’s got a great start and hopefully they’ll continue to enhance this and make it available to the community.

I did the Alfresco-Drupal CMIS integration demo (screencast) which seemed to go over well. Most people in the room acknowledged that they have more than one CMS, so there was interest something that could enable multiple web sites talking to one or more back-end CMS repositories using a standard API (CMIS).

At the end of the day a sort of “Everything you wanted to know about Alfresco but were afraid to ask” roundtable formed which was cool. I tried to demo the Alfresco-Django integration we’ve been working on. It worked on the plane and works now, but the demo gods chose that very day to expire my Alfresco license, and although hard to miss, I didn’t notice that as the root of my problem until after the meeting. It’s all good now so if you’ll be at the San Francisco event next week and want to see Django and Alfresco working together, let me know.

Highlights of the Alfresco Talks

  • Alfresco now has 1000 paying customers. Matt says it took Documentum many years to get to that point. With the price disparity, obviously, Alfresco needs many more customers than Documentum to thrive, but still, that’s quite an achievement.
  • There’s a Groovy renderer coming to Surf after 3.2.
  • Speaking of Surf, I’m not sure when it is coming, but Spring WebFlow is now being integrated into Surf which is much-needed.
  • If you’re looking for CMIS resources, CMISDev.org is a new site aimed at pulling a lot of that stuff together.
  • 3.2 Labs targeted for June
  • 3.2 Enterprise targeted for September 2009
  • 3.3 Labs/Enterprise targeted for 1Q 2010
  • 4.0 Labs/Enterprise targeted for 2nd half of 2010

The 3.2 release is shaping up to be pretty major. Here are some of the things planned for 3.2 that caught my ear:

Surf Mobile. This is an addition to the Surf framework that makes it easier to develop Surf apps that work well on the iPhone, although audience members said the demo site was also usable on their Blackberries.

New Form Service. Today you’ve got “property sheets” in the Explorer client which are driven by the content model and the web-client configuration XML, web forms in WCM which are defined using XSD, and custom forms in Surf which aren’t defined using any kind of framework at all. The new form service will provide a single form definition/presentation framework across the entire Alfresco platform. It’s a Good Thing.

IMAP integration. This allows you to use your Outlook client (and Thunderbird and whatever else you use that knows IMAP) to get things into and out of the repository. One use for this is to archive email by dragging-and-dropping mail into mail folders which are backed by Alfresco. Another is to easily snag content from the repo without leaving the mail client. I don’t know if it will be in there, but a great feature would be to allow me to drag-and-drop a piece of Alfresco content onto my message which would then get translated into the download URL rather than a file attachment.

Clustering. Several attendees fell to the ground and wept, overcome with emotion, when Uzi said 3.2 would support real clustering of both the DM and WCM repositories. Clustering is something that has bedeviled complex Alfresco implementations. I’ll maintain my composure until I see this actually working.

Index refactoring. Ever do a search that fails to return a piece of content you know is in the repo? Or, the other way, when you see something that you know was deleted? Do you mark the time it takes to reindex your repository (to fix index inconsistencies) by how many times the moon rises and sets? I have no idea whether any of these issues will get better in 3.2 but hearing “index” and “refactor” in the same sentence makes me hopeful.

All-in-all I’d say it was one of the better Alfresco-led meetups. I’m looking forward to reconnecting with many of you next week in San Francisco. I’ll see you there.

Customizing Alfresco Share: Five things to watch out for

Alfresco Share is a team-centric collaboration tool. It’s really cool and our clients have been reacting very positively to it. When customers see the AJAXalicious UI, a common reaction is to want to take the next 5 projects on their list and “do them on Share”.

In cases where the functional requirements closely resemble team collaboration, that can be a great choice. In others, it’s an abuse of the tool. Just like a lot of things in software and life, just because you can doesn’t mean you should. (Remind me to tell you the story about building a tennis court reservation system in Lotus Notes some time).

Anyway, let’s assume you’ve got a set of requirements that reasonably resembles team-based collaboration, but some of Share’s tools (wiki, blog, document library, calendar, and recently, bookmarks) don’t work exactly the way you need them to. I’m not talking about adding new, self-contained custom components. This is specifically about customizing the out-of-the-box Share components. With that in mind, here are five areas where even simple Share customization efforts could take longer than you might think.

Custom Metadata

In its current incarnation, if you have custom metadata you want to display when looking at document detail, that’s code you have to write. Alfresco’s Mike Hatfield said, via Twitter, that the 3.2 Forms Service will make this better, so that’s good. If your Share sites contain simple documents that use only out-of-the-box metadata, this won’t be an issue for you.

Custom Workflows

Currently, in Share, there are a couple of places where the jBPM workflow engine is used. First, when you invite someone to a site, that kicks off a workflow. Second, you can “assign” an advanced workflow to a document in the document library.

The first issue is that the workflow submission dialog includes only the two out-of-the-box, document-centric workflows, “Ad hoc” and “Review and Approve”. It won’t show any custom workflows you’ve deployed. The workflow modal is not inspecting the workflow UI configuration like the web client does, so even if you got your workflows to show up in that list, the form wouldn’t have the custom workflow metadata you need to launch your custom workflow properly.

When you log in to Share, you’ll see a “My Tasks” dashlet. This gives you hope that maybe that dashlet could manage tasks for any workflow. Unfortunately, it only works with the “invite user” workflow and the two document-centric, OOTB workflows.

Long story short, Share isn’t set up to work with custom workflows out-of-the-box. If you’ve got custom workflows that need to work in the Share context, you’ll need to write your own dialogs for launching the workflow and your own component for managing workflow tasks.

YUI Bubbling Events

Share makes heavy use of YUI Bubbling Events. This results in a great end-user experience–the Share components communicate with each other and refresh themselves via AJAX without page refreshes. But it does mean there’s a bit of a learning curve when following the same pattern to implement your customizations if your team has never worked with the bubbling library before. It can get kind of thick in places.

Incidentally, all of the YUI stuff is part of Share, not Surf, which is the framework used to build Share. If you’re building your own Surf app you’ll need to grab the YUI libraries (or any other libraries you want to use) yourself. It’s the same for the Flash pieces (multi-document upload, document preview). It keeps Surf light, but if you want to incorporate that kind of functionality into your Surf app, some assembly will be required.

Code Sprawl

In Share, every module has as least one JavaScript file. For example, the Document Library has six different JavaScript files weighing in at about 136KB. Sometimes what should be a simple change (adding a button, creating a new modal) requires changes to every one of those files. This combined with grokking the bubbling events translates into potentially lengthy development cycles for stuff that you wish would be quick.

Theming

The main CSS file for Share is in the themes directory. But changing that will only affect the global dashboard header and the site dashboard header. If you want to change the theme for everything in Share, including individual tools, you have to change each tool’s CSS file. Those CSS files live in the “modules” directory. It would be nice if it were easier to implement site-wide or global themes.

Adding your own Components/Tools

The impact of these issues are lessened somewhat if you are adding your own components or tools instead of customizing what’s already there. It’s easy to write your own dashlets that show up on the global dashboard or the site dashboard. And with a little work, you can write dashlets that talk to each other using YUI Bubbling Events, just like the OOTB dashlets. The area for improvement is in skinning, configuring, and extending the out-of-the-box tools.

Share Your Thoughts on Share

There’s no doubt that Share is a cool application for team-based collaboration. I didn’t expect it to be configurable to the Nth degree right away, and we may be pushing the limits of its intended use. I’m curious to hear from others who have been tweaking the app: Have you worked through these issues? Are there other examples of specific extension points Alfresco could address to make your lives easier?

Curl up with a good web script

Curl is a useful tool for all sorts of things. One specific example of when it comes in handy is when you are developing Alfresco web scripts. On a Surf project, for example, you might divide into a “Surf tier” team and a “Repository tier” team. Once you’ve agreed on the interface, including both the URLs and the format of the data that goes back-and-forth between the tiers, the two teams can start cranking out code in parallel.

If you’re on the repo team, you need a way to test your API, and you probably don’t have a UI to test it with (that’s what the other team’s working on). There are lots of solutions to this but curl is really handy and it runs everywhere (on Windows, use Cygwin).

This post isn’t intended to be a full reference or how-to for curl, and obviously, you can use curl for a lot of tasks that involve HTTP, not just Alfresco web scripts. Here are some quick examples of using curl with Alfresco web scripts to get you going.

Get a ticket

It’s highly likely that your web script will require authentication. So the first thing you do is call the login web script to get a ticket.

curl -v "http://localhost:8080/alfresco/service/api/login?u=admin&pw=somepassword"

Alfresco will respond with something like:

<?xml version="1.0" encoding="UTF-8"?>
<ticket>TICKET_e46107058fdd2760441b44481a22e7498e7dbf66</ticket>

Now you can take that ticket and append it to your subsequent web script calls.

Any web script you’ve got that accepts GET can be tested using the same simple syntax.

Post JSON to your custom web script

If all you had were GETs you’d probably just test them in your browser. POSTs, PUTs and DELETEs require a little more doing to test. You’re going to want to test those web scripts so that when the front-end team has their stuff ready, it all comes together without a lot of fuss.

So let’s say you’ve got a web script that the front-end will be POSTing JSON to. To test it out, create a file with some test JSON, then post it to the web script using curl, like this:

curl -v -X POST "http://localhost:8080/alfresco/service/someco/someScript?alf_ticket=TICKET_e46107058fdd2760441b44481a22e7498e7dbf66" -H "Content-Type: application/json" -d @/Users/jpotts/test.json

By the way, did you know that starting with 3.0, if you name your controller with “.json” before the “.js” the JSON will be sitting in a root variable called “json”?  So in this case instead of naming my controller “someScript.post.js” I’d name it “someScript.post.json.js” and then in my JavaScript, I can just eval the “json” variable that got created for me automatically and start working with the object,  like this:

var postedObject = eval('(' + json + ')');
logger.log("Customer name:" + postedObject.customerName);

Run a CMIS query

With 3.0 Alfresco added an implementation of the proposed CMIS spec to the product. CMIS gives you a Web Services API, a RESTful API, and a SQL-like query language. Once you figure out the syntax, it’s easy to post CMIS queries to the repository. You can wrap the CMIS query in XML:

<cmis:query xmlns:cmis="http://www.cmis.org/2008/05" >
<cmis:statement><![CDATA[select * from cm_content where cm_name like '%Foo%']]></cmis:statement>
</cmis:query>

Then post it using the same syntax as you saw previously, but with a different Content-Type in the header, like this:

curl -v -X POST "http://localhost:8080/alfresco/service/api/query?alf_ticket=TICKET_e46107058fdd2760441b44481a22e7498e7dbf66" -H "Content-Type: application/cmisquery+xml" -d @/Users/jpotts/cmis-query.xml

Alfresco will respond with ATOM, but it’s a little verbose so I won’t take up space here to show you the result. Also, I noticed this bombed when I ran it against 3.1 Enterprise but I haven’t drilled down on why yet.

Create a new object using CMIS ATOM

Issuing a GET against a CMIS URL returns ATOM. But CMIS URLs can also accept POSTed ATOM to do things like create new objects. For example, to create a new content object you would first create the ATOM XML:

<?xml version="1.0" encoding="utf-8"?>
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:cmis="http://www.cmis.org/2008/05">
<title>Test Plain Text Content</title>
<summary>Plain text content created via CMIS POST</summary>
<content type="text/plain">SGVyZSBpcyBzb21lIHBsYWluIHRleHQgY29udGVudC4K</content>
<cmis:object>
<cmis:properties>
<cmis:propertyString cmis:name="ObjectTypeId"><cmis:value>document</cmis:value></cmis:propertyString>
</cmis:properties>
</cmis:object>
</entry>

Note that the content has to be Base64 encoded. In this case, the content is plain text that reads, “Here is some plain text content.” One way to encode it is to use OpenSSL like “openssl base64 -in <infile> -out <outfile>”. The exact syntax of ATOM XML with CMIS is the subject for another post.

Once you’ve got the XML ready to go, post it using the same syntax shown previously, with a different Content-Type in the header:

curl -v -X POST "http://localhost:8080/alfresco/service/api/node/workspace/SpacesStore/18fd9821-42a5-4c6a-86d3-3f252679cf7d/children?alf_ticket=TICKET_e46107058fdd2760441b44481a22e7498e7dbf66" -H "Content-Type: application/atom+xml" -d @/Users/jpotts/testCreate.atom.xml

The node reference in the URL above is a reference to the folder in which this new child will be created. There’s also a similar URL that uses the path instead of a node ref if that’s more your thing.

Refreshing Web Scripts from Ant

One of the things you do quite frequently when you develop web scripts is tell Alfresco to refresh its list of web scripts. There are lots of ways to automate this, but one is to create an Ant task that uses curl to invoke the web script refresh URL. This lets you deploy your changes and tell Alfresco to refresh the list in one step (and makes sure you and your teammates never forget to do the refresh).

<target name="deploy-webscripts" depends="deploy" description="Refreshes the list of webscripts">
<exec executable="curl">
<arg value="-d"/>
<arg value="reset=on"/>
<arg value="http://${alfresco.web.url}/service/index"/>
</exec>
</target>

In this example, the “deploy” ant task this task depends on is responsible for copying the web scripts to the appropriate place in the exploded Alfresco WAR. (Thanks to my colleague Eric Shea (http://www.eshea.net/2009/01/30/alfresco-dev-survivors-kit-part-1/) for this tip).

So there you go. It’s not Earth-shattering but it might give you a productivity boost if you don’t already have curl or an alternative already in your bag of tricks.

Enjoyed the Code Camp in Munich last week

I thoroughly enjoyed my time in Germany last week. In addition to presenting the details around Alfresco’s web application framework, Surf, I met lots of great people, ate some outstanding food, and drank plenty of German beer. Out of the three Code Camps we conducted, this location had the most character. Check out the pics to see what I mean.

About 30 people from around Europe spent the day learning Alfresco Surf. We then finished up with a round table discussion. One of the campers, Gabriele Columbro, posted a great recap of the Code Camp if you want a taste of what we covered. Gabriele has a few screenshots of the slides. We’ll be posting all of the materials and labs in full soon.

Alfresco Surf overview: Recorded webinar available online

I’m looking forward to the Surf Code Camp we’re conducting on Tuesday in Munich. If you’re attending and you want a little taste of the framework, Alfresco has a one hour recorded webinar available. If you don’t get a chance to watch it prior to the Code Camp, that’s okay. We’re covering everything that’s discussed in that webinar and more. Some people have said that they would rather not come in cold, so this is for those folks.

I know not everyone’s been able to get to a Code Camp. We’re going to work with Alfresco to get the presentations, labs, code samples, and maybe even the VMWare image posted at some point this quarter in case people want to go through the material on their own.

Alfresco 3.0 Surf Code Camp Boston Wrapped Up

We hosted a good crowd of folks at Optaros headquarters in Boston today for our second Code Camp around Alfresco 3.0 Surf. Alfresco’s own Dr. Yong Qu was on hand to provide an early gift to campers–a live demo of Alfresco’s browser-based site designer tool, Web Studio. It looked like it was coming along nicely. The new tool is in Labs head but I haven’t had a chance to take a look so it was great that Yong was able to show us how it worked.

Yong showed a quick demo in which he stepped through a site creation wizard. Behind the scenes, Web Studio was creating a new web project in the Alfresco WCM store and configuring a user sandbox. Once the site was created, Yong put the site in edit mode. It makes more sense when you see it but what happens is a tray opens up that contains various lists of templates, components, and assets that can be dragged-and-dropped onto regions on the site’s pages. Once put in place, the component can be configured. Again, behind the scenes, Web Studio is creating the Surf model objects in the Alfresco WCM store (Code Campers become painfully aware of the variety and number of model objects required to build a Surf site because they do it by hand all day in the labs).

It’ll be a while (multiple months?) before Web Studio makes it into Enterprise. Until then, try it out. And while you’re in there, look at the library of components. Alfresco is hoping you will be inspired to create and submit additional components that can be similarly shared with the community.

The next Optaros-led Alfresco 3.0 Surf Code Camp will be in Munich on January 13th. I’ll be there as well as some of my other Optaros teammates, Alfresco will be there, and we’re hoping you will be there too. Read more details on the Munich event and sign up here.