|
Did you compile with –use-network=false?
I have a sample app that will be coming out where the HTML can communicate into
the SWF. And I know that the ExternalInterface was at least able to register
the callbacks out. I didn’t try making calls from the SWF out. Also have you tried putting <!-- saved
from url="" --> at the top of your HTML file? I seem to remember
that being necessary to allow local scripting. Matt From: Hi.
I would like to raise this point one last time, before the Adobe engineers lock
in this aspect of framework behaviour in the final release. Is
it really necessary to restrict the security of the Flash Player / Flex
Application model to such an extent that a flex application (SWF) located *on a users local hard disk* cannot make
calls to _javascript_ functions in its container page, also located on the same
hard disk? (I have described in the thread “_javascript_ security” my
various attempts to disprove this, to no avail). I
understand why it should be impossible for Internet based applications to
operate within a strict sandbox, which prevents them from accessing local
resources. But surely, functions scripted within the application’s
container page should also be considered to exist within the same sandbox? And
if not, how does it make sense that *Internet*
based apps can call external _javascript_, whilst local ones can’t? Flex
is a fantastic, emerging cross-platform framework technology. Imagine how
useful it would be to be able to use visual Flex components within
local-machine applications developed using other technologies, such as .NET,
Java, Delphi etc. Whilst Flex provides excellent user interface development
capabilities, it is not a tool for the kind of business application development
that these other environments excel in. It doesn’t have the same data
modelling tools, low-level system APIs, encryption libraries, etc. etc. If
you could use Flex to develop custom components, which you could then embed
within a host application using a browser component, then you would have the
best of both worlds. Those who develop Flex components would have a wider reach
for their products. Many of you will have heard of Mono, the cross-platform
.NET implementation. The one area where Mono lags most behind Microsoft’s
own implementation is in GUI development. Imagine developing a cross platform
app in .NET, using all its data access and business process modelling power,
with a Flex front end. Flex reads and writes .NET datasets very easily (just
convert them to XML, and you’ve got the power of E4X to do all your manipulation
within the UI layer). Maybe
this can be put in the category of “Flex was never meant to do
that”, but really, all it would take is being able to use the
ExternalInterface API to accept commands, report events and exchange data with
the host application via scripted functions in the container page. Ideally, the
page shouldn’t even have to exist on disk – it could be dynamically
created and fed to the browser component by the host application – but
that’s getting a bit esoteric. The main thing is being able to establish
communications between Flex and its HTML page – an interface which
already exists in its entirety, but which is locked down in such a way that it
is not useable in this scenario, as it currently stands. Again,
if anyone can prove me wrong on this, I’d love to hear how. Rant
over, have a nice day. Cheers, Tim. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
- RE: [flexcoders] One last try: Javascript security Matt Chotin
- RE: [flexcoders] One last try: Javascript secur... FineLine
- Re: [flexcoders] One last try: Javascript s... Abdul Qabiz
- Re: [flexcoders] One last try: Javascri... Abdul Qabiz
- Re: [flexcoders] One last try: Javascript s... Luís Gustavo Sanabio
- Re: [flexcoders] One last try: Javascript secur... Tom Chiverton
