The XStandard development team just let me know that XStandard v2.0 is now a publicly available product. For those of you who don't know what XStandard is, it's the leading WYSIWYG XHTML editor around. Last year, I wrote a ColdFusion version of their web services. It looks like I am going to have to update that library to cover all the new cool stuff that is available.
Looking For A New Job?
- 7 Year Lead Programmer with MSSQL expertise to assist in live website at Atprime Media Services
- .Net Developer at LendingUSA
- ColdFusion Application Developer / Portland Oregon at DealerPeak
- Web Applications Developer at University of California, Davis
This is great news. I've been looking forward to trying this out for a long time. As much as I like FCKeditor and appreciate Adobe's efforts to include it in CF8, I think XStandard still does a better job and generating semantic, valid code.
Thanks for passing on the news, sir!
Yeah, the best thing about the other editors is that they are free, and XStandard costs for a license. However, it gives you so much power, I don't mind paying for it.... now I just have time to explore all the new features... on top of looking into CF8... Ugggg! Need more time :)
I've got the same problem. To much to learn and not enough time!
So they want me to pay for something I can get for free, that doesn't even work on Linux ?
Did they not pay attention to the tail end of the 20th century ? If it's going to be on the web, it needs to work on all of the web, esp. the bits the geeks are using (because it's the geeks who often drive adoption).
First off, I am not sure that what XStandard gives you, you can necessarily get for free. Yes, there are a number of other free WYSIWYG editors, but I am not sure that they provide the exact same range of functionality that XStandard provides such as automatically stripping out xhtml-non-compliant tags and inline style attributes (thereby forcing your code to be xhtml compliant (at least more so)).
Now, I am not saying that XStandard provides all the functionality that the other editors give you. All the editors are different. I happen to love this one. To each his own. I think what also come with the tail end of the 20th century, as you say, is also diversity. Different solutions for different problems. This solution does not work for you, but it works for me.
Also, I am confident that it will be up and running on Linux eventually. At first it was just Windows. v2.0 now works on Mac. I but you that Linux is in the pipeline somewhere.
Well, XStandard offers some functionality in the Commercial version that you can't get for free. It'll allow background uploading of images via a Web Service. This means you can cut-n-paste a Word document that has embedded images and it'll upload all the images to the server automatically. You can also paste images stored in the clipboard into the editor and they're automatically uploaded.
This is one of the core reasons we went with XStandard. We wanted to build an application that made it as intuitive and easy as possible to get existing documentation to the web.
I just got some unfortunate news from XStandard's support. It turns out that v2 is incompatible with v1 license files. This means that if a customer upgrades to v2 and your site is still running a v1 license file, the customer will get a license error message and v2 will only run in v2 "lite" mode (the free version.)
I wasn't expecting to get v2 functionality with a v1 license file, but I was expecting for the v2 client to honor the v1 license file (and provide the functionality in v1.)
Since you can't run both versions simulates, this could some problems with web sites using different versions of the client.
That is certainly not good news. I wonder if there is an upgrade discount on the new license file... did you look into cost at all or hear anything?
I completely empathize with your frustration of having to pay for something when there are so many good alternatives available for free. FCKeditor is an example of a very good editor with loads of features and a huge development user support base.
That being said, most editors like FCKeditor work their magic by tapping into the browser's inherit editor capabilities. Since most built-in editor capabilities produce bad markup (e.g., IE's), these editors have to employ a great deal of JS Jujutsu to work around their failings. Even so, there are still sometimes inconsistencies between the same editor on different browsers, and the resulting markup is rarely properly structured and accessible.
Perhaps for that reason, the resulting XTHML isn't always valid and it is very difficult to ensure semantic structure in the markup.
I run a web site at http://mdcap.org/ with a full CMS employing FCKeditor and I *constantly* have to go back and fix the markup generated by the users.
XStandard addresses this by eschewing the browser's built-in editors in favor of a plug-in model. They're not alone in this approach, but to their credit, XStandard was designed from the ground-up as an XHTML-compliant editor with accessibility features built in. The end result (or the desired end state, at least) is an editor that makes it much harder for the user to create invalid, inaccessible markup.
Sorry for the long-winded response, but I realize there is a lot of confusion out there as to why one should consider purchasing XStandard when there are plenty of free alternatives available. I use FCKeditor myself, but I consider the release of XStandard 2.0 to be a Good Thing (tm).
As far as upgrading, I'd recommend contacting Sales. :) We talked about upgrade paths before purchasing our licenses since v2 was already announced (although in private beta) when we bought.
The issue that I see is users visiting websites that have licenses for different versions of XStandard will cause one of the sites to break in functionality.
Once a user upgrades to v2, any sites he visits which only have v1 licenses will only operate in "Lite" mode--which means automatic uploading will break.
Granted, right now I don't think the install base is XStandard is high enough that it's a very likely scenario, but if they want XStandard to be more widely implemented, they need to work this type of stuff out before the next release.
Yeah, agreed. Or it we could put something in the <object> tag that would actually tell it which plugin to run. That way, someone could have v1 and v2 plugins installed in parallel or something.
Well, that's what sucks. You can't run both versions at the same time:
It was reading that page that lead me to open up the support issue. Their solution is to use different browsers. That might work for Development testing, but Customers aren't going to buy into that.
I suggest XStandard users talk to firstname.lastname@example.org and express their concerns over this issue.
While they'll trying to be helpful, I don't get the feeling the really feel the issue is all that severe or one that will cause conflict with their customers.
The best solution I've seen from them is to buy both a v1 and v2 license file and push the correct license file to the user based upon user agent.
I see a couple of issues with that approach:
* As a developer, your forced to by licensing based on the version your clients might be running (which seems backwards.)
* If you force a customer to upgrade to v2, you're still potentially breaking their functionality in other sites.
While not a true apple-to-apple comparison, I compare this problem to Flash development. I mean could you imagine the headache involved if you could only develop content in Flash 6 (because that's the version of the IDE you owned) and newer versions of the Flash player/plug-in couldn't play older Flash files. It would cause all sorts of problems.
As I told support, I'm not expecting my v1 license to give me access to newer features in v2, but I do expect the v2 plug-in to work the same way it did with my v1 license.
I am with the XStandard Dev team. You raised two issues:
1. Version 1 should work with version 2 license file
This is a valid point but for technical reasons we could not do this.
2. Version 2 should work with version 1 license file with restricted feature set
I don't think any vendor does this. If I am wrong, please provide an example.
Your Flash example is not applicable because Flash player does not use a license file. And XStandard, just like Flash, can edit content created by a previous version. In the case of XStandard 2.0, the editor will simply run as Lite version when using version 1 license file so that content can be edited. They will just not have access Web services until the admin has time to upgrade the license file or setup a system to serve different license file versions based on version of the editor installed.
Dan, we do appreciate that you raised this potential problem. To date, we have not received any reports from customers who are actually experiencing this issue. If anyone is experiencing this issue, please do contact support @ xstandard.com and let us know.
Thanks for dropping by and leaving a comment - I think XStandard is awesome and I am flattered that you guys even found this blog :)
A question though, has the Web-Services development guides been upgraded to v2 yet? Or are all the SOAP examples still for v1?
Yes, the Web services documentation and examples have been updated to version 2 and there is a change log that talks about the changes made to the SOAP API.
Ben, thanks for making the CF Web services publicly available. We refer CF users to your site all the time.
It's my pleasure. I hope that I have time in the near future to start messing around with the v2.0 upgrade.
> 1. Version 1 should work with version 2 license file
> This is a valid point but for technical reasons we could not do this.
Actually, I only think v2 client should work with a v1 license file. If the new plug-in worked with a v1 license, there would be no reason for the original v1 client to work with a v2 license file.
> 2. Version 2 should work with version 1 license file with restricted
> feature set I don't think any vendor does this. If I am wrong, please
> provide an example.
Well, I can't think of a single browser plug-in that does not provide backwards compatibility.
> Your Flash example is not applicable because Flash player does not
> use a license file.
As I said in my note, I know it's not an apple-to-apple comparison, but I do see the analogy as being similar. I think the problem is your treating XStandard like the Flash IDE, where I see it as a plug-in.
If you would have allowed multiple versions of the plug-in to run in the same browser, I think it's all a moot point. However, you made the technical decision to only allow 1 instance of the plug-in to be installed.
This is the core root of the issue. If you want wide spread adoption, you're going to have to realize that not every customer is going to own licenses for the most current license of the plug-in.
As soon as one customer upgrades to the latest version, sites that rely on older license files are going to stop working for that customer.
>Dan, we do appreciate that you raised this potential problem. To date,
> we have not received any reports from customers who are actually
> experiencing this issue. If anyone is experiencing this issue, please
> do contact support @ xstandard.com and let us know.
Honestly, I'm not trying to be crass, but I think the reason you haven't had reports is because of the minimal install base. Given the minimal install base and the fact that many developers haven't begun implementing the latest plug-in probably the main reason you haven't had complaints yet.
I do really like the v1 product and have been a strong advocate of your product. I just see this move as really causing compatibility issues when trying to build web pages that rely on a plug-in that can change so drastically it breaks your page.
Do you at least acknowledge that if you build a site based for v1, that a visitor with the v2.0 plug-in can not use the site?
Do you not see that as a potential problem for customers who bought licenses for v1 for a product?
The company I work for offers an ASP-modeled solution, so we're dealing with clients who use the ASP-model. This means there's is the likely hood that one of our clients could be using another web-based product that implements XStandard. If one web-based package migrates to the newer v2 platform before the other, the other package will stop functioning and there's no good solution to give to the customer.
I'm just a developer worried that my code my break because some clients needed to migrate to v2.
- how can I insert a cfml page directly into the fcked editor. I have tried includes, try to assign the page to a variable. arrr I have cfml 7 so I am using the open source version of fck editor. - if off topic please delete, i cant find info anywhere.
To be honest, I know nothing about FCK editor.