Blog Topic List

This week went by too quickly.  Just as I was getting caught up from last week’s email it’s time to go again. Yep, I’m on vacation again next week.  Hoping for just a little less rain this time. 

In the mean time, I thought it would be helpful to share some of the blog topics I have on the backburner. 

  1. A closer look at script objects: Explain how script objects work internally.
  2. Coding style guide: I am interested in improving the readability of JavaScript code.  What can we do in terms of object/variable/function naming and general form organization to make our forms easy to grok by others.
  3. Multiple records: Did you know you can have multiple data records in your PDF?
  4. DataDescription Deep Dive: When you base your form on an XML schema or sample data we generate a data description.  The data description used at runtime to format instance data correctly.
  5. Enhancements to debugger, lintcheck: Since I’ve put these samples out I’ve been collecting a list of enhancements and bug fixes.  Just need time to implement them.
  6. Form/Fragment Version Control: When I distribute a sample, I need a way to be able to let you know when an update is available.  I’d like to have a mechanism where the form can "phone home" to discover updates.  I bet some of you have similar issues with forms you distribute to your users.
  7. Working with rich text: rawValue, saveXML(), non-standard <span> attributes, editing rich text with E4X, controlling tab stops and page breaks dynamically
  8. Debugging Performance Issues: Got a form that draws too slowly?  It’s not always easy to discover why.
  9. Locale support: XFA has terrific support for multiple locales.  Explore how you can tap into this capability.
  10. Table Joins in your data: How do you cope when your XML data has id references to other elements and you want to "join" between those "rows"?
  11. My experience

This isn’t the full set of topics, but it will do for now.  What looks interesting to you?  Are there topics you’d like to see covered that are not on this list?  Let me know.

6 Responses to Blog Topic List

  1. Bruce Robertson says:

    Hi John,I would like to understand more about script objects. We have a number of Script objects containing JavaScript objects but to get them created we have to assign the constructor function in an event handler before it can be used. For example if my script object (called scoTest) contains;var Class = function TestObject(){this.property1 = “a property”;this.property2 = “b property”;}Class.prototype.join = function(){return this.property1 + ” and ” + this.property2;}My button event becomes;var scoTestClass = scoTest.Class;var scoTestObject = new scoTestClass();app.alert(scoTestObject.join());Is there a better way?Also we can’t set breakpoints in a script object so we often develop them in an event handler and then copy it to a script object but this is a pain when it comes to amending things and the variable scope seems different so there’s often some surprises.Multiple records sounds interesting can you have a window (or cursor) on the data source, maybe displaying five records at a time scrolling.Other things I would appreciate help with;All our forms use web services for submission; this is so we can provide a response to the user within the form. We also use the Acrobat JavaScript web submission api that we have found easier to use as it returns a JavaScript object. Are there any disadvantages over the XFA data connection? Anyway a lot of our forms have attachments which we currently submit to the web service as an array of hex encoded strings. I would be interested in an example of using MTOM which is referenced in the Acrobat documentation but without examples and all my attempts have failed.We use hex encoding because we couldn’t get base64 encoding working for binary data;SOAP.stringFromStream(Net.streamEncode(SOAP.streamFromString(‘sampletext’), ‘base64’))Returns “c2FtcGxldGV4dA==” … which is fine.But if you trySOAP.stringFromStream(Net.streamEncode(SOAP.streamFromString(‘sample\x00text’), ‘base64’))You get “c2FtcGxl” … it seems to stop at the first null characters and in a binary file (like a PDF) you could to get a null character anywhere.I would also be interested in suggestions for handling source control of a form. Currently we save the XDP version of the form in our source control but this seems to contain a lot of Designer settings or that differ from user to user which complicates tracking changes, let alone tring to merge changes from two developers.Could you also explain why we get the erratic movement of the scrollbar as JavaScript executed and if there is a way of avoiding it seems worse for disabling/enabling fields than showing/hiding fields which surprises me.We use XML Schemas to define our form data and we use appinfo element of the annotation schema element to drive our server side validation exception handling. We had hoped to be able to do the same style of processing on the client side (in the form). But I’ve not been able to work out the SOM to access the schema which I can see in the XML Source.Thanks again,Bruce

  2. Dick Wyman says:

    Suppose I want to provide field name, type and size information to compositors in such a way that the forms they compose reserve space appropriately. What is the best way to provide that data? I thought the simplest way would be to create an XDP stream with a data package such that whey would open that stream and add the form while extracting field information. Does that seem appropriate?

  3. Bruce:Thanks for the feedback. All good comments. I will try to address them individually when I get to those topics.The one thing I can say right now is that I believe the null termination of the SOAP string is a known issue. I think I have a sample somewhere that will base64 encode a stream. I think it worked, but was slow on large streams. I’ll see if I can dig it up.John

  4. Dick:I’m not sure I understand your scenario exactly…But assuming your context is that you’re processing a template on the server or in designer, then it should be possible to write JavaScript that modifies your template based on your field data.Some of this is described at: I’ve missed your intent, maybe you could describe your scenario in a bit more detail…John

  5. Dick Wyman says:

    John,I want to get a form back from composition where each field has its attributes set consistent with a central definition. This is pretty easy to do using fragments when the field is placed independent of text. However, when the field is embedded in text, the Insert->Floating Field option just gives me a field with no help text, length or data type. I can re-name the field and set its attributes, but I want that to happen automatically.My compositors don’t want to edit XML, so I’m limited to what can be done from the design UI.I could do some post-processing, but that prevents the compositor from getting a WYSIWYG view while laying out the document.Is there a way to embed a script in XDP and execute it during the design session?

  6. Dick:Unfortunately the current Designer interface for inserting floating fields is pretty limited. The only option for running script in Designer is the method I described in my previous comment. The disadvantage to that approach is that your user needs to save/close/reopen in order to see the results of the script.The good news is that script inside Designer is an area we are currently prototyping. But this functionality is not available in any shipping product.John