Two of our apps are web applications with a Flex 3 front end and a SOAP-style WCF back end. To communicate with the back end, I generate web service client classes through Flex Builder 3. Everything's functional, but maintaining those generated classes has been quite annoying, and I'm looking for a better way to do things (without having to do a major rewrite, of course). Here's the problems:
I use Flex libraries to manage components shared among applications. Some of them are dependent on the generated classes, so I need the WSDL-generated classes in their own library. Flex Builder 3, however, only generates the classes for a Flex application, so I have to generate the files in the application's source tree, then manually move the files every time. This also introduces strange side-effects with the way that Eclipse manages source code (why can't it just monitor the FS like other IDEs do?).
We use data binding in the MXML to declaratively tie data to the UI. I like data binding. Unfortunately, the classes in the WSDL-generated code do not support binding. Therefore, I opted to create a program to alter the ActionScript classes, adding [Bindable] metadata to them. This has to be run every time we regenerate the code.
Flex has a very nasty bug, known about at least since March, which still hasn't been fixed: http://bugs.adobe.com/jira/browse/SDK-19811. I recently discovered this, because it was double-encoding some XML characters like < and & into < and &. Therefore, I also had to add a workaround for that to the ActionScript manipulation program.
The WSDL-code generator in Flex Builder creates a String, Boolean, Int, and other classes which are built-in types! We're always having to delete these source files to prevent the Flex compiler from sometimes balking.
It seems unlikely to me that everyone is just putting up with these issues. There must be some alternative way of generating web service proxy classes for Flex that others are employing. Since I'm time-prohibited from making the communication layer RESTful and rewriting the front end in Silverlight, what do you suggest?
You can use one of several mechanisms to read the WSDL into a program and generate whatever flex code you need.
You can use one of the two ServiceDescription classes to read in a WSDL and examine its contents in terms of an object model;
You can use T4 Templates in Visual Studio with a bit of custom work to expose the WSDL to the template (possibly through the ServiceDescription class, as above)
You can use XSLT to transform the WSDL into the code you'd like
You can write some standalone program to read the WSDL (as XML or an object model) and just emit the text you want for your proxy code.
The bottom line is that, if you're having problems with the automation tools, then there are practical ways of creating your own.
Unfortunatly Flex 3 code generation from WSDL lacks from the Bindable tag, and it is a nightmare to handle that problem manually... especially if you have a complex scenario with lots of Types.
You could just add the tag manually and remove the "generated.webservices" from all variable declarations in order to make the code compile... and then you have another problem:
What if i have to generate de code again? Either i do everything again... or i will have a bunch of runtime only detected bugs...
I used ANT to a small trick:
Add Bindable to all classes;
Remove the full namespace from all variable declarations;
<target name="updateGeneratedCode" >
<replace dir="PATH TO YOUR GENERATED CODE">
<include name="**/*.as"/>
<replacetoken>public class</replacetoken>
<replacevalue><![CDATA[[Bindable]public class]]></replacevalue>
</replace>
<replace dir="PATH TO YOUR GENERATED CODE" value=":">
<include name="**/*.as"/>
<replacetoken>:generated.webservices.</replacetoken>
</replace>
</target>
Note: the replace token ":generated.webservices." may be different in your case, so you may want to replace it by your generated namespace.
It is working for me so far.
Hope it helps someone!
Antonio Inacio
Related
I have this service: https://mnavwcfservices.stcenergy.com/FlexProcurementService.svc?singleWsdl
I am trying to use this inside Delphi XE5
I have used the WSDL Importer
The generated file is here https://www.stcenergy-online.com/dev/service.txt
Although the top level classes have been generated correctly, the lists are using list of AnyType
How do I get the correct classes to be generated?
One example is ClipMonthSummaryLine - this is in the wsdl file but does not make it into the generated file by the WSDL importer which I think is why the ArrayOfType has come in
This appears to have been caused by the use of interfaces in the C# classes
This is an absolute nightmare for me now as I never have lists of concrete classes but I think I can get round this by creating new classes that use concrete lists and mapping the data
Sir Rufo's response suggested using the Web Services Toolkit as opposed to the default WDSL importer that comes with Delphi. Although this looks very good it has proved to be a total nightmare to use to the point I may have to raise a new question about it. My new problem https://stackoverflow.com/questions/25961758/list-not-loaded-correctly-from-soap-message-wcf may have been caused by the default importer as well, but getting the files generated by the toolkit to work in Delphi is a nightmare and the documentation is not as good as it first appears.
So far I have two short questions:
1) What precisely are the benefits of creating custom nature?
2) Is it possible to somehow programmatically read files in [project]/.setting or [workspace]/.metadata/.plugins?
I'm using Eclipse Helios (3.6).
Ad 1. I've read that you can't have two natures ofthe same set, that you can use it to associate certain perspectives/tools (ex. builder) with it but well.. anyting else I can't do easily without nature? Ex. I can easily add a builder by modifying an IProject variable.
Ad 2. I tried to find a way to read project specific settings or plugin settings but failed. No specs, different file types, inconsistent XML tags... Is it at all possible without parsing them manually?
Thanks for your help!
Paweł
Think of a nature as a flag. All project-related functionality in Eclipse is triggered by natures. Project properties pages, context menu items, etc. appear based on presence of natures. Third parties can check for presence of nature to tell if the project is of certain "type". A nature also has install/uninstall methods. This gives you a convenient place to implement all actions that need to happen on the project when your technology is enabled. Why is that convenient? Because a third party can simply add the nature without knowing what else is necessary to configure and your code takes care of the rest.
Plugins write to [project]/.setting or [workspace]/.metadata/.plugins locations in different ways. The file formats are never documented as they aren't meant to be manipulated directly. Some plugins re-use the common ProjectScope and InstanceScope classes to read/write the data. Some read/write on their own. I would start with what information you are trying to read, figure out which plugin it belongs to and then see if there is public API in that plugin for accessing that information. Reading these settings directly is almost never going to be the correct approach.
Suppose I am working on exposing some of my server-side classes to a GWT application, but certain parts could be done much better using GWT-specific components (like JSNI, for instance).
What are some techniques for doing so without being too hacky?
For instance, I am aware of using a subpackage and using the <super-source/> tag, but this requires the package names to be different, which causes eclipse to complain. The general solution in the community is to then tell eclipse to use that as a source folder, but then eclipse complains about there being two classes with the same name.
Ideally, there would just be a way to keep everything in a single source tree, and actually have different classes which apply the alternate implementations. This would feel like a more OO approach.
I would like to add a suffix to a class like _gwt which accomplishes this automatically, and I know I could write a script to do this kind of transformation, but that is a kludge for sure.
I've been considering using Google's GIN/GUICE libraries for my projects in general, and I think there might be some kind of a solution there, but I am not sure as I have not thoroughly investigated it.
What are some solutions you have tried in the past on GWT projects?
The easiest way to have split implementations is to use super-source code, but only enough to instantiate a uniquely-named instance or dispatch to a different method. Ideally, the super-source implementation is just a few lines long, and not so bad that you can't roll it by hand.
To work around the Eclipse / javac double-mapping and package name issues, the GWT source uses two top-level roots for user code: user/src and user/super. For example, the AutoBeans package has a split-implementation of JSON quoting and evaluation, one for the JVM and one for the browser.
There's really no non-kludgy way to implement super-source, as this is a feature way outside what you can specify in the language. There's nothing that lets you say "use this implementation in this environment" without the use of some external tool.
Looking to format (automated, in application) some html / nvelocity templates. Tidy seems to be the answer for this, however all the .Net ports seem to be problematic and not very well maintained. Most rely on unmanaged code under the covers and that starts imposing other restrictions on the project.
For example, to use the code associated with http://www.codeproject.com/KB/mcpp/eftidynet.aspx, the projects now has to be a x86 build.
Is there a new preferred solution for doing this? Or is there a completely managed port of TidyHtml that understands nvelocity or allows custom token definition?
Let's list them:
EfTidy
ZetaHtmlTidy (mixed-mode, so it needs different assemblies for x86/x64)
tidyfornet (managed assembly but depends on external HTMLTidy native dll)
TidyATL (ATL wrapper, old, unmaintained, I think it's also mixed-mode and it even requires COM registration?)
TidyNet (fully-managed DLL, no external dependencies)
Even though it's old and unmaintained, I'm using TidyNet because it's fully managed. Does the job just fine.
BTW: Tidy and NVelocity are completely unrelated. I'd never process NVelocity templates with Tidy as it will probably break them... However you might want to run Tidy to the resulting html after processing the NVelocity template.
Like a lot of things, I'm sure there's a good reason for this, so please help me understand...
Why, by default, do WCF services store settings in app.config?
This has been so frustrating trying to work with multiple Silverlight class libraries. These class libraries are supposed to be completely independent from each other, and this dependency on the app.config seems to cause the following headaches:
Single Responsibility Principle - I should be able to add a reference to a class library and go. If that class library uses a service reference, this idea is shot before I even start coding against it.
Muddy Configuration - To get other libraries to work, I have to copy and paste the service configurations into the "main" application configs. If an endpoint changes in any way, I can't just worry about a new version of that class DLL - I have to worry about anything that uses it, too.
Complex Alternatives - Programmatically creating the endpoint isn't pretty. Period.
There has to be a better way. Why doesn't WCF at least separate the service configurations into a ServiceName.config or something that gets copied to an output directory. What am I missing? How do you deal with this?
Because the alternatives aren't pretty either. The problem with "ServiceName.config" is that ServiceName also needs to be configurable.
The root problem is having Service references in libraries to start with. And a library component cannot dictate a binding for an App. So your SRP argument does not hold.
I concur with #Henk - library assemblies shouldn't have WCF references. If for some reason it does require one, i would use dependency injection, and pass the service reference in to the library function - this is vitally important for maximum testing benefit.
I also don't buy your argument of "Programmatically creating the endpoint isn't pretty". Creating and assigning an end point is just a couple of lines of code, and is a technique i use almost exclusively with my Silverlight components (e.g. if no address is specified within the ServiceReferences.ClientConfig file then i fall back to known service locations within the hosting application, in which case those endpoints are programmatically created).
Basically, if you don't mind the couple of lines of code required to programmatically create an end point, then you can store your address details anywhere, in any config file. You only need to store the addresses in the app.config if you are going for a purely declarative approach.