RequestHandler.makeLink fullpath question

[byersa]

First of all, is this the correct protocol - I am not sure that what I am
looking at is a bug, so rather than open a JIRA issue, I want to bring it up
here, or should this sort of thing start with a JIRA entry?

The RequestHandler.makeLink has a parameter, "fullPath", that I would think
causes everything after the server and port string to be replaced by the
passed url value.
But at line 757 there is:

        newURL.append(controlPath);

So if I am doing a call from within the ecommerce webapp to a content webapp
request, I get:

http://localhost:8080/ecommerce/control/content/control/ViewSimpleContent?dataResourceId=10100

Should there be a conditional append of the controlPath?

-Al

[David E Jones]

Al,

Could you step back and describe a little more of what you are trying  
to do, the code you are using, etc? You did a good job here of  
explaining what happened but not really what you did or expected to  
happen.

In general if you are linking to another application, you don't use  
the ofbizUrl tag or any of the code behind it, like the makeLink  
method. There are a number of examples of this if you look around.

-David


On Jan 20, 2007, at 2:52 AM, Al Byers wrote:

> First of all, is this the correct protocol - I am not sure that  
> what I am
> looking at is a bug, so rather than open a JIRA issue, I want to  
> bring it up
> here, or should this sort of thing start with a JIRA entry?
>
> The RequestHandler.makeLink has a parameter, "fullPath", that I  
> would think
> causes everything after the server and port string to be replaced  
> by the
> passed url value.
> But at line 757 there is:
>
>        newURL.append(controlPath);
>
> So if I am doing a call from within the ecommerce webapp to a  
> content webapp
> request, I get:
>
> http://localhost:8080/ecommerce/control/content/control/ 
> ViewSimpleContent?dataResourceId=10100
>
> Should there be a conditional append of the controlPath?
>
> -Al

[byersa]

David,

Ok, but I thought this issue would stand on its own - is there a reason why
the control path should be added to the url if the fullPath parameter is
true? Either I don't understand the call structure for makeLink or anyone
who tries to use it with fullPath set to true will not get the expected
results.

As for my application, I am using it in the content management sense, and
the the "<content...>" tag (under certain conditions) creates an iframe in
the HTML that needs to point to the "/content/control/ViewSimpleContent"
request and I am in the ecommerce app. So I figured I could use the makeLink
call to create the correct url. I know that the "<link...>" tag does the
same sort of thing, but it does not use makeLink in this way and this seemed
like the way that makeLink should work.  I thought about it and figured it
is easier to just add the request to ecommerce, but thought the makeLink
issue was worth raising.

Thanks for your help.
-Al

On 1/20/07, David E. Jones <[hidden email]> wrote:

>
>
> Al,
>
> Could you step back and describe a little more of what you are trying
> to do, the code you are using, etc? You did a good job here of
> explaining what happened but not really what you did or expected to
> happen.
>
> In general if you are linking to another application, you don't use
> the ofbizUrl tag or any of the code behind it, like the makeLink
> method. There are a number of examples of this if you look around.
>
> -David
>
>
> On Jan 20, 2007, at 2:52 AM, Al Byers wrote:
>
> > First of all, is this the correct protocol - I am not sure that
> > what I am
> > looking at is a bug, so rather than open a JIRA issue, I want to
> > bring it up
> > here, or should this sort of thing start with a JIRA entry?
> >
> > The RequestHandler.makeLink has a parameter, "fullPath", that I
> > would think
> > causes everything after the server and port string to be replaced
> > by the
> > passed url value.
> > But at line 757 there is:
> >
> >        newURL.append(controlPath);
> >
> > So if I am doing a call from within the ecommerce webapp to a
> > content webapp
> > request, I get:
> >
> > http://localhost:8080/ecommerce/control/content/control/
> > ViewSimpleContent?dataResourceId=10100
> >
> > Should there be a conditional append of the controlPath?
> >
> > -Al
>
>
>
>

[David E Jones]

On Jan 20, 2007, at 3:25 PM, Al Byers wrote:

> David,
>
> Ok, but I thought this issue would stand on its own - is there a  
> reason why
> the control path should be added to the url if the fullPath  
> parameter is
> true? Either I don't understand the call structure for makeLink or  
> anyone
> who tries to use it with fullPath set to true will not get the  
> expected
> results.
>
> As for my application, I am using it in the content management  
> sense, and
> the the "<content...>" tag (under certain conditions) creates an  
> iframe in
> the HTML that needs to point to the "/content/control/
> ViewSimpleContent"
> request and I am in the ecommerce app. So I figured I could use the  
> makeLink
> call to create the correct url. I know that the "<link...>" tag  
> does the
> same sort of thing, but it does not use makeLink in this way and  
> this seemed
> like the way that makeLink should work.  I thought about it and  
> figured it
> is easier to just add the request to ecommerce, but thought the  
> makeLink
> issue was worth raising.

