<call-simple-method> to allow for call stack and private scope?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

<call-simple-method> to allow for call stack and private scope?

jonwimp
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
Reply | Threaded
Open this post in threaded view
|

Re: <call-simple-method> to allow for call stack and private scope?

David E Jones

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
Reply | Threaded
Open this post in threaded view
|

Re: <call-simple-method> to allow for call stack and private scope?

jonwimp
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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <call-simple-method> to allow for call stack and private scope?

jonwimp
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
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <call-simple-method> to allow for call stack and private scope?

cjhowe
This would probably be easiest to use as an attribute of
<call-simple-method/> e.g. <call-simple-method scope="true"/>
--- Jonathon -- Improov <[hidden email]> 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
> >>
> >>
> >
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <call-simple-method> to allow for call stack and private scope?

jonwimp
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 <[hidden email]> 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
>>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <call-simple-method> to allow for call stack and private scope?

cjhowe
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 <[hidden email]> 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 <[hidden email]> 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
> >>>>
> >>>
> >>
> >
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: <call-simple-method> to allow for call stack and private scope?

jonwimp
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 <[hidden email]> 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 <[hidden email]> 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
>>>
>>
>
>