Throw a more specific exception on missing input

[GoogleCodeExporter]

I have changed Server.php to throw an InvalidAMFException, if it can't read
from stdin.

I have attached the patch.

I have more stuff in the works, just to mention a few:
* Custom input (great for unit testing)
* More error handling improvements (ie. abandon the direct use of the
Exception class)
* Support for more sophisticated uses of ClassMapping (Like 10 remote
classes to 1 local class, and back)

So it might be easier with direct SVN access.

Original issue reported on code.google.com by asbj...@lila.io on 9 Sep 2008 at 6:53

Attachments:

• invalidamf.patch

[GoogleCodeExporter]

Hi Asbj, 

I can definitely give you SVN access for this.. The attached patch looks good, 
for
some of the more complex changes I'd like to see if we can discuss approach / 
whether
or not it makes sense..

More complex class-mapping is possibly today by implementing your own
onGetLocalClass/onGetRemoteClass callbacks, so right now I'd feel more complex 
use
should be something implemented by the user, and not provided by SabreAMF 
althogether..

Original comment by evert...@gmail.com on 9 Sep 2008 at 7:00

[GoogleCodeExporter]

Hi Evert,

onGetLocalClass()/onGetRemoteClass() works fine for 1-1 class mapping, but with 
M-1
class mapping. I can just return the same class in onGetLocalClass, but then I 
lose
the original class name, and when I have to sent it back to the client, I don't 
know
which remote class I should return.

My proposal to accommodate M-1 class mapping is to add an optional post object
contruction callback, with its remoteclass in the form:

OnMappedClassInitialization(object $obj, string $remoteClass)

That way it's possible to save the $remoteClass in the $obj, or be notified 
that an
ITypedObject object has been initialized. When you have a large tree it's nicer 
to be
notified than than having to seek through it.

The second change is to parse $obj as the second argument to getRemoteClass(), 
so
that it's possible to make an informed decision about which className the 
client expects.

With these two changes it becomes possible without pollution the rest of the our
framework with stuff specific to one request/response format.

Original comment by asbj...@lila.io on 9 Sep 2008 at 8:15

[GoogleCodeExporter]

So what you're proposing is replacing classes based on a constructed object ? 

The mapper would first receive an object (this could simply be a 
TypedObject-object,
as this already contains the data + the classname), and the mapper callback 
from the
user returns an object as well?

That would make perfect sense to me.. Perhaps we should move the discussion to 
the
mailing list.. http://osflash.org/mailman/listinfo/sabreamf_osflash.org

Not that there's a lot of discussion going on, but would be good to keep 
discussion
central.

Original comment by evert...@gmail.com on 9 Sep 2008 at 8:31

[GoogleCodeExporter]

Original comment by evert...@gmail.com on 9 Sep 2008 at 8:34

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

1.2

Original comment by evert...@gmail.com on 13 Sep 2008 at 9:22

• Changed state: Verified