SwizConfig strict="true" and DynamicEvents

6 views
Skip to first unread message

Nathan Mische

unread,
Nov 18, 2009, 9:26:27 PM11/18/09
to swiz-fr...@googlegroups.com
I'm running into an issue and was wondering if anyone would have a
suggestion for how to handle this. I generally define my event name
constants in my controller class and then dispatch dynamic events. The
problem I'm running into is that when using SwizConfig strict="true" I
cannot mediate dynamic events with properties because MediatorUtil
complains: Unable to mediate event " + eventName + "! Member variable
" + variable + " does not exists.

Is there anyway to use strict mode to validate the event name and not
the properties?

Thanks,

--Nathan

Nathan Mische

unread,
Nov 18, 2009, 9:53:30 PM11/18/09
to swiz-fr...@googlegroups.com
Oh, and I know I can use expressions (${beanName.CONSTANT}) but I'd
like to use a class that is not necessarily a bean.

Thanks,

--Nathan

Brian Kotek

unread,
Nov 18, 2009, 10:57:44 PM11/18/09
to swiz-fr...@googlegroups.com
You can try adding the controller package(es) to the eventPackages array in your SwizConfig.

--

You received this message because you are subscribed to the Google Groups "Swiz Framework" group.
To post to this group, send email to swiz-fr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/swiz-framework?hl=.



Sönke Rohde

unread,
Nov 19, 2009, 4:33:45 AM11/19/09
to swiz-fr...@googlegroups.com
Yes, or provide the full qualified path like com.foo.controller.MyController.FOO

Nathan Mische

unread,
Nov 19, 2009, 8:24:44 AM11/19/09
to swiz-fr...@googlegroups.com
Yes, but the problem I'm running into is that my controller doesn't
have a field that matches the properties of my dynamic event. I guess
what I'm looking for is a strict validation level, i.e. validate event
name and properties or validate only the event name.

--Nathan

Nathan Mische

unread,
Nov 19, 2009, 8:34:06 AM11/19/09
to swiz-fr...@googlegroups.com
And just to clarify, the static constant I'm trying to use is not in
my controller, but another class that is a bean. For some reason the
expression syntax is not working on this calss. I guess I could dig
into ExpressionUtils and see what is going on, but I kind of like the
strict syntax better.

Also, I'm not too familiar with describeType but does it let you know
if a class is dynamic? If so, maybe Swiz could not validate properties
for dynamic classes? Or rather, only log a warning and not throw an
error if a property is not found on a dynamic class?

--Nathan

Brian Kotek

unread,
Nov 19, 2009, 9:45:31 AM11/19/09
to swiz-fr...@googlegroups.com
Well, the entire point of enabling strict event mediation is to provide a validation mechanism that matches as closely as possible the compile-time error checking that is not possible on the metadata values. So what you're asking for isn't there, as you already know. And I'm not sure how sort sort of partial checking would work. What if someone actually has a defined event class that happens to extend DynamicEvent? If the assumption is that DynamicEvents should not have their properties validated, that would be a loss of functionality to those people. Strict is meant to fail early and hard, to mimic as closely as possible the compile-time checking.

I don't see what point there would be to having strict runtime checking without validating the properties. The only alternatives would be either doing runtime checks on *every event*, rather than just checking the class once at initialization time (which obviously would have performance implications), or not validating properties on DynamicEvents (which would hurt people who actually rely on it).

I suppose some additional validation mode could be built in, but I suspect that the others may resist adding another configuration option to satisfy this use case. In this situation, it sounds like you probably just want to turn off strict and take your chances (since that's what one is doing when they use generic DynamicEvents anyway, as Flex can't validate the properties either).

Thoughts?

Brian

Nathan Mische

unread,
Nov 19, 2009, 11:57:55 AM11/19/09
to swiz-fr...@googlegroups.com
Turns out my issue was because I didn't realize that ExpressionUtils
searched public properties before searching for static constants.

The class I'm trying to use in the expression is a proxy with a custom
getProperty method which was returning an object, instead of the
string I was expecting from my static constant.

I know it is more expensive in terms of performance, but maybe
ExpressionUtils should search static constants first, and properties
second? The reason I suggest this is I suspect the most common use
case for ExpressionUtils is to resolve static constants, but I could
be wrong.

--Nathan

Brian Kotek

unread,
Nov 19, 2009, 12:24:32 PM11/19/09
to swiz-fr...@googlegroups.com
I'm probably missing something, but what difference does it make whether the constant is checked first or the properties?

Nathan Mische

unread,
Nov 19, 2009, 12:37:19 PM11/19/09
to swiz-fr...@googlegroups.com
So, if my object is a proxy
(http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/utils/Proxy.html)
that has a getProperty method that returns an object for _any_
undefined property requested, it will return an object when I go to
resolve object[propertyName], even if that property doesn't exist.
Given the current search order this means I will get an object back
from ExpressionUtils because it will resolve
object["MY_STATIC_CONST"], but what I really want is the string
defined by the static constant "MY_STATIC_CONST". Does that make
sense?

--Nathan

Brian Kotek

unread,
Nov 19, 2009, 1:06:31 PM11/19/09
to swiz-fr...@googlegroups.com
Hmm a few things here then. So you're saying that if the order were reversed, you would get back just the value "MY_STATIC_CONST", but because it first makes requests for the properties, when it gets the constant it gives back object["MY_STATIC_CONST"]?

I'm trying to picture why you would want to allow undefined properties to return values. What does it return? An empty Object? Null?

And just to sum up the situation: you're dispatching generic DynamicEvents, where the event type is a constant defined in a controller, and the properties are defined in some other object outside of the event that responds to any property request even if the property doesn't exist? Again, I might be missing something, but doesn't all this seem like a really sketchy setup?

Nathan Mische

unread,
Nov 19, 2009, 1:26:34 PM11/19/09
to swiz-fr...@googlegroups.com
Heh. So here is where all this is coming from. I have a custom
RemoteObject class that dispatches DynamicEvents via Swiz:

<swizrpc:RemoteObject
id="stockService"
source="swizEventResponder.StockService"
destination="ColdFusion"
channelSet="{myAMFChannelSet}">
<swizrpc:method name="getQuotes"
resultEvent="{AppController.QUOTE_RESULT_EVENT}"
faultEvent="{AppController.FAULT_EVENT}" />
</swizrpc:RemoteObject>

If a fault occurs when a method is called that does not have a
faultEvent defined at the Operation or RemoteObject level I would like
to dispatch a generic SWIZ_FAULT_EVENT. I have a static constant
defined in my RemoteObject class, but if I try to resolve the
expression ${stockService.SWIZ_FAULT_EVENT} I get an AbstractOperation
back, because that is how RemoteObject is set up. For now I've created
a separate EventConstants class to hold the SWIZ_FAULT_EVENT value,
but I'd really like that value to live in the RemoteObject if
possible.

--Nathan

Brian Kotek

unread,
Nov 19, 2009, 2:10:05 PM11/19/09
to swiz-fr...@googlegroups.com
If you want to keep this setup, it sounds like the best option would be to add some code to the Proxy's getProperty method that does its own check to see if the value being asked for is actually one of the original object's static properties, and return that if it is is, and if not, let the call go through to return the operation instead?

Nathan Mische

unread,
Nov 19, 2009, 2:42:13 PM11/19/09
to swiz-fr...@googlegroups.com
Of course, that makes perfect sense! Thanks for sticking with me and
offering that suggestion.

--Nathan
Reply all
Reply to author
Forward
0 new messages