The Loop

Readers of my blog will know that I love macs. Absolutely anything to do with Apple interests me; to that end, it will not surprise you that I have been doing some iPhone development.

For kicks I decided to write a mobile XMPie Dashboard application which would let you control XMPie uProduce whilst out and about. Whilst this is a sheer technology demonstration, its fairly functional and a great example of how with the right knowledge and skill, absolutly anything is possible within the XMPie toolset.

Below is a quick screencast demonstrating the application in all its glory!....

Im interested in your thoughts, so please comment below if you feel so inclined…

As a number of you are aware, I have spent quite a bit of time wrestling with XMPie uProduce SOAP API with the CXF service framework in Java. I finally (and with quite a lot of disappointment on my part) gave up trying to get that to work. CXF just does not want to play nice and I cant seem to make the XJB bindings work correctly with it and the mish-mash WSDL coming from uProduce

Anyway… with that rant over, I tried to be objective and switched to using Metro – ok, out of the box I still had a whole heap of problems, exactly as I did with CXF. However, I have managed to wangle it!

Step 1

You will need access to an XMPie server with the API’s installed and working. For the sake of this example i just wget’d the WSDL file so the generation code was not so bloated.

Step 2

You’ll need an XSD XJB binding file which looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<bindings xmlns="http://java.sun.com/xml/ns/jaxb" 
          xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
          xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" 
          version="2.0">

  <globalBindings>
    <xjc:simple />
  </globalBindings>

  <bindings scd="~xsd:complexType">
    <class name="ComplexTypeType"/>
  </bindings>

  <bindings scd="~xsd:simpleType">
    <class name="SimpleTypeType"/>
  </bindings>

  <bindings scd="~xsd:group">
    <class name="GroupType"/>
  </bindings>

  <bindings scd="~xsd:attributeGroup">
    <class name="AttributeGroupType"/>
  </bindings>

  <bindings scd="~xsd:element">
    <class name="ElementType"/>
  </bindings>

  <bindings scd="~xsd:attribute">
    <class name="attributeType"/>
  </bindings>
</bindings>

Save this as xsd.xjb (or whatever you like, just make sure the name is reflected in the command below)

Step 3

Actually generate the code! Your command might look different, but heres mine:

  wsimport -b http://www.w3.org/2001/XMLSchema.xsd \
    -b src/xjb/xsd.xjb \
    -keep \
    -s src/java \
    -d target \
    -p com.xmpie.wsapi.icp \
    src/wsdl/InteractiveCampaign_SSP.wsdl

You should then see something like the following in your finder (or other OS file browser if not on mac):

These are the class files created for the InteractiveCampaign WSDL – all 128 of them!

Anyway, I have run out of time for today, but will try and get another blog up soon about how to use this in a client application from a java CLI.

Whilst at Drupa I was lucky enough to get a back room showing of what Creo will be releasing in Q4 of 2008 and into 2009.

The first impressions are really great – the native UI (Cocoa on OSX and .NET windowing on WinTel) means that no matter what your platform you get widgets that you are familiar with and work seamlessly with the operating system. That really is quite a differentiator when compared to competing products, and one that I am sure a lot of people would welcome as even from personal experience, quite a number of other solutions are using SWNG, or, god forbid, AWT in Java which are clunky and just not up to the modern users expectations.

Plugins

One of the things that really is very good about Darwin is the plugin system they have devised. Whilst I currently have no information on what inner complexities one might face with implementing your own plugin, the architecture I was shown looked very open, and very friendly – which is a massive plus point in my eyes.

Performance

Darwin was awesomely quick too – speed and beauty in the same package! Eliot Harper has blogged some very nice performance testing between XMPie uDirect and Creo Darwin which can be found here

Integration

Creo have changed the way in which the Darwin working environment is persisted – its now a separate DVJ file. This means that when working with InSite, the system can automagically create the darwin files for you. I’d go out on a limb and say that if InSite is able to create those files, then any other system you might want to write would also be able to generate DVJ files – this could really create some interesting options for mash-up style workflows!

What About The Cons?

Ok, so all products have there cons – thats life – at the moment Darwin only supports flat file data-sources. Perhaps that will change over time, but we’ll see I guess. Release is quite some time off so who knows what those guys might come up with!

Kudos Creo , this really is great work.

Another interesting article about Darwin and InSite can be found here

Just a quick note that I have refactored the code base for the XMPie ICP extension for Merb 0.9.2 and added some extra cool things that are inherited by the ICP subclasses.

Now, its possible to add validation into the model subclass. Lets say we have a feild defined in our uPlan called ‘email’ and ‘user_name’. I need the ‘user_name’ field to be required, which you can now do like so:

