Hi Michael,
Am 19.03.2009 um 11:32 schrieb Michael Wyraz:
>>> - TODO: Use commons-logging
>>>
>> Not so good (IMHO). If at all possible, the "RPC core" should not
>> depend on a specific logging framework (or "meta-framework" in case
>> of
>> commons-logging). It's always a pain to deal with different logging
>> frameworks, even if it just means configuring commons-logging to use
>> java.util.logging (assuming you're using j.u.l in your application
>> code). Maybe logging can be delegated to sub-classes? This way, you
>> could avoid having c-l in your runtime classpath if you don't need
>> it.
>> This is no showstopper though - a refactoring that depends on c-l is
>> better than no refactoring at all :-)
>>
> Ok, I'll re-think this ;-) But atm there's dependency to commons-
> beanutils and commons-collections. So i thought, commons-logging
> should also be ok. All other approaches would only introduce another
> (minimal) logger wrapper.
The other commons dependencies are relatively "harmless" - they don't
interfere with your application in any way. Logging frameworks OTOH
can lead to nasty issues with classloading (e.g. leaking class loaders
when re-loading a web app inside a container), and they require
additional action on your part if you don't like the default
configuration. So I'd prefer a minimal wrapper instead of an
unconditional dependency.
>>> - DONE: added support for enums
>>> - serialization: js object attributes "name"=enum.name(),
>>> "ordinal"=enum.oridinal(), "string",enum.toString()
>>> - deserialization: Integer -> ordinal, other -> name
>>>
>> I'm not so sure about this. enum support is very welcome, but it
>> should be possible to do roundtrips (Java => JS => Java). It doesn't
>> sound like that's the case with your approach, and it's a bit
>> unnatural to deal with an enum value this way in JS. My suggestion
>> would be to simply output enum.name() as a string for serialization.
>>
> This has pros and cons:
> pro: much more simple roundtrips (enum -> string -> enum)
> con: loss of information (e.g. i use the "toString()" of an enum to
> create a readable label for it)
When it comes to presenting a value to a user, you usually need a
separate conversion anyway (for I18n, formatting, maybe showing icons
instead of strings, etc). And if you think this through, you'd have to
add an attribute with the value of toString() to _all_ objects - why
treat enums in a special way? After all, any object could benefit from
a readable label, but I don't think that's the right approach (see
below).
> Another solution would be to also accept the { name: ...,
> ordinal: ..., string:... } object on deserialization (or more
> generall any object that has an integer property "ordinal" or a
> string property "name".
I think this is overkill. After all, an enum is just a way of
representing a choice out of a certain set. Why send different
representations of the same information to the client (and back in
case of roundtrips)? It just blows up the RPC packets.
For special server-side conversions (and I would put a "more readable"
enum value into that category), I think it would be better to add a
generic customization facility. For example, you could check if an
object has a "toJSON" method and use that for serialization instead of
the default implementation. The same approach has been discussed here
recently for the client side. Or you could also offer a kind of
registry where one can register custom serializers for specific
classes. This would allow you to customize the serialization in cases
where you can't create a subclass with a toJSON method. What do you
think?
Regards,
Andreas
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
