Chris,
Yes, you're right. private scope in my CallSimpleMethodScoped.java simply uses Java's native call
stack. The thing to argue about here is whether to reuse CallSimpleMethod.java or CallService.java.
So you think it'll be better to reuse the XML element <call-simple-method>? I feel the same too,
but I thought creating <call-simple-method-scoped> is less intrusive.
How about this. If <call-simple-method> has attribute "in-map-name", then the called method is
executed with a private scope, and sub elements like <result-to-field>, <results-to-map> can
occur. If that attribute doesn't exist, the called method is executed as usual like a mere macro.
Currently, my <call-simple-method-scoped> has the exact same dtd as <call-service>, except that
attribute "service-name" is replaced by "method-name", and attribute "xml-resource" is added.
Frankly, this <call-simple-method-scoped> thing is just a rapid development construct, so I don't
have to restart the server if I changed the called method signature. A called service's signature
(servicedef), if changed, will require a server restart. Or am I mistaken?
Jonathon
Chris Howe wrote:
I haven't looked at the details of it, but to achieve private scope,
wouldn't you simply need to create a new unique Map for the variables
in the "sub" method to be assigned?
Additionally, the java is abstracted away from the xml so that you can
call it the way I suggested, but implement it the way you suggested.
e.g.
if private-scope="true"
new CallSimpleMethodScoped
else
new CallSimpleMethod
--- Jonathon -- Improov <[EMAIL PROTECTED]> wrote:
Chris,
That element ties to CallSimpleMethod.java. If you look in there,
you'll see that there is
possibly lots of changes necessary to achieve private scope.
Compare that with CallService.java. Think about the shortfall in
CallSimpleMethod.java in comparison.
Question to ask: Is it easier to enhance CallService.java for private
scoped simple-method calls,
or is it easier to enhance CallSimpleMethod.java?
Bear in mind that a private scope (like a proper Java method, PHP
method, any method that is NOT a
mere macro) is useless unless we can get return values from it.
Jonathon
Chris Howe wrote:
This would probably be easiest to use as an attribute of
<call-simple-method/> e.g. <call-simple-method scope="true"/>
--- Jonathon -- Improov <[EMAIL PROTECTED]> wrote:
David,
I've created in Minilang an element <call-simple-method-scoped>
that
very closely mimics
<call-service>. In fact, CallSimpleMethodScoped.java is very
similar
to CallService.java.
The change is purely additive.
Is that advisable?
Jonathon
Jonathon -- Improov wrote:
David,
Ok, thanks. I'll do something about this, then let you guys
decide
how
to phrase it on Jira and possibly commit it if you'd like.
Jonathon
David E Jones wrote:
It would have to be an option specified in an attribute or
something.
Most of the code that uses this expects it to be an in-line call
and
share the same scope, basically running as if the code were
inserted
where the call-simple-method tag is.
Changing the default behavior would break a lot of stuff, so we
won't
be doing that. Adding an option to run in a separate scope is
fine
(the MapStack in OFBiz used by the Screen Widget and other
things
is
helpful for this).
-David
Jonathon -- Improov wrote:
Does <call-simple-method> call a simple-method that has private
scope
and local variables? I gather not.
If not, is it alright to do so? I don't mind submitting the
code
for
this.
Yes, I understand that services are the right way to go. But if
it's
not too much trouble, do we mind adding private scope and local
variables to simple-methods called via <call-simple-method>?
Any
repercussions?
Jonathon
