DIGG IT! The XTreeM editor made another big leap this weekend as I added input filters to several controls and fixed several bugs. XTreeM just passed 300 installs in only 7 days!&
The goal of XTreeM is to provide an editor for rapid/valid XML editing. If you author XML within XTreeM, it should be very difficult to create invalid XML. Any case where invalid XML can be created in XTreeM is a bug and needs to be reported. If you find one, simply paste the invalid XML into the bug form. Special thanks to all the people who have reported bugs in the editor.
I am also working on open XML editing in the textPane. Currently you can only edit TextNodes, CDATA, and Comments but soon you will be able to edit the XML directly. When the XML is edited directly the node will be reparsed prior to adding it into the model. Should there be an error in the edited XML, an error dialog will occur allowing you to fix the error prior to model modification. This will be in the editor before 0.950. Thanks to Peter Hall for this suggestion.
I am also almost done with a new XML subclass called XMLCache that provides node caching. With node caching a snapshot of formatted XML output is stored in each node as text. When a node is modified all parents are marked as dirty forcing the class to rebuild the dirty nodes when they are viewed. When a parent node is viewed, only the dirty nodes are reparsed making XML output over 20X faster. For larger XML documents this eliminates almost all of the performance problems in using the Flash Player.
0.938 Changes:
1. Element Names are filtered in data input.
2. Attributes are filtered in data input.
3. Controls are disabled when selected node is closed in Tree.
4. Attribute deletion selects the next value.
Several people have asked me why I built XTreeM. Here it is:
1. I wanted a better XML editor as most editors are simply glorified text editors. These editors provide great data editing but XML is 80% structure and 20% data. The XTreeM tree view allows you to see the structure of an XML document and edit documents through this view. It provides a powerful paradigm to edit XML allowing rapid modifications that are just not possible or safe with plain text based editors.
2. Most new data formats are based on XML. XML is the base storage format of many applications including Flex, ITunes, Flash, MS Visual Studio, Office, RSS, Atom, Web Services.
3. New Flash or Central applications can inherit from XTreeM. Almost 100% of the code used in XTreeM is reusable and I plan on using it in company and consulting projects. By focusing on XML 1.0 in Xtreem the quality will cascade into other projects reusing its core.
Happy editing, More to come!
Ted ;)
Ted- hadn't seen this before-very cool app. Very smooth. I've been doing a lot of xml creation for Poket PC apps and this could fit in nicely. I was curious if you ever used XMLspy? I have found it to be a good editor for the structure side of things. Have you thought about a way where an xml object in flash could be roundtripped to your app for editing and back? I know that it should all be external but in most prototypes it is easier to just stick it in the swf and if you get the job then pull it out for full scalable solution. THis prevents your client from not having all the files needed during a sales call. What would even be better would be a way to launch your app with a xml file that is set to be loaded by Flash actionscript. Just tossing ideas out so you can disregard any that are nuts....
Thanks! I have used XMLSpy but I found it overly complicated for simple XML editing tasks:
1. TextView (Node Folding) is confusing. It takes the whole XML document and folds around nested nodes. It is still difficult to see the overall structure of the XML as the contents distort the view.
2. Enhanced Grid View is also confusing. It takes nodes and puts them into an editable grid. It requires allot of scrolling to see larger CDATA Nodes. Again the XML Node contents get in the way of seeing the XML structure.
3. XMLSpy is 21.MB larger than XTreeM.
4. XMLSpy is not cross platform. So no MAC. ;(
Also given the feature set for XMLSpy it is tough to compare these 2 products. XTreeM is just a different approach.
On editing XML running in the Flash Player, I believe that this is not possible as Central apps run within a domain so localConnection doesn't work. Although there may be another way to do this.
One thing that might be nice is to provide a view of the Flash XMLObject from an input XML file. The tree view would allow you to navigate the strucutre of the XML Object and see the internal structure. Since MX the strucutre has been completely hidden from view making XML more difficult to work with. How can you modify what is difficult to see?
Let me see what I can do. Ted ;)
This post has been removed by a blog administrator.
Hey Ted,
I found XTreeM to be quite useful in the past and I really liked how the editor worked. Now that we have Flex and Apollo at our disposal, I was thinking it would be cool to port or update XTreeM to Flex to build an Apollo app.
Would you be willing to release the source for XTreeM for this purpose?
Thanks!