This post is part of a series, this being the fourth, and last
part, if you're interested,
read the first part here,
the second part here, and the
third part here.
In the previous part, I told you how I rendered the material
template to the client, using XSLT, JavaScript, jQuery and jQuery
UI. This time, I'm going to show you how I get that data back to
the server for generation of an actual PDF. This is where the
"ClientObjects" come in, might be a stupid name for them, but there
are three different kinds of objects in play, and that was the best
name I could think of at the time.
In .NET I have 2 kinds of objects, ClientObjects and
DataObjects. Again, naming isn't my strong suit. Basically, the
client (the UI), knows of one type, and that's the ClientObjects,
they are small, lightweight and versatile, in the way that they
have a Data property, that contains XML, so I could send whatever I
wanted with it. Essentially, the JavaScript version of the
ClientObject is the same as the .NET version of it. Why? Well, I
get instant, no hassle, deserialization, of the object into .NET.
But I'm getting ahead of myself.
The communication is done via a WCF Service, that expects JSON
serialized data, and since I have jQuery on the client side, I
simply serialize my ClientObject to JSON, and send it to my service
with the jQuery ajax() method, leaving my user experience
intact.
Once the actual data is on the server, I convert it in two
steps. Basically the idea was to minimize the data sent between the
client and the server, and to ensure that if one part was to be
replaced later, it could easily be done without having to change
everything else.
In the conversion from a ClientObject to a DataObject, the
properties in the ClientObject are validated against the data
stored in Umbraco, and it's also made sure that properties that the
editor has disabled editing of, aren't modified, and if they are,
reset their values to what the editor set them to, this is mainly
done by mapping properties, and converting values, from one data
type to another. It's also here that certain values from the
client, e.g position, is converted from a percentage, to a fixed
point value. This was done so that the preview area could have the
same size, regardless of the size of the material being edited. I
accomplished this by setting the preview area to 420x595 pixels. As
a coincidence, this just happens to be the size, in points, of a
portrait A5. From there it's just a matter of knowing the algorithm
for converting between An sizes, and you're all set.
Once we have a DataObject, an object that contains all the
aspects of what output should be generated, we're ready to generate
a PDF from that. Again, conversion is done into the objects that
DynamicPDF understands, but could just as easily be done for any of
the other components I mentioned earlier, provided you want to work
around the whole bottom-up issue.
Once the PDF is generated, it's all just a matter of saving the
file to disk on the server, where it can be accessed by the client,
and returning the path to the client. It's really simple
actually.
In closing, I would like to mention that this project was very
fun. Albeit, not very structured and thought through, it gave me
the opportunity to learn a lot. Since I developed this entire
application in five weeks, there where a lot of corners that were
cut. Since then, I've developed a new version, with far more
thought going into the design of things. It will feature a new UI,
built using Adobe Flex, and the architecture of the server side is
very modular, enabling easy extension. It has been built using
Umbraco 4.1 as a template engine, but the communication between the
server and the UI is done with Flex Remoting, using
FluorineFx. It will be totally awesome once it's ready. I've
been given permission (since I don't own the code) to showcase that
at Codegarden '10, if I can only
muster the courage to speak in front of so many people. If you're
attending, and interested, please let me know.