PDA

View Full Version : FusionPro and versioning?


esmith
November 6th, 2012, 08:22 AM
Has anyone else taken the plunge and incorporated versioning into their FusionPro projects? Is there a better way to incorporate the two rather than by using external JS files (as functions)?

Assuming I go the route of external JS, does anyone know if it's possible to extract the FusionPro terms from the FP software (or provided directly by PTI) to be added as a custom library to a 3rd party code editor?

Is this a futile idea and I'm just wasting my time looking into it? :confused:

Dan Korn
November 6th, 2012, 09:11 AM
Can you explain more about what you mean by versioning?

esmith
November 6th, 2012, 09:44 AM
Can you explain more about what you mean by versioning?
The developers creating/maintaining our custom front end solution use a GitHub repository for keeping versions of their codebase. They keep the primary code for the portals and then fork off those repositories (can you tell that I don't fully understand the lingo yet?) to make changes locally before committing to the original.

My manager has suggested that a similar setup might work for the FusionPro side as well. From what I can see, git does handle binary (PDF) files, but it doesn't "see" differences between two PDF files with changes to FP (rules, frames, etc). It seems to me that the real benefit of versioning on my end would be for changes to JavaScript rules, and the only way I can picture "capturing" the changes would be to move the code to an external text file (.js).

Of course, I don't want to lose the helpful "building blocks" for the FP-specific syntax so the jury is still out on whether FusionPro and Git are a match worth pursuing...

Dan Korn
November 6th, 2012, 01:02 PM
The developers creating/maintaining our custom front end solution use a GitHub repository for keeping versions of their codebase. They keep the primary code for the portals and then fork off those repositories (can you tell that I don't fully understand the lingo yet?) to make changes locally before committing to the original.

My manager has suggested that a similar setup might work for the FusionPro side as well. From what I can see, git does handle binary (PDF) files, but it doesn't "see" differences between two PDF files with changes to FP (rules, frames, etc). It seems to me that the real benefit of versioning on my end would be for changes to JavaScript rules, and the only way I can picture "capturing" the changes would be to move the code to an external text file (.js).
Okay, I see. As a developer, I can appreciate wanting to keep versions and track changes, especially to code, in a source control system.

You could certainly check in changes to external .js files to source control. However, that's only one aspect of the FusionPro template. You also have the layout (the .dif file), data definition (the .def file, with resources and data file properties as well as rules), and composition settings (the .cfg file). All this information is contained in the template PDF file, but if you do a Collect, then you could check in the .dif, .def, and .cfg files as text files. You still would need the background PDF, which is a binary resource, as well as any other graphics used by the job, that that would at least get most of the information into text-based files which are easier to manage and do "diffs" and merges with a source control system.
Of course, I don't want to lose the helpful "building blocks" for the FP-specific syntax so the jury is still out on whether FusionPro and Git are a match worth pursuing...
I'm not sure what you mean here. The Building Blocks still works for all the FusionPro-specific functions, even if you're using external .js files for your own functions.

esmith
November 6th, 2012, 01:18 PM
I'm not sure what you mean here. The Building Blocks still works for all the FusionPro-specific functions, even if you're using external .js files for your own functions.
If I used external .js files, I would be creating them in a 3rd party editor, correct? I assume that FP syntax (FP-specific objects and functions) would not be highlighted outside the default FP rule editor.

I would be interested in knowing if there was any option to "export" the FP object library to be used as a custom library in another code editor (assuming said editor allowed for that type of customization) so that I would still have the benefit of color coding and term recognition that I have in FP's local environment.

Dan Korn
November 6th, 2012, 02:08 PM
If I used external .js files, I would be creating them in a 3rd party editor, correct? I assume that FP syntax (FP-specific objects and functions) would not be highlighted outside the default FP rule editor.
Correct. The Rule Editor in FusionPro has a custom list of keywords which are used for syntax coloring and code completion.
I would be interested in knowing if there was any option to "export" the FP object library to be used as a custom library in another code editor (assuming said editor allowed for that type of customization) so that I would still have the benefit of color coding and term recognition that I have in FP's local environment.
There's no officially supported way to do this. That said, you could write your own logic, in JavaScript, to interpret BuildingBlocks.js and then iterate all the members of FusionProObjects and FusionPro.Builtins, which is basically what FusionPro does internally to build both the Building Blocks dialog and the list of keywords for syntax coloring and word completion in the Rule Editor. You would then have to figure out how to "register" those keywords with whatever editor you're using. And, of course, you still wouldn't be able to validate any of your JavaScript logic using any FusionPro-specific functions or objects, as the actual objects and functions would not be present in your JavaScript context.