Hi Latcho,
You're probably right about passing a stage ref to an object whose sole
purpose is connecting to the backend. Since I was just testing if I could
get the thing working, I setup the remoting stuff in the main class (a
Sprite), so I already have that there.
You could also pass just the url to the "real" class, I guess, instead of a
ref to the stage; but anyway if just setting _url to anything not null is
enough, that could also be a way to go. (I don't know if there are any pros
/ cons to any of those methods).
No problem, I'll send you a copy of my test in a off-list email (to not spam
this list; I think attachments are not allowed). It's very simple and not
too different from yours, I think, but maybe it helps you to compare both.
Another thing I tried is using a polling channel (using as a base the
example that comes with blazeds to pure AS 3) and got it working, but I
can't seem to find the project now (I'm such a bozo sometimes!). Anyway, I
remember the AS part was almost identical, just the channel creating part
changed and some mapping xml on the server side. I wasn't quite impressed
about this feature, though. I mean, the good part is that it's transparent
for you, but you could probably do the same with a timer. I was expecting
something like RMTP, allowing real data push, but apparently that's not
possible with RemoteObjects (or just with blazeDS ? Not sure).
Cheers
Juan Pablo Califano
2009/3/13 Latcho <spamtha...@gmail.com>
> Hi Juan,
> Thanks for your email. This gives me some confidence of beign on the wright
> track.
> Why I tried the Loaderconfig.url "notnull" string hack was because it just
> works but most of all because that's the only way of not having to pass a
> reference to stage.loaderInfo.url since it is not nice to have a proxy
> extending a DisplayObject and silly to pass a stage reference to the
> remoting instance to get remoting to work.
> The loaderInfo.parameters are of no importance to get it to work, so I
> dropped it.
> Good to remind me about the DTO registering, I only registered the basic
> messaging classes but I will need some more in the future.
> If you have made any examples to test this stuff, it would be nice to see
> copy of your test-setup even if it looks hacky.
> Feel free to (not) send me.
>
> Ciao,
> Latcho
>
> Juan Pablo Califano wrote:
>
>> Hi,
>> I've had this same issue some weeks ago. In my case, I had to use an
>> existing back-end that was consumed by a Flex app using RemoteObjects. The
>> requirement was to replace the front-end with a more lightweight AS pure
>> client, but keeping the back-end. After googling a bit, I found, as you did,
>> that the trick was manually registering the Flex classes that take part in
>> the communication process (before attempting any communication!); this is
>> something you get for free if you setup a Flex project, by the way (by means
>> of the Remote meta-tag).
>> I just made some tests to see whether it was feasible and haven't built
>> the real thing yet, but I it worked ok against my local service (I installed
>> BlazeDS) and against the production service (they're using FDS, I think).
>> About the mx_internal "hack", I used this code (found it googling):
>> var swfURL:String = this.loaderInfo.url;
>> LoaderConfig.mx_internal::_url = this.loaderInfo.url;
>> LoaderConfig.mx_internal::_parameters = this.loaderInfo.parameters;
>> It worked fine. I don't know if it's better this way or your way, though.
>> Maybe you already know this, but another important thing is to map /
>> register your DTO's before calling the backend; otherwise, the serialization
>> / deserialization fails.
>> I've used this code:
>> private function mapAppRemoteClasses():void {
>> // map the classes that represent entities in the backend to the AS
>> classes
>> registerClassAlias("ar.com.califa010.remotingTest.User",User);
>> } (Again, in flex project I think you'd just put a [Remote] tag on
>> you class, but in an AS project you have to do it manually).
>> Regarding the destination, I set it through the remote object using an
>> id. The actual mapping to the Java entry point is on the server; in my case
>> (BlazeDS), in the remoting-config.xml
>> <destination id="userservice-test">
>> <properties>
>> <source>ar.com.califa010.remotingTest.UserService</source>
>> </properties>
>> </destination>
>> So, in the AS side:
>> private function setupUserService():void {
>> _userService = new RemoteObject();
>> _userService.destination = "userservice-test";
>> _userService.channelSet = _amfChannelSet;
>>
>> _userService.getFriends.addEventListener(ResultEvent.RESULT,handleServiceResult);
>>
>>
>> _userService.getFriends.addEventListener(InvokeEvent.INVOKE,handleServiceInvoke);
>>
>> _userService.getFriends.addEventListener(FaultEvent.FAULT,handleServiceFault);
>>
>> _userService.loginUser.addEventListener(ResultEvent.RESULT,handleServiceResult);
>>
>>
>> _userService.loginUser.addEventListener(InvokeEvent.INVOKE,handleServiceInvoke);
>>
>> _userService.loginUser.addEventListener(FaultEvent.FAULT,handleServiceFault);
>> // call methods to test the service...
>> _userService.getFriends();
>> _userService.loginUser("username","pass");
>> }
>> As far as I know, you won't lose any significant functionality. You'll
>> lose some of the amenities provided by Flex (I mean compiling as a Flex
>> Project), like data binding, automatic alias registration, automatic linking
>> to the framework dependencies and probably some more (I don't have much
>> experience in Flex projects).
>> Hope this helps, and if you find out something interesting, please share!
>> Cheers
>> Juan Pablo Califano
>>
>> 2009/3/12, Latcho <spamtha...@gmail.com <mailto:spamtha...@gmail.com>>:
>>
>>
>> Hi friends,
>>
>> I'm a bit of a novice when it comes to remoting.
>> I want to be able to use remoting with weborb-php in AS3 pure
>> sang, fairly compact , without mxml configuation and remaining as
>> functional as possible.
>>
>> Setting a direct endpoint into the remotingObject amfchannel was
>> quite impossibe due to it beign a getter only and only
>> configurable trough mxmlc,
>> So I had to set up a channel.
>> I also had to hack the mx messaging config LoaderConfig's url ,
>> otherwise the flex mx.rpc's classes fail, if it remains a null value.
>> (found this hack/tip here:
>> http://bugs.adobe.com/jira/browse/BLZ-16#action_171947 but
>> figgured it can hold any value as long it's not null)
>>
>> So I did this
>>
>> public dynamic class AMFService extends RemoteObject
>> {
>> ....
>> mx.messaging.config.LoaderConfig.mx_internal::_url =
>> "notnull";
>>
>> public function AMFService(.......)
>> (
>> _amfChannel = new
>> AMFChannel(_destinationChannel,_serviceGateway);
>> _amfChannel.connectTimeout = _conectTimeOut;
>> _amfChannel.requestTimeout = _requestTimeout;
>> var myChannelSet:ChannelSet = new ChannelSet();
>> myChannelSet.addChannel(_amfChannel);
>>
>> ` }
>>
>>
>> furthermore this to solve some Typing errors and to get the of
>> Messages wright wright
>>
>> static private function registerClassAliases():void
>> {
>> /* REGISTERCLASSALIAS()
>> * Preserves the class (type) of an object when the
>> object is encoded in Action Message Format (AMF).
>> * When you encode an object into AMF, this function
>> saves the alias for its class,
>> * so that you can recover the class when decoding the
>> object.
>> * If the encoding context did not register an alias for
>> an object's class,
>> * the object is encoded as an anonymous object.
>> * Similarly, if the decoding context does not have the
>> same alias registered,
>> * an anonymous object is created for the decoded data.
>> * */
>> registerClassAlias("DSA", AsyncMessageExt);
>> registerClassAlias("flex.messaging.messages.AsyncMessage",
>> AsyncMessage);
>> registerClassAlias("DSA", AsyncMessageExt);
>> registerClassAlias("DSC", CommandMessageExt);
>>
>> registerClassAlias("flex.messaging.messages.CommandMessage",CommandMessage);
>>
>>
>> registerClassAlias("flex.messaging.messages.RemotingMessage",
>> RemotingMessage);
>> registerClassAlias("DSK", AcknowledgeMessageExt);
>>
>> registerClassAlias("flex.messaging.messages.AcknowledgeMessage",
>> AcknowledgeMessage);
>> registerClassAlias("flex.messaging.messages.ErrorMessage",
>> ErrorMessage);
>>
>> registerClassAlias("flex.messaging.messages.HTTPMessage",HTTPRequestMessage);
>>
>> registerClassAlias("flex.messaging.messages.SOAPMessage",
>> SOAPMessage);
>>
>> registerClassAlias("flex.messaging.messages.MessagePerformanceInfo",
>> MessagePerformanceInfo);
>> registerClassAlias("flex.messaging.io.ArrayList",
>> ArrayList);
>>
>> registerClassAlias("flex.messaging.io.ArrayCollection",ArrayCollection);
>>
>> registerClassAlias("flex.messaging.io.ObjectProxy",ObjectProxy);
>> registerClassAlias("flex.messaging.config.ConfigMap",
>> ConfigMap);
>> }
>>
>>
>> Now my questions:
>> Is this the best way to keep it tiny and pure AS3 without mxml
>> Do I drop functionallity here if it comes to remoting (and not to
>> the remote data processing) ?
>> Can this be done in an oher AS3 way without hacking with the
>> mx_internal trick ?
>> FYI, the filesize of my remoting test is now 86Kb in release mode.
>>
>> Please help me out of uncertainty :)
>>
>> Tnx
>> Latcho
>> _______________________________________________
>> Flashcoders mailing list
>> Flashcoders@chattyfig.figleaf.com
>> <mailto:Flashcoders@chattyfig.figleaf.com>
>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>>
>>
>>
> _______________________________________________
> Flashcoders mailing list
> Flashcoders@chattyfig.figleaf.com
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
