 | | | Custom Objects and Classes for Scripting | Custom Objects and Classes for Scripting 2005-03-26 - By Brad Friedman
Back
close. very close.
I looked through the Isner example. He's rolling a quick object to use
to pass arguments in and out of javascript functions. And in so doing
he's getting around the fact that javascript doesn't do "out" parameters
the way vbscript and some other languages do. He's also simplifying the
function headers, though the downside to that is that you kinda have to
memorize where you put all your parameters on the object. They're not
nicely laid out in the function header. Its a really neat trick though.
The trick to the "Why Create Custom Objects and Classes for Scripting in
XSI?" piece at CGSoup is that the object is not holding fields (Data).
Though it could hold data. Its got methods (functions) in it. And its
therefore acting like a library. Its letting you kick that object out
through a command to another script written in an entirely different
language in an entirely different file (I assume this is the magic of
activex scripting engines making it happen). And you don't have to
export each and every function as a command to do it.
So its kinda acting like a DLL in that its a library of functions. But
its implemented as a super loosely typed scripting object. No compiled
code required. And it can travel to different scripts in different
languages and still be called. Which is the really cool part :)
I took a look at your python script. I'm still not entirely up on
python but I got it. The thing thats nice about python is that its a
pretty robust OO language. Its almost java (not javascript) like in its
structure. So it handles objects, classes and packages extremely well
internally. Infact it has a one up on java in that it can be strongly
typed or weakly typed depending on what kind of environment you are in.
Java on the other hand, is alsways strongly typed. So Java would not
work very well with XSI scripting, which relys on weak typing quite a bit.
What I wonder with your example, is what would happen if you returned an
instance of your Ls class from a command, and then called that command
from say... vbscript. Would you be able to call ls.HasAreaTransforms()
from vbscript, depending on the scripting environment to take care of
things between python and vbscript? Its somewhat trivial if you already
know python because you can use python's own internal packages to do
these things staying all in python. But for other scripting languages,
it can be extremely powerful because they don't have packages and
includes to work with. And thats what the CGSoup piece is about.
Making a custom object work between languages that don't already have
nice package and include support. Or at least thats what their example
is about. They suggest other uses for the same technique as well.
What I'm currious about is just overhead and best practices with that
technique. The CGSoup piece isn't an all inclusive tutorial that covers
all the potential pitfalls so i was hoping someone had been using the
technique and could shed some light on the intricacies of it. In
particular, if anyone had been using it as a function library. Since
its functions on an instance rather than static functions in a class...
how does one get around the overhead of constant instantiation of the
object by clients of the library? Or is the overhead so tiny that its
trivial to constantly instantiate the object to get at what are
essentially static methods?
-brad
Bernard Lebel wrote:
> Hi Brad,
>
> Not sure if it will help, but Michael Isner has a bunch of script on
> XSI Base in our last Talk With The Pros workshop. His examples make
> sure of custom objects, and are in JScript :-D
>
> http://www.xsibase.com/forum/index.php?board=26;action=display;threadid=16336
;start=45
>
>
> You may want to check the ExpressionUICurve.zip file in his first post
> on the above page.
>
>
>
> That said, I think what you are referring to are compiled dlls.
> Personally, since I don't have a clue about C++ and compiling other
> than what it is used for, all I can say is that you don't need
> compiled code to call custom objects. I have a large set of handlers
> that are basically Python module, I just need to call the functions in
> the modules. I can also turn anything into an object by writing a
> class statement and instantiating this class. Example:
>
>
>
> Part of a module named LT_ligthStats.py:
>
>
> import string
> from win32com.client import constants as c
>
>
> class Ls:
>
> # Define initial state of class object
> def __init__( self, oLight ):
>
> self.Light = oLight
> self.BasicType = self.Light.activeprimitive.parameters( 'Type'
> ).value
>
>
> # advLightID custom property
> self.HasAdvancedLightIDProp = self.eval_HasAdvancedLightIDProp()
>
> # Light instancing
> self.InstancingStatus = 'NA'
>
> if self.HasAdvancedLightIDProp == True:
> # Call function to get instancing status
> self.InstancingStatus = self.eval_InstancingStatus()
>
>
> # AreaTransform custom property
> self.HasAreaTransforms = self.eval_HasAreaTransforms()
>
>
>
> The self.eval_Has...() you see above are calls to the methods of the
> same class (hence the "self" thing).
>
> Then in my XSI script, I first import the module, then instantiate the
> Ls class with an argument (the class builds statistics for a light),
> then access its attributes. The values persist only during the XSI
> session.
>
> # Import module
> import LT_lightStats
>
> # Get selected light
> oLight = xsi.selection(0)
>
> # Create instance of Ls class from module, pass it light
> ls = LT_lightStats.Ls( oLight )
>
> # Print class instance attribute
> xsi.logmessage( ls.HasAreaTransforms )
>
> # Yet again
> if ls.HasAreaTransform == True: xsi.logmessage( 'yeah!' )
> else: xsi.logmessage( 'no' )
>
>
>
> Later I can change the attribute values if I want, or add attributes.
>
> # Set my own value for attribute
> ls.HasAreaTransform = False
>
> # Add custom attribute to class instance
> ls.AnotherAttribute = 'another attribute!'
>
>
>
> Hope this helps
> Bernard
>
>
>
> Brad Friedman wrote:
>
>> Hi,
>>
>> I just read the blog entry, "Why Create Custom Objects and Classes
>> for Scripting in XSI?" over at CGSoup.
>>
>> And it solved about 5-10 design issues I was having with my toolkit
>> :) THANK YOU!
>>
>> But I have a few questions if anyone can answer.
>>
>> in the example code given, the object is retrieved with the command:
>>
>> [code]
>> set gt = GUITools(0)
>> [/code]
>>
>> which makes sense. But I was wondering about the instantiation of
>> the object itself. First of all, what are some of the best standards
>> and practices of creating objects in jscript? My understanding is
>> that there are a couple of ways to do it and I was wondering if
>> anyone has any reason why one way in particular is better for XSI.
>>
>> I intend to roll an object as a utility library of functions (as
>> suggested as one possible use in the blog entry). If I'm
>> understanding the example, I think thats what GUITools is doing as
>> well. Am I to understand that the object is instantiated every time
>> the "GUITools" command is called? Or is it cache'ing it somewhere in
>> global memory the first time and just passing the same instance on
>> subsequent calls? Or is the instantiation so cheap, it doesn't
>> matter that you instantiate it in every function you use it in? Is
>> there a good place to toss an object where it will persist for the
>> remainder of the given XSI session? Or is that foolhearty?
>>
>> thanks,
>> -brad
>> ---
>> Unsubscribe? Mail Majordomo@(protected) with the following text in
>> body:
>> unsubscribe xsi
>>
>>
>>
>
>
> ---
> Unsubscribe? Mail Majordomo@(protected) with the following text in
> body:
> unsubscribe xsi
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
|