Home | Blog | Software | Reviews and Features | Forum | Help | Donate | About us
topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • September 02, 2015, 09:54:40 AM
  • Proudly celebrating 10 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Importing an XML data (tree) file  (Read 3232 times)

superticker

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 138
    • View Profile
    • Superticker's SU reviews about technology
    • Donate to Member
Importing an XML data (tree) file
« on: November 10, 2010, 10:57:24 AM »
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

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 34,981
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Donate to Member
Re: Importing an XML data (tree) file
« Reply #1 on: November 10, 2010, 11:00:36 AM »
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

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 138
    • View Profile
    • Superticker's SU reviews about technology
    • Donate to Member
Re: Importing an XML data (tree) file
« Reply #2 on: November 10, 2010, 01:16:23 PM »
tflm doesn't support xml import (yet).... importing xml back into the form letter machine is more troublesome...
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.
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

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 34,981
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Donate to Member
Re: Importing an XML data (tree) file
« Reply #3 on: November 10, 2010, 01:24:32 PM »
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

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 34,981
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Donate to Member
Re: Importing an XML data (tree) file
« Reply #4 on: November 10, 2010, 01:32:03 PM »
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

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 138
    • View Profile
    • Superticker's SU reviews about technology
    • Donate to Member
Re: Importing an XML data (tree) file
« Reply #5 on: November 10, 2010, 02:02:28 PM »
... 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 ...
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.