Welcome Guest.   Make a donation to an author on the site September 02, 2014, 02:01:18 AM  *

Please login or register.
Or did you miss your validation email?


Login with username and password (forgot your password?)
Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.


You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.
 
Your Support Funds this Site: View the Supporter Yearbook.
   
   Forum Home   Thread Marks Chat! Downloads Search Login Register  
Pages: [1]   Go Down
  Reply  |  New Topic  |  Print  
Author Topic: Importing an XML data (tree) file  (Read 2641 times)
superticker
Supporting Member
**
Posts: 138


View Profile WWW Give some DonationCredits to this forum member
« 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?
Logged
mouser
First Author
Administrator
*****
Posts: 33,294



see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« 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.
Logged
superticker
Supporting Member
**
Posts: 138


View Profile WWW Give some DonationCredits to this forum member
« 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.
Logged
mouser
First Author
Administrator
*****
Posts: 33,294



see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« 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.
Logged
mouser
First Author
Administrator
*****
Posts: 33,294



see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« 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.
Logged
superticker
Supporting Member
**
Posts: 138


View Profile WWW Give some DonationCredits to this forum member
« 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.
Logged
Pages: [1]   Go Up
  Reply  |  New Topic  |  Print  
 
Jump to:  
   Forum Home   Thread Marks Chat! Downloads Search Login Register  

DonationCoder.com | About Us
DonationCoder.com Forum | Powered by SMF
[ Page time: 0.03s | Server load: 0.03 ]