Do you mean in the screen widget? You can just use the link tag with  
the "inter-app" url-mode.

I think I like this other way better though, ie adding a request-map  
in the ecommerce controller.xml file so it doesn't have to rely on  
that request in the content app.

-David

>
> Thanks for your help.
> -Al
>
> On 1/20/07, David E. Jones <[hidden email]> wrote:
>>
>>
>> Al,
>>
>> Could you step back and describe a little more of what you are trying
>> to do, the code you are using, etc? You did a good job here of
>> explaining what happened but not really what you did or expected to
>> happen.
>>
>> In general if you are linking to another application, you don't use
>> the ofbizUrl tag or any of the code behind it, like the makeLink
>> method. There are a number of examples of this if you look around.
>>
>> -David
>>
>>
>> On Jan 20, 2007, at 2:52 AM, Al Byers wrote:
>>
>> > First of all, is this the correct protocol - I am not sure that
>> > what I am
>> > looking at is a bug, so rather than open a JIRA issue, I want to
>> > bring it up
>> > here, or should this sort of thing start with a JIRA entry?
>> >
>> > The RequestHandler.makeLink has a parameter, "fullPath", that I
>> > would think
>> > causes everything after the server and port string to be replaced
>> > by the
>> > passed url value.
>> > But at line 757 there is:
>> >
>> >        newURL.append(controlPath);
>> >
>> > So if I am doing a call from within the ecommerce webapp to a
>> > content webapp
>> > request, I get:
>> >
>> > http://localhost:8080/ecommerce/control/content/control/
>> > ViewSimpleContent?dataResourceId=10100
>> >
>> > Should there be a conditional append of the controlPath?
>> >
>> > -Al
>>
>>
>>
>>

[byersa]

David,

Thanks, but inquiring minds want to know - isn't that a bug in makeLink? I
just have to know or I can't go on with life.

-Al

On 1/20/07, David E. Jones <[hidden email]> wrote:

>
>
> On Jan 20, 2007, at 3:25 PM, Al Byers wrote:
>
> > David,
> >
> > Ok, but I thought this issue would stand on its own - is there a
> > reason why
> > the control path should be added to the url if the fullPath
> > parameter is
> > true? Either I don't understand the call structure for makeLink or
> > anyone
> > who tries to use it with fullPath set to true will not get the
> > expected
> > results.
> >
> > As for my application, I am using it in the content management
> > sense, and
> > the the "<content...>" tag (under certain conditions) creates an
> > iframe in
> > the HTML that needs to point to the "/content/control/
> > ViewSimpleContent"
> > request and I am in the ecommerce app. So I figured I could use the
> > makeLink
> > call to create the correct url. I know that the "<link...>" tag
> > does the
> > same sort of thing, but it does not use makeLink in this way and
> > this seemed
> > like the way that makeLink should work.  I thought about it and
> > figured it
> > is easier to just add the request to ecommerce, but thought the
> > makeLink
> > issue was worth raising.
>
> Do you mean in the screen widget? You can just use the link tag with
> the "inter-app" url-mode.
>
> I think I like this other way better though, ie adding a request-map
> in the ecommerce controller.xml file so it doesn't have to rely on
> that request in the content app.
>
> -David
>
>
> >
> > Thanks for your help.
> > -Al
> >
> > On 1/20/07, David E. Jones <[hidden email]> wrote:
> >>
> >>
> >> Al,
> >>
> >> Could you step back and describe a little more of what you are trying
> >> to do, the code you are using, etc? You did a good job here of
> >> explaining what happened but not really what you did or expected to
> >> happen.
> >>
> >> In general if you are linking to another application, you don't use
> >> the ofbizUrl tag or any of the code behind it, like the makeLink
> >> method. There are a number of examples of this if you look around.
> >>
> >> -David
> >>
> >>
> >> On Jan 20, 2007, at 2:52 AM, Al Byers wrote:
> >>
> >> > First of all, is this the correct protocol - I am not sure that
> >> > what I am
> >> > looking at is a bug, so rather than open a JIRA issue, I want to
> >> > bring it up
> >> > here, or should this sort of thing start with a JIRA entry?
> >> >
> >> > The RequestHandler.makeLink has a parameter, "fullPath", that I
> >> > would think
> >> > causes everything after the server and port string to be replaced
> >> > by the
> >> > passed url value.
> >> > But at line 757 there is:
> >> >
> >> >        newURL.append(controlPath);
> >> >
> >> > So if I am doing a call from within the ecommerce webapp to a
> >> > content webapp
> >> > request, I get:
> >> >
> >> > http://localhost:8080/ecommerce/control/content/control/
> >> > ViewSimpleContent?dataResourceId=10100
> >> >
> >> > Should there be a conditional append of the controlPath?
> >> >
> >> > -Al
> >>
> >>
> >>
> >>
>
>
>
>