Importing an XML data (tree) file

[superticker]

I needed to make some global spelling changes in one of my Form Letter Machine data files.  So I exported it as an XML file and made the global substitutions in my XML editor. Now I'm trying to figure out how to import the edited XML file back into The Form Letter Machine. The Form Letter Machine seems to open with the old binary data file even when I click on the newly edited XML data file. How do I import the newly edited XML file?

[mouser]

tflm doesn't support xml import (yet).. you can use the exported XML with tfdocs.com.

importing xml back into the form letter machine is more troublesome.. and there is a question of whether i should re-write a Form Letter Machine 2 from scratch, rather than try to improve it around the edges.

[superticker]

tflm doesn't support xml import (yet).... importing xml back into the form letter machine is more troublesome...

-mouser (November 10, 2010, 11:00 AM)

Most SQL interfaces/databases can go either way. I'm not sure why the database for TFLM would be different.

... and there is a question of whether i should re-write a Form Letter Machine 2 from scratch, rather than try to improve it around the edges.

-mouser (November 10, 2010, 11:00 AM)

So what are the issues surrounding this question? What's wrong with the current design for extensibility, and in what way would a new design architecture be more extensible?

Were you going to switch to a different SQL database that supports XML imports/exports in both directions? Would this new SQL database also be used in other DonotationCoder applications (including JavaScript Web 2.0 apps) enabling collaboration? (Did some users request groupware features?)

The current program works well for my needs.

[mouser]

The tfdocs.com web service was designed to do what The Form Letter Machine does, but is much more flexible and powerful, and uses xml as its native format.

But users having to hand craft the xml data for it has proven to be it's main downfall (at least that's my interpretation, along with the normal downfall for me which is no energy or resources to spread the word about it).

The Form Letter Machine is easy (though not 100% intuitive) to create new trees with, but is somewhat limited and simplified in what you can create, and uses a proprietary tree data format which is not well suited for adding functionality.

So i think the "proper" solution would be to rewrite The Form Letter Machine to use the same xml native data as the online version, and make it suitable for the advanced features.  I'm just a bit torn as to the best way to do it.

One way that might make the most sense would be to:

• Use the same native xml format and language for the desktop version
• Support the same features in the desktop version as the web version
• Use an embedded web browser in the desktop version to display the tree and contents of the resulting document
• Use a custom tree configuration editor, similar to the one in the current Tree Form Machine.

I'm just nervous about using the web technology in the desktop version, but on the other hand there are lots of neat things you can do with the web version that would be nice to bring into desktop version, and i really don't want to be maintaining two separate systems.  Having a single shared data and rendering system just seems more sensible to me.

[mouser]

Let me elaborate a little:

I've discussed with a couple people the possibility of making the Form Letter Machine / tfdocs.com more useful.

The online tfdocs.com felt like it had some great potential to me, but was just a complete flop in terms of people actually using it.

So i'm trying in my own mind to figure out if there is some potential for these programs to find a somewhat wider audience, and if maybe there is some way for me to secure a little bit of funding in order to take them to the next level, possibly making them more useful for business users.

[superticker]

... nervous about using the web technology in the desktop version, but on the other hand there are lots of neat things you can do with the web version that would be nice to bring into desktop version, and i really don't want to be maintaining two separate systems.  Having a single shared data and rendering system just seems more sensible ...

-mouser (November 10, 2010, 01:24 PM)

I would maintain a single source-code base regardless of what you do.

There are two very different options:
1) There are some tools that will turn a desktop application into a web application. They work okay, but you have to install a special run-time library.

2) Since most people already have the Java virtual machine installed, it may make more sense to just use Java coding for everything. The Web side can do everything in Java applets or beans. And Java has a nice database facility to work from. My only concern is:

2a) Java applications execute very slowly.
2b) I'm not sure where Java is going now that Oracle owns it.