class Visitor < Xmpie::Icp::Base
  validates_presence_of :user_name
end

# in your controller...
@visitor.valid? # => true if has a user_name, otherwise false

All exciting stuff! When XMPie make ICP a more viable persistance tier, then this will no doubt be the quickest and slickest way to implement front ends in. Furthermore, with the Engine Yard team working on mod_rubinus then we should see ruby web application performance finally get where it needs to be.

I think that pretty much all the ‘Personalised URL’ jobs that I have ever needed to do have always been of the directory style, e.g:

www.domain.com/mylovelyusername

However, it strikes me that a better and more programatically favourable format is the sub-domain pattern, e.g:

mylovelyusername.domain.com

In this instance you don’t have to worry about holding information in sessions, or setting up anything else complicated to make sure that they visit that URL first – it doesn’t matter with the sub-domain pattern as you always have there unique identifier to hand in the URL. Im not wholly sure why it is that more people don’t see the benefit of doing this – if you ask me it ‘feels’ more personal that a one time visit to a directory style URL.

Check out these awesome personalized video's which its now possible to produce using XMPie version 4!

Kudos to Eliot as he has been talking about personalized video for some time now and its finally been brought into the core version 4 product.

Check these awesome samples from the recent XUG meet in Vegas...

Well, after a long stint of having no decent MySQL support (as uProduce only supports up to version 4 out of the box. Other than my ODBC monkey patch there has been no version 5 support), I have managed to find a working, and critically viable, solution for using MySQL 5 with XMPie uProduce.

cherrycitysoftware.com sell (not that you can even call it that, its only $10) a little mysql driver that with a little bit of work you can make work with uProduce and uPlan – its nice to have MySQL back!

You can use a DSN with generic DB like this:

Provider=OleMySql.MySqlSource.1;Password=YOURPASSWORD;Persist 
SecurityInfo=True;User ID=YOURUSERNAME;Data Source=YOURDBHOST;
Location=YOURDBHOST;Mode=Read;Trace="";Initial Catalog=INITIALDATABASE

Initial results are great – its working cleanly and quickly – good times with MySQL!

Well its taken a while to put together, but I am finally reaching the point at which its really useable and sweet to work with. I would love to hear peoples thoughts on this - are you already using the DW controls? If so, what are your thoughts on this new style of working? Is it too limited by way of being too techie?

Its important to note that this framework is 100% cross platform any only requires Ruby, and the RubyGems package management; this screen-cast however was created on OSX Leopard.

MAKE SURE YOU VIEW FULL SCREEN TO READ THE TEXT

Enjoy!

Well, its finally happened – an independent, open, and crucially free forum for discussing XMPie technology in a global community.

This is all pretty new but I would love to see some good conversations bubble up on there in the not too distant future – if you would like to sign up get yourself over to this page ASAP!

We are hoping that this will prove a useful and valuable resource for XMPie discussion – I hope to see as many of you on list as possible!!

For all the good things about XMPie, one of my niggles has been the lack of support for PostGRE SQL. I guess thats pretty understanderble; most of there client base use SQL server and other such MS products to some degree. There are times when id really like to use PostGre SQL as the backend and it can be a bit annoying. Anyway…thats another story…. for now were just going to look at implementing the OLEDB conectivity onto the servers to make it talk to our datasource.

Before we begin please note that it is critical to make sure that your PostgreSQL server can accept connections from your host IP. Otherwise you will get an error detailing that windows could not initialize the OLEDB provider. So, for those not familiar with PGSQL, check your postgresql.conf and pg_hba.conf….

Step 1

Ok, firstly you will need to install the OLEDB driver onto the server (and all extension serves where applicible)…

Download the OLEDB driver files from here - its currently in beta so do bear that in mind. Once downloaded, unzip it and copy libpq.dll and PgOleDb.dll to your windows\system32 folder.

Next, to register those new files as sources, go Start > Run and type

regsvr32 PGOLEDB.DLL

All being well you should see a sucsess box - if not, then i guess check your spelling against the DLL :)

Step 2

Now, provided you got your working OLEDB driver up and running in the previous step (be sure to test this with a UDL script) you should be able to add the database into the xmpie dashboard using a dsn something like this:

Provider=PostgreSQL OLE DB Provider;Password=<pass>;
User ID=root;Data Source=127.0.0.1;Location=demo;Extended Properties=&#8221;&#8221;

I am going to be doing some testing to see if this is any quicker than SQL Server (fingers crossed it will be) - stay tunned readers!

Give me a shout if you dont seem to be able to make this work (for whatever reason)