[jira] Closed: (OFBIZ-1366) Comparaison between Integer and String in RecurrenceRule.java
[ https://issues.apache.org/jira/browse/OFBIZ-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-1366. -- Resolution: Invalid Assignee: Jacques Le Roux RecurrenceRule.java has been rewritten/refactored and I suppose that this comment was written using an older version since it was already done the 24 oct 2007. Morevoer it seems that the concerns does not apply anymore since a calendar is used now for this comparaison. > Comparaison between Integer and String in RecurrenceRule.java > - > > Key: OFBIZ-1366 > URL: https://issues.apache.org/jira/browse/OFBIZ-1366 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: SVN trunk > Environment: na >Reporter: Fabien Carrion >Assignee: Jacques Le Roux > Fix For: SVN trunk > > > The mail on this link is right > http://mail-archives.apache.org/mod_mbox/ofbiz-user/200706.mbox/[EMAIL > PROTECTED] > I just made the try and confirm this bug exists. In recurenceRule, instead of > having: > if (!byMinuteList.contains(new Integer(cal.get(Calendar.MINUTE > we should have > if (!byMinuteList.contains(new String(cal.get(Calendar.MINUTE > Thanks > Fabien -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-1263) WSDL returns error if datatype of parameter is Long or Timestamp
[ https://issues.apache.org/jira/browse/OFBIZ-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-1263. -- Resolution: Fixed Fix Version/s: Release Branch 4.0 SVN trunk Assignee: Jacques Le Roux Thans Eriks, Your patch is in trunk revision 605075, release4.0 605076 > WSDL returns error if datatype of parameter is Long or Timestamp > > > Key: OFBIZ-1263 > URL: https://issues.apache.org/jira/browse/OFBIZ-1263 > Project: OFBiz > Issue Type: Bug > Components: framework >Reporter: Eriks Dobelis >Assignee: Jacques Le Roux >Priority: Minor > Fix For: SVN trunk, Release Branch 4.0 > > Attachments: model_param.diff > > > ModelParam.java does not include all datatype used in Ofbiz. If a service is > exported and one of its parameters are of type Long or Timestamp then error > is returned on requesting ...?WSDL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1249) To permit to to calculate on a DATE object in minilang
[ https://issues.apache.org/jira/browse/OFBIZ-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552615 ] Jacques Le Roux commented on OFBIZ-1249: I will try and add XSD and annotation > To permit to to calculate on a DATE object in minilang > -- > > Key: OFBIZ-1249 > URL: https://issues.apache.org/jira/browse/OFBIZ-1249 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk > Environment: all >Reporter: Fabien Carrion >Assignee: Jacques Le Roux >Priority: Minor > Fix For: SVN trunk > > Attachments: calculate_date_diff.patch, set_calendar.patch > > > This patch lets use the calculate function in the minilang service function > with java.util.Date and java.sql.Date object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
mainDecoratorLocation is broken and does not work as designed. was mainDecoratorLocation was Include of controllers
Sorry I can't leave this alone.
but every reason I have been given I have shown it can not work the way
it was intended. to allow custom apps to give a a new main-decorator to
an already existing app.
So either some more work has to be done on it, like what scott has
proposed,
Adopt a simple solution.
rename the mainDecoratorLocation to applicationname-mainDecoratorLocation
or add applicationname-mainDecoratorLocation to the context as well.
maybe add some lines in the screens that say if
applicationname-mainDecoratorLocation is not null use
mainDecoratorLocation=applicationname-mainDecoratorLocation
this would take care of backward compatibility
I am wondering how many are actually using this feature and how.
Chris Howe sent the following on 12/17/2007 4:44 PM:
> It's already in the controller.
>
> page="component://content/widget/CommonScreens.xml#main"/>
> You need to update the servlet that when it reads where to go, that it puts
> that value of page into the context. Then your decorator can pull it out.
>
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 6:39:46 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> ah gee just found a flaw
> the @page value into the context
> does that go into the products or application controller.
> will that create a backward compatibility problem?
>
>
>
> Chris Howe sent the following on 12/17/2007 4:28 PM:
>> sorry, that should be page.startsWith("component://...")
>> - Original Message
>> From: Chris Howe <[EMAIL PROTECTED]>
>> To: dev@ofbiz.apache.org
>> Sent: Monday, December 17, 2007 6:16:14 PM
>> Subject: Re: mainDecoratorLocation was Include of controllers
>>
>>
>> You'll need to get put the @page value into the context and
>> run a script in your main-decorator to determine the correct values
>>
>> if (page.like("component://partymgr")
>> applicationMenuName = "Party";
>> elseif(page.like("component://product")
>> applicationMenuName="Product";
>> etc
>> parameters.put("applicationMenuName", applicationMenuName);
>>
>> then in your main-decorator, instead of having
>> global="true"/>
>> you will have
>> > vlaue="${parameters.applicationMenuName}"/>
>> etc
>>
>> - Original Message
>> From: BJ Freeman <[EMAIL PROTECTED]>
>> To: dev@ofbiz.apache.org
>> Sent: Monday, December 17, 2007 6:07:08 PM
>> Subject: Re: mainDecoratorLocation was Include of controllers
>>
>>
>> here is an exmple
>> global="true"/>
>> > Value="component://setup/widget/setup/MainSetupMenus.xml"
>> global="true"/>
>>
>> now I can only setup that up for one menu
>> so how do I set that up for each menu for each app?
>>
>> BJ Freeman sent the following on 12/17/2007 3:59 PM:
>>> Oh.. well I did.
>>> and got all sorts of errors because I has not included what that
>>> application expected for its decorator.
>>>
>>> and I could not find a way to use the app specific information for
>> each
>>> app in my main-decorator.
>>>
>>> which started me down the road to app-mainDecoratorLocation
>>>
>>> Chris Howe sent the following on 12/17/2007 3:50 PM:
Woops...pressed the send button by mistake.
Make your own decorator in /myapp/widget/CommonScreens.xml
create a main-decorator and a global decorator and use modify to
>> your heart's content
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 5:33:01 PM
Subject: Re: mainDecoratorLocation was Include of controllers
so what is the approach that works?
Chris Howe sent the following on 12/17/2007 3:26 PM:
> That's what I wasn't understanding. Your approach fails with that
problem. The approach others have been using for the last two
>> years does
not. I thought you were asserting that both approaches fail.
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 5:21:55 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> been through this umteem times.
> sigh
> this is not the case for ftl files only widgets.
>
> I access a screen widget in x-app from my custom app.
> that screen has a decorator which eventually looks up
> mainDecoratorLocation to get the main-decorator
>
> so we are back to defining the mainDecoratorLocation.
> I can only define one mainDecoratorLocation in my web.xml
> so if I call another screen widget in y-app the information for
> the
> x-app main-decorator will be passed causing other problems.
>
> So there is no way a mainDecoratorLocation can be globally
> declared
to
> use more than one application screen widgets from the custom app
> So there is no use for using the mainDecoratorLocation outside
> that
app
> Chris Ho
Re: mainDecoratorLocation was Include of controllers
more specifically...
RequestHandler.java
after line 608
add:
req.setAttribute("_NEXT_PAGE", nextPage);
- Original Message
From: Chris Howe <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 6:44:43 PM
Subject: Re: mainDecoratorLocation was Include of controllers
It's already in the controller.
You need to update the servlet that when it reads where to go, that it
puts that value of page into the context. Then your decorator can pull
it out.
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 6:39:46 PM
Subject: Re: mainDecoratorLocation was Include of controllers
ah gee just found a flaw
the @page value into the context
does that go into the products or application controller.
will that create a backward compatibility problem?
Chris Howe sent the following on 12/17/2007 4:28 PM:
> sorry, that should be page.startsWith("component://...")
> - Original Message
> From: Chris Howe <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 6:16:14 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> You'll need to get put the @page value into the context and
> run a script in your main-decorator to determine the correct values
>
> if (page.like("component://partymgr")
> applicationMenuName = "Party";
> elseif(page.like("component://product")
> applicationMenuName="Product";
> etc
> parameters.put("applicationMenuName", applicationMenuName);
>
> then in your main-decorator, instead of having
>
> you will have
> vlaue="${parameters.applicationMenuName}"/>
> etc
>
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 6:07:08 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> here is an exmple
>
> Value="component://setup/widget/setup/MainSetupMenus.xml"
> global="true"/>
>
> now I can only setup that up for one menu
> so how do I set that up for each menu for each app?
>
> BJ Freeman sent the following on 12/17/2007 3:59 PM:
>> Oh.. well I did.
>> and got all sorts of errors because I has not included what that
>> application expected for its decorator.
>>
>> and I could not find a way to use the app specific information for
> each
>> app in my main-decorator.
>>
>> which started me down the road to app-mainDecoratorLocation
>>
>> Chris Howe sent the following on 12/17/2007 3:50 PM:
>>> Woops...pressed the send button by mistake.
>>>
>>> Make your own decorator in /myapp/widget/CommonScreens.xml
>>>
>>> create a main-decorator and a global decorator and use modify to
> your heart's content
>>> - Original Message
>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>> To: dev@ofbiz.apache.org
>>> Sent: Monday, December 17, 2007 5:33:01 PM
>>> Subject: Re: mainDecoratorLocation was Include of controllers
>>>
>>>
>>> so what is the approach that works?
>>>
>>>
>>> Chris Howe sent the following on 12/17/2007 3:26 PM:
That's what I wasn't understanding. Your approach fails with that
>>> problem. The approach others have been using for the last two
> years does
>>> not. I thought you were asserting that both approaches fail.
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 5:21:55 PM
Subject: Re: mainDecoratorLocation was Include of controllers
been through this umteem times.
sigh
this is not the case for ftl files only widgets.
I access a screen widget in x-app from my custom app.
that screen has a decorator which eventually looks up
mainDecoratorLocation to get the main-decorator
so we are back to defining the mainDecoratorLocation.
I can only define one mainDecoratorLocation in my web.xml
so if I call another screen widget in y-app the information for
the
x-app main-decorator will be passed causing other problems.
So there is no way a mainDecoratorLocation can be globally
declared
>>> to
use more than one application screen widgets from the custom app
So there is no use for using the mainDecoratorLocation outside
that
>>> app
Chris Howe sent the following on 12/17/2007 3:11 PM:
> I'm not sure I understand what you mean by access multiple apps
> from
a custom app. When you have a custom app, there is no notion
that
included screens, called screens, included controllers, etc have
a
>>> context
of ownership. The custom app is simply locating snippets of xml.
Nothing more. You can call snippets from one component or two
or
>>> five, it
doesn't matter. It only matters if you attempt to assert a
> context
>>> of
ownership; that calling a controller from the party controller
has
>>> some
meaning about associated party variables or contexts.
> - Original Message
>
Re: mainDecoratorLocation was Include of controllers
duh guess I need a nap..
you right .
:)
Chris Howe sent the following on 12/17/2007 4:44 PM:
> It's already in the controller.
>
> page="component://content/widget/CommonScreens.xml#main"/>
> You need to update the servlet that when it reads where to go, that it puts
> that value of page into the context. Then your decorator can pull it out.
>
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 6:39:46 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> ah gee just found a flaw
> the @page value into the context
> does that go into the products or application controller.
> will that create a backward compatibility problem?
>
>
>
> Chris Howe sent the following on 12/17/2007 4:28 PM:
>> sorry, that should be page.startsWith("component://...")
>> - Original Message
>> From: Chris Howe <[EMAIL PROTECTED]>
>> To: dev@ofbiz.apache.org
>> Sent: Monday, December 17, 2007 6:16:14 PM
>> Subject: Re: mainDecoratorLocation was Include of controllers
>>
>>
>> You'll need to get put the @page value into the context and
>> run a script in your main-decorator to determine the correct values
>>
>> if (page.like("component://partymgr")
>> applicationMenuName = "Party";
>> elseif(page.like("component://product")
>> applicationMenuName="Product";
>> etc
>> parameters.put("applicationMenuName", applicationMenuName);
>>
>> then in your main-decorator, instead of having
>> global="true"/>
>> you will have
>> > vlaue="${parameters.applicationMenuName}"/>
>> etc
>>
>> - Original Message
>> From: BJ Freeman <[EMAIL PROTECTED]>
>> To: dev@ofbiz.apache.org
>> Sent: Monday, December 17, 2007 6:07:08 PM
>> Subject: Re: mainDecoratorLocation was Include of controllers
>>
>>
>> here is an exmple
>> global="true"/>
>> > Value="component://setup/widget/setup/MainSetupMenus.xml"
>> global="true"/>
>>
>> now I can only setup that up for one menu
>> so how do I set that up for each menu for each app?
>>
>> BJ Freeman sent the following on 12/17/2007 3:59 PM:
>>> Oh.. well I did.
>>> and got all sorts of errors because I has not included what that
>>> application expected for its decorator.
>>>
>>> and I could not find a way to use the app specific information for
>> each
>>> app in my main-decorator.
>>>
>>> which started me down the road to app-mainDecoratorLocation
>>>
>>> Chris Howe sent the following on 12/17/2007 3:50 PM:
Woops...pressed the send button by mistake.
Make your own decorator in /myapp/widget/CommonScreens.xml
create a main-decorator and a global decorator and use modify to
>> your heart's content
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 5:33:01 PM
Subject: Re: mainDecoratorLocation was Include of controllers
so what is the approach that works?
Chris Howe sent the following on 12/17/2007 3:26 PM:
> That's what I wasn't understanding. Your approach fails with that
problem. The approach others have been using for the last two
>> years does
not. I thought you were asserting that both approaches fail.
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 5:21:55 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> been through this umteem times.
> sigh
> this is not the case for ftl files only widgets.
>
> I access a screen widget in x-app from my custom app.
> that screen has a decorator which eventually looks up
> mainDecoratorLocation to get the main-decorator
>
> so we are back to defining the mainDecoratorLocation.
> I can only define one mainDecoratorLocation in my web.xml
> so if I call another screen widget in y-app the information for
> the
> x-app main-decorator will be passed causing other problems.
>
> So there is no way a mainDecoratorLocation can be globally
> declared
to
> use more than one application screen widgets from the custom app
> So there is no use for using the mainDecoratorLocation outside
> that
app
> Chris Howe sent the following on 12/17/2007 3:11 PM:
>> I'm not sure I understand what you mean by access multiple apps
>> from
> a custom app. When you have a custom app, there is no notion
> that
> included screens, called screens, included controllers, etc have
> a
context
> of ownership. The custom app is simply locating snippets of xml.
> Nothing more. You can call snippets from one component or two
> or
five, it
> doesn't matter. It only matters if you attempt to assert a
>> context
of
> ownership; that calling a controller from the party controller
> has
some
> meaning about associated party variable
Re: mainDecoratorLocation was Include of controllers
It's already in the controller.
You need to update the servlet that when it reads where to go, that it puts
that value of page into the context. Then your decorator can pull it out.
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 6:39:46 PM
Subject: Re: mainDecoratorLocation was Include of controllers
ah gee just found a flaw
the @page value into the context
does that go into the products or application controller.
will that create a backward compatibility problem?
Chris Howe sent the following on 12/17/2007 4:28 PM:
> sorry, that should be page.startsWith("component://...")
> - Original Message
> From: Chris Howe <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 6:16:14 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> You'll need to get put the @page value into the context and
> run a script in your main-decorator to determine the correct values
>
> if (page.like("component://partymgr")
> applicationMenuName = "Party";
> elseif(page.like("component://product")
> applicationMenuName="Product";
> etc
> parameters.put("applicationMenuName", applicationMenuName);
>
> then in your main-decorator, instead of having
>
> you will have
> vlaue="${parameters.applicationMenuName}"/>
> etc
>
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 6:07:08 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> here is an exmple
>
> Value="component://setup/widget/setup/MainSetupMenus.xml"
> global="true"/>
>
> now I can only setup that up for one menu
> so how do I set that up for each menu for each app?
>
> BJ Freeman sent the following on 12/17/2007 3:59 PM:
>> Oh.. well I did.
>> and got all sorts of errors because I has not included what that
>> application expected for its decorator.
>>
>> and I could not find a way to use the app specific information for
> each
>> app in my main-decorator.
>>
>> which started me down the road to app-mainDecoratorLocation
>>
>> Chris Howe sent the following on 12/17/2007 3:50 PM:
>>> Woops...pressed the send button by mistake.
>>>
>>> Make your own decorator in /myapp/widget/CommonScreens.xml
>>>
>>> create a main-decorator and a global decorator and use modify to
> your heart's content
>>> - Original Message
>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>> To: dev@ofbiz.apache.org
>>> Sent: Monday, December 17, 2007 5:33:01 PM
>>> Subject: Re: mainDecoratorLocation was Include of controllers
>>>
>>>
>>> so what is the approach that works?
>>>
>>>
>>> Chris Howe sent the following on 12/17/2007 3:26 PM:
That's what I wasn't understanding. Your approach fails with that
>>> problem. The approach others have been using for the last two
> years does
>>> not. I thought you were asserting that both approaches fail.
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 5:21:55 PM
Subject: Re: mainDecoratorLocation was Include of controllers
been through this umteem times.
sigh
this is not the case for ftl files only widgets.
I access a screen widget in x-app from my custom app.
that screen has a decorator which eventually looks up
mainDecoratorLocation to get the main-decorator
so we are back to defining the mainDecoratorLocation.
I can only define one mainDecoratorLocation in my web.xml
so if I call another screen widget in y-app the information for
the
x-app main-decorator will be passed causing other problems.
So there is no way a mainDecoratorLocation can be globally
declared
>>> to
use more than one application screen widgets from the custom app
So there is no use for using the mainDecoratorLocation outside
that
>>> app
Chris Howe sent the following on 12/17/2007 3:11 PM:
> I'm not sure I understand what you mean by access multiple apps
> from
a custom app. When you have a custom app, there is no notion
that
included screens, called screens, included controllers, etc have
a
>>> context
of ownership. The custom app is simply locating snippets of xml.
Nothing more. You can call snippets from one component or two
or
>>> five, it
doesn't matter. It only matters if you attempt to assert a
> context
>>> of
ownership; that calling a controller from the party controller
has
>>> some
meaning about associated party variables or contexts.
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 4:57:18 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> good point. #1
> so I will not put this to sleep and do it for my releases until,
> as
>>
Re: mainDecoratorLocation was Include of controllers
ah gee just found a flaw
the @page value into the context
does that go into the products or application controller.
will that create a backward compatibility problem?
Chris Howe sent the following on 12/17/2007 4:28 PM:
> sorry, that should be page.startsWith("component://...")
> - Original Message
> From: Chris Howe <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 6:16:14 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> You'll need to get put the @page value into the context and
> run a script in your main-decorator to determine the correct values
>
> if (page.like("component://partymgr")
> applicationMenuName = "Party";
> elseif(page.like("component://product")
> applicationMenuName="Product";
> etc
> parameters.put("applicationMenuName", applicationMenuName);
>
> then in your main-decorator, instead of having
>
> you will have
> vlaue="${parameters.applicationMenuName}"/>
> etc
>
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 6:07:08 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> here is an exmple
>
> Value="component://setup/widget/setup/MainSetupMenus.xml"
> global="true"/>
>
> now I can only setup that up for one menu
> so how do I set that up for each menu for each app?
>
> BJ Freeman sent the following on 12/17/2007 3:59 PM:
>> Oh.. well I did.
>> and got all sorts of errors because I has not included what that
>> application expected for its decorator.
>>
>> and I could not find a way to use the app specific information for
> each
>> app in my main-decorator.
>>
>> which started me down the road to app-mainDecoratorLocation
>>
>> Chris Howe sent the following on 12/17/2007 3:50 PM:
>>> Woops...pressed the send button by mistake.
>>>
>>> Make your own decorator in /myapp/widget/CommonScreens.xml
>>>
>>> create a main-decorator and a global decorator and use modify to
> your heart's content
>>> - Original Message
>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>> To: dev@ofbiz.apache.org
>>> Sent: Monday, December 17, 2007 5:33:01 PM
>>> Subject: Re: mainDecoratorLocation was Include of controllers
>>>
>>>
>>> so what is the approach that works?
>>>
>>>
>>> Chris Howe sent the following on 12/17/2007 3:26 PM:
That's what I wasn't understanding. Your approach fails with that
>>> problem. The approach others have been using for the last two
> years does
>>> not. I thought you were asserting that both approaches fail.
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 5:21:55 PM
Subject: Re: mainDecoratorLocation was Include of controllers
been through this umteem times.
sigh
this is not the case for ftl files only widgets.
I access a screen widget in x-app from my custom app.
that screen has a decorator which eventually looks up
mainDecoratorLocation to get the main-decorator
so we are back to defining the mainDecoratorLocation.
I can only define one mainDecoratorLocation in my web.xml
so if I call another screen widget in y-app the information for the
x-app main-decorator will be passed causing other problems.
So there is no way a mainDecoratorLocation can be globally declared
>>> to
use more than one application screen widgets from the custom app
So there is no use for using the mainDecoratorLocation outside that
>>> app
Chris Howe sent the following on 12/17/2007 3:11 PM:
> I'm not sure I understand what you mean by access multiple apps
> from
a custom app. When you have a custom app, there is no notion that
included screens, called screens, included controllers, etc have a
>>> context
of ownership. The custom app is simply locating snippets of xml.
Nothing more. You can call snippets from one component or two or
>>> five, it
doesn't matter. It only matters if you attempt to assert a
> context
>>> of
ownership; that calling a controller from the party controller has
>>> some
meaning about associated party variables or contexts.
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 4:57:18 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> good point. #1
> so I will not put this to sleep and do it for my releases until,
> as
you
> say it become a problem
>
> However the use of mainDecoratorLocation beyond an app should be
> discourage for access multiple apps from a custom app as well.
> the conflict of data in each main-decorator has specific app
> information.
>
>
>
>
> Chris Howe sent the following on 12/17/2007 2:47 PM:
>> Note: I'm not saying that prefixi
[jira] Issue Comment Edited: (OFBIZ-1531) implement a fix to solve the location="${parameters.mainDecoratorLocation} giving an error.
[
https://issues.apache.org/jira/browse/OFBIZ-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552587
]
bjfreeman edited comment on OFBIZ-1531 at 12/17/07 4:37 PM:
-
in then dev mailing list chris came up with a feasable solution
this is from his email.
You'll need to get put the @page value into the context and run a
script in your main-decorator to determine the correct values
if (page.like("component://partymgr")
applicationMenuName = "Party";
elseif(page.like("component://product")
applicationMenuName="Product";
etc
parameters.put("applicationMenuName", applicationMenuName);
then in your main-decorator, instead of having
you will have
etc
chris corrected :
sorry, that should be page.startsWith("component://...")
was (Author: bjfreeman):
in then dev mailing list chris came up with a feasable solution
this is from his email.
You'll need to get put the @page value into the context and run a
script in your main-decorator to determine the correct values
if (page.like("component://partymgr")
applicationMenuName = "Party";
elseif(page.like("component://product")
applicationMenuName="Product";
etc
parameters.put("applicationMenuName", applicationMenuName);
then in your main-decorator, instead of having
you will have
etc
> implement a fix to solve the location="${parameters.mainDecoratorLocation}
> giving an error.
> ---
>
> Key: OFBIZ-1531
> URL: https://issues.apache.org/jira/browse/OFBIZ-1531
> Project: OFBiz
> Issue Type: Bug
>Affects Versions: SVN trunk, Release Branch 4.0
>Reporter: BJ Freeman
>Priority: Minor
> Fix For: SVN trunk, Release Branch 4.0
>
>
> Though not meant to be used for intra-apps
> the Include feature is being used that way in the controller for
> common-controller.
> there is a gotcha describe in the dev ML about
> .mainDecoratorLocation not being accessed when since it is in the context in
> the web.xml
> To remedy this
> all
> location="${parameters.mainDecoratorLocation}
> will be changed to the actual path found in the web.xml for each application.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: mainDecoratorLocation was Include of controllers
for those that have read christopher robin
"All I want is a little marmalade for my bread"
thanks chris have put in
https://issues.apache.org/jira/browse/OFBIZ-1531
will comment further with what I get working in my global when done
Chris Howe sent the following on 12/17/2007 4:28 PM:
> sorry, that should be page.startsWith("component://...")
> - Original Message
> From: Chris Howe <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 6:16:14 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> You'll need to get put the @page value into the context and
> run a script in your main-decorator to determine the correct values
>
> if (page.like("component://partymgr")
> applicationMenuName = "Party";
> elseif(page.like("component://product")
> applicationMenuName="Product";
> etc
> parameters.put("applicationMenuName", applicationMenuName);
>
> then in your main-decorator, instead of having
>
> you will have
> vlaue="${parameters.applicationMenuName}"/>
> etc
>
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 6:07:08 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> here is an exmple
>
> Value="component://setup/widget/setup/MainSetupMenus.xml"
> global="true"/>
>
> now I can only setup that up for one menu
> so how do I set that up for each menu for each app?
>
> BJ Freeman sent the following on 12/17/2007 3:59 PM:
>> Oh.. well I did.
>> and got all sorts of errors because I has not included what that
>> application expected for its decorator.
>>
>> and I could not find a way to use the app specific information for
> each
>> app in my main-decorator.
>>
>> which started me down the road to app-mainDecoratorLocation
>>
>> Chris Howe sent the following on 12/17/2007 3:50 PM:
>>> Woops...pressed the send button by mistake.
>>>
>>> Make your own decorator in /myapp/widget/CommonScreens.xml
>>>
>>> create a main-decorator and a global decorator and use modify to
> your heart's content
>>> - Original Message
>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>> To: dev@ofbiz.apache.org
>>> Sent: Monday, December 17, 2007 5:33:01 PM
>>> Subject: Re: mainDecoratorLocation was Include of controllers
>>>
>>>
>>> so what is the approach that works?
>>>
>>>
>>> Chris Howe sent the following on 12/17/2007 3:26 PM:
That's what I wasn't understanding. Your approach fails with that
>>> problem. The approach others have been using for the last two
> years does
>>> not. I thought you were asserting that both approaches fail.
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 5:21:55 PM
Subject: Re: mainDecoratorLocation was Include of controllers
been through this umteem times.
sigh
this is not the case for ftl files only widgets.
I access a screen widget in x-app from my custom app.
that screen has a decorator which eventually looks up
mainDecoratorLocation to get the main-decorator
so we are back to defining the mainDecoratorLocation.
I can only define one mainDecoratorLocation in my web.xml
so if I call another screen widget in y-app the information for the
x-app main-decorator will be passed causing other problems.
So there is no way a mainDecoratorLocation can be globally declared
>>> to
use more than one application screen widgets from the custom app
So there is no use for using the mainDecoratorLocation outside that
>>> app
Chris Howe sent the following on 12/17/2007 3:11 PM:
> I'm not sure I understand what you mean by access multiple apps
> from
a custom app. When you have a custom app, there is no notion that
included screens, called screens, included controllers, etc have a
>>> context
of ownership. The custom app is simply locating snippets of xml.
Nothing more. You can call snippets from one component or two or
>>> five, it
doesn't matter. It only matters if you attempt to assert a
> context
>>> of
ownership; that calling a controller from the party controller has
>>> some
meaning about associated party variables or contexts.
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 4:57:18 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> good point. #1
> so I will not put this to sleep and do it for my releases until,
> as
you
> say it become a problem
>
> However the use of mainDecoratorLocation beyond an app should be
> discourage for access multiple apps from a custom app as well.
> the conflict of data in each main-decorator has specific app
> information.
>
>
>
>
> Chris Howe sent the followin
[jira] Resolved: (OFBIZ-1531) implement a fix to solve the location="${parameters.mainDecoratorLocation} giving an error.
[
https://issues.apache.org/jira/browse/OFBIZ-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BJ Freeman resolved OFBIZ-1531.
---
Resolution: Fixed
in then dev mailing list chris came up with a feasable solution
this is from his email.
You'll need to get put the @page value into the context and run a
script in your main-decorator to determine the correct values
if (page.like("component://partymgr")
applicationMenuName = "Party";
elseif(page.like("component://product")
applicationMenuName="Product";
etc
parameters.put("applicationMenuName", applicationMenuName);
then in your main-decorator, instead of having
you will have
etc
> implement a fix to solve the location="${parameters.mainDecoratorLocation}
> giving an error.
> ---
>
> Key: OFBIZ-1531
> URL: https://issues.apache.org/jira/browse/OFBIZ-1531
> Project: OFBiz
> Issue Type: Bug
>Affects Versions: SVN trunk, Release Branch 4.0
>Reporter: BJ Freeman
>Priority: Minor
> Fix For: SVN trunk, Release Branch 4.0
>
>
> Though not meant to be used for intra-apps
> the Include feature is being used that way in the controller for
> common-controller.
> there is a gotcha describe in the dev ML about
> .mainDecoratorLocation not being accessed when since it is in the context in
> the web.xml
> To remedy this
> all
> location="${parameters.mainDecoratorLocation}
> will be changed to the actual path found in the web.xml for each application.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: mainDecoratorLocation was Include of controllers
sorry, that should be page.startsWith("component://...")
- Original Message
From: Chris Howe <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 6:16:14 PM
Subject: Re: mainDecoratorLocation was Include of controllers
You'll need to get put the @page value into the context and
run a script in your main-decorator to determine the correct values
if (page.like("component://partymgr")
applicationMenuName = "Party";
elseif(page.like("component://product")
applicationMenuName="Product";
etc
parameters.put("applicationMenuName", applicationMenuName);
then in your main-decorator, instead of having
you will have
etc
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 6:07:08 PM
Subject: Re: mainDecoratorLocation was Include of controllers
here is an exmple
now I can only setup that up for one menu
so how do I set that up for each menu for each app?
BJ Freeman sent the following on 12/17/2007 3:59 PM:
> Oh.. well I did.
> and got all sorts of errors because I has not included what that
> application expected for its decorator.
>
> and I could not find a way to use the app specific information for
each
> app in my main-decorator.
>
> which started me down the road to app-mainDecoratorLocation
>
> Chris Howe sent the following on 12/17/2007 3:50 PM:
>> Woops...pressed the send button by mistake.
>>
>> Make your own decorator in /myapp/widget/CommonScreens.xml
>>
>> create a main-decorator and a global decorator and use modify to
your heart's content
>>
>> - Original Message
>> From: BJ Freeman <[EMAIL PROTECTED]>
>> To: dev@ofbiz.apache.org
>> Sent: Monday, December 17, 2007 5:33:01 PM
>> Subject: Re: mainDecoratorLocation was Include of controllers
>>
>>
>> so what is the approach that works?
>>
>>
>> Chris Howe sent the following on 12/17/2007 3:26 PM:
>>> That's what I wasn't understanding. Your approach fails with that
>> problem. The approach others have been using for the last two
years does
>> not. I thought you were asserting that both approaches fail.
>>> - Original Message
>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>> To: dev@ofbiz.apache.org
>>> Sent: Monday, December 17, 2007 5:21:55 PM
>>> Subject: Re: mainDecoratorLocation was Include of controllers
>>>
>>>
>>> been through this umteem times.
>>> sigh
>>> this is not the case for ftl files only widgets.
>>>
>>> I access a screen widget in x-app from my custom app.
>>> that screen has a decorator which eventually looks up
>>> mainDecoratorLocation to get the main-decorator
>>>
>>> so we are back to defining the mainDecoratorLocation.
>>> I can only define one mainDecoratorLocation in my web.xml
>>> so if I call another screen widget in y-app the information for the
>>> x-app main-decorator will be passed causing other problems.
>>>
>>> So there is no way a mainDecoratorLocation can be globally declared
>> to
>>> use more than one application screen widgets from the custom app
>>> So there is no use for using the mainDecoratorLocation outside that
>> app
>>>
>>> Chris Howe sent the following on 12/17/2007 3:11 PM:
I'm not sure I understand what you mean by access multiple apps
from
>>> a custom app. When you have a custom app, there is no notion that
>>> included screens, called screens, included controllers, etc have a
>> context
>>> of ownership. The custom app is simply locating snippets of xml.
>>> Nothing more. You can call snippets from one component or two or
>> five, it
>>> doesn't matter. It only matters if you attempt to assert a
context
>> of
>>> ownership; that calling a controller from the party controller has
>> some
>>> meaning about associated party variables or contexts.
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 4:57:18 PM
Subject: Re: mainDecoratorLocation was Include of controllers
good point. #1
so I will not put this to sleep and do it for my releases until,
as
>>> you
say it become a problem
However the use of mainDecoratorLocation beyond an app should be
discourage for access multiple apps from a custom app as well.
the conflict of data in each main-decorator has specific app
information.
Chris Howe sent the following on 12/17/2007 2:47 PM:
> Note: I'm not saying that prefixing the variable is a bad
solution
I'm just throwing out the downsides of it
> 1) The use case you present should not be encouraged. The
opportunity for conflicting requests/views between multiple
>>> controllers will
drive you bat crazy with unexpected results. The intent of the
>>>
element is to modularize commonly used requests/views. Throwing
everything in a bag and hoping you pull the expected result/view
>> out
>>> is kind
of dangerous. Absent a compellin
Re: mainDecoratorLocation was Include of controllers
that looks reasonable.have to looks up page.
Chris Howe sent the following on 12/17/2007 4:16 PM:
> You'll need to get put the @page value into the context and run a
> script in your main-decorator to determine the correct values
>
> if (page.like("component://partymgr")
> applicationMenuName = "Party";
> elseif(page.like("component://product")
> applicationMenuName="Product";
> etc
> parameters.put("applicationMenuName", applicationMenuName);
>
> then in your main-decorator, instead of having
>
> you will have
>
> etc
>
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 6:07:08 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> here is an exmple
>
> Value="component://setup/widget/setup/MainSetupMenus.xml"
> global="true"/>
>
> now I can only setup that up for one menu
> so how do I set that up for each menu for each app?
>
> BJ Freeman sent the following on 12/17/2007 3:59 PM:
>> Oh.. well I did.
>> and got all sorts of errors because I has not included what that
>> application expected for its decorator.
>>
>> and I could not find a way to use the app specific information for
> each
>> app in my main-decorator.
>>
>> which started me down the road to app-mainDecoratorLocation
>>
>> Chris Howe sent the following on 12/17/2007 3:50 PM:
>>> Woops...pressed the send button by mistake.
>>>
>>> Make your own decorator in /myapp/widget/CommonScreens.xml
>>>
>>> create a main-decorator and a global decorator and use modify to
> your heart's content
>>> - Original Message
>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>> To: dev@ofbiz.apache.org
>>> Sent: Monday, December 17, 2007 5:33:01 PM
>>> Subject: Re: mainDecoratorLocation was Include of controllers
>>>
>>>
>>> so what is the approach that works?
>>>
>>>
>>> Chris Howe sent the following on 12/17/2007 3:26 PM:
That's what I wasn't understanding. Your approach fails with that
>>> problem. The approach others have been using for the last two
> years does
>>> not. I thought you were asserting that both approaches fail.
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 5:21:55 PM
Subject: Re: mainDecoratorLocation was Include of controllers
been through this umteem times.
sigh
this is not the case for ftl files only widgets.
I access a screen widget in x-app from my custom app.
that screen has a decorator which eventually looks up
mainDecoratorLocation to get the main-decorator
so we are back to defining the mainDecoratorLocation.
I can only define one mainDecoratorLocation in my web.xml
so if I call another screen widget in y-app the information for the
x-app main-decorator will be passed causing other problems.
So there is no way a mainDecoratorLocation can be globally declared
>>> to
use more than one application screen widgets from the custom app
So there is no use for using the mainDecoratorLocation outside that
>>> app
Chris Howe sent the following on 12/17/2007 3:11 PM:
> I'm not sure I understand what you mean by access multiple apps
> from
a custom app. When you have a custom app, there is no notion that
included screens, called screens, included controllers, etc have a
>>> context
of ownership. The custom app is simply locating snippets of xml.
Nothing more. You can call snippets from one component or two or
>>> five, it
doesn't matter. It only matters if you attempt to assert a
> context
>>> of
ownership; that calling a controller from the party controller has
>>> some
meaning about associated party variables or contexts.
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 4:57:18 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> good point. #1
> so I will not put this to sleep and do it for my releases until,
> as
you
> say it become a problem
>
> However the use of mainDecoratorLocation beyond an app should be
> discourage for access multiple apps from a custom app as well.
> the conflict of data in each main-decorator has specific app
> information.
>
>
>
>
> Chris Howe sent the following on 12/17/2007 2:47 PM:
>> Note: I'm not saying that prefixing the variable is a bad
> solution
> I'm just throwing out the downsides of it
>> 1) The use case you present should not be encouraged. The
> opportunity for conflicting requests/views between multiple
controllers will
> drive you bat crazy with unexpected results. The intent of the
> element is to modularize commonly used requests/views. Throwing
> everything in a bag and hoping you pull
Re: mainDecoratorLocation was Include of controllers
yes. Adrian Crum sent the following on 12/17/2007 4:15 PM: > That's probably where the disconnect is coming in. The way the system is > set up, you would have your own application menu, which would look > something like: > > My Custom Application > Main | My Page 1 | My Page 2 | Party Communications | Product Lookup | > Logout > > The Party Communcations screen would come from the Party Manager, and > the Product Lookup screen would come from Product Manager. > > -Adrian > > > BJ Freeman wrote: > >> here is an exmple >> >> > Value="component://setup/widget/setup/MainSetupMenus.xml" global="true"/> >> >> now I can only setup that up for one menu >> so how do I set that up for each menu for each app? >> >> BJ Freeman sent the following on 12/17/2007 3:59 PM: >> >>> Oh.. well I did. >>> and got all sorts of errors because I has not included what that >>> application expected for its decorator. >>> >>> and I could not find a way to use the app specific information for each >>> app in my main-decorator. >>> >>> which started me down the road to app-mainDecoratorLocation >>> >>> Chris Howe sent the following on 12/17/2007 3:50 PM: >>> Woops...pressed the send button by mistake. Make your own decorator in /myapp/widget/CommonScreens.xml create a main-decorator and a global decorator and use modify to your heart's content - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 5:33:01 PM Subject: Re: mainDecoratorLocation was Include of controllers so what is the approach that works? Chris Howe sent the following on 12/17/2007 3:26 PM: > That's what I wasn't understanding. Your approach fails with that problem. The approach others have been using for the last two years does not. I thought you were asserting that both approaches fail. > - Original Message > From: BJ Freeman <[EMAIL PROTECTED]> > To: dev@ofbiz.apache.org > Sent: Monday, December 17, 2007 5:21:55 PM > Subject: Re: mainDecoratorLocation was Include of controllers > > > been through this umteem times. > sigh > this is not the case for ftl files only widgets. > > I access a screen widget in x-app from my custom app. > that screen has a decorator which eventually looks up > mainDecoratorLocation to get the main-decorator > > so we are back to defining the mainDecoratorLocation. > I can only define one mainDecoratorLocation in my web.xml > so if I call another screen widget in y-app the information for the > x-app main-decorator will be passed causing other problems. > > So there is no way a mainDecoratorLocation can be globally declared to > use more than one application screen widgets from the custom app > So there is no use for using the mainDecoratorLocation outside that app > Chris Howe sent the following on 12/17/2007 3:11 PM: > >> I'm not sure I understand what you mean by access multiple apps from > > a custom app. When you have a custom app, there is no notion that > included screens, called screens, included controllers, etc have a context > of ownership. The custom app is simply locating snippets of xml. > Nothing more. You can call snippets from one component or two or five, it > doesn't matter. It only matters if you attempt to assert a context of > ownership; that calling a controller from the party controller has some > meaning about associated party variables or contexts. > >> - Original Message >> From: BJ Freeman <[EMAIL PROTECTED]> >> To: dev@ofbiz.apache.org >> Sent: Monday, December 17, 2007 4:57:18 PM >> Subject: Re: mainDecoratorLocation was Include of controllers >> >> >> good point. #1 >> so I will not put this to sleep and do it for my releases until, as > > you > >> say it become a problem >> >> However the use of mainDecoratorLocation beyond an app should be >> discourage for access multiple apps from a custom app as well. >> the conflict of data in each main-decorator has specific app >> information. >> >> >> >> >> Chris Howe sent the following on 12/17/2007 2:47 PM: >> >>> Note: I'm not saying that prefixing the variable is a bad solution >> >> I'm just throwing out the downsides of it >> >>> 1) The use case you present should not be encouraged. The >> >> opportunity for conflicting requests/views between multiple > > controllers will > >> drive you bat crazy with unexpected results. The intent of the > > > >> element is to modularize commonly used requests/views. Throwing >> everything in a bag and hoping you pull th
Re: mainDecoratorLocation was Include of controllers
Chris Howe sent the following on 12/17/2007 4:09 PM: > be sure to define the mainDecoratorLocation in the web.xml as > component://myapp/widget/CommonScreens.xml yes > >>From there the only app specific stuff is the whether it's including >>leftbar/rightbar/etc. You will need to define those basic ones as well. you have not looked at the current main-decoroators here is one from party 1) defines Java scripts to use 2) defines So I can only define one so when partymgr looks for the active app it will go to setup instead of patrymgr. This mean I have a lot of overhead in maintainence instead of just using the partymgr as is. or like > > - Original Message > From: BJ Freeman <[EMAIL PROTECTED]> > To: dev@ofbiz.apache.org > Sent: Monday, December 17, 2007 5:59:58 PM > Subject: Re: mainDecoratorLocation was Include of controllers > > > Oh.. well I did. > and got all sorts of errors because I has not included what that > application expected for its decorator. > > and I could not find a way to use the app specific information for each > app in my main-decorator. > > which started me down the road to app-mainDecoratorLocation > > Chris Howe sent the following on 12/17/2007 3:50 PM: >> Woops...pressed the send button by mistake. >> >> Make your own decorator in /myapp/widget/CommonScreens.xml >> >> create a main-decorator and a global decorator and use modify to your > heart's content >> - Original Message >> From: BJ Freeman <[EMAIL PROTECTED]> >> To: dev@ofbiz.apache.org >> Sent: Monday, December 17, 2007 5:33:01 PM >> Subject: Re: mainDecoratorLocation was Include of controllers >> >> >> so what is the approach that works? >> >> >> Chris Howe sent the following on 12/17/2007 3:26 PM: >>> That's what I wasn't understanding. Your approach fails with that >> problem. The approach others have been using for the last two years > does >> not. I thought you were asserting that both approaches fail. >>> - Original Message >>> From: BJ Freeman <[EMAIL PROTECTED]> >>> To: dev@ofbiz.apache.org >>> Sent: Monday, December 17, 2007 5:21:55 PM >>> Subject: Re: mainDecoratorLocation was Include of controllers >>> >>> >>> been through this umteem times. >>> sigh >>> this is not the case for ftl files only widgets. >>> >>> I access a screen widget in x-app from my custom app. >>> that screen has a decorator which eventually looks up >>> mainDecoratorLocation to get the main-decorator >>> >>> so we are back to defining the mainDecoratorLocation. >>> I can only define one mainDecoratorLocation in my web.xml >>> so if I call another screen widget in y-app the information for the >>> x-app main-decorator will be passed causing other problems. >>> >>> So there is no way a mainDecoratorLocation can be globally declared >> to >>> use more than one application screen widgets from the custom app >>> So there is no use for using the mainDecoratorLocation outside that >> app >>> >>> Chris Howe sent the following on 12/17/2007 3:11 PM: I'm not sure I understand what you mean by access multiple apps > from >>> a custom app. When you have a custom app, there is no notion that >>> included screens, called screens, included controllers, etc have a >> context >>> of ownership. The custom app is simply locating snippets of xml. >>> Nothing more. You can call snippets from one component or two or >> five, it >>> doesn't matter. It only matters if you attempt to assert a context >> of >>> ownership; that calling a controller from the party controller has >> some >>> meaning about associated party variables or contexts. - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 4:57:18 PM Subject: Re: mainDecoratorLocation was Include of controllers good point. #1 so I will not put this to sleep and do it for my releases until, as >>> you say it become a problem However the use of mainDecoratorLocation beyond an app should be discourage for access multiple apps from a custom app as well. the conflict of data in each main-decorator has specific app information. Chris Howe sent the following on 12/17/2007 2:47 PM: > Note: I'm not saying that prefixing the variable is a bad solution I'm just throwing out the downsides of it > 1) The use case you present should not be encouraged. The opportunity for conflicting requests/views between multiple >>> controllers will drive you bat crazy with unexpected results. The intent of the >>> element is to modularize commonly used requests/views. Throwing everything in a bag and hoping you pull the expected result/view >> out >>> is kind of dangerous. Absent a compelling use case, movement towards an external widely adopted standard, or utilizing more generic >>> practices it's difficult to overcome the backward co
Re: mainDecoratorLocation was Include of controllers
You'll need to get put the @page value into the context and run a
script in your main-decorator to determine the correct values
if (page.like("component://partymgr")
applicationMenuName = "Party";
elseif(page.like("component://product")
applicationMenuName="Product";
etc
parameters.put("applicationMenuName", applicationMenuName);
then in your main-decorator, instead of having
you will have
etc
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 6:07:08 PM
Subject: Re: mainDecoratorLocation was Include of controllers
here is an exmple
now I can only setup that up for one menu
so how do I set that up for each menu for each app?
BJ Freeman sent the following on 12/17/2007 3:59 PM:
> Oh.. well I did.
> and got all sorts of errors because I has not included what that
> application expected for its decorator.
>
> and I could not find a way to use the app specific information for
each
> app in my main-decorator.
>
> which started me down the road to app-mainDecoratorLocation
>
> Chris Howe sent the following on 12/17/2007 3:50 PM:
>> Woops...pressed the send button by mistake.
>>
>> Make your own decorator in /myapp/widget/CommonScreens.xml
>>
>> create a main-decorator and a global decorator and use modify to
your heart's content
>>
>> - Original Message
>> From: BJ Freeman <[EMAIL PROTECTED]>
>> To: dev@ofbiz.apache.org
>> Sent: Monday, December 17, 2007 5:33:01 PM
>> Subject: Re: mainDecoratorLocation was Include of controllers
>>
>>
>> so what is the approach that works?
>>
>>
>> Chris Howe sent the following on 12/17/2007 3:26 PM:
>>> That's what I wasn't understanding. Your approach fails with that
>> problem. The approach others have been using for the last two
years does
>> not. I thought you were asserting that both approaches fail.
>>> - Original Message
>>> From: BJ Freeman <[EMAIL PROTECTED]>
>>> To: dev@ofbiz.apache.org
>>> Sent: Monday, December 17, 2007 5:21:55 PM
>>> Subject: Re: mainDecoratorLocation was Include of controllers
>>>
>>>
>>> been through this umteem times.
>>> sigh
>>> this is not the case for ftl files only widgets.
>>>
>>> I access a screen widget in x-app from my custom app.
>>> that screen has a decorator which eventually looks up
>>> mainDecoratorLocation to get the main-decorator
>>>
>>> so we are back to defining the mainDecoratorLocation.
>>> I can only define one mainDecoratorLocation in my web.xml
>>> so if I call another screen widget in y-app the information for the
>>> x-app main-decorator will be passed causing other problems.
>>>
>>> So there is no way a mainDecoratorLocation can be globally declared
>> to
>>> use more than one application screen widgets from the custom app
>>> So there is no use for using the mainDecoratorLocation outside that
>> app
>>>
>>> Chris Howe sent the following on 12/17/2007 3:11 PM:
I'm not sure I understand what you mean by access multiple apps
from
>>> a custom app. When you have a custom app, there is no notion that
>>> included screens, called screens, included controllers, etc have a
>> context
>>> of ownership. The custom app is simply locating snippets of xml.
>>> Nothing more. You can call snippets from one component or two or
>> five, it
>>> doesn't matter. It only matters if you attempt to assert a
context
>> of
>>> ownership; that calling a controller from the party controller has
>> some
>>> meaning about associated party variables or contexts.
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 4:57:18 PM
Subject: Re: mainDecoratorLocation was Include of controllers
good point. #1
so I will not put this to sleep and do it for my releases until,
as
>>> you
say it become a problem
However the use of mainDecoratorLocation beyond an app should be
discourage for access multiple apps from a custom app as well.
the conflict of data in each main-decorator has specific app
information.
Chris Howe sent the following on 12/17/2007 2:47 PM:
> Note: I'm not saying that prefixing the variable is a bad
solution
I'm just throwing out the downsides of it
> 1) The use case you present should not be encouraged. The
opportunity for conflicting requests/views between multiple
>>> controllers will
drive you bat crazy with unexpected results. The intent of the
>>>
element is to modularize commonly used requests/views. Throwing
everything in a bag and hoping you pull the expected result/view
>> out
>>> is kind
of dangerous. Absent a compelling use case, movement towards an
external widely adopted standard, or utilizing more generic
>>> practices it's
difficult to overcome the backward compatibility issue.
> 2) if you were to address the backward compatibility issue by
>> ma
Re: mainDecoratorLocation was Include of controllers
That's probably where the disconnect is coming in. The way the system is set up, you would have your own application menu, which would look something like: My Custom Application Main | My Page 1 | My Page 2 | Party Communications | Product Lookup | Logout The Party Communcations screen would come from the Party Manager, and the Product Lookup screen would come from Product Manager. -Adrian BJ Freeman wrote: here is an exmple now I can only setup that up for one menu so how do I set that up for each menu for each app? BJ Freeman sent the following on 12/17/2007 3:59 PM: Oh.. well I did. and got all sorts of errors because I has not included what that application expected for its decorator. and I could not find a way to use the app specific information for each app in my main-decorator. which started me down the road to app-mainDecoratorLocation Chris Howe sent the following on 12/17/2007 3:50 PM: Woops...pressed the send button by mistake. Make your own decorator in /myapp/widget/CommonScreens.xml create a main-decorator and a global decorator and use modify to your heart's content - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 5:33:01 PM Subject: Re: mainDecoratorLocation was Include of controllers so what is the approach that works? Chris Howe sent the following on 12/17/2007 3:26 PM: That's what I wasn't understanding. Your approach fails with that problem. The approach others have been using for the last two years does not. I thought you were asserting that both approaches fail. - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 5:21:55 PM Subject: Re: mainDecoratorLocation was Include of controllers been through this umteem times. sigh this is not the case for ftl files only widgets. I access a screen widget in x-app from my custom app. that screen has a decorator which eventually looks up mainDecoratorLocation to get the main-decorator so we are back to defining the mainDecoratorLocation. I can only define one mainDecoratorLocation in my web.xml so if I call another screen widget in y-app the information for the x-app main-decorator will be passed causing other problems. So there is no way a mainDecoratorLocation can be globally declared to use more than one application screen widgets from the custom app So there is no use for using the mainDecoratorLocation outside that app Chris Howe sent the following on 12/17/2007 3:11 PM: I'm not sure I understand what you mean by access multiple apps from a custom app. When you have a custom app, there is no notion that included screens, called screens, included controllers, etc have a context of ownership. The custom app is simply locating snippets of xml. Nothing more. You can call snippets from one component or two or five, it doesn't matter. It only matters if you attempt to assert a context of ownership; that calling a controller from the party controller has some meaning about associated party variables or contexts. - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 4:57:18 PM Subject: Re: mainDecoratorLocation was Include of controllers good point. #1 so I will not put this to sleep and do it for my releases until, as you say it become a problem However the use of mainDecoratorLocation beyond an app should be discourage for access multiple apps from a custom app as well. the conflict of data in each main-decorator has specific app information. Chris Howe sent the following on 12/17/2007 2:47 PM: Note: I'm not saying that prefixing the variable is a bad solution I'm just throwing out the downsides of it 1) The use case you present should not be encouraged. The opportunity for conflicting requests/views between multiple controllers will drive you bat crazy with unexpected results. The intent of the element is to modularize commonly used requests/views. Throwing everything in a bag and hoping you pull the expected result/view out is kind of dangerous. Absent a compelling use case, movement towards an external widely adopted standard, or utilizing more generic practices it's difficult to overcome the backward compatibility issue. 2) if you were to address the backward compatibility issue by making the mainDecoratorLocation the default if [prefix]-mainDeocratorLocation were null, I believe that you would be moving away from the Java Servlet spec by processing the context parameter. I could certainly be wrong. I'm no expert on such things. - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 4:27:19 PM Subject: Re: mainDecoratorLocation was Include of controllers It seems a lot of work for simple solution how about app-mainDecoratorLocati
Re: mainDecoratorLocation was Include of controllers
BJ Freeman wrote: Oh.. well I did. and got all sorts of errors because I has not included what that application expected for its decorator. and I could not find a way to use the app specific information for each app in my main-decorator. which started me down the road to app-mainDecoratorLocation Most main-decorators don't have app-specific information in them. They pretty much all set up the same context variables and such. You will need to add elements for each of the app's UI labels properties files and any other app specific things (like the party manager java script and stylesheet mentioned earlier). So, there is some effort involved and a few additional lines of code in your custom app main-decorator, but the tradeoff is not having to re-design screens. -Adrian
Re: mainDecoratorLocation was Include of controllers
be sure to define the mainDecoratorLocation in the web.xml as component://myapp/widget/CommonScreens.xml >From there the only app specific stuff is the whether it's including >leftbar/rightbar/etc. You will need to define those basic ones as well. - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 5:59:58 PM Subject: Re: mainDecoratorLocation was Include of controllers Oh.. well I did. and got all sorts of errors because I has not included what that application expected for its decorator. and I could not find a way to use the app specific information for each app in my main-decorator. which started me down the road to app-mainDecoratorLocation Chris Howe sent the following on 12/17/2007 3:50 PM: > Woops...pressed the send button by mistake. > > Make your own decorator in /myapp/widget/CommonScreens.xml > > create a main-decorator and a global decorator and use modify to your heart's content > > - Original Message > From: BJ Freeman <[EMAIL PROTECTED]> > To: dev@ofbiz.apache.org > Sent: Monday, December 17, 2007 5:33:01 PM > Subject: Re: mainDecoratorLocation was Include of controllers > > > so what is the approach that works? > > > Chris Howe sent the following on 12/17/2007 3:26 PM: >> That's what I wasn't understanding. Your approach fails with that > problem. The approach others have been using for the last two years does > not. I thought you were asserting that both approaches fail. >> - Original Message >> From: BJ Freeman <[EMAIL PROTECTED]> >> To: dev@ofbiz.apache.org >> Sent: Monday, December 17, 2007 5:21:55 PM >> Subject: Re: mainDecoratorLocation was Include of controllers >> >> >> been through this umteem times. >> sigh >> this is not the case for ftl files only widgets. >> >> I access a screen widget in x-app from my custom app. >> that screen has a decorator which eventually looks up >> mainDecoratorLocation to get the main-decorator >> >> so we are back to defining the mainDecoratorLocation. >> I can only define one mainDecoratorLocation in my web.xml >> so if I call another screen widget in y-app the information for the >> x-app main-decorator will be passed causing other problems. >> >> So there is no way a mainDecoratorLocation can be globally declared > to >> use more than one application screen widgets from the custom app >> So there is no use for using the mainDecoratorLocation outside that > app >> >> >> Chris Howe sent the following on 12/17/2007 3:11 PM: >>> I'm not sure I understand what you mean by access multiple apps from >> a custom app. When you have a custom app, there is no notion that >> included screens, called screens, included controllers, etc have a > context >> of ownership. The custom app is simply locating snippets of xml. >> Nothing more. You can call snippets from one component or two or > five, it >> doesn't matter. It only matters if you attempt to assert a context > of >> ownership; that calling a controller from the party controller has > some >> meaning about associated party variables or contexts. >>> - Original Message >>> From: BJ Freeman <[EMAIL PROTECTED]> >>> To: dev@ofbiz.apache.org >>> Sent: Monday, December 17, 2007 4:57:18 PM >>> Subject: Re: mainDecoratorLocation was Include of controllers >>> >>> >>> good point. #1 >>> so I will not put this to sleep and do it for my releases until, as >> you >>> say it become a problem >>> >>> However the use of mainDecoratorLocation beyond an app should be >>> discourage for access multiple apps from a custom app as well. >>> the conflict of data in each main-decorator has specific app >>> information. >>> >>> >>> >>> >>> Chris Howe sent the following on 12/17/2007 2:47 PM: Note: I'm not saying that prefixing the variable is a bad solution >>> I'm just throwing out the downsides of it 1) The use case you present should not be encouraged. The >>> opportunity for conflicting requests/views between multiple >> controllers will >>> drive you bat crazy with unexpected results. The intent of the >> >>> element is to modularize commonly used requests/views. Throwing >>> everything in a bag and hoping you pull the expected result/view > out >> is kind >>> of dangerous. Absent a compelling use case, movement towards an >>> external widely adopted standard, or utilizing more generic >> practices it's >>> difficult to overcome the backward compatibility issue. 2) if you were to address the backward compatibility issue by > making >>> the mainDecoratorLocation the default if >> [prefix]-mainDeocratorLocation >>> were null, I believe that you would be moving away from the Java >>> Servlet spec by processing the context parameter. I could > certainly >> be >>> wrong. I'm no expert on such things. - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 4:27:1
Re: mainDecoratorLocation was Include of controllers
here is an exmple now I can only setup that up for one menu so how do I set that up for each menu for each app? BJ Freeman sent the following on 12/17/2007 3:59 PM: > Oh.. well I did. > and got all sorts of errors because I has not included what that > application expected for its decorator. > > and I could not find a way to use the app specific information for each > app in my main-decorator. > > which started me down the road to app-mainDecoratorLocation > > Chris Howe sent the following on 12/17/2007 3:50 PM: >> Woops...pressed the send button by mistake. >> >> Make your own decorator in /myapp/widget/CommonScreens.xml >> >> create a main-decorator and a global decorator and use modify to your >> heart's content >> >> - Original Message >> From: BJ Freeman <[EMAIL PROTECTED]> >> To: dev@ofbiz.apache.org >> Sent: Monday, December 17, 2007 5:33:01 PM >> Subject: Re: mainDecoratorLocation was Include of controllers >> >> >> so what is the approach that works? >> >> >> Chris Howe sent the following on 12/17/2007 3:26 PM: >>> That's what I wasn't understanding. Your approach fails with that >> problem. The approach others have been using for the last two years does >> not. I thought you were asserting that both approaches fail. >>> - Original Message >>> From: BJ Freeman <[EMAIL PROTECTED]> >>> To: dev@ofbiz.apache.org >>> Sent: Monday, December 17, 2007 5:21:55 PM >>> Subject: Re: mainDecoratorLocation was Include of controllers >>> >>> >>> been through this umteem times. >>> sigh >>> this is not the case for ftl files only widgets. >>> >>> I access a screen widget in x-app from my custom app. >>> that screen has a decorator which eventually looks up >>> mainDecoratorLocation to get the main-decorator >>> >>> so we are back to defining the mainDecoratorLocation. >>> I can only define one mainDecoratorLocation in my web.xml >>> so if I call another screen widget in y-app the information for the >>> x-app main-decorator will be passed causing other problems. >>> >>> So there is no way a mainDecoratorLocation can be globally declared >> to >>> use more than one application screen widgets from the custom app >>> So there is no use for using the mainDecoratorLocation outside that >> app >>> >>> Chris Howe sent the following on 12/17/2007 3:11 PM: I'm not sure I understand what you mean by access multiple apps from >>> a custom app. When you have a custom app, there is no notion that >>> included screens, called screens, included controllers, etc have a >> context >>> of ownership. The custom app is simply locating snippets of xml. >>> Nothing more. You can call snippets from one component or two or >> five, it >>> doesn't matter. It only matters if you attempt to assert a context >> of >>> ownership; that calling a controller from the party controller has >> some >>> meaning about associated party variables or contexts. - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 4:57:18 PM Subject: Re: mainDecoratorLocation was Include of controllers good point. #1 so I will not put this to sleep and do it for my releases until, as >>> you say it become a problem However the use of mainDecoratorLocation beyond an app should be discourage for access multiple apps from a custom app as well. the conflict of data in each main-decorator has specific app information. Chris Howe sent the following on 12/17/2007 2:47 PM: > Note: I'm not saying that prefixing the variable is a bad solution I'm just throwing out the downsides of it > 1) The use case you present should not be encouraged. The opportunity for conflicting requests/views between multiple >>> controllers will drive you bat crazy with unexpected results. The intent of the >>> element is to modularize commonly used requests/views. Throwing everything in a bag and hoping you pull the expected result/view >> out >>> is kind of dangerous. Absent a compelling use case, movement towards an external widely adopted standard, or utilizing more generic >>> practices it's difficult to overcome the backward compatibility issue. > 2) if you were to address the backward compatibility issue by >> making the mainDecoratorLocation the default if >>> [prefix]-mainDeocratorLocation were null, I believe that you would be moving away from the Java Servlet spec by processing the context parameter. I could >> certainly >>> be wrong. I'm no expert on such things. > - Original Message > From: BJ Freeman <[EMAIL PROTECTED]> > To: dev@ofbiz.apache.org > Sent: Monday, December 17, 2007 4:27:19 PM > Subject: Re: mainDecoratorLocation was Include of controllers > > > It seems a lot of work for simple solution > how about app-mainDeco
[jira] Updated: (OFBIZ-1249) To permit to to calculate on a DATE object in minilang
[ https://issues.apache.org/jira/browse/OFBIZ-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Crum updated OFBIZ-1249: --- Attachment: set_calendar.patch set_calendar.patch is a quick-and-dirty stab at the new simple method. It compiles but it is untested. If it works on the first try - cool, commit it. Otherwise post comments here and I'll get back to it when I have more time. > To permit to to calculate on a DATE object in minilang > -- > > Key: OFBIZ-1249 > URL: https://issues.apache.org/jira/browse/OFBIZ-1249 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk > Environment: all >Reporter: Fabien Carrion >Assignee: Jacques Le Roux >Priority: Minor > Fix For: SVN trunk > > Attachments: calculate_date_diff.patch, set_calendar.patch > > > This patch lets use the calculate function in the minilang service function > with java.util.Date and java.sql.Date object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: mainDecoratorLocation was Include of controllers
Oh.. well I did. and got all sorts of errors because I has not included what that application expected for its decorator. and I could not find a way to use the app specific information for each app in my main-decorator. which started me down the road to app-mainDecoratorLocation Chris Howe sent the following on 12/17/2007 3:50 PM: > Woops...pressed the send button by mistake. > > Make your own decorator in /myapp/widget/CommonScreens.xml > > create a main-decorator and a global decorator and use modify to your heart's > content > > - Original Message > From: BJ Freeman <[EMAIL PROTECTED]> > To: dev@ofbiz.apache.org > Sent: Monday, December 17, 2007 5:33:01 PM > Subject: Re: mainDecoratorLocation was Include of controllers > > > so what is the approach that works? > > > Chris Howe sent the following on 12/17/2007 3:26 PM: >> That's what I wasn't understanding. Your approach fails with that > problem. The approach others have been using for the last two years does > not. I thought you were asserting that both approaches fail. >> - Original Message >> From: BJ Freeman <[EMAIL PROTECTED]> >> To: dev@ofbiz.apache.org >> Sent: Monday, December 17, 2007 5:21:55 PM >> Subject: Re: mainDecoratorLocation was Include of controllers >> >> >> been through this umteem times. >> sigh >> this is not the case for ftl files only widgets. >> >> I access a screen widget in x-app from my custom app. >> that screen has a decorator which eventually looks up >> mainDecoratorLocation to get the main-decorator >> >> so we are back to defining the mainDecoratorLocation. >> I can only define one mainDecoratorLocation in my web.xml >> so if I call another screen widget in y-app the information for the >> x-app main-decorator will be passed causing other problems. >> >> So there is no way a mainDecoratorLocation can be globally declared > to >> use more than one application screen widgets from the custom app >> So there is no use for using the mainDecoratorLocation outside that > app >> >> >> Chris Howe sent the following on 12/17/2007 3:11 PM: >>> I'm not sure I understand what you mean by access multiple apps from >> a custom app. When you have a custom app, there is no notion that >> included screens, called screens, included controllers, etc have a > context >> of ownership. The custom app is simply locating snippets of xml. >> Nothing more. You can call snippets from one component or two or > five, it >> doesn't matter. It only matters if you attempt to assert a context > of >> ownership; that calling a controller from the party controller has > some >> meaning about associated party variables or contexts. >>> - Original Message >>> From: BJ Freeman <[EMAIL PROTECTED]> >>> To: dev@ofbiz.apache.org >>> Sent: Monday, December 17, 2007 4:57:18 PM >>> Subject: Re: mainDecoratorLocation was Include of controllers >>> >>> >>> good point. #1 >>> so I will not put this to sleep and do it for my releases until, as >> you >>> say it become a problem >>> >>> However the use of mainDecoratorLocation beyond an app should be >>> discourage for access multiple apps from a custom app as well. >>> the conflict of data in each main-decorator has specific app >>> information. >>> >>> >>> >>> >>> Chris Howe sent the following on 12/17/2007 2:47 PM: Note: I'm not saying that prefixing the variable is a bad solution >>> I'm just throwing out the downsides of it 1) The use case you present should not be encouraged. The >>> opportunity for conflicting requests/views between multiple >> controllers will >>> drive you bat crazy with unexpected results. The intent of the >> >>> element is to modularize commonly used requests/views. Throwing >>> everything in a bag and hoping you pull the expected result/view > out >> is kind >>> of dangerous. Absent a compelling use case, movement towards an >>> external widely adopted standard, or utilizing more generic >> practices it's >>> difficult to overcome the backward compatibility issue. 2) if you were to address the backward compatibility issue by > making >>> the mainDecoratorLocation the default if >> [prefix]-mainDeocratorLocation >>> were null, I believe that you would be moving away from the Java >>> Servlet spec by processing the context parameter. I could > certainly >> be >>> wrong. I'm no expert on such things. - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 4:27:19 PM Subject: Re: mainDecoratorLocation was Include of controllers It seems a lot of work for simple solution how about app-mainDecoratorLocation then if someone want to use their own decorator it will still work. they just define each app-mainDecoratorLocation in their web.xml it either points to the original location or their customer >>> decorator. >>> >>> >>> >>> >>> >> >> >>
Re: mainDecoratorLocation was Include of controllers
Woops...pressed the send button by mistake. Make your own decorator in /myapp/widget/CommonScreens.xml create a main-decorator and a global decorator and use modify to your heart's content - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 5:33:01 PM Subject: Re: mainDecoratorLocation was Include of controllers so what is the approach that works? Chris Howe sent the following on 12/17/2007 3:26 PM: > That's what I wasn't understanding. Your approach fails with that problem. The approach others have been using for the last two years does not. I thought you were asserting that both approaches fail. > > - Original Message > From: BJ Freeman <[EMAIL PROTECTED]> > To: dev@ofbiz.apache.org > Sent: Monday, December 17, 2007 5:21:55 PM > Subject: Re: mainDecoratorLocation was Include of controllers > > > been through this umteem times. > sigh > this is not the case for ftl files only widgets. > > I access a screen widget in x-app from my custom app. > that screen has a decorator which eventually looks up > mainDecoratorLocation to get the main-decorator > > so we are back to defining the mainDecoratorLocation. > I can only define one mainDecoratorLocation in my web.xml > so if I call another screen widget in y-app the information for the > x-app main-decorator will be passed causing other problems. > > So there is no way a mainDecoratorLocation can be globally declared to > use more than one application screen widgets from the custom app > So there is no use for using the mainDecoratorLocation outside that app > > > > Chris Howe sent the following on 12/17/2007 3:11 PM: >> I'm not sure I understand what you mean by access multiple apps from > a custom app. When you have a custom app, there is no notion that > included screens, called screens, included controllers, etc have a context > of ownership. The custom app is simply locating snippets of xml. > Nothing more. You can call snippets from one component or two or five, it > doesn't matter. It only matters if you attempt to assert a context of > ownership; that calling a controller from the party controller has some > meaning about associated party variables or contexts. >> - Original Message >> From: BJ Freeman <[EMAIL PROTECTED]> >> To: dev@ofbiz.apache.org >> Sent: Monday, December 17, 2007 4:57:18 PM >> Subject: Re: mainDecoratorLocation was Include of controllers >> >> >> good point. #1 >> so I will not put this to sleep and do it for my releases until, as > you >> say it become a problem >> >> However the use of mainDecoratorLocation beyond an app should be >> discourage for access multiple apps from a custom app as well. >> the conflict of data in each main-decorator has specific app >> information. >> >> >> >> >> Chris Howe sent the following on 12/17/2007 2:47 PM: >>> Note: I'm not saying that prefixing the variable is a bad solution >> I'm just throwing out the downsides of it >>> 1) The use case you present should not be encouraged. The >> opportunity for conflicting requests/views between multiple > controllers will >> drive you bat crazy with unexpected results. The intent of the > >> element is to modularize commonly used requests/views. Throwing >> everything in a bag and hoping you pull the expected result/view out > is kind >> of dangerous. Absent a compelling use case, movement towards an >> external widely adopted standard, or utilizing more generic > practices it's >> difficult to overcome the backward compatibility issue. >>> 2) if you were to address the backward compatibility issue by making >> the mainDecoratorLocation the default if > [prefix]-mainDeocratorLocation >> were null, I believe that you would be moving away from the Java >> Servlet spec by processing the context parameter. I could certainly > be >> wrong. I'm no expert on such things. >>> - Original Message >>> From: BJ Freeman <[EMAIL PROTECTED]> >>> To: dev@ofbiz.apache.org >>> Sent: Monday, December 17, 2007 4:27:19 PM >>> Subject: Re: mainDecoratorLocation was Include of controllers >>> >>> >>> It seems a lot of work for simple solution >>> how about app-mainDecoratorLocation >>> then if someone want to use their own decorator it will still work. >>> they just define each app-mainDecoratorLocation in their web.xml >>> it either points to the original location or their customer >> decorator. >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> > > > > > > >
Re: mainDecoratorLocation was Include of controllers
Make your own decorator - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 5:33:01 PM Subject: Re: mainDecoratorLocation was Include of controllers so what is the approach that works? Chris Howe sent the following on 12/17/2007 3:26 PM: > That's what I wasn't understanding. Your approach fails with that problem. The approach others have been using for the last two years does not. I thought you were asserting that both approaches fail. > > - Original Message > From: BJ Freeman <[EMAIL PROTECTED]> > To: dev@ofbiz.apache.org > Sent: Monday, December 17, 2007 5:21:55 PM > Subject: Re: mainDecoratorLocation was Include of controllers > > > been through this umteem times. > sigh > this is not the case for ftl files only widgets. > > I access a screen widget in x-app from my custom app. > that screen has a decorator which eventually looks up > mainDecoratorLocation to get the main-decorator > > so we are back to defining the mainDecoratorLocation. > I can only define one mainDecoratorLocation in my web.xml > so if I call another screen widget in y-app the information for the > x-app main-decorator will be passed causing other problems. > > So there is no way a mainDecoratorLocation can be globally declared to > use more than one application screen widgets from the custom app > So there is no use for using the mainDecoratorLocation outside that app > > > > Chris Howe sent the following on 12/17/2007 3:11 PM: >> I'm not sure I understand what you mean by access multiple apps from > a custom app. When you have a custom app, there is no notion that > included screens, called screens, included controllers, etc have a context > of ownership. The custom app is simply locating snippets of xml. > Nothing more. You can call snippets from one component or two or five, it > doesn't matter. It only matters if you attempt to assert a context of > ownership; that calling a controller from the party controller has some > meaning about associated party variables or contexts. >> - Original Message >> From: BJ Freeman <[EMAIL PROTECTED]> >> To: dev@ofbiz.apache.org >> Sent: Monday, December 17, 2007 4:57:18 PM >> Subject: Re: mainDecoratorLocation was Include of controllers >> >> >> good point. #1 >> so I will not put this to sleep and do it for my releases until, as > you >> say it become a problem >> >> However the use of mainDecoratorLocation beyond an app should be >> discourage for access multiple apps from a custom app as well. >> the conflict of data in each main-decorator has specific app >> information. >> >> >> >> >> Chris Howe sent the following on 12/17/2007 2:47 PM: >>> Note: I'm not saying that prefixing the variable is a bad solution >> I'm just throwing out the downsides of it >>> 1) The use case you present should not be encouraged. The >> opportunity for conflicting requests/views between multiple > controllers will >> drive you bat crazy with unexpected results. The intent of the > >> element is to modularize commonly used requests/views. Throwing >> everything in a bag and hoping you pull the expected result/view out > is kind >> of dangerous. Absent a compelling use case, movement towards an >> external widely adopted standard, or utilizing more generic > practices it's >> difficult to overcome the backward compatibility issue. >>> 2) if you were to address the backward compatibility issue by making >> the mainDecoratorLocation the default if > [prefix]-mainDeocratorLocation >> were null, I believe that you would be moving away from the Java >> Servlet spec by processing the context parameter. I could certainly > be >> wrong. I'm no expert on such things. >>> - Original Message >>> From: BJ Freeman <[EMAIL PROTECTED]> >>> To: dev@ofbiz.apache.org >>> Sent: Monday, December 17, 2007 4:27:19 PM >>> Subject: Re: mainDecoratorLocation was Include of controllers >>> >>> >>> It seems a lot of work for simple solution >>> how about app-mainDecoratorLocation >>> then if someone want to use their own decorator it will still work. >>> they just define each app-mainDecoratorLocation in their web.xml >>> it either points to the original location or their customer >> decorator. >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> > > > > > > >
Re: mainDecoratorLocation was Include of controllers
so what is the approach that works? Chris Howe sent the following on 12/17/2007 3:26 PM: > That's what I wasn't understanding. Your approach fails with that problem. > The approach others have been using for the last two years does not. I > thought you were asserting that both approaches fail. > > - Original Message > From: BJ Freeman <[EMAIL PROTECTED]> > To: dev@ofbiz.apache.org > Sent: Monday, December 17, 2007 5:21:55 PM > Subject: Re: mainDecoratorLocation was Include of controllers > > > been through this umteem times. > sigh > this is not the case for ftl files only widgets. > > I access a screen widget in x-app from my custom app. > that screen has a decorator which eventually looks up > mainDecoratorLocation to get the main-decorator > > so we are back to defining the mainDecoratorLocation. > I can only define one mainDecoratorLocation in my web.xml > so if I call another screen widget in y-app the information for the > x-app main-decorator will be passed causing other problems. > > So there is no way a mainDecoratorLocation can be globally declared to > use more than one application screen widgets from the custom app > So there is no use for using the mainDecoratorLocation outside that app > > > > Chris Howe sent the following on 12/17/2007 3:11 PM: >> I'm not sure I understand what you mean by access multiple apps from > a custom app. When you have a custom app, there is no notion that > included screens, called screens, included controllers, etc have a context > of ownership. The custom app is simply locating snippets of xml. > Nothing more. You can call snippets from one component or two or five, it > doesn't matter. It only matters if you attempt to assert a context of > ownership; that calling a controller from the party controller has some > meaning about associated party variables or contexts. >> - Original Message >> From: BJ Freeman <[EMAIL PROTECTED]> >> To: dev@ofbiz.apache.org >> Sent: Monday, December 17, 2007 4:57:18 PM >> Subject: Re: mainDecoratorLocation was Include of controllers >> >> >> good point. #1 >> so I will not put this to sleep and do it for my releases until, as > you >> say it become a problem >> >> However the use of mainDecoratorLocation beyond an app should be >> discourage for access multiple apps from a custom app as well. >> the conflict of data in each main-decorator has specific app >> information. >> >> >> >> >> Chris Howe sent the following on 12/17/2007 2:47 PM: >>> Note: I'm not saying that prefixing the variable is a bad solution >> I'm just throwing out the downsides of it >>> 1) The use case you present should not be encouraged. The >> opportunity for conflicting requests/views between multiple > controllers will >> drive you bat crazy with unexpected results. The intent of the > >> element is to modularize commonly used requests/views. Throwing >> everything in a bag and hoping you pull the expected result/view out > is kind >> of dangerous. Absent a compelling use case, movement towards an >> external widely adopted standard, or utilizing more generic > practices it's >> difficult to overcome the backward compatibility issue. >>> 2) if you were to address the backward compatibility issue by making >> the mainDecoratorLocation the default if > [prefix]-mainDeocratorLocation >> were null, I believe that you would be moving away from the Java >> Servlet spec by processing the context parameter. I could certainly > be >> wrong. I'm no expert on such things. >>> - Original Message >>> From: BJ Freeman <[EMAIL PROTECTED]> >>> To: dev@ofbiz.apache.org >>> Sent: Monday, December 17, 2007 4:27:19 PM >>> Subject: Re: mainDecoratorLocation was Include of controllers >>> >>> >>> It seems a lot of work for simple solution >>> how about app-mainDecoratorLocation >>> then if someone want to use their own decorator it will still work. >>> they just define each app-mainDecoratorLocation in their web.xml >>> it either points to the original location or their customer >> decorator. >>> >>> >>> >>> >>> >>> >> >> >> >> >> >> > > > > > > >
[jira] Updated: (OFBIZ-1532) Run GiftCertificateServices.createTransaction as system user
[ https://issues.apache.org/jira/browse/OFBIZ-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-1532: --- Priority: Major (was: Blocker) Thanks Adrian, I will have a look tomorrow. I have also a problem thereafter to reload amount in the gift card. I already knew (at least it seems to me) that you can ignore the required PIN number by putting anything in it. But even using a correct gift card number I get this message "The question [Gift Card Number:] requires a valid gift-card number.". It comes from createSurveyResponse... later... BTW, Blocker was far too much. ;o) > Run GiftCertificateServices.createTransaction as system user > > > Key: OFBIZ-1532 > URL: https://issues.apache.org/jira/browse/OFBIZ-1532 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux > Attachments: GiftCertificateServices.java.patch > > > To be able to run GiftCertificateServices.createTransaction (to create a Gift > Certificate from eCommerce : Gift Card Activation) we have to run as system > user (it needs ACCTG_ATX_CREATE) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: mainDecoratorLocation was Include of controllers
That's what I wasn't understanding. Your approach fails with that problem. The approach others have been using for the last two years does not. I thought you were asserting that both approaches fail. - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 5:21:55 PM Subject: Re: mainDecoratorLocation was Include of controllers been through this umteem times. sigh this is not the case for ftl files only widgets. I access a screen widget in x-app from my custom app. that screen has a decorator which eventually looks up mainDecoratorLocation to get the main-decorator so we are back to defining the mainDecoratorLocation. I can only define one mainDecoratorLocation in my web.xml so if I call another screen widget in y-app the information for the x-app main-decorator will be passed causing other problems. So there is no way a mainDecoratorLocation can be globally declared to use more than one application screen widgets from the custom app So there is no use for using the mainDecoratorLocation outside that app Chris Howe sent the following on 12/17/2007 3:11 PM: > I'm not sure I understand what you mean by access multiple apps from a custom app. When you have a custom app, there is no notion that included screens, called screens, included controllers, etc have a context of ownership. The custom app is simply locating snippets of xml. Nothing more. You can call snippets from one component or two or five, it doesn't matter. It only matters if you attempt to assert a context of ownership; that calling a controller from the party controller has some meaning about associated party variables or contexts. > > - Original Message > From: BJ Freeman <[EMAIL PROTECTED]> > To: dev@ofbiz.apache.org > Sent: Monday, December 17, 2007 4:57:18 PM > Subject: Re: mainDecoratorLocation was Include of controllers > > > good point. #1 > so I will not put this to sleep and do it for my releases until, as you > say it become a problem > > However the use of mainDecoratorLocation beyond an app should be > discourage for access multiple apps from a custom app as well. > the conflict of data in each main-decorator has specific app > information. > > > > > Chris Howe sent the following on 12/17/2007 2:47 PM: >> Note: I'm not saying that prefixing the variable is a bad solution > I'm just throwing out the downsides of it >> 1) The use case you present should not be encouraged. The > opportunity for conflicting requests/views between multiple controllers will > drive you bat crazy with unexpected results. The intent of the > element is to modularize commonly used requests/views. Throwing > everything in a bag and hoping you pull the expected result/view out is kind > of dangerous. Absent a compelling use case, movement towards an > external widely adopted standard, or utilizing more generic practices it's > difficult to overcome the backward compatibility issue. >> 2) if you were to address the backward compatibility issue by making > the mainDecoratorLocation the default if [prefix]-mainDeocratorLocation > were null, I believe that you would be moving away from the Java > Servlet spec by processing the context parameter. I could certainly be > wrong. I'm no expert on such things. >> - Original Message >> From: BJ Freeman <[EMAIL PROTECTED]> >> To: dev@ofbiz.apache.org >> Sent: Monday, December 17, 2007 4:27:19 PM >> Subject: Re: mainDecoratorLocation was Include of controllers >> >> >> It seems a lot of work for simple solution >> how about app-mainDecoratorLocation >> then if someone want to use their own decorator it will still work. >> they just define each app-mainDecoratorLocation in their web.xml >> it either points to the original location or their customer > decorator. >> >> >> >> >> >> >> > > > > > > >
Re: mainDecoratorLocation was Include of controllers
been through this umteem times. sigh this is not the case for ftl files only widgets. I access a screen widget in x-app from my custom app. that screen has a decorator which eventually looks up mainDecoratorLocation to get the main-decorator so we are back to defining the mainDecoratorLocation. I can only define one mainDecoratorLocation in my web.xml so if I call another screen widget in y-app the information for the x-app main-decorator will be passed causing other problems. So there is no way a mainDecoratorLocation can be globally declared to use more than one application screen widgets from the custom app So there is no use for using the mainDecoratorLocation outside that app Chris Howe sent the following on 12/17/2007 3:11 PM: > I'm not sure I understand what you mean by access multiple apps from a custom > app. When you have a custom app, there is no notion that included screens, > called screens, included controllers, etc have a context of ownership. The > custom app is simply locating snippets of xml. Nothing more. You can call > snippets from one component or two or five, it doesn't matter. It only > matters if you attempt to assert a context of ownership; that calling a > controller from the party controller has some meaning about associated party > variables or contexts. > > - Original Message > From: BJ Freeman <[EMAIL PROTECTED]> > To: dev@ofbiz.apache.org > Sent: Monday, December 17, 2007 4:57:18 PM > Subject: Re: mainDecoratorLocation was Include of controllers > > > good point. #1 > so I will not put this to sleep and do it for my releases until, as you > say it become a problem > > However the use of mainDecoratorLocation beyond an app should be > discourage for access multiple apps from a custom app as well. > the conflict of data in each main-decorator has specific app > information. > > > > > Chris Howe sent the following on 12/17/2007 2:47 PM: >> Note: I'm not saying that prefixing the variable is a bad solution > I'm just throwing out the downsides of it >> 1) The use case you present should not be encouraged. The > opportunity for conflicting requests/views between multiple controllers will > drive you bat crazy with unexpected results. The intent of the > element is to modularize commonly used requests/views. Throwing > everything in a bag and hoping you pull the expected result/view out is kind > of dangerous. Absent a compelling use case, movement towards an > external widely adopted standard, or utilizing more generic practices it's > difficult to overcome the backward compatibility issue. >> 2) if you were to address the backward compatibility issue by making > the mainDecoratorLocation the default if [prefix]-mainDeocratorLocation > were null, I believe that you would be moving away from the Java > Servlet spec by processing the context parameter. I could certainly be > wrong. I'm no expert on such things. >> - Original Message >> From: BJ Freeman <[EMAIL PROTECTED]> >> To: dev@ofbiz.apache.org >> Sent: Monday, December 17, 2007 4:27:19 PM >> Subject: Re: mainDecoratorLocation was Include of controllers >> >> >> It seems a lot of work for simple solution >> how about app-mainDecoratorLocation >> then if someone want to use their own decorator it will still work. >> they just define each app-mainDecoratorLocation in their web.xml >> it either points to the original location or their customer > decorator. >> >> >> >> >> >> >> > > > > > > >
Re: mainDecoratorLocation was Include of controllers
I'm not sure I understand what you mean by access multiple apps from a custom app. When you have a custom app, there is no notion that included screens, called screens, included controllers, etc have a context of ownership. The custom app is simply locating snippets of xml. Nothing more. You can call snippets from one component or two or five, it doesn't matter. It only matters if you attempt to assert a context of ownership; that calling a controller from the party controller has some meaning about associated party variables or contexts. - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 4:57:18 PM Subject: Re: mainDecoratorLocation was Include of controllers good point. #1 so I will not put this to sleep and do it for my releases until, as you say it become a problem However the use of mainDecoratorLocation beyond an app should be discourage for access multiple apps from a custom app as well. the conflict of data in each main-decorator has specific app information. Chris Howe sent the following on 12/17/2007 2:47 PM: > Note: I'm not saying that prefixing the variable is a bad solution I'm just throwing out the downsides of it > 1) The use case you present should not be encouraged. The opportunity for conflicting requests/views between multiple controllers will drive you bat crazy with unexpected results. The intent of the element is to modularize commonly used requests/views. Throwing everything in a bag and hoping you pull the expected result/view out is kind of dangerous. Absent a compelling use case, movement towards an external widely adopted standard, or utilizing more generic practices it's difficult to overcome the backward compatibility issue. > > 2) if you were to address the backward compatibility issue by making the mainDecoratorLocation the default if [prefix]-mainDeocratorLocation were null, I believe that you would be moving away from the Java Servlet spec by processing the context parameter. I could certainly be wrong. I'm no expert on such things. > > - Original Message > From: BJ Freeman <[EMAIL PROTECTED]> > To: dev@ofbiz.apache.org > Sent: Monday, December 17, 2007 4:27:19 PM > Subject: Re: mainDecoratorLocation was Include of controllers > > > It seems a lot of work for simple solution > how about app-mainDecoratorLocation > then if someone want to use their own decorator it will still work. > they just define each app-mainDecoratorLocation in their web.xml > it either points to the original location or their customer decorator. > > > > > > > >
[jira] Commented: (OFBIZ-1532) Run GiftCertificateServices.createTransaction as system user
[ https://issues.apache.org/jira/browse/OFBIZ-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552563 ] Adrian Crum commented on OFBIZ-1532: Jacques, If you look at the seed data for the ACCTG_ATX_CREATE permission, you will see a suggestion on how to handle that with a permissions service SECA. Use the Asset Maintentance permission service SECAs as an example. > Run GiftCertificateServices.createTransaction as system user > > > Key: OFBIZ-1532 > URL: https://issues.apache.org/jira/browse/OFBIZ-1532 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Blocker > Attachments: GiftCertificateServices.java.patch > > > To be able to run GiftCertificateServices.createTransaction (to create a Gift > Certificate from eCommerce : Gift Card Activation) we have to run as system > user (it needs ACCTG_ATX_CREATE) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1532) Run GiftCertificateServices.createTransaction as system user
[ https://issues.apache.org/jira/browse/OFBIZ-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-1532: --- Attachment: GiftCertificateServices.java.patch As I'm not a specialist of the accounting component and due to recent changes I'd prefer some reviews before commiting this pacth. In case that running as system user could cause some unforeseen problems. > Run GiftCertificateServices.createTransaction as system user > > > Key: OFBIZ-1532 > URL: https://issues.apache.org/jira/browse/OFBIZ-1532 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: SVN trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Blocker > Attachments: GiftCertificateServices.java.patch > > > To be able to run GiftCertificateServices.createTransaction (to create a Gift > Certificate from eCommerce : Gift Card Activation) we have to run as system > user (it needs ACCTG_ATX_CREATE) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-1532) Run GiftCertificateServices.createTransaction as system user
Run GiftCertificateServices.createTransaction as system user Key: OFBIZ-1532 URL: https://issues.apache.org/jira/browse/OFBIZ-1532 Project: OFBiz Issue Type: Bug Components: accounting Affects Versions: SVN trunk Reporter: Jacques Le Roux Assignee: Jacques Le Roux Priority: Blocker To be able to run GiftCertificateServices.createTransaction (to create a Gift Certificate from eCommerce : Gift Card Activation) we have to run as system user (it needs ACCTG_ATX_CREATE) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1504) New screen to manage the default glAccountId for the InvoiceItemType entity.
[ https://issues.apache.org/jira/browse/OFBIZ-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552560 ] Ashish Vijaywargiya commented on OFBIZ-1504: Alok and Pranay your patch is in rev # 605032 -- Ashish Vijaywargiya > New screen to manage the default glAccountId for the InvoiceItemType entity. > > > Key: OFBIZ-1504 > URL: https://issues.apache.org/jira/browse/OFBIZ-1504 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: SVN trunk >Reporter: Jacopo Cappellato > Attachments: jira-issue-1504, jira-issue-1504.patch, > jira-issue-1504.patch > > > This is *not* an organization specific screen, and so it will be accessible > from the top menu of the accounting component. > In the new screen, it will only be possible to update the glAccountId field > of the existing records; adding/removing new records is not allowed, nor > updating the other fields of the InvoiceItemType entity. > Also, the name of the top menu should reflect the specialized scope of this > screen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: mainDecoratorLocation was Include of controllers
good point. #1 so I will not put this to sleep and do it for my releases until, as you say it become a problem However the use of mainDecoratorLocation beyond an app should be discourage for access multiple apps from a custom app as well. the conflict of data in each main-decorator has specific app information. Chris Howe sent the following on 12/17/2007 2:47 PM: > Note: I'm not saying that prefixing the variable is a bad solution I'm just > throwing out the downsides of it > 1) The use case you present should not be encouraged. The opportunity for > conflicting requests/views between multiple controllers will drive you bat > crazy with unexpected results. The intent of the element is to > modularize commonly used requests/views. Throwing everything in a bag and > hoping you pull the expected result/view out is kind of dangerous. Absent a > compelling use case, movement towards an external widely adopted standard, or > utilizing more generic practices it's difficult to overcome the backward > compatibility issue. > > 2) if you were to address the backward compatibility issue by making the > mainDecoratorLocation the default if [prefix]-mainDeocratorLocation were > null, I believe that you would be moving away from the Java Servlet spec by > processing the context parameter. I could certainly be wrong. I'm no expert > on such things. > > - Original Message > From: BJ Freeman <[EMAIL PROTECTED]> > To: dev@ofbiz.apache.org > Sent: Monday, December 17, 2007 4:27:19 PM > Subject: Re: mainDecoratorLocation was Include of controllers > > > It seems a lot of work for simple solution > how about app-mainDecoratorLocation > then if someone want to use their own decorator it will still work. > they just define each app-mainDecoratorLocation in their web.xml > it either points to the original location or their customer decorator. > > > > > > > >
[jira] Closed: (OFBIZ-1504) New screen to manage the default glAccountId for the InvoiceItemType entity.
[ https://issues.apache.org/jira/browse/OFBIZ-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya closed OFBIZ-1504. -- Resolution: Fixed Thanks Alok Agnihotri for the initial patch. Pranay thanks to you too for your valuable patch. -- Ashish Vijaywargiya > New screen to manage the default glAccountId for the InvoiceItemType entity. > > > Key: OFBIZ-1504 > URL: https://issues.apache.org/jira/browse/OFBIZ-1504 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: SVN trunk >Reporter: Jacopo Cappellato > Attachments: jira-issue-1504, jira-issue-1504.patch, > jira-issue-1504.patch > > > This is *not* an organization specific screen, and so it will be accessible > from the top menu of the accounting component. > In the new screen, it will only be possible to update the glAccountId field > of the existing records; adding/removing new records is not allowed, nor > updating the other fields of the InvoiceItemType entity. > Also, the name of the top menu should reflect the specialized scope of this > screen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Difference between GL account type and class
David and Jacopo, You both never fail to amaze me with the time and care taken to craft your answers to OfBizian's questions - and even their inane rants (complaints? - hehe). I can't thank you enough and wanted to wish you guys and the rest of the list a very joyous Holiday Season and a Happy New Year! All the best, -Yousef Shemisa -Original Message- From: David E Jones [mailto:[EMAIL PROTECTED] Sent: Monday, December 17, 2007 13:07 To: dev@ofbiz.apache.org Subject: Re: Difference between GL account type and class A complaint is a complaint, and doesn't usually get you very far in a collaborative environment. Complaining in any form basically says that someone else created a problem and that person should solve it... so whoever that is: get on it already! You're either helping to create the software or you're not. If you are, then any complaint you have is technically a complaint against a group that includes yourself, and hence doesn't make much sense... That may bring you around to wanting to make changes to this, which brings you to contribution guidelines and good ways of working with other people and an existing code base (whether it be open source or not...). The main one I'm thinking of is the Rule #2: read before you write, ie understand something before you desire to change it (which I guess is what you're getting at with your first question). There are other interesting and helpful points here: http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices I think that's what Jacopo is referring to. As for this question, I don't remember it ever being asked (perhaps it was another related question though, phrased differently or something?). Of course, there are hundreds of questions every week going through the mailing lists and NO paid support staff (just people in their "spare" time helping out), so such questions are sometimes either lost or not considered as a high a priority as other active issues and questions that could use attention... and there are ALWAYS more issues and questions than one has time to work through completely. == In any case, the difference between a GlAccount class and type is that they are independent, ie like two dimensions on a graph. Some combinations of them don't make sense and they are certainly meant to be used together. The best way to understand them, as with many such entities that are concerned with types of records that require different code behavior, is to look at the seed data for the entity(ies). In this case that file is AccountingTypeData.xml. If you have looked at that and it doesn't make sense then maybe the best next step is to write a more detailed question to say what makes sense and what seems to conflict, and then maybe someone can be more helpful, instead of just guessing about what you're trying to find. At a high level you can see the different top-level classes and types, ie the ones with no parentClassId or parentTypeId. That is more helpful for the class as the classes are used in the posting routines to determine how an account should be treated (ie whether it is a debit or credit account, mainly). One thing that might make understanding these more difficult is misunderstanding their intent, and that seems to be the case with your comment about deciding how to determine an account to post to. The types and classes are NOT meant for that, there are other entities for that depending on where the information is coming from. For example when posting an accounting transaction based on an invoice you would look up the GlAccounts to use based on the internal organization the invoice is related to, and the InvoiceItemType for each item, and for some items like those for selling a product you would also try to use the productId to look up the glAccountId to use. If you browse around these entities you'll see a bunch of defined relationships between them for this purpose. -David On Dec 17, 2007, at 10:17 AM, Jim Barrows wrote: > I wasn't complaining about the lack of documentation, just the lack of > an answer. > And I solved that complaint by responding to you, that your assumption > was my assumption. I also don't consider the comment "Very > Frustrating" to be a complaint. It's a statement of fact. > > The rest was just an idea to be kicked around. However, after further > looking in to the code that's not going to be very easy to do. We use > both. I'm at work, so the details are fuzzy, but in some cases we use > either class or type to determine which account a transaction should > go into if no account is provided. A couple of other places where we > use that extra information to do the same type of thing. > > I would change the documentation and comment the code if I could get a > confirmation of the assumption. No documentation is better then bad > documentation. > > On 12/17/07, Jacopo Cappellato <[EMAIL PROTECTED]> wrote: >> Jim, >> >> we are building th
Re: mainDecoratorLocation was Include of controllers
Note: I'm not saying that prefixing the variable is a bad solution I'm just throwing out the downsides of it 1) The use case you present should not be encouraged. The opportunity for conflicting requests/views between multiple controllers will drive you bat crazy with unexpected results. The intent of the element is to modularize commonly used requests/views. Throwing everything in a bag and hoping you pull the expected result/view out is kind of dangerous. Absent a compelling use case, movement towards an external widely adopted standard, or utilizing more generic practices it's difficult to overcome the backward compatibility issue. 2) if you were to address the backward compatibility issue by making the mainDecoratorLocation the default if [prefix]-mainDeocratorLocation were null, I believe that you would be moving away from the Java Servlet spec by processing the context parameter. I could certainly be wrong. I'm no expert on such things. - Original Message From: BJ Freeman <[EMAIL PROTECTED]> To: dev@ofbiz.apache.org Sent: Monday, December 17, 2007 4:27:19 PM Subject: Re: mainDecoratorLocation was Include of controllers It seems a lot of work for simple solution how about app-mainDecoratorLocation then if someone want to use their own decorator it will still work. they just define each app-mainDecoratorLocation in their web.xml it either points to the original location or their customer decorator.
Re: mainDecoratorLocation was Include of controllers
It seems a lot of work for simple solution
how about app-mainDecoratorLocation
then if someone want to use their own decorator it will still work.
they just define each app-mainDecoratorLocation in their web.xml
it either points to the original location or their customer decorator.
Chris Howe sent the following on 12/17/2007 2:01 PM:
> I suggested that as well and Scott echoed it. It doesn't seem to be
> satisfactory to BJ. So we work at it.
>
> - Original Message
> From: Adrian Crum <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 3:57:53 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> If all BJ wants to do is display an existing screen with its existing
> main decorator, then he can
> just use the screen's URL.
>
> Chris Howe wrote:
>
>> Because he wants screens from the party component to be decorated
> with the mainDecoratorLocation defined in
> party/webapp/partymgr/WEB-INF/web.xml and screens from the product compnent
> decorated with the
> mainDecoratorLocation defined in product/webapp/catalog/WEB-INF/web.xml
>> Adrian's solution doesn't appear to solve this problem for BJ. (I had
> misread the details of his explanation in saying that it had
> previously). BJ requires a custom servlet that will do something like the
> following:
>> 1) process as normal until it begins to process the view
>> 2) place the @page attribute into the context (split the
> screen ${screen} from the location${location})
>> 3) render the following screen
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> - Original Message
>> From: Scott Gray <[EMAIL PROTECTED]>
>> To: dev@ofbiz.apache.org
>> Sent: Monday, December 17, 2007 3:27:53 PM
>> Subject: Re: mainDecoratorLocation was Include of controllers
>>
>>
>> Why couldn't you supply your own custom mainDecorator? What do the
>> base
>> mainDecorators provide that you can't in your custom app?
>>
>> Scott
>>
>> On 18/12/2007, BJ Freeman <[EMAIL PROTECTED]> wrote:
>>
>>> Based on this, I can never see how even if I called from a custom app
>>> different screens in different apps how one main-decorator
>>> so I am not sure how this feature would work at all.
>>>
>>> Hence my original suggestion that is apps main-decorator be declared
>> as
>>
>>> application-mainDecoratorLocation
>>> this way I could include each apps mainDecoratorLocation and not have
>> to
>>
>>> worry
>>>
>>>
>>> BJ Freeman sent the following on 12/17/2007 12:55 PM:
>>>
I have a menu, no screens, that calls ListPartyCommEvents
this goes to the party controller to resolve.
the party controller uses it view for ListPartyCommEvents
It can not read the party web.xml so will error even with your
>> changes.
>>
so lets say i put in a mainDecoratorLocation in my web xml and
>> define it
>>
like the one in the party commonscreens.xml
so far so good.
Now I call a screen in say Product. except the
>> mainDecoratorLocation for
>>
it has a different main-decorator. so all the requirements are not
defined in the party main-Decorator I have ported over.
we still have a problem since all the apps main-decorators are not
>> the
>>
>>> same.
>>>
now if the main-decorators were all the same then I could use one
location in any of the apps and everything would be ok
Adrian Crum sent the following on 12/17/2007 12:40 PM:
> 1. Move the CommonCommunicationEventDecorator screen to the
> communicationsscreens.xml file.
> 2. Change all
> location="${parameters.mainDecoratorLocation}">
>
> to
>
> location="${parameters.communicationEventDecoratorLocation}">
>
> Since parameters.communicationEventDecoratorLocation isn't defined
> anywhere, the location will evaluate to the current file:
> communicationsscreens.xml. All communication screens still work
>> the
>>
>>> same
>>>
> in Party Manager, but now you can reuse those screens in another
>> app.
>>
> When you use one of the communication screens in your custom app
>> (via
>>
> included controller.xml file or otherwise) the
> parameters.communicationEventDecoratorLocation still isn't defined
> anywhere, so it still evaluates to the current file:
> communicationsscreens.xml. The communication screen and the
> CommonCommunicationEventDecorator will both appear - decorated
>> with
>>
>>> your
>>>
> custom app's main decorator.
>
> (Optional) If someone didn't like the
>>> CommonCommunicationEventDecorator,
>>>
> then they could design their own and specify its location in
> parameters.communicationEventDecoratorLocation.
>
> -Adrian
>
> BJ Freeman wrote:
>
>
>> Ok here is a real situation:
>> take the party/widgets/partymgr/commicationsscreens.xml
>> > location="${parameters.mai
Re: Include of controllers
you say this works, let me walk you thru this
I agree with you statements as far as it went.
however you did not cover the
location="${parameters.mainDecoratorLocation}">
for main-decorator.
Now it is true if I put the
mainDecoratorLocation in my web.xml this will work.
the next test though is to do this for a second app
now theres the rub since I can only declare one mainDecoratorLocation in
my web.xml
so I can only declare the location for one main-decorator and it has to
work for all apps.
oops another gotcha.
each main-decorator defines things specific to that app for it to work
properly.
Like were to find components.
So the only simple solution is to have a
app-mainDecoratorLocation like party-mainDecoratorLocation
then I can declare each one in my web xml.
Adrian Crum sent the following on 12/17/2007 9:33 AM:
> BJ,
>
> Go ahead and create one. I will work on it when I have time.
>
> To be sure we're all on the same page, the problem exists when screens
> are nested as follows:
>
>
>
>
>
> ...
>
>
>
>
>
> and the location of the sub-decorator screen is defined as
> ${parameters.mainDecoratorLocation}. When a custom app tries to reuse
> the actual-content screen, errors are generated because
> location="${parameters.mainDecoratorLocation}"> evaluates to the custom
> app's main decorator xml file, and the sub-decorator screen doesn't
> exist there.
>
> The solution to the problem is to avoid using
> ${parameters.mainDecoratorLocation} as a location for sub-decorators and
> either have no location specified or use a different parameter for the
> sub-decorator's location - like ${subDecoratorLocation}.
>
> A good example of this approach is in AgreementScreens.xml in the
> Accounting component. All of the Agreement screens share a common
> sub-decorator (CommonAgreementDecorator) - and that decorator's location
> is specified as ${parameters.agreementDecoratorLocation}. The
> agreementDecoratorLocation parameter isn't defined anywhere, so the
> location= expression evaluates to an empty String - which causes the
> screen widget view handler to look for CommonAgreementDecorator in the
> existing file.
>
> A custom app that reuses one of the Agreement screens will only need to
> specify the mainDecoratorLocation parameter. Since no
> agreementDecoratorLocation parameter is defined in the custom app, the
> sub-decorator in AgreementScreens.xml is used (same as above). If a
> custom app wanted to have a custom sub-decorator, then it can specify
> that decorator's location in the agreementDecoratorLocation parameter.
>
> -Adrian
>
> BJ Freeman wrote:
>
>> I agree, it is not a controller or web.xml issue. However it is when it
>> shows up.
>> I will change them as I come along also.
>> thanks, that is all I wanted to know.
>> do you want to create a jira so I can submit changes?
>>
>> Adrian Crum sent the following on 12/17/2007 7:57 AM:
>>
>>> As I mentioned before, the problem is with the coding style on some
>>> screens, not with the controller or web.xml files. I recently changed
>>> some of the accounting screens to correct this error.
>>>
>>> -Adrian
>>>
>>> BJ Freeman wrote:
>>>
>>>
I am not really, trying to attach the context as a whole.
only trying to get the mainDecoratorLocation
which is stored as a context in web.xml.
The problem is if I put mainDecoratorLocation, in my web.xml
then all applications I call thru my controller, or the included ones,
will use my mainDecoratorLocation full path.
Maybe the solution is to put the main-decorator for all apps in the
framework/commons
then like in many of the application they have specific decorators that
include the main-decorator.
the problems is how to fill in the actions, etcetera
Chris Howe sent the following on 12/15/2007 10:40 AM:
> All the does is grab some xml elements from the location
> described. Theoretically, It doesn't even need to be from the same
> server, much less the same app (may have interesting possibilities
> BTW). This is why I'm having such a hard time understanding why you
> are trying to attach context to it.
>
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Saturday, December 15, 2007 12:19:27 PM
> Subject: Re: Include of controllers
>
>
> I was going thru the trunk and noticed this in all the controllers
> location="component://common/webcommon/WEB-INF/common-controller.xml"/>
>
>
> so there is a rule that says you can include a controller not in the
> same app.
>
>
> BJ Freeman sent the following on 11/10/2007 4:15 PM:
>
>
>> Almost.
>> when the included controller view calles a screen in the partymgr
>
> screen
>
>
>> , and that screen calls for a parm that is web.xml. the parm is not
>> availible for the s
[jira] Commented: (OFBIZ-1388) Bug in lookup windows URL
[ https://issues.apache.org/jira/browse/OFBIZ-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552549 ] Bilgin Ibryam commented on OFBIZ-1388: -- Committed in 4.0 rev. 605015 > Bug in lookup windows URL > - > > Key: OFBIZ-1388 > URL: https://issues.apache.org/jira/browse/OFBIZ-1388 > Project: OFBiz > Issue Type: Bug > Components: framework, order >Affects Versions: SVN trunk, Release Branch 4.0 >Reporter: Bilgin Ibryam >Assignee: Jacques Le Roux >Priority: Minor > Fix For: SVN trunk, Release Branch 4.0 > > Attachments: JsLookup.patch, lookup.patch, quicklookup.patch > > > Hi all, > I just noticed a bug in lookup windows url generation. > One way to generate the bug is this: > Go to order manager and add to cart configurable pc (PC001). You can do it > browsing Configurable PCs category on the left corner. > After you add PC001 to cart, you will be in order entry screen and your URL > should look like this: > https://localhost:8443/ordermgr/control/additem/product > At this stage if you try to add another product AND click on the product > lookup button, the screen in the lookup window will be orderentry screen but > not the product lookup screen! > Popup screen will not generate LookupProduct request as it is expected, > instead the request is "additem/LookupProduct" and then ControlServlet > transform it to additem request. You can see that additem is coming from the > URL we mentioned /control/additem/product > Any ideas how to fix this bug? > Bilgin Ibryam -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1249) To permit to to calculate on a DATE object in minilang
[ https://issues.apache.org/jira/browse/OFBIZ-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552548 ] Adrian Crum commented on OFBIZ-1249: I said that there must be at least one adjuster, otherwise the set-calendar operation doesn't make any sense. The remark about "field=" being optional can be ignored. That was more clearly defined as others added their suggestions. "field=" will work just like the existing set operation. > To permit to to calculate on a DATE object in minilang > -- > > Key: OFBIZ-1249 > URL: https://issues.apache.org/jira/browse/OFBIZ-1249 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk > Environment: all >Reporter: Fabien Carrion >Assignee: Jacques Le Roux >Priority: Minor > Fix For: SVN trunk > > Attachments: calculate_date_diff.patch > > > This patch lets use the calculate function in the minilang service function > with java.util.Date and java.sql.Date object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1504) New screen to manage the default glAccountId for the InvoiceItemType entity.
[ https://issues.apache.org/jira/browse/OFBIZ-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pranay Pandey updated OFBIZ-1504: - Attachment: jira-issue-1504.patch Here i am submitting the updated patch for this issue. -- Pranay > New screen to manage the default glAccountId for the InvoiceItemType entity. > > > Key: OFBIZ-1504 > URL: https://issues.apache.org/jira/browse/OFBIZ-1504 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: SVN trunk >Reporter: Jacopo Cappellato > Attachments: jira-issue-1504, jira-issue-1504.patch, > jira-issue-1504.patch > > > This is *not* an organization specific screen, and so it will be accessible > from the top menu of the accounting component. > In the new screen, it will only be possible to update the glAccountId field > of the existing records; adding/removing new records is not allowed, nor > updating the other fields of the InvoiceItemType entity. > Also, the name of the top menu should reflect the specialized scope of this > screen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: mainDecoratorLocation was Include of controllers
I suggested that as well and Scott echoed it. It doesn't seem to be
satisfactory to BJ. So we work at it.
- Original Message
From: Adrian Crum <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 3:57:53 PM
Subject: Re: mainDecoratorLocation was Include of controllers
If all BJ wants to do is display an existing screen with its existing
main decorator, then he can
just use the screen's URL.
Chris Howe wrote:
> Because he wants screens from the party component to be decorated
with the mainDecoratorLocation defined in
party/webapp/partymgr/WEB-INF/web.xml and screens from the product compnent
decorated with the
mainDecoratorLocation defined in product/webapp/catalog/WEB-INF/web.xml
>
> Adrian's solution doesn't appear to solve this problem for BJ. (I had
misread the details of his explanation in saying that it had
previously). BJ requires a custom servlet that will do something like the
following:
>
> 1) process as normal until it begins to process the view
> 2) place the @page attribute into the context (split the
screen ${screen} from the location${location})
> 3) render the following screen
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> - Original Message
> From: Scott Gray <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Monday, December 17, 2007 3:27:53 PM
> Subject: Re: mainDecoratorLocation was Include of controllers
>
>
> Why couldn't you supply your own custom mainDecorator? What do the
> base
> mainDecorators provide that you can't in your custom app?
>
> Scott
>
> On 18/12/2007, BJ Freeman <[EMAIL PROTECTED]> wrote:
>
>>Based on this, I can never see how even if I called from a custom app
>>different screens in different apps how one main-decorator
>>so I am not sure how this feature would work at all.
>>
>>Hence my original suggestion that is apps main-decorator be declared
>
> as
>
>>application-mainDecoratorLocation
>>this way I could include each apps mainDecoratorLocation and not have
>
> to
>
>>worry
>>
>>
>>BJ Freeman sent the following on 12/17/2007 12:55 PM:
>>
>>>I have a menu, no screens, that calls ListPartyCommEvents
>>>this goes to the party controller to resolve.
>>>the party controller uses it view for ListPartyCommEvents
>>>It can not read the party web.xml so will error even with your
>
> changes.
>
>>>so lets say i put in a mainDecoratorLocation in my web xml and
>
> define it
>
>>>like the one in the party commonscreens.xml
>>>
>>>so far so good.
>>>
>>>Now I call a screen in say Product. except the
>
> mainDecoratorLocation for
>
>>>it has a different main-decorator. so all the requirements are not
>>>defined in the party main-Decorator I have ported over.
>>>
>>>we still have a problem since all the apps main-decorators are not
>
> the
>
>>same.
>>
>>>now if the main-decorators were all the same then I could use one
>>>location in any of the apps and everything would be ok
>>>
>>>
>>>
>>>Adrian Crum sent the following on 12/17/2007 12:40 PM:
>>>
1. Move the CommonCommunicationEventDecorator screen to the
communicationsscreens.xml file.
2. Change all
>>>location="${parameters.mainDecoratorLocation}">
to
>>>location="${parameters.communicationEventDecoratorLocation}">
Since parameters.communicationEventDecoratorLocation isn't defined
anywhere, the location will evaluate to the current file:
communicationsscreens.xml. All communication screens still work
>
> the
>
>>same
>>
in Party Manager, but now you can reuse those screens in another
>
> app.
>
When you use one of the communication screens in your custom app
>
> (via
>
included controller.xml file or otherwise) the
parameters.communicationEventDecoratorLocation still isn't defined
anywhere, so it still evaluates to the current file:
communicationsscreens.xml. The communication screen and the
CommonCommunicationEventDecorator will both appear - decorated
>
> with
>
>>your
>>
custom app's main decorator.
(Optional) If someone didn't like the
>>
>>CommonCommunicationEventDecorator,
>>
then they could design their own and specify its location in
parameters.communicationEventDecoratorLocation.
-Adrian
BJ Freeman wrote:
>Ok here is a real situation:
>take the party/widgets/partymgr/commicationsscreens.xml
>location="${parameters.mainDecoratorLocation}">
>which is the CommonSreens.xml
>which has
>location="${parameters.mainDecoratorLocation}">
>
>the main-decorator has
>location="component://common/widget/CommonScreens.xml"/>
>
>
>how would the be with your example
>
>
>
>Adrian Crum sent the following on 12/17/2007 9:33 AM:
>
>
>>BJ,
>>
>>Go ahead and create one. I will work on it when I have time.
>>
>>To be sure we're all on the sam
Re: _ATX_CREATE
OK, I do it Jacques De : "Adrian Crum" <[EMAIL PROTECTED]> > Take a look at services_ledger.xml, line 264. It would be preferable to > convert it to permission > service. > > > Jacques Le Roux wrote: > > > Actually the file AcctgTransServices.xml is not containing services > > implementions but simple-methods. So I will simply replace > > ACCOUNTING by ACCTG where relevant (a sole occurence, the one I pointed) > > > > Jacques > > > > De : "Jacques Le Roux" <[EMAIL PROTECTED]> > > > >>OK I do it > >> > >>Jacques > >> > >>De : "Adrian Crum" <[EMAIL PROTECTED]> > >> > >>>Oops, I just found it. That one slipped in there somehow. That method > >>>should use the permission service. > >>> > >>> > >>>Adrian Crum wrote: > >>> > >>> > I don't see any permission checking logic in AcctgTransServices.xml. I > refactored it to use the permission service. > > > Jacques Le Roux wrote: > > > >Seems that we are on the same page, I will change also > >AcctgTransServices.xml accordingly. As I can't see any problems with > >this I > >will do it right now... > > > >Jacques > > > >De : "Adrian Crum" <[EMAIL PROTECTED]> > > > >>The accounting component services use the ACCTG_ATX_CREATE > >>permission. Properties files should be > >>updated accordingly. > >> > >> > >>Jacques Le Roux wrote: > >> > >> > >> > >>>Thanks Adrian > >>> > >>>But I'm afraid it's not the case. > >>> > >>>Because, > >>>1) I updated this instance this morning and did an ant clean-all > >>>this afternoon and re-created a new Postgres DB this afternon > >>>2) > >>> a) Have a look at AcctgTransServices.xml and > >>>SecurityEntityLabels.properties for ACCOUNTING_ATX_CREATE > >>> b) AccountingSecurityData.xml for ACCTG_ATX_CREATE > >>> > >>>You may even try to search for "ATX_CREATE" in all files ;o) > >>> > >>>It seems to me that ACCOUNTING_ATX_CREATE should be replaced by > >>>ACCTG_ATX_CREATE. I would like to know what the community prefer > > > > > >as > > > > > >>>I need this to commit changes from POS. > >>> > >>>BTW I wonder if we should kept POS SecurityGroupPermission in > >>>PosSecurityData.xml or we should not better put them in > > > > > >corresponding > > > > > >>>basic applications (we should find a common name for applications in > >>>applcations dir, I'm not sure if basic is the right word). > >>> > >>>Thanks > >>> > >>>Jacques > >>> > >>> > >>> > >>> > >>> > >>> > Jacques, > > Do a clean and re-run install. You have mixed seed data. > > -Adrian > > Jacques Le Roux wrote: > > > > > >I wonder why there are 2 _ATX_CREATE permissions > > > >ACCOUNTING_ATX_CREATE Create general ledger accounting transaction > >and entries. > >and > >ACCTG_ATX_CREATE : Create general ledger accounting transaction > >and entries > > > >Is there a reason or is this a duplicate as I suppose ? > > > >Thanks > > > >Jacques > > > > > > > > > >
Re: mainDecoratorLocation was Include of controllers
If all BJ wants to do is display an existing screen with its existing main decorator, then he can
just use the screen's URL.
Chris Howe wrote:
Because he wants screens from the party component to be decorated with the
mainDecoratorLocation defined in party/webapp/partymgr/WEB-INF/web.xml and
screens from the product compnent decorated with the mainDecoratorLocation
defined in product/webapp/catalog/WEB-INF/web.xml
Adrian's solution doesn't appear to solve this problem for BJ. (I had misread
the details of his explanation in saying that it had previously). BJ requires
a custom servlet that will do something like the following:
1) process as normal until it begins to process the view
2) place the @page attribute into the context (split the screen
${screen} from the location${location})
3) render the following screen
- Original Message
From: Scott Gray <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 3:27:53 PM
Subject: Re: mainDecoratorLocation was Include of controllers
Why couldn't you supply your own custom mainDecorator? What do the
base
mainDecorators provide that you can't in your custom app?
Scott
On 18/12/2007, BJ Freeman <[EMAIL PROTECTED]> wrote:
Based on this, I can never see how even if I called from a custom app
different screens in different apps how one main-decorator
so I am not sure how this feature would work at all.
Hence my original suggestion that is apps main-decorator be declared
as
application-mainDecoratorLocation
this way I could include each apps mainDecoratorLocation and not have
to
worry
BJ Freeman sent the following on 12/17/2007 12:55 PM:
I have a menu, no screens, that calls ListPartyCommEvents
this goes to the party controller to resolve.
the party controller uses it view for ListPartyCommEvents
It can not read the party web.xml so will error even with your
changes.
so lets say i put in a mainDecoratorLocation in my web xml and
define it
like the one in the party commonscreens.xml
so far so good.
Now I call a screen in say Product. except the
mainDecoratorLocation for
it has a different main-decorator. so all the requirements are not
defined in the party main-Decorator I have ported over.
we still have a problem since all the apps main-decorators are not
the
same.
now if the main-decorators were all the same then I could use one
location in any of the apps and everything would be ok
Adrian Crum sent the following on 12/17/2007 12:40 PM:
1. Move the CommonCommunicationEventDecorator screen to the
communicationsscreens.xml file.
2. Change all
to
Since parameters.communicationEventDecoratorLocation isn't defined
anywhere, the location will evaluate to the current file:
communicationsscreens.xml. All communication screens still work
the
same
in Party Manager, but now you can reuse those screens in another
app.
When you use one of the communication screens in your custom app
(via
included controller.xml file or otherwise) the
parameters.communicationEventDecoratorLocation still isn't defined
anywhere, so it still evaluates to the current file:
communicationsscreens.xml. The communication screen and the
CommonCommunicationEventDecorator will both appear - decorated
with
your
custom app's main decorator.
(Optional) If someone didn't like the
CommonCommunicationEventDecorator,
then they could design their own and specify its location in
parameters.communicationEventDecoratorLocation.
-Adrian
BJ Freeman wrote:
Ok here is a real situation:
take the party/widgets/partymgr/commicationsscreens.xml
which is the CommonSreens.xml
which has
the main-decorator has
how would the be with your example
Adrian Crum sent the following on 12/17/2007 9:33 AM:
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when
screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to
reuse
the actual-content screen, errors are generated because
evaluates to the
custom
app's main decorator xml file, and the sub-decorator screen
doesn't
exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for
sub-decorators
and
either have no location specified or use a different parameter
for
the
sub-decorator's location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in
the
Accounting component. All of the Agreement screens share a
common
sub-decorator (CommonAgreementDecorator) - and that decorator's
location
is specified as ${parameters.agreementDecoratorLocation}. The
agreementDecoratorLocation parameter isn't defined anywhere, so
the
location= e
Re: mainDecoratorLocation was Include of controllers
did you use two different apps from your app?
yes it will work for one app.
Adrian Crum sent the following on 12/17/2007 1:49 PM:
> The best way to prove it is to code it according to my suggestion and
> test it against the original problem you stated in this thread. It
> works. How do I know that? Because I did it a month ago.
>
> -Adrian
>
> BJ Freeman wrote:
>
>> best way to prove this is to have a menu in a new app.
>> point it to two different screens one in each app.
>> try to get both screens to work with out error.
>> even using your code.
>>
>> BJ Freeman sent the following on 12/17/2007 1:39 PM:
>>
>>> you did not say to change
>>> >> location="${parameters.mainDecoratorLocation}">
>>>
>>> so even your change will not work.
>>>
>>> Adrian Crum sent the following on 12/17/2007 1:32 PM:
>>>
That line wouldn't exist if you made the change I suggested.
Make the code changes, THEN tell me what's wrong with it. Telling me
what's already wrong with it is pointless - I already know the existing
code doesn't work.
BJ Freeman wrote:
> I beg to differ with you.
> where is
> name="CommonCommunicationEventDecorator"
> location="${parameters.mainDecoratorLocation}">
>
> defined
> where is
> location="${parameters.mainDecoratorLocation}">
> in the CommonPartyDecorator defined.
>
> Adrian Crum sent the following on 12/17/2007 1:03 PM:
>
>
>> ListPartyCommEvents request maps to ListPartyCommEvents view, that
>> maps
>> to
>> component://party/widget/partymgr/CommunicationScreens.xml#ListPartyCommEvents.
>>
>>
>>
>>
>> The ListPartyCommEvents screen in CommunicationScreens.xml doesn't
>> contain anything specific to the Party Manager's web.xml file. I
>> don't
>> see what the problem is.
>>
>> Maybe you should include an exact error message.
>>
>> -Adrian
>>
>> BJ Freeman wrote:
>>
>>
>>
>>> I have a menu, no screens, that calls ListPartyCommEvents
>>> this goes to the party controller to resolve.
>>> the party controller uses it view for ListPartyCommEvents
>>> It can not read the party web.xml so will error even with your
>>> changes.
>>>
>>> so lets say i put in a mainDecoratorLocation in my web xml and
>>> define it
>>> like the one in the party commonscreens.xml
>>>
>>> so far so good.
>>>
>>> Now I call a screen in say Product. except the mainDecoratorLocation
>>> for
>>> it has a different main-decorator. so all the requirements are not
>>> defined in the party main-Decorator I have ported over.
>>>
>>> we still have a problem since all the apps main-decorators are
>>> not the
>>> same.
>>>
>>> now if the main-decorators were all the same then I could use one
>>> location in any of the apps and everything would be ok
>>>
>>>
>>>
>>> Adrian Crum sent the following on 12/17/2007 12:40 PM:
>>>
>>>
>>>
1. Move the CommonCommunicationEventDecorator screen to the
communicationsscreens.xml file.
2. Change all
>>> location="${parameters.mainDecoratorLocation}">
to
>>> location="${parameters.communicationEventDecoratorLocation}">
Since parameters.communicationEventDecoratorLocation isn't defined
anywhere, the location will evaluate to the current file:
communicationsscreens.xml. All communication screens still work the
same
in Party Manager, but now you can reuse those screens in another
app.
When you use one of the communication screens in your custom app
(via
included controller.xml file or otherwise) the
parameters.communicationEventDecoratorLocation still isn't defined
anywhere, so it still evaluates to the current file:
communicationsscreens.xml. The communication screen and the
CommonCommunicationEventDecorator will both appear - decorated with
your
custom app's main decorator.
(Optional) If someone didn't like the
CommonCommunicationEventDecorator,
then they could design their own and specify its location in
parameters.communicationEventDecoratorLocation.
-Adrian
BJ Freeman wrote:
> Ok here is a real situation:
> take the party/widgets/partymgr/commicationsscreens.xml
> location="${parameters.mainDecoratorLocation}">
> which is the CommonSreens.xml
> which has
> location="${parameters.mainDecoratorLocation}">
>
> the main-decorator has
> location="component://common/widget/CommonScreens.xml"/>
>
Re: mainDecoratorLocation change to app-mainDecoratorLocation was Include of controllers
Ok so if we just change mainDecoratorLocation to
party-mainDecoratorLocation
everything will work
I can just include in my web.xml
one for each app I am using.
they will thier own main-decorators and everthing works as it should.
very simple fix.
BJ Freeman sent the following on 12/17/2007 1:44 PM:
> and just to make this a point
> there can be only one
>
> so if I had my own main-decorator it would not work for calling all
> other apps.
>
>
> BJ Freeman sent the following on 12/17/2007 1:38 PM:
>> short answer is I can
>> but that still would not solve the problem.
>> take the party main-decorator
>>
>>
>> > value="/partymgr/static/partymgr.js" global="true"/>
>> > value="/partymgr/static/partymgr.css" global="true"/>
>>
>> > value="component://party/webapp/partymgr/includes/appheader.ftl"
>> global="true"/>
>>
>> not these can not be the same ones if I am calling the product
>> main-decorator
>>
>> > value="component://product/webapp/catalog/includes/appheader.ftl"
>> global="true"/>
>>
>>
>>
>> Scott Gray sent the following on 12/17/2007 1:27 PM:
>>> Why couldn't you supply your own custom mainDecorator? What do the base
>>> mainDecorators provide that you can't in your custom app?
>>>
>>> Scott
>>>
>>> On 18/12/2007, BJ Freeman <[EMAIL PROTECTED]> wrote:
Based on this, I can never see how even if I called from a custom app
different screens in different apps how one main-decorator
so I am not sure how this feature would work at all.
Hence my original suggestion that is apps main-decorator be declared as
application-mainDecoratorLocation
this way I could include each apps mainDecoratorLocation and not have to
worry
BJ Freeman sent the following on 12/17/2007 12:55 PM:
> I have a menu, no screens, that calls ListPartyCommEvents
> this goes to the party controller to resolve.
> the party controller uses it view for ListPartyCommEvents
> It can not read the party web.xml so will error even with your changes.
>
> so lets say i put in a mainDecoratorLocation in my web xml and define it
> like the one in the party commonscreens.xml
>
> so far so good.
>
> Now I call a screen in say Product. except the mainDecoratorLocation for
> it has a different main-decorator. so all the requirements are not
> defined in the party main-Decorator I have ported over.
>
> we still have a problem since all the apps main-decorators are not the
same.
> now if the main-decorators were all the same then I could use one
> location in any of the apps and everything would be ok
>
>
>
> Adrian Crum sent the following on 12/17/2007 12:40 PM:
>> 1. Move the CommonCommunicationEventDecorator screen to the
>> communicationsscreens.xml file.
>> 2. Change all
>> > location="${parameters.mainDecoratorLocation}">
>>
>> to
>>
>> > location="${parameters.communicationEventDecoratorLocation}">
>>
>> Since parameters.communicationEventDecoratorLocation isn't defined
>> anywhere, the location will evaluate to the current file:
>> communicationsscreens.xml. All communication screens still work the
same
>> in Party Manager, but now you can reuse those screens in another app.
>>
>> When you use one of the communication screens in your custom app (via
>> included controller.xml file or otherwise) the
>> parameters.communicationEventDecoratorLocation still isn't defined
>> anywhere, so it still evaluates to the current file:
>> communicationsscreens.xml. The communication screen and the
>> CommonCommunicationEventDecorator will both appear - decorated with
your
>> custom app's main decorator.
>>
>> (Optional) If someone didn't like the
CommonCommunicationEventDecorator,
>> then they could design their own and specify its location in
>> parameters.communicationEventDecoratorLocation.
>>
>> -Adrian
>>
>> BJ Freeman wrote:
>>
>>> Ok here is a real situation:
>>> take the party/widgets/partymgr/commicationsscreens.xml
>>> >> location="${parameters.mainDecoratorLocation}">
>>> which is the CommonSreens.xml
>>> which has
>>> >> location="${parameters.mainDecoratorLocation}">
>>>
>>> the main-decorator has
>>> >> location="component://common/widget/CommonScreens.xml"/>
>>>
>>>
>>> how would the be with your example
>>>
>>>
>>>
>>> Adrian Crum sent the following on 12/17/2007 9:33 AM:
>>>
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when
screens
are nested as follows:
...
>>
Re: mainDecoratorLocation was Include of controllers
Because he wants screens from the party component to be decorated with the
mainDecoratorLocation defined in party/webapp/partymgr/WEB-INF/web.xml and
screens from the product compnent decorated with the mainDecoratorLocation
defined in product/webapp/catalog/WEB-INF/web.xml
Adrian's solution doesn't appear to solve this problem for BJ. (I had misread
the details of his explanation in saying that it had previously). BJ requires
a custom servlet that will do something like the following:
1) process as normal until it begins to process the view
2) place the @page attribute into the context (split the screen
${screen} from the location${location})
3) render the following screen
- Original Message
From: Scott Gray <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 3:27:53 PM
Subject: Re: mainDecoratorLocation was Include of controllers
Why couldn't you supply your own custom mainDecorator? What do the
base
mainDecorators provide that you can't in your custom app?
Scott
On 18/12/2007, BJ Freeman <[EMAIL PROTECTED]> wrote:
>
> Based on this, I can never see how even if I called from a custom app
> different screens in different apps how one main-decorator
> so I am not sure how this feature would work at all.
>
> Hence my original suggestion that is apps main-decorator be declared
as
> application-mainDecoratorLocation
> this way I could include each apps mainDecoratorLocation and not have
to
> worry
>
>
> BJ Freeman sent the following on 12/17/2007 12:55 PM:
> > I have a menu, no screens, that calls ListPartyCommEvents
> > this goes to the party controller to resolve.
> > the party controller uses it view for ListPartyCommEvents
> > It can not read the party web.xml so will error even with your
changes.
> >
> > so lets say i put in a mainDecoratorLocation in my web xml and
define it
> > like the one in the party commonscreens.xml
> >
> > so far so good.
> >
> > Now I call a screen in say Product. except the
mainDecoratorLocation for
> > it has a different main-decorator. so all the requirements are not
> > defined in the party main-Decorator I have ported over.
> >
> > we still have a problem since all the apps main-decorators are not
the
> same.
> >
> > now if the main-decorators were all the same then I could use one
> > location in any of the apps and everything would be ok
> >
> >
> >
> > Adrian Crum sent the following on 12/17/2007 12:40 PM:
> >> 1. Move the CommonCommunicationEventDecorator screen to the
> >> communicationsscreens.xml file.
> >> 2. Change all
> >> >> location="${parameters.mainDecoratorLocation}">
> >>
> >> to
> >>
> >> >> location="${parameters.communicationEventDecoratorLocation}">
> >>
> >> Since parameters.communicationEventDecoratorLocation isn't defined
> >> anywhere, the location will evaluate to the current file:
> >> communicationsscreens.xml. All communication screens still work
the
> same
> >> in Party Manager, but now you can reuse those screens in another
app.
> >>
> >> When you use one of the communication screens in your custom app
(via
> >> included controller.xml file or otherwise) the
> >> parameters.communicationEventDecoratorLocation still isn't defined
> >> anywhere, so it still evaluates to the current file:
> >> communicationsscreens.xml. The communication screen and the
> >> CommonCommunicationEventDecorator will both appear - decorated
with
> your
> >> custom app's main decorator.
> >>
> >> (Optional) If someone didn't like the
> CommonCommunicationEventDecorator,
> >> then they could design their own and specify its location in
> >> parameters.communicationEventDecoratorLocation.
> >>
> >> -Adrian
> >>
> >> BJ Freeman wrote:
> >>
> >>> Ok here is a real situation:
> >>> take the party/widgets/partymgr/commicationsscreens.xml
> >>> >>> location="${parameters.mainDecoratorLocation}">
> >>> which is the CommonSreens.xml
> >>> which has
> >>> >>> location="${parameters.mainDecoratorLocation}">
> >>>
> >>> the main-decorator has
> >>> >>> location="component://common/widget/CommonScreens.xml"/>
> >>>
> >>>
> >>> how would the be with your example
> >>>
> >>>
> >>>
> >>> Adrian Crum sent the following on 12/17/2007 9:33 AM:
> >>>
> BJ,
>
> Go ahead and create one. I will work on it when I have time.
>
> To be sure we're all on the same page, the problem exists when
> screens
> are nested as follows:
>
>
>
>
>
> ...
>
>
>
>
>
> and the location of the sub-decorator screen is defined as
> ${parameters.mainDecoratorLocation}. When a custom app tries to
reuse
> the actual-content screen, errors are generated because
> location="${parameters.mainDecoratorLocation}"> evaluates to the
> custom
> app's main decorator xml file, and the sub-decorator screen
doesn't
> exist there.
Re: mainDecoratorLocation was Include of controllers
The best way to prove it is to code it according to my suggestion and test it against the original
problem you stated in this thread. It works. How do I know that? Because I did it a month ago.
-Adrian
BJ Freeman wrote:
best way to prove this is to have a menu in a new app.
point it to two different screens one in each app.
try to get both screens to work with out error.
even using your code.
BJ Freeman sent the following on 12/17/2007 1:39 PM:
you did not say to change
so even your change will not work.
Adrian Crum sent the following on 12/17/2007 1:32 PM:
That line wouldn't exist if you made the change I suggested.
Make the code changes, THEN tell me what's wrong with it. Telling me
what's already wrong with it is pointless - I already know the existing
code doesn't work.
BJ Freeman wrote:
I beg to differ with you.
where is
defined
where is
in the CommonPartyDecorator defined.
Adrian Crum sent the following on 12/17/2007 1:03 PM:
ListPartyCommEvents request maps to ListPartyCommEvents view, that maps
to
component://party/widget/partymgr/CommunicationScreens.xml#ListPartyCommEvents.
The ListPartyCommEvents screen in CommunicationScreens.xml doesn't
contain anything specific to the Party Manager's web.xml file. I don't
see what the problem is.
Maybe you should include an exact error message.
-Adrian
BJ Freeman wrote:
I have a menu, no screens, that calls ListPartyCommEvents
this goes to the party controller to resolve.
the party controller uses it view for ListPartyCommEvents
It can not read the party web.xml so will error even with your changes.
so lets say i put in a mainDecoratorLocation in my web xml and
define it
like the one in the party commonscreens.xml
so far so good.
Now I call a screen in say Product. except the mainDecoratorLocation
for
it has a different main-decorator. so all the requirements are not
defined in the party main-Decorator I have ported over.
we still have a problem since all the apps main-decorators are not the
same.
now if the main-decorators were all the same then I could use one
location in any of the apps and everything would be ok
Adrian Crum sent the following on 12/17/2007 12:40 PM:
1. Move the CommonCommunicationEventDecorator screen to the
communicationsscreens.xml file.
2. Change all
to
Since parameters.communicationEventDecoratorLocation isn't defined
anywhere, the location will evaluate to the current file:
communicationsscreens.xml. All communication screens still work the
same
in Party Manager, but now you can reuse those screens in another app.
When you use one of the communication screens in your custom app (via
included controller.xml file or otherwise) the
parameters.communicationEventDecoratorLocation still isn't defined
anywhere, so it still evaluates to the current file:
communicationsscreens.xml. The communication screen and the
CommonCommunicationEventDecorator will both appear - decorated with
your
custom app's main decorator.
(Optional) If someone didn't like the
CommonCommunicationEventDecorator,
then they could design their own and specify its location in
parameters.communicationEventDecoratorLocation.
-Adrian
BJ Freeman wrote:
Ok here is a real situation:
take the party/widgets/partymgr/commicationsscreens.xml
which is the CommonSreens.xml
which has
the main-decorator has
how would the be with your example
Adrian Crum sent the following on 12/17/2007 9:33 AM:
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when
screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to
reuse
the actual-content screen, errors are generated because
evaluates to the
custom
app's main decorator xml file, and the sub-decorator screen doesn't
exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for
sub-decorators and
either have no location specified or use a different parameter
for the
sub-decorator's location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in the
Accounting component. All of the Agreement screens share a common
sub-decorator (CommonAgreementDecorator) - and that decorator's
location
is specified as ${parameters.agreementDecoratorLocation}. The
agreementDecoratorLocation parameter isn't defined anywhere, so the
location= expression evaluates to an empty String - which causes the
screen widget view handler to look for CommonAgreementDecorator
in the
existing file.
A custom app that reuses one of the Agreement screens will only
need to
specify the mainDecoratorLocation parameter. Since no
agreementDecoratorLocation parameter is defined in the custom
app, the
sub-decorator in AgreementScreens.xml is used (same as above). If a
custom app wanted to hav
[jira] Commented: (OFBIZ-1249) To permit to to calculate on a DATE object in minilang
[
https://issues.apache.org/jira/browse/OFBIZ-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552542
]
Jacques Le Roux commented on OFBIZ-1249:
If I have weel understood, Adrian proposed in dev ML that the attribute
"field=" could be optionnal, and also adjusters attributes (years="${year}"...
millis="${millis}") . But there must be at least one of them (including
"field=" in them, this is not clear to me ?)
I don't think a such a rule (optionnal but one fields rule) is already used in
minilang.
> To permit to to calculate on a DATE object in minilang
> --
>
> Key: OFBIZ-1249
> URL: https://issues.apache.org/jira/browse/OFBIZ-1249
> Project: OFBiz
> Issue Type: New Feature
> Components: framework
>Affects Versions: SVN trunk
> Environment: all
>Reporter: Fabien Carrion
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: calculate_date_diff.patch
>
>
> This patch lets use the calculate function in the minilang service function
> with java.util.Date and java.sql.Date object.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: mainDecoratorLocation was Include of controllers
best way to prove this is to have a menu in a new app.
point it to two different screens one in each app.
try to get both screens to work with out error.
even using your code.
BJ Freeman sent the following on 12/17/2007 1:39 PM:
> you did not say to change
> location="${parameters.mainDecoratorLocation}">
>
> so even your change will not work.
>
> Adrian Crum sent the following on 12/17/2007 1:32 PM:
>> That line wouldn't exist if you made the change I suggested.
>>
>> Make the code changes, THEN tell me what's wrong with it. Telling me
>> what's already wrong with it is pointless - I already know the existing
>> code doesn't work.
>>
>>
>> BJ Freeman wrote:
>>
>>> I beg to differ with you.
>>> where is
>>> >> name="CommonCommunicationEventDecorator"
>>> location="${parameters.mainDecoratorLocation}">
>>>
>>> defined
>>> where is
>>> >> location="${parameters.mainDecoratorLocation}">
>>> in the CommonPartyDecorator defined.
>>>
>>> Adrian Crum sent the following on 12/17/2007 1:03 PM:
>>>
ListPartyCommEvents request maps to ListPartyCommEvents view, that maps
to
component://party/widget/partymgr/CommunicationScreens.xml#ListPartyCommEvents.
The ListPartyCommEvents screen in CommunicationScreens.xml doesn't
contain anything specific to the Party Manager's web.xml file. I don't
see what the problem is.
Maybe you should include an exact error message.
-Adrian
BJ Freeman wrote:
> I have a menu, no screens, that calls ListPartyCommEvents
> this goes to the party controller to resolve.
> the party controller uses it view for ListPartyCommEvents
> It can not read the party web.xml so will error even with your changes.
>
> so lets say i put in a mainDecoratorLocation in my web xml and
> define it
> like the one in the party commonscreens.xml
>
> so far so good.
>
> Now I call a screen in say Product. except the mainDecoratorLocation
> for
> it has a different main-decorator. so all the requirements are not
> defined in the party main-Decorator I have ported over.
>
> we still have a problem since all the apps main-decorators are not the
> same.
>
> now if the main-decorators were all the same then I could use one
> location in any of the apps and everything would be ok
>
>
>
> Adrian Crum sent the following on 12/17/2007 12:40 PM:
>
>
>> 1. Move the CommonCommunicationEventDecorator screen to the
>> communicationsscreens.xml file.
>> 2. Change all
>> > location="${parameters.mainDecoratorLocation}">
>>
>> to
>>
>> > location="${parameters.communicationEventDecoratorLocation}">
>>
>> Since parameters.communicationEventDecoratorLocation isn't defined
>> anywhere, the location will evaluate to the current file:
>> communicationsscreens.xml. All communication screens still work the
>> same
>> in Party Manager, but now you can reuse those screens in another app.
>>
>> When you use one of the communication screens in your custom app (via
>> included controller.xml file or otherwise) the
>> parameters.communicationEventDecoratorLocation still isn't defined
>> anywhere, so it still evaluates to the current file:
>> communicationsscreens.xml. The communication screen and the
>> CommonCommunicationEventDecorator will both appear - decorated with
>> your
>> custom app's main decorator.
>>
>> (Optional) If someone didn't like the
>> CommonCommunicationEventDecorator,
>> then they could design their own and specify its location in
>> parameters.communicationEventDecoratorLocation.
>>
>> -Adrian
>>
>> BJ Freeman wrote:
>>
>>
>>
>>> Ok here is a real situation:
>>> take the party/widgets/partymgr/commicationsscreens.xml
>>> >> location="${parameters.mainDecoratorLocation}">
>>> which is the CommonSreens.xml
>>> which has
>>> >> location="${parameters.mainDecoratorLocation}">
>>>
>>> the main-decorator has
>>> >> location="component://common/widget/CommonScreens.xml"/>
>>>
>>>
>>> how would the be with your example
>>>
>>>
>>>
>>> Adrian Crum sent the following on 12/17/2007 9:33 AM:
>>>
>>>
>>>
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when
screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to
reuse
the actual-content screen, errors are generated because
Re: mainDecoratorLocation was Include of controllers
and just to make this a point
there can be only one
so if I had my own main-decorator it would not work for calling all
other apps.
BJ Freeman sent the following on 12/17/2007 1:38 PM:
> short answer is I can
> but that still would not solve the problem.
> take the party main-decorator
>
>
> value="/partymgr/static/partymgr.js" global="true"/>
> value="/partymgr/static/partymgr.css" global="true"/>
>
> value="component://party/webapp/partymgr/includes/appheader.ftl"
> global="true"/>
>
> not these can not be the same ones if I am calling the product
> main-decorator
>
> value="component://product/webapp/catalog/includes/appheader.ftl"
> global="true"/>
>
>
>
> Scott Gray sent the following on 12/17/2007 1:27 PM:
>> Why couldn't you supply your own custom mainDecorator? What do the base
>> mainDecorators provide that you can't in your custom app?
>>
>> Scott
>>
>> On 18/12/2007, BJ Freeman <[EMAIL PROTECTED]> wrote:
>>> Based on this, I can never see how even if I called from a custom app
>>> different screens in different apps how one main-decorator
>>> so I am not sure how this feature would work at all.
>>>
>>> Hence my original suggestion that is apps main-decorator be declared as
>>> application-mainDecoratorLocation
>>> this way I could include each apps mainDecoratorLocation and not have to
>>> worry
>>>
>>>
>>> BJ Freeman sent the following on 12/17/2007 12:55 PM:
I have a menu, no screens, that calls ListPartyCommEvents
this goes to the party controller to resolve.
the party controller uses it view for ListPartyCommEvents
It can not read the party web.xml so will error even with your changes.
so lets say i put in a mainDecoratorLocation in my web xml and define it
like the one in the party commonscreens.xml
so far so good.
Now I call a screen in say Product. except the mainDecoratorLocation for
it has a different main-decorator. so all the requirements are not
defined in the party main-Decorator I have ported over.
we still have a problem since all the apps main-decorators are not the
>>> same.
now if the main-decorators were all the same then I could use one
location in any of the apps and everything would be ok
Adrian Crum sent the following on 12/17/2007 12:40 PM:
> 1. Move the CommonCommunicationEventDecorator screen to the
> communicationsscreens.xml file.
> 2. Change all
> location="${parameters.mainDecoratorLocation}">
>
> to
>
> location="${parameters.communicationEventDecoratorLocation}">
>
> Since parameters.communicationEventDecoratorLocation isn't defined
> anywhere, the location will evaluate to the current file:
> communicationsscreens.xml. All communication screens still work the
>>> same
> in Party Manager, but now you can reuse those screens in another app.
>
> When you use one of the communication screens in your custom app (via
> included controller.xml file or otherwise) the
> parameters.communicationEventDecoratorLocation still isn't defined
> anywhere, so it still evaluates to the current file:
> communicationsscreens.xml. The communication screen and the
> CommonCommunicationEventDecorator will both appear - decorated with
>>> your
> custom app's main decorator.
>
> (Optional) If someone didn't like the
>>> CommonCommunicationEventDecorator,
> then they could design their own and specify its location in
> parameters.communicationEventDecoratorLocation.
>
> -Adrian
>
> BJ Freeman wrote:
>
>> Ok here is a real situation:
>> take the party/widgets/partymgr/commicationsscreens.xml
>> > location="${parameters.mainDecoratorLocation}">
>> which is the CommonSreens.xml
>> which has
>> > location="${parameters.mainDecoratorLocation}">
>>
>> the main-decorator has
>> > location="component://common/widget/CommonScreens.xml"/>
>>
>>
>> how would the be with your example
>>
>>
>>
>> Adrian Crum sent the following on 12/17/2007 9:33 AM:
>>
>>> BJ,
>>>
>>> Go ahead and create one. I will work on it when I have time.
>>>
>>> To be sure we're all on the same page, the problem exists when
>>> screens
>>> are nested as follows:
>>>
>>>
>>>
>>>
>>>
>>>...
>>>
>>>
>>>
>>>
>>>
>>> and the location of the sub-decorator screen is defined as
>>> ${parameters.mainDecoratorLocation}. When a custom app tries to reuse
>>> the actual-content screen, errors are generated because
>>> >> location="${parameters.mainDecoratorLocation}"> evaluates to the
>>> custom
>>> app's main decorator xml file, and the sub-decorator screen doesn't
>>> exist the
Re: mainDecoratorLocation was Include of controllers
No, that's not what I said.
BJ Freeman wrote:
you did not say to change
so even your change will not work.
Adrian Crum sent the following on 12/17/2007 1:32 PM:
That line wouldn't exist if you made the change I suggested.
Make the code changes, THEN tell me what's wrong with it. Telling me
what's already wrong with it is pointless - I already know the existing
code doesn't work.
BJ Freeman wrote:
I beg to differ with you.
where is
defined
where is
in the CommonPartyDecorator defined.
Adrian Crum sent the following on 12/17/2007 1:03 PM:
ListPartyCommEvents request maps to ListPartyCommEvents view, that maps
to
component://party/widget/partymgr/CommunicationScreens.xml#ListPartyCommEvents.
The ListPartyCommEvents screen in CommunicationScreens.xml doesn't
contain anything specific to the Party Manager's web.xml file. I don't
see what the problem is.
Maybe you should include an exact error message.
-Adrian
BJ Freeman wrote:
I have a menu, no screens, that calls ListPartyCommEvents
this goes to the party controller to resolve.
the party controller uses it view for ListPartyCommEvents
It can not read the party web.xml so will error even with your changes.
so lets say i put in a mainDecoratorLocation in my web xml and
define it
like the one in the party commonscreens.xml
so far so good.
Now I call a screen in say Product. except the mainDecoratorLocation
for
it has a different main-decorator. so all the requirements are not
defined in the party main-Decorator I have ported over.
we still have a problem since all the apps main-decorators are not the
same.
now if the main-decorators were all the same then I could use one
location in any of the apps and everything would be ok
Adrian Crum sent the following on 12/17/2007 12:40 PM:
1. Move the CommonCommunicationEventDecorator screen to the
communicationsscreens.xml file.
2. Change all
to
Since parameters.communicationEventDecoratorLocation isn't defined
anywhere, the location will evaluate to the current file:
communicationsscreens.xml. All communication screens still work the
same
in Party Manager, but now you can reuse those screens in another app.
When you use one of the communication screens in your custom app (via
included controller.xml file or otherwise) the
parameters.communicationEventDecoratorLocation still isn't defined
anywhere, so it still evaluates to the current file:
communicationsscreens.xml. The communication screen and the
CommonCommunicationEventDecorator will both appear - decorated with
your
custom app's main decorator.
(Optional) If someone didn't like the
CommonCommunicationEventDecorator,
then they could design their own and specify its location in
parameters.communicationEventDecoratorLocation.
-Adrian
BJ Freeman wrote:
Ok here is a real situation:
take the party/widgets/partymgr/commicationsscreens.xml
which is the CommonSreens.xml
which has
the main-decorator has
how would the be with your example
Adrian Crum sent the following on 12/17/2007 9:33 AM:
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when
screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to
reuse
the actual-content screen, errors are generated because
evaluates to the
custom
app's main decorator xml file, and the sub-decorator screen doesn't
exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for
sub-decorators and
either have no location specified or use a different parameter
for the
sub-decorator's location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in the
Accounting component. All of the Agreement screens share a common
sub-decorator (CommonAgreementDecorator) - and that decorator's
location
is specified as ${parameters.agreementDecoratorLocation}. The
agreementDecoratorLocation parameter isn't defined anywhere, so the
location= expression evaluates to an empty String - which causes the
screen widget view handler to look for CommonAgreementDecorator
in the
existing file.
A custom app that reuses one of the Agreement screens will only
need to
specify the mainDecoratorLocation parameter. Since no
agreementDecoratorLocation parameter is defined in the custom
app, the
sub-decorator in AgreementScreens.xml is used (same as above). If a
custom app wanted to have a custom sub-decorator, then it can
specify
that decorator's location in the agreementDecoratorLocation
parameter.
-Adrian
BJ Freeman wrote:
I agree, it is not a controller or web.xml issue. However it is
when it
shows up.
I will change them as I come along also.
thanks, that is all I wanted to know.
do you want to create a jira so I can submit changes?
Adrian Crum sent the following on 12/17/2
Re: mainDecoratorLocation was Include of controllers
In that case, activeApp becomes your custom app, and appheaderTemplate points to your custom app
header template. The party manager javascript and stylesheet elements would have to be copied over
to your main-decorator.
BJ Freeman wrote:
short answer is I can
but that still would not solve the problem.
take the party main-decorator
not these can not be the same ones if I am calling the product
main-decorator
Scott Gray sent the following on 12/17/2007 1:27 PM:
Why couldn't you supply your own custom mainDecorator? What do the base
mainDecorators provide that you can't in your custom app?
Scott
On 18/12/2007, BJ Freeman <[EMAIL PROTECTED]> wrote:
Based on this, I can never see how even if I called from a custom app
different screens in different apps how one main-decorator
so I am not sure how this feature would work at all.
Hence my original suggestion that is apps main-decorator be declared as
application-mainDecoratorLocation
this way I could include each apps mainDecoratorLocation and not have to
worry
BJ Freeman sent the following on 12/17/2007 12:55 PM:
I have a menu, no screens, that calls ListPartyCommEvents
this goes to the party controller to resolve.
the party controller uses it view for ListPartyCommEvents
It can not read the party web.xml so will error even with your changes.
so lets say i put in a mainDecoratorLocation in my web xml and define it
like the one in the party commonscreens.xml
so far so good.
Now I call a screen in say Product. except the mainDecoratorLocation for
it has a different main-decorator. so all the requirements are not
defined in the party main-Decorator I have ported over.
we still have a problem since all the apps main-decorators are not the
same.
now if the main-decorators were all the same then I could use one
location in any of the apps and everything would be ok
Adrian Crum sent the following on 12/17/2007 12:40 PM:
1. Move the CommonCommunicationEventDecorator screen to the
communicationsscreens.xml file.
2. Change all
to
Since parameters.communicationEventDecoratorLocation isn't defined
anywhere, the location will evaluate to the current file:
communicationsscreens.xml. All communication screens still work the
same
in Party Manager, but now you can reuse those screens in another app.
When you use one of the communication screens in your custom app (via
included controller.xml file or otherwise) the
parameters.communicationEventDecoratorLocation still isn't defined
anywhere, so it still evaluates to the current file:
communicationsscreens.xml. The communication screen and the
CommonCommunicationEventDecorator will both appear - decorated with
your
custom app's main decorator.
(Optional) If someone didn't like the
CommonCommunicationEventDecorator,
then they could design their own and specify its location in
parameters.communicationEventDecoratorLocation.
-Adrian
BJ Freeman wrote:
Ok here is a real situation:
take the party/widgets/partymgr/commicationsscreens.xml
which is the CommonSreens.xml
which has
the main-decorator has
how would the be with your example
Adrian Crum sent the following on 12/17/2007 9:33 AM:
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when
screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to reuse
the actual-content screen, errors are generated because
evaluates to the
custom
app's main decorator xml file, and the sub-decorator screen doesn't
exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for sub-decorators
and
either have no location specified or use a different parameter for
the
sub-decorator's location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in the
Accounting component. All of the Agreement screens share a common
sub-decorator (CommonAgreementDecorator) - and that decorator's
location
is specified as ${parameters.agreementDecoratorLocation}. The
agreementDecoratorLocation parameter isn't defined anywhere, so the
location= expression evaluates to an empty String - which causes the
screen widget view handler to look for CommonAgreementDecorator in
the
existing file.
A custom app that reuses one of the Agreement screens will only need
to
specify the mainDecoratorLocation parameter. Since no
agreementDecoratorLocation parameter is defined in the custom app,
the
sub-decorator in AgreementScreens.xml is used (same as above). If a
custom app wanted to have a custom sub-decorator, then it can specify
that decorator's location in the agreementDecoratorLocation
parameter.
-Adrian
BJ Freeman wrote:
Re: svn commit: r604986 - /ofbiz/trunk/applications/accounting/config/payment.properties
Oops; sorry forgot the # when copying. Mmm... I wonder if it will not give the same result a null string or a false string is the same for an URL isn'it ? Jacques De : "BJ Freeman" <[EMAIL PROTECTED]> > actually suggested, since he put in the code to look for a blank parm > > #payment.paypal.notify=http://[yourServerName]/ecommerce/control/payPalNotify > payment.paypal.notify= > > Note the # Which is the equivalent of a remark > > [EMAIL PROTECTED] sent the following on 12/17/2007 12:31 PM: > > Author: jleroux > > Date: Mon Dec 17 12:31:47 2007 > > New Revision: 604986 > > > > URL: http://svn.apache.org/viewvc?rev=604986&view=rev > > Log: > > I guess it's better to put this one too (and 3 typos) > > > > Modified: > > ofbiz/trunk/applications/accounting/config/payment.properties > > > > Modified: ofbiz/trunk/applications/accounting/config/payment.properties > > URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/payment.properties?rev=604986&r1=604985&r2=604986&view=diff > > == > > --- ofbiz/trunk/applications/accounting/config/payment.properties (original) > > +++ ofbiz/trunk/applications/accounting/config/payment.properties Mon Dec > > 17 12:31:47 2007 > > @@ -242,16 +242,16 @@ > > [EMAIL PROTECTED] > > > > # PayPal Notify URL > > -payment.paypal.notify=http://[yourServerName)/ecommerce/control/payPalNotify > > +payment.paypal.notify=http://[yourServerName]/ecommerce/control/payPalNotify > > > > # PayPal Return URL > > -payment.paypal.return=http://[yourServerName)/ecommerce/control/orderhistory > > +payment.paypal.return=http://[yourServerName]/ecommerce/control/orderhistory > > > > # PayPal Return On Cancel URL > > -payment.paypal.cancelReturn=http://[yourServerName)/ecommerce/control/payPalCancel/main > > +payment.paypal.cancelReturn=http://[yourServerName]/ecommerce/control/payPalCancel/main > > > > # Image To Use On PayPal > > -payment.paypal.image=http://demo.hotwaxmedia.com/images/ofbiz_logo.jpg > > +payment.paypal.image=http://[yourServerName]/images/ofbiz_logo.jpg > > > > # Thank-You / Confirm Order Template (rendered via Freemarker) > > payment.paypal.confirmTemplate=/order/emailconfirmation.ftl > > > > > > > > > > >
Re: mainDecoratorLocation was Include of controllers
you did not say to change
so even your change will not work.
Adrian Crum sent the following on 12/17/2007 1:32 PM:
> That line wouldn't exist if you made the change I suggested.
>
> Make the code changes, THEN tell me what's wrong with it. Telling me
> what's already wrong with it is pointless - I already know the existing
> code doesn't work.
>
>
> BJ Freeman wrote:
>
>> I beg to differ with you.
>> where is
>> > name="CommonCommunicationEventDecorator"
>> location="${parameters.mainDecoratorLocation}">
>>
>> defined
>> where is
>> > location="${parameters.mainDecoratorLocation}">
>> in the CommonPartyDecorator defined.
>>
>> Adrian Crum sent the following on 12/17/2007 1:03 PM:
>>
>>> ListPartyCommEvents request maps to ListPartyCommEvents view, that maps
>>> to
>>> component://party/widget/partymgr/CommunicationScreens.xml#ListPartyCommEvents.
>>>
>>>
>>>
>>> The ListPartyCommEvents screen in CommunicationScreens.xml doesn't
>>> contain anything specific to the Party Manager's web.xml file. I don't
>>> see what the problem is.
>>>
>>> Maybe you should include an exact error message.
>>>
>>> -Adrian
>>>
>>> BJ Freeman wrote:
>>>
>>>
I have a menu, no screens, that calls ListPartyCommEvents
this goes to the party controller to resolve.
the party controller uses it view for ListPartyCommEvents
It can not read the party web.xml so will error even with your changes.
so lets say i put in a mainDecoratorLocation in my web xml and
define it
like the one in the party commonscreens.xml
so far so good.
Now I call a screen in say Product. except the mainDecoratorLocation
for
it has a different main-decorator. so all the requirements are not
defined in the party main-Decorator I have ported over.
we still have a problem since all the apps main-decorators are not the
same.
now if the main-decorators were all the same then I could use one
location in any of the apps and everything would be ok
Adrian Crum sent the following on 12/17/2007 12:40 PM:
> 1. Move the CommonCommunicationEventDecorator screen to the
> communicationsscreens.xml file.
> 2. Change all
> location="${parameters.mainDecoratorLocation}">
>
> to
>
> location="${parameters.communicationEventDecoratorLocation}">
>
> Since parameters.communicationEventDecoratorLocation isn't defined
> anywhere, the location will evaluate to the current file:
> communicationsscreens.xml. All communication screens still work the
> same
> in Party Manager, but now you can reuse those screens in another app.
>
> When you use one of the communication screens in your custom app (via
> included controller.xml file or otherwise) the
> parameters.communicationEventDecoratorLocation still isn't defined
> anywhere, so it still evaluates to the current file:
> communicationsscreens.xml. The communication screen and the
> CommonCommunicationEventDecorator will both appear - decorated with
> your
> custom app's main decorator.
>
> (Optional) If someone didn't like the
> CommonCommunicationEventDecorator,
> then they could design their own and specify its location in
> parameters.communicationEventDecoratorLocation.
>
> -Adrian
>
> BJ Freeman wrote:
>
>
>
>> Ok here is a real situation:
>> take the party/widgets/partymgr/commicationsscreens.xml
>> > location="${parameters.mainDecoratorLocation}">
>> which is the CommonSreens.xml
>> which has
>> > location="${parameters.mainDecoratorLocation}">
>>
>> the main-decorator has
>> > location="component://common/widget/CommonScreens.xml"/>
>>
>>
>> how would the be with your example
>>
>>
>>
>> Adrian Crum sent the following on 12/17/2007 9:33 AM:
>>
>>
>>
>>> BJ,
>>>
>>> Go ahead and create one. I will work on it when I have time.
>>>
>>> To be sure we're all on the same page, the problem exists when
>>> screens
>>> are nested as follows:
>>>
>>>
>>>
>>>
>>>
>>> ...
>>>
>>>
>>>
>>>
>>>
>>> and the location of the sub-decorator screen is defined as
>>> ${parameters.mainDecoratorLocation}. When a custom app tries to
>>> reuse
>>> the actual-content screen, errors are generated because
>>> >> location="${parameters.mainDecoratorLocation}"> evaluates to the
>>> custom
>>> app's main decorator xml file, and the sub-decorator screen doesn't
>>> exist there.
>>>
>>> The solution to the problem is to avoid using
>>> ${parameters.mainDecoratorLocation} as a location for
>>> sub-decorators and
>>> either have no location specified or use a different parameter
>>> for the
>>> sub-
Re: mainDecoratorLocation was Include of controllers
short answer is I can
but that still would not solve the problem.
take the party main-decorator
not these can not be the same ones if I am calling the product
main-decorator
Scott Gray sent the following on 12/17/2007 1:27 PM:
> Why couldn't you supply your own custom mainDecorator? What do the base
> mainDecorators provide that you can't in your custom app?
>
> Scott
>
> On 18/12/2007, BJ Freeman <[EMAIL PROTECTED]> wrote:
>> Based on this, I can never see how even if I called from a custom app
>> different screens in different apps how one main-decorator
>> so I am not sure how this feature would work at all.
>>
>> Hence my original suggestion that is apps main-decorator be declared as
>> application-mainDecoratorLocation
>> this way I could include each apps mainDecoratorLocation and not have to
>> worry
>>
>>
>> BJ Freeman sent the following on 12/17/2007 12:55 PM:
>>> I have a menu, no screens, that calls ListPartyCommEvents
>>> this goes to the party controller to resolve.
>>> the party controller uses it view for ListPartyCommEvents
>>> It can not read the party web.xml so will error even with your changes.
>>>
>>> so lets say i put in a mainDecoratorLocation in my web xml and define it
>>> like the one in the party commonscreens.xml
>>>
>>> so far so good.
>>>
>>> Now I call a screen in say Product. except the mainDecoratorLocation for
>>> it has a different main-decorator. so all the requirements are not
>>> defined in the party main-Decorator I have ported over.
>>>
>>> we still have a problem since all the apps main-decorators are not the
>> same.
>>> now if the main-decorators were all the same then I could use one
>>> location in any of the apps and everything would be ok
>>>
>>>
>>>
>>> Adrian Crum sent the following on 12/17/2007 12:40 PM:
1. Move the CommonCommunicationEventDecorator screen to the
communicationsscreens.xml file.
2. Change all
>>> location="${parameters.mainDecoratorLocation}">
to
>>> location="${parameters.communicationEventDecoratorLocation}">
Since parameters.communicationEventDecoratorLocation isn't defined
anywhere, the location will evaluate to the current file:
communicationsscreens.xml. All communication screens still work the
>> same
in Party Manager, but now you can reuse those screens in another app.
When you use one of the communication screens in your custom app (via
included controller.xml file or otherwise) the
parameters.communicationEventDecoratorLocation still isn't defined
anywhere, so it still evaluates to the current file:
communicationsscreens.xml. The communication screen and the
CommonCommunicationEventDecorator will both appear - decorated with
>> your
custom app's main decorator.
(Optional) If someone didn't like the
>> CommonCommunicationEventDecorator,
then they could design their own and specify its location in
parameters.communicationEventDecoratorLocation.
-Adrian
BJ Freeman wrote:
> Ok here is a real situation:
> take the party/widgets/partymgr/commicationsscreens.xml
> location="${parameters.mainDecoratorLocation}">
> which is the CommonSreens.xml
> which has
> location="${parameters.mainDecoratorLocation}">
>
> the main-decorator has
> location="component://common/widget/CommonScreens.xml"/>
>
>
> how would the be with your example
>
>
>
> Adrian Crum sent the following on 12/17/2007 9:33 AM:
>
>> BJ,
>>
>> Go ahead and create one. I will work on it when I have time.
>>
>> To be sure we're all on the same page, the problem exists when
>> screens
>> are nested as follows:
>>
>>
>>
>>
>>
>>...
>>
>>
>>
>>
>>
>> and the location of the sub-decorator screen is defined as
>> ${parameters.mainDecoratorLocation}. When a custom app tries to reuse
>> the actual-content screen, errors are generated because
>> > location="${parameters.mainDecoratorLocation}"> evaluates to the
>> custom
>> app's main decorator xml file, and the sub-decorator screen doesn't
>> exist there.
>>
>> The solution to the problem is to avoid using
>> ${parameters.mainDecoratorLocation} as a location for sub-decorators
>> and
>> either have no location specified or use a different parameter for
>> the
>> sub-decorator's location - like ${subDecoratorLocation}.
>>
>> A good example of this approach is in AgreementScreens.xml in the
>> Accounting component. All of the Agreement screens share a common
>> sub-decorator (CommonAgreementDecorator) - and that decorator's
>> location
>> is specified as ${parameters.agreementDecoratorLocation}. The
>> agreementDec
Re: adopting commented examples in config files
Anyway it's one in trunk and release4.0, following your suggestion. Jacques De : "BJ Freeman" <[EMAIL PROTECTED]> > don't see that message. > I am aware I don't get all the message from the ML. > considering the server my mail server is on, I am not sure why that is > the case > > Jacques Le Roux sent the following on 12/17/2007 12:16 PM: > > Yes, I already agreed, see my msg from 17/12/2007 at 01:30 in this thread > > :o) > > > > Doing it right now, and I will backport to release4.0 > > > > Jacques > > > > De : "BJ Freeman" <[EMAIL PROTECTED]> > >> The generalization is if we adopted the blank parm to check for, any > >> parm example will be lost. > >> so when this is done, the parm that was there should be commented then a > >> new parm that is blank be used. > >> > >> > >> Jacques Le Roux sent the following on 12/17/2007 10:52 AM: > >>> BJ, > >>> > >>> Don't worry about a Jira issue (except if you see some kind of > >>> generalisation). I will commit it directly soon... > >>> > >>> Thanks > >>> > >>> Jacques > >>> > >>> De : "BJ Freeman" <[EMAIL PROTECTED]> > I will create a general JIra for a config information > I don't have commit privileges. > > > [EMAIL PROTECTED] sent the following on 12/17/2007 7:16 AM: > > Yes, BJ Freeman you can commit by yourself or at least I will wait some > > ideas about that from others people. > > Is it something to commit also in the relase 4 ? > > > > Thanks > > Marco > > > >> I like the way the Apache httpd server has it config files commented. > >> it give you a example of what should go into the config. > >> I user the paypal config as an example. > >> > >> #payment.paypal.notify=http://[yourserver]/ecommerce/control/payPalNotify > >> payment.paypal.notify= > >> > >> so the configuration person does not have to hunt down documentation > >> when implementing these not so apparent configurations. > >> > >> > > > > > >>> > >>> > > > > > > >
Re: mainDecoratorLocation was Include of controllers
That line wouldn't exist if you made the change I suggested.
Make the code changes, THEN tell me what's wrong with it. Telling me what's already wrong with it is
pointless - I already know the existing code doesn't work.
BJ Freeman wrote:
I beg to differ with you.
where is
defined
where is
in the CommonPartyDecorator defined.
Adrian Crum sent the following on 12/17/2007 1:03 PM:
ListPartyCommEvents request maps to ListPartyCommEvents view, that maps
to
component://party/widget/partymgr/CommunicationScreens.xml#ListPartyCommEvents.
The ListPartyCommEvents screen in CommunicationScreens.xml doesn't
contain anything specific to the Party Manager's web.xml file. I don't
see what the problem is.
Maybe you should include an exact error message.
-Adrian
BJ Freeman wrote:
I have a menu, no screens, that calls ListPartyCommEvents
this goes to the party controller to resolve.
the party controller uses it view for ListPartyCommEvents
It can not read the party web.xml so will error even with your changes.
so lets say i put in a mainDecoratorLocation in my web xml and define it
like the one in the party commonscreens.xml
so far so good.
Now I call a screen in say Product. except the mainDecoratorLocation for
it has a different main-decorator. so all the requirements are not
defined in the party main-Decorator I have ported over.
we still have a problem since all the apps main-decorators are not the
same.
now if the main-decorators were all the same then I could use one
location in any of the apps and everything would be ok
Adrian Crum sent the following on 12/17/2007 12:40 PM:
1. Move the CommonCommunicationEventDecorator screen to the
communicationsscreens.xml file.
2. Change all
to
Since parameters.communicationEventDecoratorLocation isn't defined
anywhere, the location will evaluate to the current file:
communicationsscreens.xml. All communication screens still work the same
in Party Manager, but now you can reuse those screens in another app.
When you use one of the communication screens in your custom app (via
included controller.xml file or otherwise) the
parameters.communicationEventDecoratorLocation still isn't defined
anywhere, so it still evaluates to the current file:
communicationsscreens.xml. The communication screen and the
CommonCommunicationEventDecorator will both appear - decorated with your
custom app's main decorator.
(Optional) If someone didn't like the CommonCommunicationEventDecorator,
then they could design their own and specify its location in
parameters.communicationEventDecoratorLocation.
-Adrian
BJ Freeman wrote:
Ok here is a real situation:
take the party/widgets/partymgr/commicationsscreens.xml
which is the CommonSreens.xml
which has
the main-decorator has
how would the be with your example
Adrian Crum sent the following on 12/17/2007 9:33 AM:
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to reuse
the actual-content screen, errors are generated because
evaluates to the
custom
app's main decorator xml file, and the sub-decorator screen doesn't
exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for
sub-decorators and
either have no location specified or use a different parameter for the
sub-decorator's location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in the
Accounting component. All of the Agreement screens share a common
sub-decorator (CommonAgreementDecorator) - and that decorator's
location
is specified as ${parameters.agreementDecoratorLocation}. The
agreementDecoratorLocation parameter isn't defined anywhere, so the
location= expression evaluates to an empty String - which causes the
screen widget view handler to look for CommonAgreementDecorator in the
existing file.
A custom app that reuses one of the Agreement screens will only
need to
specify the mainDecoratorLocation parameter. Since no
agreementDecoratorLocation parameter is defined in the custom app, the
sub-decorator in AgreementScreens.xml is used (same as above). If a
custom app wanted to have a custom sub-decorator, then it can specify
that decorator's location in the agreementDecoratorLocation parameter.
-Adrian
BJ Freeman wrote:
I agree, it is not a controller or web.xml issue. However it is
when it
shows up.
I will change them as I come along also.
thanks, that is all I wanted to know.
do you want to create a jira so I can submit changes?
Adrian Crum sent the following on 12/17/2007 7:57 AM:
As I mentioned before, the problem is with the coding style on some
screens, not with the controller or web.xml files. I recently
changed
some of the
Re: mainDecoratorLocation was Include of controllers
I beg to differ with you.
where is
defined
where is
in the CommonPartyDecorator defined.
Adrian Crum sent the following on 12/17/2007 1:03 PM:
> ListPartyCommEvents request maps to ListPartyCommEvents view, that maps
> to
> component://party/widget/partymgr/CommunicationScreens.xml#ListPartyCommEvents.
>
>
> The ListPartyCommEvents screen in CommunicationScreens.xml doesn't
> contain anything specific to the Party Manager's web.xml file. I don't
> see what the problem is.
>
> Maybe you should include an exact error message.
>
> -Adrian
>
> BJ Freeman wrote:
>
>> I have a menu, no screens, that calls ListPartyCommEvents
>> this goes to the party controller to resolve.
>> the party controller uses it view for ListPartyCommEvents
>> It can not read the party web.xml so will error even with your changes.
>>
>> so lets say i put in a mainDecoratorLocation in my web xml and define it
>> like the one in the party commonscreens.xml
>>
>> so far so good.
>>
>> Now I call a screen in say Product. except the mainDecoratorLocation for
>> it has a different main-decorator. so all the requirements are not
>> defined in the party main-Decorator I have ported over.
>>
>> we still have a problem since all the apps main-decorators are not the
>> same.
>>
>> now if the main-decorators were all the same then I could use one
>> location in any of the apps and everything would be ok
>>
>>
>>
>> Adrian Crum sent the following on 12/17/2007 12:40 PM:
>>
>>> 1. Move the CommonCommunicationEventDecorator screen to the
>>> communicationsscreens.xml file.
>>> 2. Change all
>>> >> location="${parameters.mainDecoratorLocation}">
>>>
>>> to
>>>
>>> >> location="${parameters.communicationEventDecoratorLocation}">
>>>
>>> Since parameters.communicationEventDecoratorLocation isn't defined
>>> anywhere, the location will evaluate to the current file:
>>> communicationsscreens.xml. All communication screens still work the same
>>> in Party Manager, but now you can reuse those screens in another app.
>>>
>>> When you use one of the communication screens in your custom app (via
>>> included controller.xml file or otherwise) the
>>> parameters.communicationEventDecoratorLocation still isn't defined
>>> anywhere, so it still evaluates to the current file:
>>> communicationsscreens.xml. The communication screen and the
>>> CommonCommunicationEventDecorator will both appear - decorated with your
>>> custom app's main decorator.
>>>
>>> (Optional) If someone didn't like the CommonCommunicationEventDecorator,
>>> then they could design their own and specify its location in
>>> parameters.communicationEventDecoratorLocation.
>>>
>>> -Adrian
>>>
>>> BJ Freeman wrote:
>>>
>>>
Ok here is a real situation:
take the party/widgets/partymgr/commicationsscreens.xml
>>> location="${parameters.mainDecoratorLocation}">
which is the CommonSreens.xml
which has
>>> location="${parameters.mainDecoratorLocation}">
the main-decorator has
>>> location="component://common/widget/CommonScreens.xml"/>
how would the be with your example
Adrian Crum sent the following on 12/17/2007 9:33 AM:
> BJ,
>
> Go ahead and create one. I will work on it when I have time.
>
> To be sure we're all on the same page, the problem exists when screens
> are nested as follows:
>
>
>
>
>
> ...
>
>
>
>
>
> and the location of the sub-decorator screen is defined as
> ${parameters.mainDecoratorLocation}. When a custom app tries to reuse
> the actual-content screen, errors are generated because
> location="${parameters.mainDecoratorLocation}"> evaluates to the
> custom
> app's main decorator xml file, and the sub-decorator screen doesn't
> exist there.
>
> The solution to the problem is to avoid using
> ${parameters.mainDecoratorLocation} as a location for
> sub-decorators and
> either have no location specified or use a different parameter for the
> sub-decorator's location - like ${subDecoratorLocation}.
>
> A good example of this approach is in AgreementScreens.xml in the
> Accounting component. All of the Agreement screens share a common
> sub-decorator (CommonAgreementDecorator) - and that decorator's
> location
> is specified as ${parameters.agreementDecoratorLocation}. The
> agreementDecoratorLocation parameter isn't defined anywhere, so the
> location= expression evaluates to an empty String - which causes the
> screen widget view handler to look for CommonAgreementDecorator in the
> existing file.
>
> A custom app that reuses one of the Agreement screens will only
> need to
> specify the mainDecoratorLocation parameter. Since no
> agreementDecoratorLocation parameter is defined in the custom app, the
> sub-decorator in AgreementScre
Re: mainDecoratorLocation was Include of controllers
Why couldn't you supply your own custom mainDecorator? What do the base
mainDecorators provide that you can't in your custom app?
Scott
On 18/12/2007, BJ Freeman <[EMAIL PROTECTED]> wrote:
>
> Based on this, I can never see how even if I called from a custom app
> different screens in different apps how one main-decorator
> so I am not sure how this feature would work at all.
>
> Hence my original suggestion that is apps main-decorator be declared as
> application-mainDecoratorLocation
> this way I could include each apps mainDecoratorLocation and not have to
> worry
>
>
> BJ Freeman sent the following on 12/17/2007 12:55 PM:
> > I have a menu, no screens, that calls ListPartyCommEvents
> > this goes to the party controller to resolve.
> > the party controller uses it view for ListPartyCommEvents
> > It can not read the party web.xml so will error even with your changes.
> >
> > so lets say i put in a mainDecoratorLocation in my web xml and define it
> > like the one in the party commonscreens.xml
> >
> > so far so good.
> >
> > Now I call a screen in say Product. except the mainDecoratorLocation for
> > it has a different main-decorator. so all the requirements are not
> > defined in the party main-Decorator I have ported over.
> >
> > we still have a problem since all the apps main-decorators are not the
> same.
> >
> > now if the main-decorators were all the same then I could use one
> > location in any of the apps and everything would be ok
> >
> >
> >
> > Adrian Crum sent the following on 12/17/2007 12:40 PM:
> >> 1. Move the CommonCommunicationEventDecorator screen to the
> >> communicationsscreens.xml file.
> >> 2. Change all
> >> >> location="${parameters.mainDecoratorLocation}">
> >>
> >> to
> >>
> >> >> location="${parameters.communicationEventDecoratorLocation}">
> >>
> >> Since parameters.communicationEventDecoratorLocation isn't defined
> >> anywhere, the location will evaluate to the current file:
> >> communicationsscreens.xml. All communication screens still work the
> same
> >> in Party Manager, but now you can reuse those screens in another app.
> >>
> >> When you use one of the communication screens in your custom app (via
> >> included controller.xml file or otherwise) the
> >> parameters.communicationEventDecoratorLocation still isn't defined
> >> anywhere, so it still evaluates to the current file:
> >> communicationsscreens.xml. The communication screen and the
> >> CommonCommunicationEventDecorator will both appear - decorated with
> your
> >> custom app's main decorator.
> >>
> >> (Optional) If someone didn't like the
> CommonCommunicationEventDecorator,
> >> then they could design their own and specify its location in
> >> parameters.communicationEventDecoratorLocation.
> >>
> >> -Adrian
> >>
> >> BJ Freeman wrote:
> >>
> >>> Ok here is a real situation:
> >>> take the party/widgets/partymgr/commicationsscreens.xml
> >>> >>> location="${parameters.mainDecoratorLocation}">
> >>> which is the CommonSreens.xml
> >>> which has
> >>> >>> location="${parameters.mainDecoratorLocation}">
> >>>
> >>> the main-decorator has
> >>> >>> location="component://common/widget/CommonScreens.xml"/>
> >>>
> >>>
> >>> how would the be with your example
> >>>
> >>>
> >>>
> >>> Adrian Crum sent the following on 12/17/2007 9:33 AM:
> >>>
> BJ,
>
> Go ahead and create one. I will work on it when I have time.
>
> To be sure we're all on the same page, the problem exists when
> screens
> are nested as follows:
>
>
>
>
>
> ...
>
>
>
>
>
> and the location of the sub-decorator screen is defined as
> ${parameters.mainDecoratorLocation}. When a custom app tries to reuse
> the actual-content screen, errors are generated because
> location="${parameters.mainDecoratorLocation}"> evaluates to the
> custom
> app's main decorator xml file, and the sub-decorator screen doesn't
> exist there.
>
> The solution to the problem is to avoid using
> ${parameters.mainDecoratorLocation} as a location for sub-decorators
> and
> either have no location specified or use a different parameter for
> the
> sub-decorator's location - like ${subDecoratorLocation}.
>
> A good example of this approach is in AgreementScreens.xml in the
> Accounting component. All of the Agreement screens share a common
> sub-decorator (CommonAgreementDecorator) - and that decorator's
> location
> is specified as ${parameters.agreementDecoratorLocation}. The
> agreementDecoratorLocation parameter isn't defined anywhere, so the
> location= expression evaluates to an empty String - which causes the
> screen widget view handler to look for CommonAgreementDecorator in
> the
> existing file.
>
> A custom app that reuses one of the Agreement screens will only need
> to
> specify the mainDecoratorLocatio
Re: mainDecoratorLocation was Include of controllers
Based on this, I can never see how even if I called from a custom app
different screens in different apps how one main-decorator
so I am not sure how this feature would work at all.
Hence my original suggestion that is apps main-decorator be declared as
application-mainDecoratorLocation
this way I could include each apps mainDecoratorLocation and not have to
worry
BJ Freeman sent the following on 12/17/2007 12:55 PM:
> I have a menu, no screens, that calls ListPartyCommEvents
> this goes to the party controller to resolve.
> the party controller uses it view for ListPartyCommEvents
> It can not read the party web.xml so will error even with your changes.
>
> so lets say i put in a mainDecoratorLocation in my web xml and define it
> like the one in the party commonscreens.xml
>
> so far so good.
>
> Now I call a screen in say Product. except the mainDecoratorLocation for
> it has a different main-decorator. so all the requirements are not
> defined in the party main-Decorator I have ported over.
>
> we still have a problem since all the apps main-decorators are not the same.
>
> now if the main-decorators were all the same then I could use one
> location in any of the apps and everything would be ok
>
>
>
> Adrian Crum sent the following on 12/17/2007 12:40 PM:
>> 1. Move the CommonCommunicationEventDecorator screen to the
>> communicationsscreens.xml file.
>> 2. Change all
>> > location="${parameters.mainDecoratorLocation}">
>>
>> to
>>
>> > location="${parameters.communicationEventDecoratorLocation}">
>>
>> Since parameters.communicationEventDecoratorLocation isn't defined
>> anywhere, the location will evaluate to the current file:
>> communicationsscreens.xml. All communication screens still work the same
>> in Party Manager, but now you can reuse those screens in another app.
>>
>> When you use one of the communication screens in your custom app (via
>> included controller.xml file or otherwise) the
>> parameters.communicationEventDecoratorLocation still isn't defined
>> anywhere, so it still evaluates to the current file:
>> communicationsscreens.xml. The communication screen and the
>> CommonCommunicationEventDecorator will both appear - decorated with your
>> custom app's main decorator.
>>
>> (Optional) If someone didn't like the CommonCommunicationEventDecorator,
>> then they could design their own and specify its location in
>> parameters.communicationEventDecoratorLocation.
>>
>> -Adrian
>>
>> BJ Freeman wrote:
>>
>>> Ok here is a real situation:
>>> take the party/widgets/partymgr/commicationsscreens.xml
>>> >> location="${parameters.mainDecoratorLocation}">
>>> which is the CommonSreens.xml
>>> which has
>>> >> location="${parameters.mainDecoratorLocation}">
>>>
>>> the main-decorator has
>>> >> location="component://common/widget/CommonScreens.xml"/>
>>>
>>>
>>> how would the be with your example
>>>
>>>
>>>
>>> Adrian Crum sent the following on 12/17/2007 9:33 AM:
>>>
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to reuse
the actual-content screen, errors are generated because
>>> location="${parameters.mainDecoratorLocation}"> evaluates to the custom
app's main decorator xml file, and the sub-decorator screen doesn't
exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for sub-decorators and
either have no location specified or use a different parameter for the
sub-decorator's location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in the
Accounting component. All of the Agreement screens share a common
sub-decorator (CommonAgreementDecorator) - and that decorator's location
is specified as ${parameters.agreementDecoratorLocation}. The
agreementDecoratorLocation parameter isn't defined anywhere, so the
location= expression evaluates to an empty String - which causes the
screen widget view handler to look for CommonAgreementDecorator in the
existing file.
A custom app that reuses one of the Agreement screens will only need to
specify the mainDecoratorLocation parameter. Since no
agreementDecoratorLocation parameter is defined in the custom app, the
sub-decorator in AgreementScreens.xml is used (same as above). If a
custom app wanted to have a custom sub-decorator, then it can specify
that decorator's location in the agreementDecoratorLocation parameter.
-Adrian
BJ Freeman wrote:
> I agree, it is not a controller or web.xml issue. However it is when it
>
[jira] Assigned: (OFBIZ-1505) New screen to manage the default glAccountId for the PaymentMethodType entity.
[ https://issues.apache.org/jira/browse/OFBIZ-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya reassigned OFBIZ-1505: -- Assignee: Ashish Vijaywargiya > New screen to manage the default glAccountId for the PaymentMethodType entity. > -- > > Key: OFBIZ-1505 > URL: https://issues.apache.org/jira/browse/OFBIZ-1505 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: SVN trunk >Reporter: Jacopo Cappellato >Assignee: Ashish Vijaywargiya > Attachments: Jira_issue_1505.patch, Jira_issue_1505.patch, > Jira_issue_1505.patch > > > This is *not* an organization specific screen, and so it will be accessible > from the top menu of the accounting component. > In the new screen, it will only be possible to update the glAccountId field > of the existing records; adding/removing new records is not allowed, nor > updating the other fields of the PaymentMethodType entity. > Also, the name of the top menu should reflect the specialized scope of this > screen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-1505) New screen to manage the default glAccountId for the PaymentMethodType entity.
[ https://issues.apache.org/jira/browse/OFBIZ-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya closed OFBIZ-1505. -- Resolution: Fixed Thanks Brajesh Patel for your valuable patch. Your patch is in rev # 605007. -- Ashish Vijaywargiya > New screen to manage the default glAccountId for the PaymentMethodType entity. > -- > > Key: OFBIZ-1505 > URL: https://issues.apache.org/jira/browse/OFBIZ-1505 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: SVN trunk >Reporter: Jacopo Cappellato >Assignee: Ashish Vijaywargiya > Attachments: Jira_issue_1505.patch, Jira_issue_1505.patch, > Jira_issue_1505.patch > > > This is *not* an organization specific screen, and so it will be accessible > from the top menu of the accounting component. > In the new screen, it will only be possible to update the glAccountId field > of the existing records; adding/removing new records is not allowed, nor > updating the other fields of the PaymentMethodType entity. > Also, the name of the top menu should reflect the specialized scope of this > screen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Difference between GL account type and class
A complaint is a complaint, and doesn't usually get you very far in a collaborative environment. Complaining in any form basically says that someone else created a problem and that person should solve it... so whoever that is: get on it already! You're either helping to create the software or you're not. If you are, then any complaint you have is technically a complaint against a group that includes yourself, and hence doesn't make much sense... That may bring you around to wanting to make changes to this, which brings you to contribution guidelines and good ways of working with other people and an existing code base (whether it be open source or not...). The main one I'm thinking of is the Rule #2: read before you write, ie understand something before you desire to change it (which I guess is what you're getting at with your first question). There are other interesting and helpful points here: http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices I think that's what Jacopo is referring to. As for this question, I don't remember it ever being asked (perhaps it was another related question though, phrased differently or something?). Of course, there are hundreds of questions every week going through the mailing lists and NO paid support staff (just people in their "spare" time helping out), so such questions are sometimes either lost or not considered as a high a priority as other active issues and questions that could use attention... and there are ALWAYS more issues and questions than one has time to work through completely. == In any case, the difference between a GlAccount class and type is that they are independent, ie like two dimensions on a graph. Some combinations of them don't make sense and they are certainly meant to be used together. The best way to understand them, as with many such entities that are concerned with types of records that require different code behavior, is to look at the seed data for the entity(ies). In this case that file is AccountingTypeData.xml. If you have looked at that and it doesn't make sense then maybe the best next step is to write a more detailed question to say what makes sense and what seems to conflict, and then maybe someone can be more helpful, instead of just guessing about what you're trying to find. At a high level you can see the different top-level classes and types, ie the ones with no parentClassId or parentTypeId. That is more helpful for the class as the classes are used in the posting routines to determine how an account should be treated (ie whether it is a debit or credit account, mainly). One thing that might make understanding these more difficult is misunderstanding their intent, and that seems to be the case with your comment about deciding how to determine an account to post to. The types and classes are NOT meant for that, there are other entities for that depending on where the information is coming from. For example when posting an accounting transaction based on an invoice you would look up the GlAccounts to use based on the internal organization the invoice is related to, and the InvoiceItemType for each item, and for some items like those for selling a product you would also try to use the productId to look up the glAccountId to use. If you browse around these entities you'll see a bunch of defined relationships between them for this purpose. -David On Dec 17, 2007, at 10:17 AM, Jim Barrows wrote: I wasn't complaining about the lack of documentation, just the lack of an answer. And I solved that complaint by responding to you, that your assumption was my assumption. I also don't consider the comment "Very Frustrating" to be a complaint. It's a statement of fact. The rest was just an idea to be kicked around. However, after further looking in to the code that's not going to be very easy to do. We use both. I'm at work, so the details are fuzzy, but in some cases we use either class or type to determine which account a transaction should go into if no account is provided. A couple of other places where we use that extra information to do the same type of thing. I would change the documentation and comment the code if I could get a confirmation of the assumption. No documentation is better then bad documentation. On 12/17/07, Jacopo Cappellato <[EMAIL PROTECTED]> wrote: Jim, we are building the accounting component and you kindly offered to help: if you are unhappy with the documentation, dig into the code and write it. You know what? After about 5 years working in this project I'm getting bored of people's complaints... Jacopo Jim Barrows wrote: That's my assumption. I asked the exact same question some time ago, and got a nothing as a response. Very frustrating. I think there should only be 5 accountTypes - Revenue, Expense, Asset, Liability, Owners Eq
Re: svn commit: r604898 - /ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilDateTime.java
I was going to comment on this too. As Adrian has expressed a number
of times using millisecond calculations is not reliable and the
Calendar or similar objects should be used instead.
-David
On Dec 17, 2007, at 8:40 AM, Adrian Crum wrote:
Hans,
Did you read my last email on this subject? Your methods will not
work properly. Please use the
UtilDateTime.adjustTimestamp(Timestamp stamp, int adjType, int
adjQuantity, TimeZone timeZone, Locale locale)
method.
-Adrian
[EMAIL PROTECTED] wrote:
Author: hansbak
Date: Mon Dec 17 07:24:46 2007
New Revision: 604898
URL: http://svn.apache.org/viewvc?rev=604898&view=rev
Log:
another small day calculation class to be used in minilanguage
Modified:
ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/
UtilDateTime.java
Modified: ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/
UtilDateTime.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/UtilDateTime.java?rev=604898&r1=604897&r2=604898&view=diff
=
=
=
=
=
=
=
=
=
=
--- ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/
UtilDateTime.java (original)
+++ ofbiz/trunk/framework/base/src/base/org/ofbiz/base/util/
UtilDateTime.java Mon Dec 17 07:24:46 2007
@@ -83,6 +83,10 @@
return new Timestamp(start.getTime() + (24*60*60*1000*days));
}
+public static Timestamp addDaysToTimestamp(Timestamp start,
Double days) {
+return new Timestamp(start.getTime() + ((int)
(24*60*60*1000*days)));
+}
+
public static double getInterval(Timestamp from, Timestamp
thru) {
return thru != null ? thru.getTime() - from.getTime() +
(thru.getNanos() - from.getNanos()) / 100 : 0;
}
smime.p7s
Description: S/MIME cryptographic signature
[jira] Updated: (OFBIZ-1505) New screen to manage the default glAccountId for the PaymentMethodType entity.
[ https://issues.apache.org/jira/browse/OFBIZ-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pranay Pandey updated OFBIZ-1505: - Attachment: Jira_issue_1505.patch Here I am submitting the updated patch for this issue. -- Pranay > New screen to manage the default glAccountId for the PaymentMethodType entity. > -- > > Key: OFBIZ-1505 > URL: https://issues.apache.org/jira/browse/OFBIZ-1505 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: SVN trunk >Reporter: Jacopo Cappellato > Attachments: Jira_issue_1505.patch, Jira_issue_1505.patch, > Jira_issue_1505.patch > > > This is *not* an organization specific screen, and so it will be accessible > from the top menu of the accounting component. > In the new screen, it will only be possible to update the glAccountId field > of the existing records; adding/removing new records is not allowed, nor > updating the other fields of the PaymentMethodType entity. > Also, the name of the top menu should reflect the specialized scope of this > screen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: mainDecoratorLocation was Include of controllers
ListPartyCommEvents request maps to ListPartyCommEvents view, that maps to
component://party/widget/partymgr/CommunicationScreens.xml#ListPartyCommEvents.
The ListPartyCommEvents screen in CommunicationScreens.xml doesn't contain anything specific to the
Party Manager's web.xml file. I don't see what the problem is.
Maybe you should include an exact error message.
-Adrian
BJ Freeman wrote:
I have a menu, no screens, that calls ListPartyCommEvents
this goes to the party controller to resolve.
the party controller uses it view for ListPartyCommEvents
It can not read the party web.xml so will error even with your changes.
so lets say i put in a mainDecoratorLocation in my web xml and define it
like the one in the party commonscreens.xml
so far so good.
Now I call a screen in say Product. except the mainDecoratorLocation for
it has a different main-decorator. so all the requirements are not
defined in the party main-Decorator I have ported over.
we still have a problem since all the apps main-decorators are not the same.
now if the main-decorators were all the same then I could use one
location in any of the apps and everything would be ok
Adrian Crum sent the following on 12/17/2007 12:40 PM:
1. Move the CommonCommunicationEventDecorator screen to the
communicationsscreens.xml file.
2. Change all
to
Since parameters.communicationEventDecoratorLocation isn't defined
anywhere, the location will evaluate to the current file:
communicationsscreens.xml. All communication screens still work the same
in Party Manager, but now you can reuse those screens in another app.
When you use one of the communication screens in your custom app (via
included controller.xml file or otherwise) the
parameters.communicationEventDecoratorLocation still isn't defined
anywhere, so it still evaluates to the current file:
communicationsscreens.xml. The communication screen and the
CommonCommunicationEventDecorator will both appear - decorated with your
custom app's main decorator.
(Optional) If someone didn't like the CommonCommunicationEventDecorator,
then they could design their own and specify its location in
parameters.communicationEventDecoratorLocation.
-Adrian
BJ Freeman wrote:
Ok here is a real situation:
take the party/widgets/partymgr/commicationsscreens.xml
which is the CommonSreens.xml
which has
the main-decorator has
how would the be with your example
Adrian Crum sent the following on 12/17/2007 9:33 AM:
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to reuse
the actual-content screen, errors are generated because
evaluates to the custom
app's main decorator xml file, and the sub-decorator screen doesn't
exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for sub-decorators and
either have no location specified or use a different parameter for the
sub-decorator's location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in the
Accounting component. All of the Agreement screens share a common
sub-decorator (CommonAgreementDecorator) - and that decorator's location
is specified as ${parameters.agreementDecoratorLocation}. The
agreementDecoratorLocation parameter isn't defined anywhere, so the
location= expression evaluates to an empty String - which causes the
screen widget view handler to look for CommonAgreementDecorator in the
existing file.
A custom app that reuses one of the Agreement screens will only need to
specify the mainDecoratorLocation parameter. Since no
agreementDecoratorLocation parameter is defined in the custom app, the
sub-decorator in AgreementScreens.xml is used (same as above). If a
custom app wanted to have a custom sub-decorator, then it can specify
that decorator's location in the agreementDecoratorLocation parameter.
-Adrian
BJ Freeman wrote:
I agree, it is not a controller or web.xml issue. However it is when it
shows up.
I will change them as I come along also.
thanks, that is all I wanted to know.
do you want to create a jira so I can submit changes?
Adrian Crum sent the following on 12/17/2007 7:57 AM:
As I mentioned before, the problem is with the coding style on some
screens, not with the controller or web.xml files. I recently changed
some of the accounting screens to correct this error.
-Adrian
BJ Freeman wrote:
I am not really, trying to attach the context as a whole.
only trying to get the mainDecoratorLocation
which is stored as a context in web.xml.
The problem is if I put mainDecoratorLocation, in my web.xml
then all applications I call thru my controller, or the included
ones,
will use my mainDecoratorLocation full path.
Maybe the solution is to put
[jira] Updated: (OFBIZ-1504) New screen to manage the default glAccountId for the InvoiceItemType entity.
[ https://issues.apache.org/jira/browse/OFBIZ-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pranay Pandey updated OFBIZ-1504: - Comment: was deleted > New screen to manage the default glAccountId for the InvoiceItemType entity. > > > Key: OFBIZ-1504 > URL: https://issues.apache.org/jira/browse/OFBIZ-1504 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: SVN trunk >Reporter: Jacopo Cappellato > Attachments: jira-issue-1504, jira-issue-1504.patch > > > This is *not* an organization specific screen, and so it will be accessible > from the top menu of the accounting component. > In the new screen, it will only be possible to update the glAccountId field > of the existing records; adding/removing new records is not allowed, nor > updating the other fields of the InvoiceItemType entity. > Also, the name of the top menu should reflect the specialized scope of this > screen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1504) New screen to manage the default glAccountId for the InvoiceItemType entity.
[ https://issues.apache.org/jira/browse/OFBIZ-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pranay Pandey updated OFBIZ-1504: - Attachment: (was: Update_JIRA_1505.patch) > New screen to manage the default glAccountId for the InvoiceItemType entity. > > > Key: OFBIZ-1504 > URL: https://issues.apache.org/jira/browse/OFBIZ-1504 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: SVN trunk >Reporter: Jacopo Cappellato > Attachments: jira-issue-1504, jira-issue-1504.patch > > > This is *not* an organization specific screen, and so it will be accessible > from the top menu of the accounting component. > In the new screen, it will only be possible to update the glAccountId field > of the existing records; adding/removing new records is not allowed, nor > updating the other fields of the InvoiceItemType entity. > Also, the name of the top menu should reflect the specialized scope of this > screen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1504) New screen to manage the default glAccountId for the InvoiceItemType entity.
[ https://issues.apache.org/jira/browse/OFBIZ-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pranay Pandey updated OFBIZ-1504: - Attachment: Update_JIRA_1505.patch Here i am submitting the updated patch for this issue. -- Pranay > New screen to manage the default glAccountId for the InvoiceItemType entity. > > > Key: OFBIZ-1504 > URL: https://issues.apache.org/jira/browse/OFBIZ-1504 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: SVN trunk >Reporter: Jacopo Cappellato > Attachments: jira-issue-1504, jira-issue-1504.patch > > > This is *not* an organization specific screen, and so it will be accessible > from the top menu of the accounting component. > In the new screen, it will only be possible to update the glAccountId field > of the existing records; adding/removing new records is not allowed, nor > updating the other fields of the InvoiceItemType entity. > Also, the name of the top menu should reflect the specialized scope of this > screen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: _ATX_CREATE
Take a look at services_ledger.xml, line 264. It would be preferable to convert it to permission service. Jacques Le Roux wrote: Actually the file AcctgTransServices.xml is not containing services implementions but simple-methods. So I will simply replace ACCOUNTING by ACCTG where relevant (a sole occurence, the one I pointed) Jacques De : "Jacques Le Roux" <[EMAIL PROTECTED]> OK I do it Jacques De : "Adrian Crum" <[EMAIL PROTECTED]> Oops, I just found it. That one slipped in there somehow. That method should use the permission service. Adrian Crum wrote: I don't see any permission checking logic in AcctgTransServices.xml. I refactored it to use the permission service. Jacques Le Roux wrote: Seems that we are on the same page, I will change also AcctgTransServices.xml accordingly. As I can't see any problems with this I will do it right now... Jacques De : "Adrian Crum" <[EMAIL PROTECTED]> The accounting component services use the ACCTG_ATX_CREATE permission. Properties files should be updated accordingly. Jacques Le Roux wrote: Thanks Adrian But I'm afraid it's not the case. Because, 1) I updated this instance this morning and did an ant clean-all this afternoon and re-created a new Postgres DB this afternon 2) a) Have a look at AcctgTransServices.xml and SecurityEntityLabels.properties for ACCOUNTING_ATX_CREATE b) AccountingSecurityData.xml for ACCTG_ATX_CREATE You may even try to search for "ATX_CREATE" in all files ;o) It seems to me that ACCOUNTING_ATX_CREATE should be replaced by ACCTG_ATX_CREATE. I would like to know what the community prefer as I need this to commit changes from POS. BTW I wonder if we should kept POS SecurityGroupPermission in PosSecurityData.xml or we should not better put them in corresponding basic applications (we should find a common name for applications in applcations dir, I'm not sure if basic is the right word). Thanks Jacques Jacques, Do a clean and re-run install. You have mixed seed data. -Adrian Jacques Le Roux wrote: I wonder why there are 2 _ATX_CREATE permissions ACCOUNTING_ATX_CREATE Create general ledger accounting transaction and entries. and ACCTG_ATX_CREATE : Create general ledger accounting transaction and entries Is there a reason or is this a duplicate as I suppose ? Thanks Jacques
Re: mainDecoratorLocation was Include of controllers
I have a menu, no screens, that calls ListPartyCommEvents
this goes to the party controller to resolve.
the party controller uses it view for ListPartyCommEvents
It can not read the party web.xml so will error even with your changes.
so lets say i put in a mainDecoratorLocation in my web xml and define it
like the one in the party commonscreens.xml
so far so good.
Now I call a screen in say Product. except the mainDecoratorLocation for
it has a different main-decorator. so all the requirements are not
defined in the party main-Decorator I have ported over.
we still have a problem since all the apps main-decorators are not the same.
now if the main-decorators were all the same then I could use one
location in any of the apps and everything would be ok
Adrian Crum sent the following on 12/17/2007 12:40 PM:
> 1. Move the CommonCommunicationEventDecorator screen to the
> communicationsscreens.xml file.
> 2. Change all
> location="${parameters.mainDecoratorLocation}">
>
> to
>
> location="${parameters.communicationEventDecoratorLocation}">
>
> Since parameters.communicationEventDecoratorLocation isn't defined
> anywhere, the location will evaluate to the current file:
> communicationsscreens.xml. All communication screens still work the same
> in Party Manager, but now you can reuse those screens in another app.
>
> When you use one of the communication screens in your custom app (via
> included controller.xml file or otherwise) the
> parameters.communicationEventDecoratorLocation still isn't defined
> anywhere, so it still evaluates to the current file:
> communicationsscreens.xml. The communication screen and the
> CommonCommunicationEventDecorator will both appear - decorated with your
> custom app's main decorator.
>
> (Optional) If someone didn't like the CommonCommunicationEventDecorator,
> then they could design their own and specify its location in
> parameters.communicationEventDecoratorLocation.
>
> -Adrian
>
> BJ Freeman wrote:
>
>> Ok here is a real situation:
>> take the party/widgets/partymgr/commicationsscreens.xml
>> > location="${parameters.mainDecoratorLocation}">
>> which is the CommonSreens.xml
>> which has
>> > location="${parameters.mainDecoratorLocation}">
>>
>> the main-decorator has
>> > location="component://common/widget/CommonScreens.xml"/>
>>
>>
>> how would the be with your example
>>
>>
>>
>> Adrian Crum sent the following on 12/17/2007 9:33 AM:
>>
>>> BJ,
>>>
>>> Go ahead and create one. I will work on it when I have time.
>>>
>>> To be sure we're all on the same page, the problem exists when screens
>>> are nested as follows:
>>>
>>>
>>>
>>>
>>>
>>>...
>>>
>>>
>>>
>>>
>>>
>>> and the location of the sub-decorator screen is defined as
>>> ${parameters.mainDecoratorLocation}. When a custom app tries to reuse
>>> the actual-content screen, errors are generated because
>>> >> location="${parameters.mainDecoratorLocation}"> evaluates to the custom
>>> app's main decorator xml file, and the sub-decorator screen doesn't
>>> exist there.
>>>
>>> The solution to the problem is to avoid using
>>> ${parameters.mainDecoratorLocation} as a location for sub-decorators and
>>> either have no location specified or use a different parameter for the
>>> sub-decorator's location - like ${subDecoratorLocation}.
>>>
>>> A good example of this approach is in AgreementScreens.xml in the
>>> Accounting component. All of the Agreement screens share a common
>>> sub-decorator (CommonAgreementDecorator) - and that decorator's location
>>> is specified as ${parameters.agreementDecoratorLocation}. The
>>> agreementDecoratorLocation parameter isn't defined anywhere, so the
>>> location= expression evaluates to an empty String - which causes the
>>> screen widget view handler to look for CommonAgreementDecorator in the
>>> existing file.
>>>
>>> A custom app that reuses one of the Agreement screens will only need to
>>> specify the mainDecoratorLocation parameter. Since no
>>> agreementDecoratorLocation parameter is defined in the custom app, the
>>> sub-decorator in AgreementScreens.xml is used (same as above). If a
>>> custom app wanted to have a custom sub-decorator, then it can specify
>>> that decorator's location in the agreementDecoratorLocation parameter.
>>>
>>> -Adrian
>>>
>>> BJ Freeman wrote:
>>>
>>>
I agree, it is not a controller or web.xml issue. However it is when it
shows up.
I will change them as I come along also.
thanks, that is all I wanted to know.
do you want to create a jira so I can submit changes?
Adrian Crum sent the following on 12/17/2007 7:57 AM:
> As I mentioned before, the problem is with the coding style on some
> screens, not with the controller or web.xml files. I recently changed
> some of the accounting screens to correct this error.
>
> -Adrian
>
> BJ Freeman wrote:
>
>
>
>> I am not really, trying to attach the conte
Re: _ATX_CREATE
Actually the file AcctgTransServices.xml is not containing services implementions but simple-methods. So I will simply replace ACCOUNTING by ACCTG where relevant (a sole occurence, the one I pointed) Jacques De : "Jacques Le Roux" <[EMAIL PROTECTED]> > OK I do it > > Jacques > > De : "Adrian Crum" <[EMAIL PROTECTED]> > > Oops, I just found it. That one slipped in there somehow. That method > > should use the permission service. > > > > > > Adrian Crum wrote: > > > > > I don't see any permission checking logic in AcctgTransServices.xml. I > > > refactored it to use the permission service. > > > > > > > > > Jacques Le Roux wrote: > > > > > >> Seems that we are on the same page, I will change also > > >> AcctgTransServices.xml accordingly. As I can't see any problems with > > >> this I > > >> will do it right now... > > >> > > >> Jacques > > >> > > >> De : "Adrian Crum" <[EMAIL PROTECTED]> > > >> > > >>> The accounting component services use the ACCTG_ATX_CREATE > > >>> permission. Properties files should be > > >>> updated accordingly. > > >>> > > >>> > > >>> Jacques Le Roux wrote: > > >>> > > >>> > > Thanks Adrian > > > > But I'm afraid it's not the case. > > > > Because, > > 1) I updated this instance this morning and did an ant clean-all > > this afternoon and re-created a new Postgres DB this afternon > > 2) > > a) Have a look at AcctgTransServices.xml and > > SecurityEntityLabels.properties for ACCOUNTING_ATX_CREATE > > b) AccountingSecurityData.xml for ACCTG_ATX_CREATE > > > > You may even try to search for "ATX_CREATE" in all files ;o) > > > > It seems to me that ACCOUNTING_ATX_CREATE should be replaced by > > ACCTG_ATX_CREATE. I would like to know what the community prefer > > >> > > >> > > >> as > > >> > > I need this to commit changes from POS. > > > > BTW I wonder if we should kept POS SecurityGroupPermission in > > PosSecurityData.xml or we should not better put them in > > >> > > >> > > >> corresponding > > >> > > basic applications (we should find a common name for applications in > > applcations dir, I'm not sure if basic is the right word). > > > > Thanks > > > > Jacques > > > > > > > > > > > > > Jacques, > > > > > > Do a clean and re-run install. You have mixed seed data. > > > > > > -Adrian > > > > > > Jacques Le Roux wrote: > > > > > > > > > > > >> I wonder why there are 2 _ATX_CREATE permissions > > >> > > >> ACCOUNTING_ATX_CREATE Create general ledger accounting transaction > > >> and entries. > > >> and > > >> ACCTG_ATX_CREATE : Create general ledger accounting transaction > > >> and entries > > >> > > >> Is there a reason or is this a duplicate as I suppose ? > > >> > > >> Thanks > > >> > > >> Jacques > > > > > > > > > > >> > > >> > > > > > > > > >
[jira] Closed: (OFBIZ-1109) Ability to add items with modifiers
[ https://issues.apache.org/jira/browse/OFBIZ-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-1109. -- Resolution: Fixed Fix Version/s: SVN trunk > Ability to add items with modifiers > --- > > Key: OFBIZ-1109 > URL: https://issues.apache.org/jira/browse/OFBIZ-1109 > Project: OFBiz > Issue Type: New Feature > Components: pos >Affects Versions: SVN trunk >Reporter: Chris Lombardi >Assignee: Jacques Le Roux > Fix For: SVN trunk > > Attachments: 16Dec2007.patch, 21Nov2007.patch > > > I would like to add the ability to add and configure "aggregated" items via > the POS system. > A few scenarios should be supported. > 1. The item has a default configuration and can be added without > configuration. > 2. The item requires configuration and a screen to configure the item should > present upon adding the item. > 3. A configurable item should allow editing after both earlier scenarios. > I have a prototype mostly working, but I'd like to determine the following: > 1. Is anyone else interested in this functionality? > 2. What does everyone think is the best way to accomplish this? > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-1109) Ability to add items with modifiers
[ https://issues.apache.org/jira/browse/OFBIZ-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552526 ] Jacques Le Roux commented on OFBIZ-1109: Thanks Chris, Your patch is in trunk revision: 604993. Some advices, questions and remarks : Please don't add xpos.properties in your patches. As you may know this file is dynamically modified by the system to allow XUI localisation. About this subject I have added the following lines ### This file contains labels directly translated by XUI framework ### This file contains labels translated by the POS component (ie not by XUI framework) in respectively XuiUilabels*.properties files and pos*.properties file to make things more obvious. Should we keep PosTransaction.configureItem commented ? Please update or remove code comments, for instance the one I already noticed in a comment above I commented some remaining Debug.logInfo in ConfigureItem feel free to uncomment if you feel they are needed. Thanks for your great work, I love the color ! > Ability to add items with modifiers > --- > > Key: OFBIZ-1109 > URL: https://issues.apache.org/jira/browse/OFBIZ-1109 > Project: OFBiz > Issue Type: New Feature > Components: pos >Affects Versions: SVN trunk >Reporter: Chris Lombardi >Assignee: Jacques Le Roux > Fix For: SVN trunk > > Attachments: 16Dec2007.patch, 21Nov2007.patch > > > I would like to add the ability to add and configure "aggregated" items via > the POS system. > A few scenarios should be supported. > 1. The item has a default configuration and can be added without > configuration. > 2. The item requires configuration and a screen to configure the item should > present upon adding the item. > 3. A configurable item should allow editing after both earlier scenarios. > I have a prototype mostly working, but I'd like to determine the following: > 1. Is anyone else interested in this functionality? > 2. What does everyone think is the best way to accomplish this? > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: mainDecoratorLocation was Include of controllers
1. Move the CommonCommunicationEventDecorator screen to the
communicationsscreens.xml file.
2. Change all
location="${parameters.mainDecoratorLocation}">
to
location="${parameters.communicationEventDecoratorLocation}">
Since parameters.communicationEventDecoratorLocation isn't defined anywhere, the location will
evaluate to the current file: communicationsscreens.xml. All communication screens still work the
same in Party Manager, but now you can reuse those screens in another app.
When you use one of the communication screens in your custom app (via included controller.xml file
or otherwise) the parameters.communicationEventDecoratorLocation still isn't defined anywhere, so it
still evaluates to the current file: communicationsscreens.xml. The communication screen and the
CommonCommunicationEventDecorator will both appear - decorated with your custom app's main decorator.
(Optional) If someone didn't like the CommonCommunicationEventDecorator, then they could design
their own and specify its location in parameters.communicationEventDecoratorLocation.
-Adrian
BJ Freeman wrote:
Ok here is a real situation:
take the party/widgets/partymgr/commicationsscreens.xml
which is the CommonSreens.xml
which has
the main-decorator has
how would the be with your example
Adrian Crum sent the following on 12/17/2007 9:33 AM:
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to reuse
the actual-content screen, errors are generated because
evaluates to the custom
app's main decorator xml file, and the sub-decorator screen doesn't
exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for sub-decorators and
either have no location specified or use a different parameter for the
sub-decorator's location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in the
Accounting component. All of the Agreement screens share a common
sub-decorator (CommonAgreementDecorator) - and that decorator's location
is specified as ${parameters.agreementDecoratorLocation}. The
agreementDecoratorLocation parameter isn't defined anywhere, so the
location= expression evaluates to an empty String - which causes the
screen widget view handler to look for CommonAgreementDecorator in the
existing file.
A custom app that reuses one of the Agreement screens will only need to
specify the mainDecoratorLocation parameter. Since no
agreementDecoratorLocation parameter is defined in the custom app, the
sub-decorator in AgreementScreens.xml is used (same as above). If a
custom app wanted to have a custom sub-decorator, then it can specify
that decorator's location in the agreementDecoratorLocation parameter.
-Adrian
BJ Freeman wrote:
I agree, it is not a controller or web.xml issue. However it is when it
shows up.
I will change them as I come along also.
thanks, that is all I wanted to know.
do you want to create a jira so I can submit changes?
Adrian Crum sent the following on 12/17/2007 7:57 AM:
As I mentioned before, the problem is with the coding style on some
screens, not with the controller or web.xml files. I recently changed
some of the accounting screens to correct this error.
-Adrian
BJ Freeman wrote:
I am not really, trying to attach the context as a whole.
only trying to get the mainDecoratorLocation
which is stored as a context in web.xml.
The problem is if I put mainDecoratorLocation, in my web.xml
then all applications I call thru my controller, or the included ones,
will use my mainDecoratorLocation full path.
Maybe the solution is to put the main-decorator for all apps in the
framework/commons
then like in many of the application they have specific decorators that
include the main-decorator.
the problems is how to fill in the actions, etcetera
Chris Howe sent the following on 12/15/2007 10:40 AM:
All the does is grab some xml elements from the location
described. Theoretically, It doesn't even need to be from the same
server, much less the same app (may have interesting possibilities
BTW). This is why I'm having such a hard time understanding why you
are trying to attach context to it.
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Saturday, December 15, 2007 12:19:27 PM
Subject: Re: Include of controllers
I was going thru the trunk and noticed this in all the controllers
so there is a rule that says you can include a controller not in the
same app.
BJ Freeman sent the following on 11/10/2007 4:15 PM:
Almost.
when the included controller view calles a screen in the partymgr
screen
, and that screen calls for a parm that is web.xml. the parm is no
Re: svn commit: r604986 - /ofbiz/trunk/applications/accounting/config/payment.properties
actually suggested, since he put in the code to look for a blank parm #payment.paypal.notify=http://[yourServerName]/ecommerce/control/payPalNotify payment.paypal.notify= Note the # Which is the equivalent of a remark [EMAIL PROTECTED] sent the following on 12/17/2007 12:31 PM: > Author: jleroux > Date: Mon Dec 17 12:31:47 2007 > New Revision: 604986 > > URL: http://svn.apache.org/viewvc?rev=604986&view=rev > Log: > I guess it's better to put this one too (and 3 typos) > > Modified: > ofbiz/trunk/applications/accounting/config/payment.properties > > Modified: ofbiz/trunk/applications/accounting/config/payment.properties > URL: > http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/payment.properties?rev=604986&r1=604985&r2=604986&view=diff > == > --- ofbiz/trunk/applications/accounting/config/payment.properties (original) > +++ ofbiz/trunk/applications/accounting/config/payment.properties Mon Dec 17 > 12:31:47 2007 > @@ -242,16 +242,16 @@ > [EMAIL PROTECTED] > > # PayPal Notify URL > -payment.paypal.notify=http://[yourServerName)/ecommerce/control/payPalNotify > +payment.paypal.notify=http://[yourServerName]/ecommerce/control/payPalNotify > > # PayPal Return URL > -payment.paypal.return=http://[yourServerName)/ecommerce/control/orderhistory > +payment.paypal.return=http://[yourServerName]/ecommerce/control/orderhistory > > # PayPal Return On Cancel URL > -payment.paypal.cancelReturn=http://[yourServerName)/ecommerce/control/payPalCancel/main > +payment.paypal.cancelReturn=http://[yourServerName]/ecommerce/control/payPalCancel/main > > # Image To Use On PayPal > -payment.paypal.image=http://demo.hotwaxmedia.com/images/ofbiz_logo.jpg > +payment.paypal.image=http://[yourServerName]/images/ofbiz_logo.jpg > > # Thank-You / Confirm Order Template (rendered via Freemarker) > payment.paypal.confirmTemplate=/order/emailconfirmation.ftl > > > > >
Re: mainDecoratorLocation was Include of controllers
I will still get the error since the parameters.mainDecoratorLocation
for that is in the web.xml for party.
BJ Freeman sent the following on 12/17/2007 12:23 PM:
> Ok here is a real situation:
> take the party/widgets/partymgr/commicationsscreens.xml
> location="${parameters.mainDecoratorLocation}">
> which is the CommonSreens.xml
> which has
> location="${parameters.mainDecoratorLocation}">
>
> the main-decorator has
> location="component://common/widget/CommonScreens.xml"/>
>
>
> how would the be with your example
>
>
>
> Adrian Crum sent the following on 12/17/2007 9:33 AM:
>> BJ,
>>
>> Go ahead and create one. I will work on it when I have time.
>>
>> To be sure we're all on the same page, the problem exists when screens
>> are nested as follows:
>>
>>
>>
>>
>>
>> ...
>>
>>
>>
>>
>>
>> and the location of the sub-decorator screen is defined as
>> ${parameters.mainDecoratorLocation}. When a custom app tries to reuse
>> the actual-content screen, errors are generated because
>> > location="${parameters.mainDecoratorLocation}"> evaluates to the custom
>> app's main decorator xml file, and the sub-decorator screen doesn't
>> exist there.
>>
>> The solution to the problem is to avoid using
>> ${parameters.mainDecoratorLocation} as a location for sub-decorators and
>> either have no location specified or use a different parameter for the
>> sub-decorator's location - like ${subDecoratorLocation}.
>>
>> A good example of this approach is in AgreementScreens.xml in the
>> Accounting component. All of the Agreement screens share a common
>> sub-decorator (CommonAgreementDecorator) - and that decorator's location
>> is specified as ${parameters.agreementDecoratorLocation}. The
>> agreementDecoratorLocation parameter isn't defined anywhere, so the
>> location= expression evaluates to an empty String - which causes the
>> screen widget view handler to look for CommonAgreementDecorator in the
>> existing file.
>>
>> A custom app that reuses one of the Agreement screens will only need to
>> specify the mainDecoratorLocation parameter. Since no
>> agreementDecoratorLocation parameter is defined in the custom app, the
>> sub-decorator in AgreementScreens.xml is used (same as above). If a
>> custom app wanted to have a custom sub-decorator, then it can specify
>> that decorator's location in the agreementDecoratorLocation parameter.
>>
>> -Adrian
>>
>> BJ Freeman wrote:
>>
>>> I agree, it is not a controller or web.xml issue. However it is when it
>>> shows up.
>>> I will change them as I come along also.
>>> thanks, that is all I wanted to know.
>>> do you want to create a jira so I can submit changes?
>>>
>>> Adrian Crum sent the following on 12/17/2007 7:57 AM:
>>>
As I mentioned before, the problem is with the coding style on some
screens, not with the controller or web.xml files. I recently changed
some of the accounting screens to correct this error.
-Adrian
BJ Freeman wrote:
> I am not really, trying to attach the context as a whole.
> only trying to get the mainDecoratorLocation
> which is stored as a context in web.xml.
> The problem is if I put mainDecoratorLocation, in my web.xml
> then all applications I call thru my controller, or the included ones,
> will use my mainDecoratorLocation full path.
> Maybe the solution is to put the main-decorator for all apps in the
> framework/commons
> then like in many of the application they have specific decorators that
> include the main-decorator.
> the problems is how to fill in the actions, etcetera
>
> Chris Howe sent the following on 12/15/2007 10:40 AM:
>
>
>> All the does is grab some xml elements from the location
>> described. Theoretically, It doesn't even need to be from the same
>> server, much less the same app (may have interesting possibilities
>> BTW). This is why I'm having such a hard time understanding why you
>> are trying to attach context to it.
>>
>> - Original Message
>> From: BJ Freeman <[EMAIL PROTECTED]>
>> To: dev@ofbiz.apache.org
>> Sent: Saturday, December 15, 2007 12:19:27 PM
>> Subject: Re: Include of controllers
>>
>>
>> I was going thru the trunk and noticed this in all the controllers
>> > location="component://common/webcommon/WEB-INF/common-controller.xml"/>
>>
>>
>> so there is a rule that says you can include a controller not in the
>> same app.
>>
>>
>> BJ Freeman sent the following on 11/10/2007 4:15 PM:
>>
>>
>>> Almost.
>>> when the included controller view calles a screen in the partymgr
>> screen
>>
>>
>>> , and that screen calls for a parm that is web.xml. the parm is not
>>> availible for the screen and so fails.
>>>
>>> At this time, the way I handle this is to put the parm in my Web.xml.
>>>
>>> M
Re: adopting commented examples in config files
don't see that message. I am aware I don't get all the message from the ML. considering the server my mail server is on, I am not sure why that is the case Jacques Le Roux sent the following on 12/17/2007 12:16 PM: > Yes, I already agreed, see my msg from 17/12/2007 at 01:30 in this thread :o) > > Doing it right now, and I will backport to release4.0 > > Jacques > > De : "BJ Freeman" <[EMAIL PROTECTED]> >> The generalization is if we adopted the blank parm to check for, any >> parm example will be lost. >> so when this is done, the parm that was there should be commented then a >> new parm that is blank be used. >> >> >> Jacques Le Roux sent the following on 12/17/2007 10:52 AM: >>> BJ, >>> >>> Don't worry about a Jira issue (except if you see some kind of >>> generalisation). I will commit it directly soon... >>> >>> Thanks >>> >>> Jacques >>> >>> De : "BJ Freeman" <[EMAIL PROTECTED]> I will create a general JIra for a config information I don't have commit privileges. [EMAIL PROTECTED] sent the following on 12/17/2007 7:16 AM: > Yes, BJ Freeman you can commit by yourself or at least I will wait some > ideas about that from others people. > Is it something to commit also in the relase 4 ? > > Thanks > Marco > >> I like the way the Apache httpd server has it config files commented. >> it give you a example of what should go into the config. >> I user the paypal config as an example. >> >> #payment.paypal.notify=http://[yourserver]/ecommerce/control/payPalNotify >> payment.paypal.notify= >> >> so the configuration person does not have to hunt down documentation >> when implementing these not so apparent configurations. >> >> > > >>> >>> > > >
Re:mainDecoratorLocation was Include of controllers
Ok here is a real situation:
take the party/widgets/partymgr/commicationsscreens.xml
which is the CommonSreens.xml
which has
the main-decorator has
how would the be with your example
Adrian Crum sent the following on 12/17/2007 9:33 AM:
> BJ,
>
> Go ahead and create one. I will work on it when I have time.
>
> To be sure we're all on the same page, the problem exists when screens
> are nested as follows:
>
>
>
>
>
> ...
>
>
>
>
>
> and the location of the sub-decorator screen is defined as
> ${parameters.mainDecoratorLocation}. When a custom app tries to reuse
> the actual-content screen, errors are generated because
> location="${parameters.mainDecoratorLocation}"> evaluates to the custom
> app's main decorator xml file, and the sub-decorator screen doesn't
> exist there.
>
> The solution to the problem is to avoid using
> ${parameters.mainDecoratorLocation} as a location for sub-decorators and
> either have no location specified or use a different parameter for the
> sub-decorator's location - like ${subDecoratorLocation}.
>
> A good example of this approach is in AgreementScreens.xml in the
> Accounting component. All of the Agreement screens share a common
> sub-decorator (CommonAgreementDecorator) - and that decorator's location
> is specified as ${parameters.agreementDecoratorLocation}. The
> agreementDecoratorLocation parameter isn't defined anywhere, so the
> location= expression evaluates to an empty String - which causes the
> screen widget view handler to look for CommonAgreementDecorator in the
> existing file.
>
> A custom app that reuses one of the Agreement screens will only need to
> specify the mainDecoratorLocation parameter. Since no
> agreementDecoratorLocation parameter is defined in the custom app, the
> sub-decorator in AgreementScreens.xml is used (same as above). If a
> custom app wanted to have a custom sub-decorator, then it can specify
> that decorator's location in the agreementDecoratorLocation parameter.
>
> -Adrian
>
> BJ Freeman wrote:
>
>> I agree, it is not a controller or web.xml issue. However it is when it
>> shows up.
>> I will change them as I come along also.
>> thanks, that is all I wanted to know.
>> do you want to create a jira so I can submit changes?
>>
>> Adrian Crum sent the following on 12/17/2007 7:57 AM:
>>
>>> As I mentioned before, the problem is with the coding style on some
>>> screens, not with the controller or web.xml files. I recently changed
>>> some of the accounting screens to correct this error.
>>>
>>> -Adrian
>>>
>>> BJ Freeman wrote:
>>>
>>>
I am not really, trying to attach the context as a whole.
only trying to get the mainDecoratorLocation
which is stored as a context in web.xml.
The problem is if I put mainDecoratorLocation, in my web.xml
then all applications I call thru my controller, or the included ones,
will use my mainDecoratorLocation full path.
Maybe the solution is to put the main-decorator for all apps in the
framework/commons
then like in many of the application they have specific decorators that
include the main-decorator.
the problems is how to fill in the actions, etcetera
Chris Howe sent the following on 12/15/2007 10:40 AM:
> All the does is grab some xml elements from the location
> described. Theoretically, It doesn't even need to be from the same
> server, much less the same app (may have interesting possibilities
> BTW). This is why I'm having such a hard time understanding why you
> are trying to attach context to it.
>
> - Original Message
> From: BJ Freeman <[EMAIL PROTECTED]>
> To: dev@ofbiz.apache.org
> Sent: Saturday, December 15, 2007 12:19:27 PM
> Subject: Re: Include of controllers
>
>
> I was going thru the trunk and noticed this in all the controllers
> location="component://common/webcommon/WEB-INF/common-controller.xml"/>
>
>
> so there is a rule that says you can include a controller not in the
> same app.
>
>
> BJ Freeman sent the following on 11/10/2007 4:15 PM:
>
>
>> Almost.
>> when the included controller view calles a screen in the partymgr
>
> screen
>
>
>> , and that screen calls for a parm that is web.xml. the parm is not
>> availible for the screen and so fails.
>>
>> At this time, the way I handle this is to put the parm in my Web.xml.
>>
>> My suggestions was that if a call is made to a parm that would be in
>
> the
>
>
>> applications, in this case partymgr, web.xml, that widget looks up
>
> the
>
>
>> web.xml for that application to get it.
>>
>>
>> Chris Howe sent the following on 11/10/2007 2:23 PM:
>>
>>
>>> Okay, I've read through the thread. In that case, I might suggest
>
> to take a step back and look at
[jira] Commented: (OFBIZ-1249) To permit to to calculate on a DATE object in minilang
[ https://issues.apache.org/jira/browse/OFBIZ-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552518 ] Adrian Crum commented on OFBIZ-1249: I'm thinking we could add one more attribute to this: align-start="day | week | month | year" to align the new date/time to the specified period. > To permit to to calculate on a DATE object in minilang > -- > > Key: OFBIZ-1249 > URL: https://issues.apache.org/jira/browse/OFBIZ-1249 > Project: OFBiz > Issue Type: New Feature > Components: framework >Affects Versions: SVN trunk > Environment: all >Reporter: Fabien Carrion >Assignee: Jacques Le Roux >Priority: Minor > Fix For: SVN trunk > > Attachments: calculate_date_diff.patch > > > This patch lets use the calculate function in the minilang service function > with java.util.Date and java.sql.Date object. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: adopting commented examples in config files
Yes, I already agreed, see my msg from 17/12/2007 at 01:30 in this thread :o) Doing it right now, and I will backport to release4.0 Jacques De : "BJ Freeman" <[EMAIL PROTECTED]> > The generalization is if we adopted the blank parm to check for, any > parm example will be lost. > so when this is done, the parm that was there should be commented then a > new parm that is blank be used. > > > Jacques Le Roux sent the following on 12/17/2007 10:52 AM: > > BJ, > > > > Don't worry about a Jira issue (except if you see some kind of > > generalisation). I will commit it directly soon... > > > > Thanks > > > > Jacques > > > > De : "BJ Freeman" <[EMAIL PROTECTED]> > >> I will create a general JIra for a config information > >> I don't have commit privileges. > >> > >> > >> [EMAIL PROTECTED] sent the following on 12/17/2007 7:16 AM: > >>> Yes, BJ Freeman you can commit by yourself or at least I will wait some > >>> ideas about that from others people. > >>> Is it something to commit also in the relase 4 ? > >>> > >>> Thanks > >>> Marco > >>> > I like the way the Apache httpd server has it config files commented. > it give you a example of what should go into the config. > I user the paypal config as an example. > > #payment.paypal.notify=http://[yourserver]/ecommerce/control/payPalNotify > payment.paypal.notify= > > so the configuration person does not have to hunt down documentation > when implementing these not so apparent configurations. > > > >>> > >>> > >>> > > > > > > >
Re: _ATX_CREATE
OK I do it Jacques De : "Adrian Crum" <[EMAIL PROTECTED]> > Oops, I just found it. That one slipped in there somehow. That method should > use the permission service. > > > Adrian Crum wrote: > > > I don't see any permission checking logic in AcctgTransServices.xml. I > > refactored it to use the permission service. > > > > > > Jacques Le Roux wrote: > > > >> Seems that we are on the same page, I will change also > >> AcctgTransServices.xml accordingly. As I can't see any problems with > >> this I > >> will do it right now... > >> > >> Jacques > >> > >> De : "Adrian Crum" <[EMAIL PROTECTED]> > >> > >>> The accounting component services use the ACCTG_ATX_CREATE > >>> permission. Properties files should be > >>> updated accordingly. > >>> > >>> > >>> Jacques Le Roux wrote: > >>> > >>> > Thanks Adrian > > But I'm afraid it's not the case. > > Because, > 1) I updated this instance this morning and did an ant clean-all > this afternoon and re-created a new Postgres DB this afternon > 2) > a) Have a look at AcctgTransServices.xml and > SecurityEntityLabels.properties for ACCOUNTING_ATX_CREATE > b) AccountingSecurityData.xml for ACCTG_ATX_CREATE > > You may even try to search for "ATX_CREATE" in all files ;o) > > It seems to me that ACCOUNTING_ATX_CREATE should be replaced by > ACCTG_ATX_CREATE. I would like to know what the community prefer > >> > >> > >> as > >> > I need this to commit changes from POS. > > BTW I wonder if we should kept POS SecurityGroupPermission in > PosSecurityData.xml or we should not better put them in > >> > >> > >> corresponding > >> > basic applications (we should find a common name for applications in > applcations dir, I'm not sure if basic is the right word). > > Thanks > > Jacques > > > > > > > Jacques, > > > > Do a clean and re-run install. You have mixed seed data. > > > > -Adrian > > > > Jacques Le Roux wrote: > > > > > > > >> I wonder why there are 2 _ATX_CREATE permissions > >> > >> ACCOUNTING_ATX_CREATE Create general ledger accounting transaction > >> and entries. > >> and > >> ACCTG_ATX_CREATE : Create general ledger accounting transaction > >> and entries > >> > >> Is there a reason or is this a duplicate as I suppose ? > >> > >> Thanks > >> > >> Jacques > > > > > > >> > >> > > > > >
Re: _ATX_CREATE
Oops, I just found it. That one slipped in there somehow. That method should use the permission service. Adrian Crum wrote: I don't see any permission checking logic in AcctgTransServices.xml. I refactored it to use the permission service. Jacques Le Roux wrote: Seems that we are on the same page, I will change also AcctgTransServices.xml accordingly. As I can't see any problems with this I will do it right now... Jacques De : "Adrian Crum" <[EMAIL PROTECTED]> The accounting component services use the ACCTG_ATX_CREATE permission. Properties files should be updated accordingly. Jacques Le Roux wrote: Thanks Adrian But I'm afraid it's not the case. Because, 1) I updated this instance this morning and did an ant clean-all this afternoon and re-created a new Postgres DB this afternon 2) a) Have a look at AcctgTransServices.xml and SecurityEntityLabels.properties for ACCOUNTING_ATX_CREATE b) AccountingSecurityData.xml for ACCTG_ATX_CREATE You may even try to search for "ATX_CREATE" in all files ;o) It seems to me that ACCOUNTING_ATX_CREATE should be replaced by ACCTG_ATX_CREATE. I would like to know what the community prefer as I need this to commit changes from POS. BTW I wonder if we should kept POS SecurityGroupPermission in PosSecurityData.xml or we should not better put them in corresponding basic applications (we should find a common name for applications in applcations dir, I'm not sure if basic is the right word). Thanks Jacques Jacques, Do a clean and re-run install. You have mixed seed data. -Adrian Jacques Le Roux wrote: I wonder why there are 2 _ATX_CREATE permissions ACCOUNTING_ATX_CREATE Create general ledger accounting transaction and entries. and ACCTG_ATX_CREATE : Create general ledger accounting transaction and entries Is there a reason or is this a duplicate as I suppose ? Thanks Jacques
[jira] Updated: (OFBIZ-1531) implement a fix to solve the location="${parameters.mainDecoratorLocation} giving an error.
[
https://issues.apache.org/jira/browse/OFBIZ-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BJ Freeman updated OFBIZ-1531:
--
Fix Version/s: Release Branch 4.0
Issue Type: Bug (was: Improvement)
Affects Version/s: Release Branch 4.0
Summary: implement a fix to solve the
location="${parameters.mainDecoratorLocation} giving an error. (was: replace
location="${parameters.mainDecoratorLocation} with the actual location found in
the web.xml)
To be sure we're all on the same page, the problem exists when screens are
nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to reuse the
actual-content screen, errors are generated because evaluates
to the custom app's main decorator xml file, and the sub-decorator screen
doesn't exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for sub-decorators and either
have no location specified or use a different parameter for the sub-decorator's
location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in the Accounting
component. All of the Agreement screens share a common sub-decorator
(CommonAgreementDecorator) - and that decorator's location is specified as
${parameters.agreementDecoratorLocation}. The agreementDecoratorLocation
parameter isn't defined anywhere, so the location= expression evaluates to an
empty String - which causes the screen widget view handler to look for
CommonAgreementDecorator in the existing file.
A custom app that reuses one of the Agreement screens will only need to specify
the mainDecoratorLocation parameter. Since no agreementDecoratorLocation
parameter is defined in the custom app, the sub-decorator in
AgreementScreens.xml is used (same as above). If a custom app wanted to have a
custom sub-decorator, then it can specify that decorator's location in the
agreementDecoratorLocation parameter.
-Adrian
> implement a fix to solve the location="${parameters.mainDecoratorLocation}
> giving an error.
> ---
>
> Key: OFBIZ-1531
> URL: https://issues.apache.org/jira/browse/OFBIZ-1531
> Project: OFBiz
> Issue Type: Bug
>Affects Versions: SVN trunk, Release Branch 4.0
>Reporter: BJ Freeman
>Priority: Minor
> Fix For: SVN trunk, Release Branch 4.0
>
>
> Though not meant to be used for intra-apps
> the Include feature is being used that way in the controller for
> common-controller.
> there is a gotcha describe in the dev ML about
> .mainDecoratorLocation not being accessed when since it is in the context in
> the web.xml
> To remedy this
> all
> location="${parameters.mainDecoratorLocation}
> will be changed to the actual path found in the web.xml for each application.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: _ATX_CREATE
I don't see any permission checking logic in AcctgTransServices.xml. I refactored it to use the permission service. Jacques Le Roux wrote: Seems that we are on the same page, I will change also AcctgTransServices.xml accordingly. As I can't see any problems with this I will do it right now... Jacques De : "Adrian Crum" <[EMAIL PROTECTED]> The accounting component services use the ACCTG_ATX_CREATE permission. Properties files should be updated accordingly. Jacques Le Roux wrote: Thanks Adrian But I'm afraid it's not the case. Because, 1) I updated this instance this morning and did an ant clean-all this afternoon and re-created a new Postgres DB this afternon 2) a) Have a look at AcctgTransServices.xml and SecurityEntityLabels.properties for ACCOUNTING_ATX_CREATE b) AccountingSecurityData.xml for ACCTG_ATX_CREATE You may even try to search for "ATX_CREATE" in all files ;o) It seems to me that ACCOUNTING_ATX_CREATE should be replaced by ACCTG_ATX_CREATE. I would like to know what the community prefer as I need this to commit changes from POS. BTW I wonder if we should kept POS SecurityGroupPermission in PosSecurityData.xml or we should not better put them in corresponding basic applications (we should find a common name for applications in applcations dir, I'm not sure if basic is the right word). Thanks Jacques Jacques, Do a clean and re-run install. You have mixed seed data. -Adrian Jacques Le Roux wrote: I wonder why there are 2 _ATX_CREATE permissions ACCOUNTING_ATX_CREATE Create general ledger accounting transaction and entries. and ACCTG_ATX_CREATE : Create general ledger accounting transaction and entries Is there a reason or is this a duplicate as I suppose ? Thanks Jacques
Re: adopting commented examples in config files
The generalization is if we adopted the blank parm to check for, any parm example will be lost. so when this is done, the parm that was there should be commented then a new parm that is blank be used. Jacques Le Roux sent the following on 12/17/2007 10:52 AM: > BJ, > > Don't worry about a Jira issue (except if you see some kind of > generalisation). I will commit it directly soon... > > Thanks > > Jacques > > De : "BJ Freeman" <[EMAIL PROTECTED]> >> I will create a general JIra for a config information >> I don't have commit privileges. >> >> >> [EMAIL PROTECTED] sent the following on 12/17/2007 7:16 AM: >>> Yes, BJ Freeman you can commit by yourself or at least I will wait some >>> ideas about that from others people. >>> Is it something to commit also in the relase 4 ? >>> >>> Thanks >>> Marco >>> I like the way the Apache httpd server has it config files commented. it give you a example of what should go into the config. I user the paypal config as an example. #payment.paypal.notify=http://[yourserver]/ecommerce/control/payPalNotify payment.paypal.notify= so the configuration person does not have to hunt down documentation when implementing these not so apparent configurations. >>> >>> >>> > > >
Re: java.lang.ClassCastException: org.ofbiz.geronimo.GeronimoTransactionFactory
Please use user ML for such question : it's explained here
http://docs.ofbiz.org/display/OFBADMIN/Mailing+Lists#MailingLists-DeveloperList:dev@ofbiz.apache.org
Jacques
De : "qiyadeng" <[EMAIL PROTECTED]>
>
> I create a new component in the hot-deploy.
> first, i just add a index.jsp in the component's webapp,everything is ok.
>
> I want to test the GenericDelegator ,so I create a servlet for test.
>
> this is servlet code:
>
> /*
> * To change this template, choose Tools | Templates
> * and open the template in the editor.
> */
>
> package qiya.deng.servlet;
>
> import java.io.*;
> import java.net.*;
>
> import java.util.HashMap;
> import java.util.Iterator;
> import java.util.List;
> import java.util.Map;
> import java.util.Map.Entry;
> import java.util.Set;
> import java.util.Vector;
> import javax.servlet.*;
> import javax.servlet.http.*;
> import org.ofbiz.entity.GenericDelegator;
> import org.ofbiz.entity.GenericEntity;
>
> /**
> *
> * @author qiya
> */
> public class ViewMethod extends HttpServlet {
>
> /**
> * Processes requests for both HTTP GET and
> POST methods.
> * @param request servlet request
> * @param response servlet response
> */
> protected void processRequest(HttpServletRequest request,
> HttpServletResponse response)
> throws ServletException, IOException {
> response.setContentType("text/html;charset=UTF-8");
> PrintWriter out = response.getWriter();
>
>
> out.println("");
> out.println("");
> out.println("Servlet ViewMethod");
> out.println("");
> out.println("");
> out.println("Servlet ViewMethod at " +
> request.getContextPath () + "");
> out.println("");
> out.println("");
>
>
> try {
>
> GenericDelegator delegator;
> StringBuilder xmlString = new StringBuilder();
> List productStoresList = new Vector();
> try {
> delegator = GenericDelegator.getGenericDelegator("default");
> productStoresList = delegator.findAll("ProductStore");
>
> Iterator itera = productStoresList.iterator();
> Map newmap;
> xmlString.append("");
> while (itera.hasNext()) {
> xmlString.append("");
> GenericEntity elem = (GenericEntity) itera.next();
> newmap = new HashMap();
> newmap = elem.getAllFields();
>
> Set returnMap = newmap.entrySet();
> for (Iterator i1 = returnMap.iterator(); i1.hasNext();) {
>
> Entry en = (Entry) i1.next();
> xmlString.append("<" + en.getKey().toString() + ">");
> xmlString.append(en.getValue());
> xmlString.append("");
> }
> xmlString.append("");
> }
> xmlString.append("");
> } catch (Exception exe) {
> exe.printStackTrace();
> }
> System.out.println(xmlString.toString());
> out.println(xmlString.toString());
>
>
> } finally {
> out.close();
> }
> }
>
> //
> /**
> * Handles the HTTP GET method.
> * @param request servlet request
> * @param response servlet response
> */
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response)
> throws ServletException, IOException {
> processRequest(request, response);
> }
>
> /**
> * Handles the HTTP POST method.
> * @param request servlet request
> * @param response servlet response
> */
> protected void doPost(HttpServletRequest request, HttpServletResponse
> response)
> throws ServletException, IOException {
> processRequest(request, response);
> }
>
> /**
> * Returns a short description of the servlet.
> */
> public String getServletInfo() {
> return "Short description";
> }
> //
> }
>
>
>
> when i calling the servlet ,there is something wrong information in the
> console.
>
>
> java.lang.ClassCastException: org.ofbiz.geronimo.GeronimoTransactionFactory
> at
> org.ofbiz.entity.transaction.TransactionFactory.getTransactionFactory
> (TransactionFactory.java:67)
> at
> org.ofbiz.entity.transaction.TransactionFactory.getUserTransaction(Tr
> ansactionFactory.java:90)
> at
> org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.ja
> va:67)
> at
> org.ofbiz.entity.transaction.TransactionUtil.begin(TransactionUtil.ja
> va:58)
> at
> org.ofbiz.entity.GenericDelegator.findCountByCondition(GenericDelegat
> or.java:1854)
> at
> org.ofbiz.entity.GenericDelegator.findCountByCondition(GenericDelegat
> or.java:1845)
> at
> org.ofbiz.entity.GenericDelegator.findCountByAnd(GenericDelegator.jav
> a:1840)
> at org.ofbiz.entity.util.EntityCrypto.(EntityCrypto.java:62
Re: _ATX_CREATE
Seems that we are on the same page, I will change also AcctgTransServices.xml accordingly. As I can't see any problems with this I will do it right now... Jacques De : "Adrian Crum" <[EMAIL PROTECTED]> > The accounting component services use the ACCTG_ATX_CREATE permission. > Properties files should be > updated accordingly. > > > Jacques Le Roux wrote: > > > Thanks Adrian > > > > But I'm afraid it's not the case. > > > > Because, > > 1) I updated this instance this morning and did an ant clean-all this > > afternoon and re-created a new Postgres DB this afternon > > 2) > > a) Have a look at AcctgTransServices.xml and > > SecurityEntityLabels.properties for ACCOUNTING_ATX_CREATE > > b) AccountingSecurityData.xml for ACCTG_ATX_CREATE > > > > You may even try to search for "ATX_CREATE" in all files ;o) > > > > It seems to me that ACCOUNTING_ATX_CREATE should be replaced by > > ACCTG_ATX_CREATE. I would like to know what the community prefer as > > I need this to commit changes from POS. > > > > BTW I wonder if we should kept POS SecurityGroupPermission in > > PosSecurityData.xml or we should not better put them in corresponding > > basic applications (we should find a common name for applications in > > applcations dir, I'm not sure if basic is the right word). > > > > Thanks > > > > Jacques > > > > > > > > > >>Jacques, > >> > >>Do a clean and re-run install. You have mixed seed data. > >> > >>-Adrian > >> > >>Jacques Le Roux wrote: > >> > >> > >>>I wonder why there are 2 _ATX_CREATE permissions > >>> > >>>ACCOUNTING_ATX_CREATE Create general ledger accounting transaction and > >>>entries. > >>>and > >>>ACCTG_ATX_CREATE : Create general ledger accounting transaction and entries > >>> > >>>Is there a reason or is this a duplicate as I suppose ? > >>> > >>>Thanks > >>> > >>>Jacques > >> > > > > >
Re: Calculate on a DATE object in minilang
Adrian,
Actually on my side the point was more about optionnal but one fields rule. I
wanted to underline this as "I don't think such a rule
is already used in minilang."
Jacques
- Message d'origine -
De : "Adrian Crum" <[EMAIL PROTECTED]>
À :
Envoyé : lundi 17 décembre 2007 17:13
Objet : Re: Calculate on a DATE object in minilang
> Jacques,
>
> If you go back to the start of this thread, you will see that there is an
> existing Jira issue.
>
> Jacopo,
>
> I would be happy to work on this. It would help if someone could C&P the
> minilang format we
> discussed into the Jira issue, then I will work on it as soon as I'm done
> with a project at work.
>
> -Adrian
>
> Jacques Le Roux wrote:
>
> > We should 1st create a Jira issue for this, isn'it (maybe there is already
> > one) ? I guess your example is a good base for that
using
> > all adjusters Adrian proposed years="${year}"... millis="${millis}".
> > Adrian proposed that the field "field=" could be optionnal, so the
> > adjusters fields, but there must be at least one of them
> > (including "field=" in them ?) I don't think a such a rule is already used
> > in minilang.
> >
> > Jacques
> >
> >
> > De : "Jacopo Cappellato" <[EMAIL PROTECTED]>
> >
> >>It would be nice to have:
> >>
> >> >>days="+1"/>
> >>
> >>
> >>
> >>Output:
> >>
> >>"Tomorrow is Wednesday"
> >>
> >>Jacopo
> >
> >
> > Jacques
> >
> > De : "Jacopo Cappellato" <[EMAIL PROTECTED]>
> >
> >>I'm keeping this thread alive because I have a wish to see the
> >> (or ) operation implemented: in fact in
> >>the Minilang service I've committed yesterday to close a financial time
> >>period we have the requirement to get a Timestamp (older than an
> >>existing one of a few seconds).
> >>I'm wondering if someone here could help with this task... maybe Adrian
> >>"The Lord Of Time" Crum? ;-)
> >>
> >>Jacopo
> >>
> >>
> >>Jacques Le Roux wrote:
> >>
> >>>I just had a cursory review, yes seems like a good idea. I agree with
> >>>Adrian view : rely on joda team as possible. And maybe
> >
> > help
> >
> >>>them also, though joda looks like being already very well advanced.
> >>>
> >>>+1 for me
> >>>
> >>>Jacques
> >>>
> >>>De : "Jim Barrows" <[EMAIL PROTECTED]>
> >>>
> Or, at least provide a better starting point then the java date stuff :)
>
> On Dec 10, 2007 10:22 AM, Adrian Crum <[EMAIL PROTECTED]> wrote:
>
> >Jim,
> >
> >That looks very interesting! We already have the UtilDateTime class that
> >does pretty much the same
> >thing. I'll take a look at it - there's a chance we can eliminate a lot
> >of OFBiz code by going with
> >the joda-time code.
> >
> >-Adrian
> >
> >
> >Jim Barrows wrote:
> >
> >
> >>What about wrapping joda time (joda-time.sourceforge.net) up in
> >>mini-lang?
> >>
> >>On Dec 10, 2007 10:04 AM, Chris Howe <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>Keep in mind there are additional outputs that one might want from
> >>>date/time math. Weekday of first of month, week of
year,
> >>>
> >>>etc. I'm lacking moments of inspiration on the subject at the moment, so
> >>>I'll just put that out there for now instead of
> >
> > offering a
> >
> >>>solution :P
> >>>
> >>>- Original Message
> >>>From: Jacopo Cappellato <[EMAIL PROTECTED]>
> >>>To: dev@ofbiz.apache.org
> >>>Sent: Monday, December 10, 2007 10:24:27 AM
> >>>Subject: Re: Calculate on a DATE object in minilang
> >>>
> >>>
> >>>Adrian,
> >>>
> >>>looks pretty good.
> >>>One small suggestion: use "field" instead of "to-field" to use the same
> >>>
> >>>convention of the set operator:
> >>>
> >>> >>> years="+1" months="+1" ... millis="+1"
> >>> locale="parameters.locale" time-zone="parameters.timeZone"/>
> >>>
> >>>Jacopo
> >>>
> >>>
> >>> Adrian Crum wrote:
> >>>
> >>>
> Thanks Jacques.
>
> I've been thinking about this a little, and here is my suggestion:
>
> years="+1" months="+1" ... millis="+1"
> locale="parameters.locale" time-zone="parameters.timeZone"/>
>
> The to-field attribute would be optional, as well as any of the
> adjusters. An element that has no adjusters
> >>>
> >>>produces
> >>>
> >>>
> an error.
>
> Adjustments would be performed using the minilang context's locale
> >>>
> >>>and
> >>>
> >>>
> time zone, unless the locale and time-zone attributes are used.
>
> Any thoughts?
>
> -Adrian
>
> Jacques Le Roux wrote:
>
>
>
> >Thanks Adrian,
> >
> >I put your comment and Chris's in the issue. Hopefully Fabien will
> >take care of it (propose somehting), else we will see later...
> >
> >Jacques
> >
> >>>
Re: Include of controllers
The original intent of having the mainDecoratorLocation parameter was to be able to reuse OOTB
screens and have them decorated with your custom app's main decorator. If BJ wants to do something
different than that, then yes - he'll need to do some extra work in his custom app.
This thread started with a simple problem - BJ included the Party Manager component's controller.xml
file in his custom app so he could reuse the party manager screens. That SHOULD work, but instead it
generates errors. I looked at how the party manager screens were set up and I saw where the problem
was - not in the controller.xml file or in the web.xml file, but in the design of the screens. They
can't be reused - regardless of whether you try to reuse them via including a controller.xml file or
by some other means.
If BJ would try my suggestion, I believe it will solve his problem. We can argue about the correct
solution all day, but it's just a waste of bandwidth until someone actually tries it.
-Adrian
Scott Gray wrote:
I agree with Chris' interpretation here, while you are right Adrian about
the sub decorators you're missing what BJ is trying to acheive. He wants to
include the controllers from the base apps but not have to define his own
mainDecoratorLocation for the screens from those apps.
Regards
Scott
On 18/12/2007, Adrian Crum <[EMAIL PROTECTED]> wrote:
Actually, it would be better if we stuck to the original example you gave
- communication events in
the Party Manager component. Have you tried the solution I offerred?
-Adrian
Adrian Crum wrote:
Exactly. That's because the screen was designed poorly. If the products
screen was fixed as I suggested, then it would work as you would expect.
BJ Freeman wrote:
The problem is any screen that used
location="${parameters.mainDecoratorLocation}
will can not be called from a remote controller that includes the
controller for that app.
so if myapp controller includes the products controller and that then
brings up a view in products. it will not find the
parameters.mainDecoratorLocation for products
and will error.
Adrian Crum sent the following on 12/17/2007 9:33 AM:
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to reuse
the actual-content screen, errors are generated because
evaluates to the
custom
app's main decorator xml file, and the sub-decorator screen doesn't
exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for sub-decorators
and
either have no location specified or use a different parameter for the
sub-decorator's location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in the
Accounting component. All of the Agreement screens share a common
sub-decorator (CommonAgreementDecorator) - and that decorator's
location
is specified as ${parameters.agreementDecoratorLocation}. The
agreementDecoratorLocation parameter isn't defined anywhere, so the
location= expression evaluates to an empty String - which causes the
screen widget view handler to look for CommonAgreementDecorator in the
existing file.
A custom app that reuses one of the Agreement screens will only need
to
specify the mainDecoratorLocation parameter. Since no
agreementDecoratorLocation parameter is defined in the custom app, the
sub-decorator in AgreementScreens.xml is used (same as above). If a
custom app wanted to have a custom sub-decorator, then it can specify
that decorator's location in the agreementDecoratorLocation parameter.
-Adrian
BJ Freeman wrote:
I agree, it is not a controller or web.xml issue. However it is when
it
shows up.
I will change them as I come along also.
thanks, that is all I wanted to know.
do you want to create a jira so I can submit changes?
Adrian Crum sent the following on 12/17/2007 7:57 AM:
As I mentioned before, the problem is with the coding style on some
screens, not with the controller or web.xml files. I recently
changed
some of the accounting screens to correct this error.
-Adrian
BJ Freeman wrote:
I am not really, trying to attach the context as a whole.
only trying to get the mainDecoratorLocation
which is stored as a context in web.xml.
The problem is if I put mainDecoratorLocation, in my web.xml
then all applications I call thru my controller, or the included
ones,
will use my mainDecoratorLocation full path.
Maybe the solution is to put the main-decorator for all apps in the
framework/commons
then like in many of the application they have specific decorators
that
include the main-decorator.
the problems is how to fill in the actions, etcetera
Chris Howe sent the following on 12/15/2007 10:40 AM:
All the does is grab some xm
Re: Include of controllers
only shied away from it because I don't understand it yet
so will try to make it work with you suggestion.
Adrian Crum sent the following on 12/17/2007 10:42 AM:
> Actually, it would be better if we stuck to the original example you
> gave - communication events in the Party Manager component. Have you
> tried the solution I offerred?
>
> -Adrian
>
> Adrian Crum wrote:
>
>> Exactly. That's because the screen was designed poorly. If the
>> products screen was fixed as I suggested, then it would work as you
>> would expect.
>>
>> BJ Freeman wrote:
>>
>>> The problem is any screen that used
>>> location="${parameters.mainDecoratorLocation}
>>> will can not be called from a remote controller that includes the
>>> controller for that app.
>>> so if myapp controller includes the products controller and that then
>>> brings up a view in products. it will not find the
>>> parameters.mainDecoratorLocation for products
>>> and will error.
>>>
>>> Adrian Crum sent the following on 12/17/2007 9:33 AM:
>>>
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to reuse
the actual-content screen, errors are generated because
>>> location="${parameters.mainDecoratorLocation}"> evaluates to the custom
app's main decorator xml file, and the sub-decorator screen doesn't
exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for sub-decorators
and
either have no location specified or use a different parameter for the
sub-decorator's location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in the
Accounting component. All of the Agreement screens share a common
sub-decorator (CommonAgreementDecorator) - and that decorator's
location
is specified as ${parameters.agreementDecoratorLocation}. The
agreementDecoratorLocation parameter isn't defined anywhere, so the
location= expression evaluates to an empty String - which causes the
screen widget view handler to look for CommonAgreementDecorator in the
existing file.
A custom app that reuses one of the Agreement screens will only need to
specify the mainDecoratorLocation parameter. Since no
agreementDecoratorLocation parameter is defined in the custom app, the
sub-decorator in AgreementScreens.xml is used (same as above). If a
custom app wanted to have a custom sub-decorator, then it can specify
that decorator's location in the agreementDecoratorLocation parameter.
-Adrian
BJ Freeman wrote:
> I agree, it is not a controller or web.xml issue. However it is
> when it
> shows up.
> I will change them as I come along also.
> thanks, that is all I wanted to know.
> do you want to create a jira so I can submit changes?
>
> Adrian Crum sent the following on 12/17/2007 7:57 AM:
>
>
>> As I mentioned before, the problem is with the coding style on some
>> screens, not with the controller or web.xml files. I recently changed
>> some of the accounting screens to correct this error.
>>
>> -Adrian
>>
>> BJ Freeman wrote:
>>
>>
>>
>>> I am not really, trying to attach the context as a whole.
>>> only trying to get the mainDecoratorLocation
>>> which is stored as a context in web.xml.
>>> The problem is if I put mainDecoratorLocation, in my web.xml
>>> then all applications I call thru my controller, or the included
>>> ones,
>>> will use my mainDecoratorLocation full path.
>>> Maybe the solution is to put the main-decorator for all apps in the
>>> framework/commons
>>> then like in many of the application they have specific
>>> decorators that
>>> include the main-decorator.
>>> the problems is how to fill in the actions, etcetera
>>>
>>> Chris Howe sent the following on 12/15/2007 10:40 AM:
>>>
>>>
>>>
All the does is grab some xml elements from the location
described. Theoretically, It doesn't even need to be from the same
server, much less the same app (may have interesting possibilities
BTW). This is why I'm having such a hard time understanding why
you
are trying to attach context to it.
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Saturday, December 15, 2007 12:19:27 PM
Subject: Re: Include of controllers
I was going thru the trunk and noticed
Re: adopting commented examples in config files
BJ, Don't worry about a Jira issue (except if you see some kind of generalisation). I will commit it directly soon... Thanks Jacques De : "BJ Freeman" <[EMAIL PROTECTED]> > I will create a general JIra for a config information > I don't have commit privileges. > > > [EMAIL PROTECTED] sent the following on 12/17/2007 7:16 AM: > > Yes, BJ Freeman you can commit by yourself or at least I will wait some > > ideas about that from others people. > > Is it something to commit also in the relase 4 ? > > > > Thanks > > Marco > > > >> I like the way the Apache httpd server has it config files commented. > >> it give you a example of what should go into the config. > >> I user the paypal config as an example. > >> > >> #payment.paypal.notify=http://[yourserver]/ecommerce/control/payPalNotify > >> payment.paypal.notify= > >> > >> so the configuration person does not have to hunt down documentation > >> when implementing these not so apparent configurations. > >> > >> > > > > > > > > >
[jira] Closed: (OFBIZ-1530) AR: implement a service to compute outstanding amounts of past due date invoices
[ https://issues.apache.org/jira/browse/OFBIZ-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacopo Cappellato closed OFBIZ-1530. Resolution: Fixed > AR: implement a service to compute outstanding amounts of past due date > invoices > > > Key: OFBIZ-1530 > URL: https://issues.apache.org/jira/browse/OFBIZ-1530 > Project: OFBiz > Issue Type: Sub-task > Components: accounting >Affects Versions: SVN trunk >Reporter: Jacopo Cappellato >Assignee: Jacopo Cappellato > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Include of controllers
Ok I will try to get my head around you solution.
:)
Adrian Crum sent the following on 12/17/2007 10:42 AM:
> Actually, it would be better if we stuck to the original example you
> gave - communication events in the Party Manager component. Have you
> tried the solution I offerred?
>
> -Adrian
>
> Adrian Crum wrote:
>
>> Exactly. That's because the screen was designed poorly. If the
>> products screen was fixed as I suggested, then it would work as you
>> would expect.
>>
>> BJ Freeman wrote:
>>
>>> The problem is any screen that used
>>> location="${parameters.mainDecoratorLocation}
>>> will can not be called from a remote controller that includes the
>>> controller for that app.
>>> so if myapp controller includes the products controller and that then
>>> brings up a view in products. it will not find the
>>> parameters.mainDecoratorLocation for products
>>> and will error.
>>>
>>> Adrian Crum sent the following on 12/17/2007 9:33 AM:
>>>
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to reuse
the actual-content screen, errors are generated because
>>> location="${parameters.mainDecoratorLocation}"> evaluates to the custom
app's main decorator xml file, and the sub-decorator screen doesn't
exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for sub-decorators
and
either have no location specified or use a different parameter for the
sub-decorator's location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in the
Accounting component. All of the Agreement screens share a common
sub-decorator (CommonAgreementDecorator) - and that decorator's
location
is specified as ${parameters.agreementDecoratorLocation}. The
agreementDecoratorLocation parameter isn't defined anywhere, so the
location= expression evaluates to an empty String - which causes the
screen widget view handler to look for CommonAgreementDecorator in the
existing file.
A custom app that reuses one of the Agreement screens will only need to
specify the mainDecoratorLocation parameter. Since no
agreementDecoratorLocation parameter is defined in the custom app, the
sub-decorator in AgreementScreens.xml is used (same as above). If a
custom app wanted to have a custom sub-decorator, then it can specify
that decorator's location in the agreementDecoratorLocation parameter.
-Adrian
BJ Freeman wrote:
> I agree, it is not a controller or web.xml issue. However it is
> when it
> shows up.
> I will change them as I come along also.
> thanks, that is all I wanted to know.
> do you want to create a jira so I can submit changes?
>
> Adrian Crum sent the following on 12/17/2007 7:57 AM:
>
>
>> As I mentioned before, the problem is with the coding style on some
>> screens, not with the controller or web.xml files. I recently changed
>> some of the accounting screens to correct this error.
>>
>> -Adrian
>>
>> BJ Freeman wrote:
>>
>>
>>
>>> I am not really, trying to attach the context as a whole.
>>> only trying to get the mainDecoratorLocation
>>> which is stored as a context in web.xml.
>>> The problem is if I put mainDecoratorLocation, in my web.xml
>>> then all applications I call thru my controller, or the included
>>> ones,
>>> will use my mainDecoratorLocation full path.
>>> Maybe the solution is to put the main-decorator for all apps in the
>>> framework/commons
>>> then like in many of the application they have specific
>>> decorators that
>>> include the main-decorator.
>>> the problems is how to fill in the actions, etcetera
>>>
>>> Chris Howe sent the following on 12/15/2007 10:40 AM:
>>>
>>>
>>>
All the does is grab some xml elements from the location
described. Theoretically, It doesn't even need to be from the same
server, much less the same app (may have interesting possibilities
BTW). This is why I'm having such a hard time understanding why
you
are trying to attach context to it.
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Saturday, December 15, 2007 12:19:27 PM
Subject: Re: Include of controllers
I was going thru the trunk and noticed this in all the controllers
>>> location
Re: Include of controllers
I agree with Chris' interpretation here, while you are right Adrian about
the sub decorators you're missing what BJ is trying to acheive. He wants to
include the controllers from the base apps but not have to define his own
mainDecoratorLocation for the screens from those apps.
Regards
Scott
On 18/12/2007, Adrian Crum <[EMAIL PROTECTED]> wrote:
>
> Actually, it would be better if we stuck to the original example you gave
> - communication events in
> the Party Manager component. Have you tried the solution I offerred?
>
> -Adrian
>
> Adrian Crum wrote:
>
> > Exactly. That's because the screen was designed poorly. If the products
> > screen was fixed as I suggested, then it would work as you would expect.
> >
> > BJ Freeman wrote:
> >
> >> The problem is any screen that used
> >> location="${parameters.mainDecoratorLocation}
> >> will can not be called from a remote controller that includes the
> >> controller for that app.
> >> so if myapp controller includes the products controller and that then
> >> brings up a view in products. it will not find the
> >> parameters.mainDecoratorLocation for products
> >> and will error.
> >>
> >> Adrian Crum sent the following on 12/17/2007 9:33 AM:
> >>
> >>> BJ,
> >>>
> >>> Go ahead and create one. I will work on it when I have time.
> >>>
> >>> To be sure we're all on the same page, the problem exists when screens
> >>> are nested as follows:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>...
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> and the location of the sub-decorator screen is defined as
> >>> ${parameters.mainDecoratorLocation}. When a custom app tries to reuse
> >>> the actual-content screen, errors are generated because
> >>> >>> location="${parameters.mainDecoratorLocation}"> evaluates to the
> custom
> >>> app's main decorator xml file, and the sub-decorator screen doesn't
> >>> exist there.
> >>>
> >>> The solution to the problem is to avoid using
> >>> ${parameters.mainDecoratorLocation} as a location for sub-decorators
> and
> >>> either have no location specified or use a different parameter for the
> >>> sub-decorator's location - like ${subDecoratorLocation}.
> >>>
> >>> A good example of this approach is in AgreementScreens.xml in the
> >>> Accounting component. All of the Agreement screens share a common
> >>> sub-decorator (CommonAgreementDecorator) - and that decorator's
> location
> >>> is specified as ${parameters.agreementDecoratorLocation}. The
> >>> agreementDecoratorLocation parameter isn't defined anywhere, so the
> >>> location= expression evaluates to an empty String - which causes the
> >>> screen widget view handler to look for CommonAgreementDecorator in the
> >>> existing file.
> >>>
> >>> A custom app that reuses one of the Agreement screens will only need
> to
> >>> specify the mainDecoratorLocation parameter. Since no
> >>> agreementDecoratorLocation parameter is defined in the custom app, the
> >>> sub-decorator in AgreementScreens.xml is used (same as above). If a
> >>> custom app wanted to have a custom sub-decorator, then it can specify
> >>> that decorator's location in the agreementDecoratorLocation parameter.
> >>>
> >>> -Adrian
> >>>
> >>> BJ Freeman wrote:
> >>>
> >>>
> I agree, it is not a controller or web.xml issue. However it is when
> it
> shows up.
> I will change them as I come along also.
> thanks, that is all I wanted to know.
> do you want to create a jira so I can submit changes?
>
> Adrian Crum sent the following on 12/17/2007 7:57 AM:
>
>
> > As I mentioned before, the problem is with the coding style on some
> > screens, not with the controller or web.xml files. I recently
> changed
> > some of the accounting screens to correct this error.
> >
> > -Adrian
> >
> > BJ Freeman wrote:
> >
> >
> >
> >> I am not really, trying to attach the context as a whole.
> >> only trying to get the mainDecoratorLocation
> >> which is stored as a context in web.xml.
> >> The problem is if I put mainDecoratorLocation, in my web.xml
> >> then all applications I call thru my controller, or the included
> >> ones,
> >> will use my mainDecoratorLocation full path.
> >> Maybe the solution is to put the main-decorator for all apps in the
> >> framework/commons
> >> then like in many of the application they have specific decorators
> >> that
> >> include the main-decorator.
> >> the problems is how to fill in the actions, etcetera
> >>
> >> Chris Howe sent the following on 12/15/2007 10:40 AM:
> >>
> >>
> >>
> >>> All the does is grab some xml elements from the location
> >>> described. Theoretically, It doesn't even need to be from the
> same
> >>> server, much less the same app (may have interesting possibilities
> >>> BTW). This is why I'm having such a hard time understanding why
> you
> >>> are trying to attach context to it.
> >>>
Re: Include of controllers
Actually, it would be better if we stuck to the original example you gave - communication events in
the Party Manager component. Have you tried the solution I offerred?
-Adrian
Adrian Crum wrote:
Exactly. That's because the screen was designed poorly. If the products
screen was fixed as I suggested, then it would work as you would expect.
BJ Freeman wrote:
The problem is any screen that used
location="${parameters.mainDecoratorLocation}
will can not be called from a remote controller that includes the
controller for that app.
so if myapp controller includes the products controller and that then
brings up a view in products. it will not find the
parameters.mainDecoratorLocation for products
and will error.
Adrian Crum sent the following on 12/17/2007 9:33 AM:
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to reuse
the actual-content screen, errors are generated because
evaluates to the custom
app's main decorator xml file, and the sub-decorator screen doesn't
exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for sub-decorators and
either have no location specified or use a different parameter for the
sub-decorator's location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in the
Accounting component. All of the Agreement screens share a common
sub-decorator (CommonAgreementDecorator) - and that decorator's location
is specified as ${parameters.agreementDecoratorLocation}. The
agreementDecoratorLocation parameter isn't defined anywhere, so the
location= expression evaluates to an empty String - which causes the
screen widget view handler to look for CommonAgreementDecorator in the
existing file.
A custom app that reuses one of the Agreement screens will only need to
specify the mainDecoratorLocation parameter. Since no
agreementDecoratorLocation parameter is defined in the custom app, the
sub-decorator in AgreementScreens.xml is used (same as above). If a
custom app wanted to have a custom sub-decorator, then it can specify
that decorator's location in the agreementDecoratorLocation parameter.
-Adrian
BJ Freeman wrote:
I agree, it is not a controller or web.xml issue. However it is when it
shows up.
I will change them as I come along also.
thanks, that is all I wanted to know.
do you want to create a jira so I can submit changes?
Adrian Crum sent the following on 12/17/2007 7:57 AM:
As I mentioned before, the problem is with the coding style on some
screens, not with the controller or web.xml files. I recently changed
some of the accounting screens to correct this error.
-Adrian
BJ Freeman wrote:
I am not really, trying to attach the context as a whole.
only trying to get the mainDecoratorLocation
which is stored as a context in web.xml.
The problem is if I put mainDecoratorLocation, in my web.xml
then all applications I call thru my controller, or the included
ones,
will use my mainDecoratorLocation full path.
Maybe the solution is to put the main-decorator for all apps in the
framework/commons
then like in many of the application they have specific decorators
that
include the main-decorator.
the problems is how to fill in the actions, etcetera
Chris Howe sent the following on 12/15/2007 10:40 AM:
All the does is grab some xml elements from the location
described. Theoretically, It doesn't even need to be from the same
server, much less the same app (may have interesting possibilities
BTW). This is why I'm having such a hard time understanding why you
are trying to attach context to it.
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Saturday, December 15, 2007 12:19:27 PM
Subject: Re: Include of controllers
I was going thru the trunk and noticed this in all the controllers
location="component://common/webcommon/WEB-INF/common-controller.xml"/>
so there is a rule that says you can include a controller not in the
same app.
BJ Freeman sent the following on 11/10/2007 4:15 PM:
Almost.
when the included controller view calles a screen in the partymgr
screen
, and that screen calls for a parm that is web.xml. the parm is not
availible for the screen and so fails.
At this time, the way I handle this is to put the parm in my
Web.xml.
My suggestions was that if a call is made to a parm that would
be in
the
applications, in this case partymgr, web.xml, that widget looks up
the
web.xml for that application to get it.
Chris Howe sent the following on 11/10/2007 2:23 PM:
Okay, I've read through the thread. In that case, I might suggest
to take a step back and look at what the two functionalities were
designed t
Re: Include of controllers
Exactly. That's because the screen was designed poorly. If the products screen was fixed as I
suggested, then it would work as you would expect.
BJ Freeman wrote:
The problem is any screen that used
location="${parameters.mainDecoratorLocation}
will can not be called from a remote controller that includes the
controller for that app.
so if myapp controller includes the products controller and that then
brings up a view in products. it will not find the
parameters.mainDecoratorLocation for products
and will error.
Adrian Crum sent the following on 12/17/2007 9:33 AM:
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When a custom app tries to reuse
the actual-content screen, errors are generated because
evaluates to the custom
app's main decorator xml file, and the sub-decorator screen doesn't
exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for sub-decorators and
either have no location specified or use a different parameter for the
sub-decorator's location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in the
Accounting component. All of the Agreement screens share a common
sub-decorator (CommonAgreementDecorator) - and that decorator's location
is specified as ${parameters.agreementDecoratorLocation}. The
agreementDecoratorLocation parameter isn't defined anywhere, so the
location= expression evaluates to an empty String - which causes the
screen widget view handler to look for CommonAgreementDecorator in the
existing file.
A custom app that reuses one of the Agreement screens will only need to
specify the mainDecoratorLocation parameter. Since no
agreementDecoratorLocation parameter is defined in the custom app, the
sub-decorator in AgreementScreens.xml is used (same as above). If a
custom app wanted to have a custom sub-decorator, then it can specify
that decorator's location in the agreementDecoratorLocation parameter.
-Adrian
BJ Freeman wrote:
I agree, it is not a controller or web.xml issue. However it is when it
shows up.
I will change them as I come along also.
thanks, that is all I wanted to know.
do you want to create a jira so I can submit changes?
Adrian Crum sent the following on 12/17/2007 7:57 AM:
As I mentioned before, the problem is with the coding style on some
screens, not with the controller or web.xml files. I recently changed
some of the accounting screens to correct this error.
-Adrian
BJ Freeman wrote:
I am not really, trying to attach the context as a whole.
only trying to get the mainDecoratorLocation
which is stored as a context in web.xml.
The problem is if I put mainDecoratorLocation, in my web.xml
then all applications I call thru my controller, or the included ones,
will use my mainDecoratorLocation full path.
Maybe the solution is to put the main-decorator for all apps in the
framework/commons
then like in many of the application they have specific decorators that
include the main-decorator.
the problems is how to fill in the actions, etcetera
Chris Howe sent the following on 12/15/2007 10:40 AM:
All the does is grab some xml elements from the location
described. Theoretically, It doesn't even need to be from the same
server, much less the same app (may have interesting possibilities
BTW). This is why I'm having such a hard time understanding why you
are trying to attach context to it.
- Original Message
From: BJ Freeman <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Saturday, December 15, 2007 12:19:27 PM
Subject: Re: Include of controllers
I was going thru the trunk and noticed this in all the controllers
so there is a rule that says you can include a controller not in the
same app.
BJ Freeman sent the following on 11/10/2007 4:15 PM:
Almost.
when the included controller view calles a screen in the partymgr
screen
, and that screen calls for a parm that is web.xml. the parm is not
availible for the screen and so fails.
At this time, the way I handle this is to put the parm in my Web.xml.
My suggestions was that if a call is made to a parm that would be in
the
applications, in this case partymgr, web.xml, that widget looks up
the
web.xml for that application to get it.
Chris Howe sent the following on 11/10/2007 2:23 PM:
Okay, I've read through the thread. In that case, I might suggest
to take a step back and look at what the two functionalities were
designed to accomplish.
Creating the mainDecoratorLocation variable in the web.xml was
designed for _screen reuse. the include element in the controller.xml
file
was designed for request/response maintenance.
With that in mind, you can include another controller in your custom
application
Re: Include of controllers
If my suggestion is followed, then BJ can include all the controllers he wants and all of the
included screens will perform as expected - no additional work is needed.
-Adrian
Chris Howe wrote:
I would agree with the solution you offered of sending the views to custom
application screens that dictate how the controller is to be used.. BJ does
not. BJ doesn't want to create any screens in his custom application.
- Original Message
From: Adrian Crum <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 12:20:23 PM
Subject: Re: Include of controllers
I don't agree that that is the only way to solve the problem. I have
suggested the CORRECT solution
to this problem ever since the beginning of this thread, but that
solution is being ignored, and
instead it is being replced with a kludge that tries to fix a SYMPTOM,
and not the real problem.
-Adrian
Chris Howe wrote:
BJ's problem occurs because when he s the party
controller and the catalog controller, he wants the requests/views
from
the party controller to have mainDecoratorLocation equal one place
and
the requests/views from the catalog controller to equal another.
The only way for it to solve BJ's issue is to replace current
${parameters.mainDecoratorLocation} with
${parameters.randomVariableThatSuggestsTheScreenThisIsBeingCalledFromBelongsToAWebAppDecoratorLocation}
or
to remove the variable location altogether, thus breaking the ability
call that screen from a custom application. Not simply provide a variable
to location's that are empty.
- Original Message
From: Adrian Crum <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 11:46:26 AM
Subject: Re: Include of controllers
If BJ supplies a patch as I described, then we'll see if it solves
his
problem. If it does, then
we're talking about the same issue. ;-)
-Adrian
Chris Howe wrote:
You two are talking about different issues. BJ is describing a
pitfall that occurs when you use the tag in the controller
for a
scenario that wasn't considered when the tag was
implemented
in the controller.
- Original Message
From: Adrian Crum <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Monday, December 17, 2007 11:33:43 AM
Subject: Re: Include of controllers
BJ,
Go ahead and create one. I will work on it when I have time.
To be sure we're all on the same page, the problem exists when
screens
are nested as follows:
...
and the location of the sub-decorator screen is defined as
${parameters.mainDecoratorLocation}. When
a custom app tries to reuse the actual-content screen, errors are
generated because
location="${parameters.mainDecoratorLocation}"> evaluates to
the custom app's main decorator xml file, and the sub-decorator
screen
doesn't exist there.
The solution to the problem is to avoid using
${parameters.mainDecoratorLocation} as a location for
sub-decorators and either have no location specified or use a
different
parameter for the
sub-decorator's location - like ${subDecoratorLocation}.
A good example of this approach is in AgreementScreens.xml in the
Accounting component. All of the
Agreement screens share a common sub-decorator
(CommonAgreementDecorator) - and that decorator's
location is specified as ${parameters.agreementDecoratorLocation}.
The
agreementDecoratorLocation
parameter isn't defined anywhere, so the location= expression
evaluates
to an empty String - which
causes the screen widget view handler to look for
CommonAgreementDecorator in the existing file.
A custom app that reuses one of the Agreement screens will only need
to
specify the
mainDecoratorLocation parameter. Since no agreementDecoratorLocation
parameter is defined in the
custom app, the sub-decorator in AgreementScreens.xml is used (same
as
above). If a custom app
wanted to have a custom sub-decorator, then it can specify that
decorator's location in the
agreementDecoratorLocation parameter.
-Adrian
BJ Freeman wrote:
I agree, it is not a controller or web.xml issue. However it is when
it
shows up.
I will change them as I come along also.
thanks, that is all I wanted to know.
do you want to create a jira so I can submit changes?
Adrian Crum sent the following on 12/17/2007 7:57 AM:
As I mentioned before, the problem is with the coding style on some
screens, not with the controller or web.xml files. I recently
changed
some of the accounting screens to correct this error.
-Adrian
BJ Freeman wrote:
I am not really, trying to attach the context as a whole.
only trying to get the mainDecoratorLocation
which is stored as a context in web.xml.
The problem is if I put mainDecoratorLocation, in my web.xml
then all applications I call thru my controller, or the included
ones,
will use my mainDecoratorLocation full path.
Maybe the solution is to put the main-decorator for all
