|
Hello Martin. To my mind, API should be in
addition enough simple in order to make proxy classes compact (simply recall
appropriate GUI native method). I know, it really will be a lot
of work to implement all proxies for different GUI framework. But concerned to
ActionStep, AsWing and MX V2 frameworks, I think there will be no big changes
in its API in the future since it’s based on existed APIs approved by
years of using on other platforms. Also I hope GUI framework developers will be
interested to give me some help supporting proxy implementations in the future.
Iiley Chen (AsWing) already offered me some help. Regards, Igor From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Heidegger Are you sure that its a
good idea to start this way? 2006/1/24, Igor V. Sadovskiy < [EMAIL PROTECTED]>: Hello
All. I'm
going to start new open-source project called AsGuiProxy (os AsGUI). It will
provide unified interface and its implementations for different Flash GUI
frameworks. Proxy classes which implements unified interfaces will allow to
access GUI controls implemented in different frameworks. It
will allow to easy switch between used GUI frameworks only changing used
GuiProxy factory. Also it could be used as an addition to the Model-View
controller architecture for libraries, frameworks and applications. So no more
doubts which GUI framework to choose for your application evermore ;) Your code
doesn't depend on chosen concrete GUI API. For
the 1.0 version I plan to implement only visual controls utilizing support. It
means only already existed UI controls could be accessed using AsGuiProxy API
(but not created or removed). It makes sense since form layouts could be
specified at design stage (using Macromedia Flash IDE for MX V2 components or
XML markup language for other frameworks). Passing a reference of the control
to the factory I will obtain an implementation of the unified interface wrapped
passed object and allowed to access it. It will looks like: GuiProxyManager.setFactory(AswingGuiProxyFactory.getInstance()); //
and later var
combo: GuiProxyCombobox =
GuiProxyManager.getFactoty().getComboBox(aswingComboBox); So
using "combo" instance it will be possible to get access to the
Aswing's combo box through unified AsGuiProxy API. For
the next releases I'm planning to get component containers support (for all
kinds of Forms, Panels, Dialogs, etc.). Also create/remove GUI control support
will be added. Initially
I have a plan to create proxies for 4 GUI frameworks: MX V2, AsWing, ActionStep
and EnFlash. All another frameworks are welcome J But I expect for some help from GUI framework's developers (of
course if you are interested in ;) Also any another help offers are appreciated
since there will be a lot to do. Also
before starting implementation works I'd like to discuss AsGuiProxy API
architecture. It doesn't make sense to design self own GUI API and write proxy
implementations using. It will oblige AsGuiProxy users to study new API. So the
best solution to my mind it to take some existed GUI API and implement it as a
API for AsGuiProxy. It will allow to not "invent wheel" again .Also
it will be easy for users already familiar with this API to move their
applications to AsGuiProxy. So
the main criteria for used API choosing are its flexibility and popularity. I'd
like to start some discussion or voting so everybody who is interested in could
contribute their opinions and as a result find the optimal for all solution. P.S.
Especially I prefer AsWing API since I like Swing ideology and Java at all. And
everything except MX V2 API!! I think everybody already get tired with ;) Regards, Igor
|
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
