Dear XOTcl/NSF community,
in order to contrain the input of certain methods to allow only objects of a certain type/class, e.g.:
Utility proc get_object_id_from_sourced_guid { -sourced_guid:sourced_guid } { ... }
we have the following code in our code base:
if {[info command ::xotcl::nonposArgs] ne ""} { ::xotcl::nonposArgs proc sourced_guid args { if {[llength $args] < 2} return foreach {name value} $args break if {![::xotcl::Object isobject $value]} {error "'$value' is not an object"} if {![$value istype ::foo::bar::SourcedGuid]} {error "'$value' is not of type SourcedGuid but [$value info class]"} } ::Serializer exportMethods { ::xotcl::nonposArgs proc sourced_guid } }
This works with XOTcl 1.6, but we now see the following warnings when running the code under NSF:
Warning: nsf: Could not find value checker type=sourced_guid defined on ::nx::methodParameterSlot
What is the correct way to port this to XOTcl 2.0?
Thank you for your help! Michael
Hi Michael!
What is the correct way to port this to XOTcl 2.0?
This is most likely not an authoritative answer, I don't have the time right now to think this through properly. The following should get you going for the time being:
if {[info command ::nx::methodParameterSlot] ne ""} { ::nx::methodParameterSlot object method type=sourced_guid {name value args} { if {![::nsf::is object $value] || [xotcl::Object info instances -closure $value] eq ""} { error "'$value' is not an XOTcl object" } if {![$value istype ::foo::bar::SourcedGuid]} { error "'$value' is not of type SourcedGuid but [$value info class]" } } }
If you plan to co-maintain two code bases (one compatible with 1.6 and the other for 2+), then you might want to consider factoring out the value checker into a plain Tcl proc and forward/alias to this proc conditionally from ::xotcl::nonposArgs and ::nx::methodParameterSlot, respectively.
I leave this as an exercise to you ;)
Let me know whether the above works for you for the time being.
Cheers, Stefan
P.S.: I suggest using "return -code error" in your value checker to skip one level on the callstack trace reported to the developer, to hide the details of the value checker in the reported trace.
Thank you, Stefan.
After fiddling around, it seems (at first sight) that the following snippet does the trick:
if {[info command ::nx::methodParameterSlot] ne ""} { ::nx::MethodParameterSlot method type=sourced_guid {name value} { if {![::nsf::is object $value] || [xotcl::Object info instances -closure $value] eq ""} { return -code error "'$value' is not an XOTcl object" } if {![$value istype ::foo::bar::SourcedGuid]} { return -code error "'$value' is not of type SourcedGuid but [$value info class]" } } ::Serializer exportMethods { ::nx::MethodParameterSlot method type=sourced_guid } }
All the best, Michael
PS: For novices the "mixture" of ::nx and ::xotcl is a bit unexpected, for example when serializing ::xotcl::MetaSlot on my OpenACS instance, one can see, that e.g. the superclass of ::xotcl::MetaSlot is ::nx::MetaSlot et cetera. My intuitive expectation was that both XOTcl 2 and NX exist as different languages within NSF, but more or less completely isolated from each other. I suppose the reason is to keep the source code required to support the "legacy" XOTcl syntax as small as possible?
On Wed, Jul 15, 2015 at 1:58 PM, Stefan Sobernig stefan.sobernig@wu.ac.at wrote:
Hi Michael!
What is the correct way to port this to XOTcl 2.0?
This is most likely not an authoritative answer, I don't have the time right now to think this through properly. The following should get you going for the time being:
if {[info command ::nx::methodParameterSlot] ne ""} { ::nx::methodParameterSlot object method type=sourced_guid {name value args} { if {![::nsf::is object $value] || [xotcl::Object info instances -closure $value] eq ""} { error "'$value' is not an XOTcl object" } if {![$value istype ::foo::bar::SourcedGuid]} { error "'$value' is not of type SourcedGuid but [$value info class]" } } }
If you plan to co-maintain two code bases (one compatible with 1.6 and the other for 2+), then you might want to consider factoring out the value checker into a plain Tcl proc and forward/alias to this proc conditionally from ::xotcl::nonposArgs and ::nx::methodParameterSlot, respectively.
I leave this as an exercise to you ;)
Let me know whether the above works for you for the time being.
Cheers, Stefan
P.S.: I suggest using "return -code error" in your value checker to skip one level on the callstack trace reported to the developer, to hide the details of the value checker in the reported trace.
PS: For novices the "mixture" of ::nx and ::xotcl is a bit unexpected, for example when serializing ::xotcl::MetaSlot on my OpenACS instance, one can see, that e.g. the superclass of ::xotcl::MetaSlot is ::nx::MetaSlot et cetera. My intuitive expectation was that both XOTcl 2 and NX exist as different languages within NSF, but more or less completely isolated from each other.
XOTcl building on NX (esp. slots) is hinted at some spots in the migration guide at https://next-scripting.org/xowiki/docs/nx/nx-migration/index1#_parameters_2.
I suppose the reason is to keep the source code required to support the "legacy" XOTcl syntax as small as possible?
So it is.
Stefan
OpenACS contains for XOTcl 1 compatible slot interface for the basic slot features. The advanced slot features were marked in XOTcl 1 as "experimental", some of these will require some work in XOTcl 2. The NX slot-system is much more advanced and regular than the XOTcl-1 predecessor, therefore we made this short cut, knowing, that some power-users will need some fiddling. if there are problems, we try to help as usual.
greetings from mx -gn
Am 16.07.15 um 04:47 schrieb Stefan Sobernig:
PS: For novices the "mixture" of ::nx and ::xotcl is a bit unexpected, for example when serializing ::xotcl::MetaSlot on my OpenACS instance, one can see, that e.g. the superclass of ::xotcl::MetaSlot is ::nx::MetaSlot et cetera. My intuitive expectation was that both XOTcl 2 and NX exist as different languages within NSF, but more or less completely isolated from each other.
XOTcl building on NX (esp. slots) is hinted at some spots in the migration guide at https://next-scripting.org/xowiki/docs/nx/nx-migration/index1#_parameters_2.
I suppose the reason is to keep the source code required to support the "legacy" XOTcl syntax as small as possible?
So it is.
Stefan _______________________________________________ Xotcl mailing list Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
-
Gustaf Neumann -
Michael Aram -
Stefan Sobernig