I have a web application written in Flex and I'm trying to build an AIR application from the same code base using conditional compilation.
In the AIR application, I need to have import statements such as the following:
import flash.data.SQLConnection;
import flash.filesystem.File;
but I cannot have these import statements in the web application because they are AIR only classes.
I thought I could use conditional compilation to overcome this issue but then I read the following on page http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7abd.html:
"You cannot use constant Boolean values to conditionalize metadata or import statements."
If that's the case, how can I have common codebase for Flex based web as well as desktop applications? Has anyone solved this conundrum?
Thanks,
Dilip
More on this question after some trials and errors...
I have 3 projects in Eclipse for this project... one for web application, one for AIR application and one for the common source code. In the web and AIR project, I point to the common source code. In the common code, I used conditional compilation and it looks like you can do something like the following:
CONFIG::desktopMode {
import flash.data.SQLConnection;
import flash.events.SQLEvent;
import flash.events.SQLErrorEvent;
import flash.filesystem.File;
}
and similar approach to include web or AIR specific functions during compilation. The approach seems to have worked so far!
The only place I have run across issues is in my Cairngorm's model locator. If I put CONFIG::desktopMode around import statements in Cairngorm's model locator, it starts giving "Uncaught exception in compiler" or "1131 classes must not be nested" error. I'm not sure how to address this error!
Dilip
You can avoid imports referring fully qualified class names in code. This way you can use conditional compilation.
A common 'codebase' isn't really the situation. Your common codebase is the views and such, but from your Flex to your Air application, your business layer changes. For this, I would recommend you create 2 different projects (one for web, the other for air) and have a library project for all common components, classes, whatever, that can be shared between the two.
It's impossible to have a class like you're saying that says 'if flex, only use this code; if air use this one' since the air SDK adds extra functionality and just saying 'import this' won't work because you also need to remove all references to that import which makes it unreadable.
You need to architect your project properly so that you can separate and abstract out most classes so they can be used for both projects, and then within each project have their specific implementation. Using an application framework like Parsley might help you to accomplish this; I know it helped me.
You can always switch to some full preprocessor like M4 and build your program using normal build tools and not the IDE.
Related
When I am migrating the flex to royale application , i am unable to implement the concept MDIWindow Concept in royale.
I am able to find in Visual Studio Code IDE the implementation
//Generated from: C:\RemoteObjectAMFTest\external\flexlib.swc
package flexlib.mdi.containers
public class MDIWindow extends mx.containers.Panel
but not able to find at compile time.
could you please help to compile MDIWindow successfully in royale?
col: 9 Warning: Definition flexlib.containers.MDIWindow could not be found.
import flexmdi.containers.MDIWindow; or flexlib.containers.MDIWindow
As far as I know, MDIWindow has not been ported to Royale. Your best bet might be to decide on the features you actually need for your app and implement those parts yourself. Hope this helps.
I have an play application with the following structure:
-mainApp
-app
- controllers
- models
- services
- views
-test
-modules
...
And i have a subproject in the modules folder.
Now I want to use the class Test.class in the "services"-folder in a class of a submodule (called "listadmin"). I thought it's possible with the import:
import services.Test;
But this doesn't work. I get the error (if I compile) that the system don't know the package service.
How do i import a class of the main-project in a subproject?
Thanks for help!
I think the only way you can do that is to have the sub-project dependOn the main project. Of course, the main project also will dependOn the subproject, so I'm not sure what you gain by creating a sub-project. I'm having a similar issue. I'm trying to separate my big project into self-contained smaller projects, but I need some info from the big project (the main template file so my views fit in with the rest of the application, a default URL to send pages to when users don't have permission to see pages, etc.) If I can't find that someone has already asked this question, I'm going to, so keep an eye out.
As I understand it Qt provides 2 main plugin mechanisms:
Plugins that extend Qt "Qt Extensions"
Plugins that extend applications developed with Qt
I'm interested in developing plugins for my application (2).
I use PySide but can't find any resources about developing application plugins using PySide/PyQt.
Following the C++ Qt documentation I understand that the application has to use the Q_DECLARE_INTERFACE() macro and the plugins have to use both Q_INTERFACES() and Q_EXPORT_PLUGIN2() macros but I don't know the code they represent to try and translate it to python. Or is there another way I've missed?
Update:
The closest thing to a solution I could find so far is Alex Martelli's answer to a similar question. Although it looks like it would work I'd rather use an official Qt approach to avoid any cross-platform issues.
I think Qt's plugin system is intended to allow people to write C++ plugins compiled as binaries. I don't even know if it's theoretically possible to write plugins in Python that will use a C++ binary interface like that.
If you want to support Python plugins your best bet would be to use one of the many pure python plugin systems out there. I have written a PySide app that uses YAPSY to load plugin scripts. YAPSY is a very simple, compact plugin module. It's very easy to include directly in your app as it's a single file, and is BSD licensed so you can use it commercially. Just search for it on Google. I was even able to package my app using py2exe and still retain the ability to import python source file plugins from a plugin directory.
I'm a fan of the Roll Your Own approach.
By a plugin, I mean:
Plugin: a module or package loaded during runtime which augments or modifies the main module's behavior
I see two requirements for a plugin:
Can the main module load the plugin during runtime?
Is data accessible between the main module and the plugin?
Assumptions
Developing a plugin system is highly subjective. There are many design decisions to make and there is no One True Way. The usual constraints are time, effort, and experience. Be aware that assumptions must be made and that the implementation often defines terminology (e.g. "plugin" or "package"). Be kind and document those as best as possible.
This plugin implementation assumes:
A plugin is either a Python file or a directory (i.e. "plugin package")
A plugin package is a directory with structure:
plugin_package/
plugin_package.py <-- entry point
other_module.py <-+
some_subdir/ |- other files
icon.png <-+
Note that a Plugin package isn't necessarily a Python package. Whether or not a plugin package is a Python package depends on how you want to handle imports.
The plugin name is the same as the plugin entry point's file name, as well as the plugin package directory
The QApplication's QMainWindow is the primary source of data to share from the main module
1. Loading a plugin module
Two pieces of information are required to load a plugin module: the path to the entry point and the plugin's name. How these are obtained can vary and getting them usually requires string/path parsing. For what follows, assume:
plugin_path is the absolute path of the plugin entry point and,
plugin_name is the plugin name (which is the module name by the above assumptions).
Python has implemented and re-implemented the import mechanism numerous times. The import method used at the time of writing (using Python 3.8) is:
import importlib
from importlib.util import spec_from_loader, module_from_spec
from importlib.machinery import SourceFileLoader
loader = SourceFileLoader(plugin_name, plugin_path)
spec = spec_from_loader(plugin_name, loader)
plugin_module = module_from_spec(spec)
spec.loader.exec_module(plugin_module)
# Required for reloading a module
sys.modules[plugin_name] = plugin_module
# # This is how to reload a module
# importlib.reload(plugin_module)
It's probably a good idea to include error handling and a record of which modules have been loaded (e.g. by storing them in a dict). Those details are excluded here for brevity.
2. Sharing data
There are two directions which data may be shared:
Can the main module access the plugin module's data?
Can the plugin module access the main module's data?
The main module can access plugin data for free after import (by definition). Simply access the plugin module's __dict__:
# Accessing plugin data from the main module
some_data = plugin_module.__dict__.get('data')
Accessing the main module's data from within the plugin is a trickier problem.
As stated above, I usually consider the QMainWindow as synonymous with the end-user's notion of "the application". It's the primary widget users interact with and, as such, typically houses most of the data or has easy access to it. The challenge is sharing the QMainWindow instance.
The solution to sharing QMainWindow instance data is to make it a singleton. This forces any QMainWindow to be the main window users interact with. There are several ways to create singletons in Python. The two most common ways are probably using metaclasses or modules. I've had the most success using the module singleton approach.
Break the QMainWindow code into a separate Python module. At the module level, create but don't initialize a QMainWindow. Create a module-level instance so that other modules can access the instance as a module attribute. Don't initialize it because init requires a QApplication (and because the main window module is not the application entry point).
# main_window.py
from PySide2 import QtWidgets
class MyMainWindow(QtWidgets.QMainWindow):
def __init__(self):
super().__init__()
main_window_instance = MyMainWindow.__new__(MyMainWindow)
Use a separate module, such as main.py, for the application entry point. Import the main window instance, create the QApplication, and initialize the main window.
# main.py
import sys
# Importing the instance makes it a module singleton
from main_window import main_window_instance
from PySide2 import QtWidgets
if __name__ == '__main__':
app = QtWidgets.QApplication(sys.argv)
main_window_instance.__init__()
main_window_instance.show()
sys.exit(app.exec_())
Importing the main window instance is what makes it a singleton. Creating the QApplication here isn't strictly necessary (it's a singleton, too), but feels cleaner to me.
Now, when plugins are loaded during runtime, they can import the main_window_instance. Because the main_window module has already been loaded by the main.py entry point, it's the main window used by the main module (and not a new instance). Data from the main module can now be accessed from the plugin module.
# plugin.py
# The plugin can now access the main module's data
from main_window import main_window_instance
main_window_instance.setWindowTitle('Changed from plugin')
Comments
The minimum setup requires three files: main.py, main_window.py, and plugin.py. The main_window.py defines and instantiates the main window, the main.py makes it a singleton and initializes it, and the plugin.py imports and uses the instance.
Lots of details were left out in hopes that the primary components could be made apparent. Ideally, the Qt and Python documentation should be enough to fill in the gaps...
There are further considerations, such as how to distribute and manage plugins. Plugins could be hosted remotely, packaged as (zip) archives, bundled as proper Python packages, etc. Plugins can be as simple (or as complex) as you want. Hopefully this answer provides ample inspiration for how you want your plugin system to look.
I received this warning when I migrated my application from flex 3 to flex 4:
components:MyApp is a module or application that is directly referenced. This will cause components:MyApp and all of its dependencies to be linked in with modules:searchModule. Using an interface is the recommended practice to avoid this. Unknown Flex Problem
MyApp is a class which extends the Application component and in the module named "searchModule" there's this line:
var parentApp:myApp = parentApplication as MyApp;
I then use the variable myApp to call methods defined in the MyApp class from within this module.
This warning is reported 10 times because I am doing the same in other modules.
I want to fix it but I don't understand the part "this will cause its dependencies to be linked in with modules" and how would I make an interface to avoid this? And why there wasn't a warning about it in flex 3?
Thanks in advance
I'm guessing a bit, but...
The Flex Framework is one of those special Adobe-only libraries that can be cached by the Flex player. As such, with certain compile settings, the SWF from the compiler does not contain the Flex library. In lex 4, the framework is not compiled into your application SWf, resulting in significantly smaller application file size.
If you extend the Application class, which it sounds like you done, the compiler cannot count on your new "Application" being in the cached Flex Framework and therefore must compile your new class, and therefore the Application tag into your SWF. This is going to daisy chain significantly; as the Application tag does a lot of Flex Framework setup stuff.
I assume that is what the warning means in terms of dependencies.
Did you really extend Application with additional functionality? Or is "MyApp.mxml" just the name of the your main application file?
You might try this:
var parentApp:Application = parentApplication as Application;
I believe there is a FlexGlobals class introduced in Flex 4, which can also give you access to the top level Application.
In terms of using an interface. Interfaces are designed to help remove specific dependencies. You can create an interface for your new functionality of the new Application class and reference that instead.
var parentApp:myApp = parentApplication as IMyApp
Based on my interpertation of the messages you're seeing that may address the issue.
I had this error when I had Application MXML insted of Component MXML, for example.
Changed Application to Group, in referenced Component, and warning was no more.
Reason for error was, because I worked on component in separate project as application, and later copied it to main project, but I didn't change it to component.
Anyone come across this error when trying to import a WSDL in Flex builder 3?
Seems it only occurs when trying to import a WCF based service which has 'virtual' endpoints...
Some digging around makes me think Flex has trouble parsing the wsdl (however standard web services work fine).
A bug has been opened for months and still no reply from Adobe:
http://bugs.adobe.com/jira/browse/FB-13542
I am using Flex Builder 3 and the solution found here http://poradowski.com/fb/ that was mentioned in the adobe bug base at FB-13542 worked for me. I just backed up the com.adobe.flexbuilder.axis2_3.0.214193.jar file and put the updated jar file in it's place. Restarted Flex Builder and was able to import our wsdl that had the "policy" tags in it.
This generally happens when you are using the StAX API, and you do not have a StAX implementation in your classpath. See http://forums.java.net/jive/thread.jspa?messageID=117971
I am not too familiar with Flex - but even if you are not using StAX directly, it may be using it under the covers.