Re: svn commit: r663501 - in /ofbiz/trunk: ./ applications/ecommerce/webapp/ecommerce/blog/ applications/ecommerce/widget/ framework/common/webcommon/includes/ framework/common/widget/ framework/image
Thanks for pointing it out Adrian, I've restored the workeffort calendar styles in rev. 663842. Regards Scott 2008/6/6 Adrian Crum <[EMAIL PROTECTED]>: > Why was the calendar CSS class removed in this commit? Now the workeffort > calendar screen layout is broken. > > -Adrian > > > [EMAIL PROTECTED] wrote: > >> Author: lektran >> Date: Thu Jun 5 01:45:10 2008 >> New Revision: 663501 >> >> URL: http://svn.apache.org/viewvc?rev=663501&view=rev >> Log: >> Replaced the Tigra calendar with Calendar Date Select ( >> http://code.google.com/p/calendardateselect/) - OFBIZ-1808 >> >> Added: >>ofbiz/trunk/framework/images/webapp/images/calendar_date_select.js >> (with props) >> Removed: >>ofbiz/trunk/framework/images/webapp/images/calendar.html >>ofbiz/trunk/framework/images/webapp/images/calendar1.js >> Modified: >>ofbiz/trunk/LICENSE >>ofbiz/trunk/NOTICE >>ofbiz/trunk/applications/ecommerce/webapp/ecommerce/blog/main.ftl >>ofbiz/trunk/applications/ecommerce/widget/CommonScreens.xml >>ofbiz/trunk/framework/common/webcommon/includes/lookup.ftl >>ofbiz/trunk/framework/common/widget/CommonScreens.xml >>ofbiz/trunk/framework/images/webapp/images/fieldlookup.js >>ofbiz/trunk/framework/images/webapp/images/maincss.css >>ofbiz/trunk/specialpurpose/cmssite/template/cms/HtmlHead.ftl >>ofbiz/trunk/specialpurpose/googlebase/widget/GoogleBaseScreens.xml >> >> Modified: ofbiz/trunk/LICENSE >> URL: >> http://svn.apache.org/viewvc/ofbiz/trunk/LICENSE?rev=663501&r1=663500&r2=663501&view=diff >> >> == >> --- ofbiz/trunk/LICENSE (original) >> +++ ofbiz/trunk/LICENSE Thu Jun 5 01:45:10 2008 >> @@ -1184,6 +1184,7 @@ >> ofbiz/trunk/framework/base/lib/icu4j_3_6.jar >> ofbiz/trunk/framework/entity/lib/ofbiz-minerva.jar >> ofbiz/trunk/framework/images/webapp/images/htmledit/whizzywig_v55i.js >> +ofbiz/trunk/framework/images/webapp/images/calendar_date_select.js >> = >> The MIT License >> @@ -2205,24 +2206,6 @@ >> of California, with venue lying in Santa Clara County, California. >> >> = >> -Apache OFBiz includes the Tigra Calendar HTML and JavaScript files: >> -ofbiz/trunk/framework/images/webapp/images/calendar.html >> -ofbiz/trunk/framework/images/webapp/images/calendar1.js >> -Tigra Calendar is licensed as follows: >> -= >> -Title: Tigra Calendar >> -URL: http://www.softcomplex.com/products/tigra_calendar/ >> -Version: 3.2 >> -Date: 10/14/2002 (mm/dd/) >> -Feedback: [EMAIL PROTECTED] (specify product title in the >> subject) >> -Note: Permission given to use this script in ANY kind of applications if >> - header lines are left unchanged. >> -Note: Script consists of two files: calendar?.js and calendar.html >> -About us: Our company provides offshore IT consulting services. >> -Contact us at [EMAIL PROTECTED] if you have any programming task >> you >> -want to be handled by professionals. Our typical hourly rate is $20. >> - >> -= >> Apache OFBiz includes the XML Schema files from the Open Applications >> Group, Inc >> NOTE: these files and the license are for an older version of the OAGIS >> specification, namely version 7.2.1. >> >> Modified: ofbiz/trunk/NOTICE >> URL: >> http://svn.apache.org/viewvc/ofbiz/trunk/NOTICE?rev=663501&r1=663500&r2=663501&view=diff >> >> == >> --- ofbiz/trunk/NOTICE (original) >> +++ ofbiz/trunk/NOTICE Thu Jun 5 01:45:10 2008 >> @@ -255,16 +255,6 @@ >> framework/images/webapp/images/pngbehavior.htc >> >> = >> -== Tigra Calendar Notice == >> -= >> - >> -This product includes files developed by >> -Softcomplex (www.softcomplex.com): >> - >> -framework\images\webapp\images\calendar.html >> -framework\images\webapp\images\calendar1.js >> - >> -= >> == JSON-LIB Notice== >> = >> >> Modified: >> ofbiz/trunk/applications/ecommerce/webapp/ecommerce/blog/main.ftl >> URL: >> http://svn.apache.org/viewvc/ofbiz/trunk/applications/ecommerce/webapp/ecommerce/blog/main.ftl?rev=663501&r1=663500&r2=663501&view=diff >> >> == >> --- ofbiz/trunk/applications/ecommerce/webapp/ecommerce/blog/main.ftl >> (original) >> +++ ofbiz/trunk/applications/ecommerce/we
[jira] Assigned: (OFBIZ-1824) Missing paginate target causes bugs on some screens
[ https://issues.apache.org/jira/browse/OFBIZ-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Mayur reassigned OFBIZ-1824: -- Assignee: Vikas Mayur > Missing paginate target causes bugs on some screens > > > Key: OFBIZ-1824 > URL: https://issues.apache.org/jira/browse/OFBIZ-1824 > Project: OFBiz > Issue Type: Bug > Components: party, product >Affects Versions: SVN trunk >Reporter: Valentina Sirkova >Assignee: Vikas Mayur >Priority: Trivial > Fix For: SVN trunk > > Attachments: PaginateTarget.patch > > > The first bug is observed when you go to "Promos" in Catalog manager and > attempt to change pages through the dropdown. > The second bug could be caught when you go to Party manager, choose a > security group, and then try to change pages through the drop down or remove > permission and then try to go to the next or the previous page(the remove > action is being processed one more time:) ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1825) Colors and localisation for the calendar
[
https://issues.apache.org/jira/browse/OFBIZ-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux updated OFBIZ-1825:
---
Attachment: calendarDateSelectColor.patch
Same patch updated after Scott's clean up (some css tags were removed by error)
> Colors and localisation for the calendar
>
>
> Key: OFBIZ-1825
> URL: https://issues.apache.org/jira/browse/OFBIZ-1825
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL COMPONENTS
>Affects Versions: SVN trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: calendarDateSelectColor.patch,
> calendarDateSelectColor.patch, Existing.jpg, Proposition.jpg, WE_CAL.gif
>
>
> I tried to change the calendar colors, to be more "in the OFBiz way". Please
> let me you know what you think.
> I also changed some colors to respect our CSS best practices (no color names).
> Here are some remarks :
> Colors
> * I kept the 3 chars scheme when it's was obvious. For instance we don't
> need to set #00 or #ff when actually #000 or #fff is sufficient.
> * I used Wikipedia as reference http://en.wikipedia.org/wiki/Web_colors for
> choising colors. While doing this change I wondered if we could not authorise
> and even recommend to use sandard names for colors as shown in Wikipedia
> page. I found it easier to recall a color by its names than by an hexa
> number...! As long as we would use this Wikipedia reference I think it could
> be possible to use names instead of hexa, WDYT ?
> * The days initials are not centered but at left (It's late and I did not
> found the reason)
> We need to provide a localisation mean. From
> http://electronicholas.com/calendar?style=default&format=natural it should
> not be too hard. I propose a simple way, maybe we can do better
> * More calendar formats in a calendar.properties file (like the euro or
> american ones)
> * For the moment I think all string are harcoded in calendar_date_select.js
> Date.weekdays = $w("S M T W T F S");
> Date.first_day_of_week = 0;
> Date.months = $w("January February March April May June July August
> September October November December" );
> _translations = {
> "OK": "OK",
> "Now": "Now",
> "Today": "Today"
> }
> A very simple way (but not very clever I must admit) could be to set a
> property for the language to use in calendar.properties file and use it in a
> switch statement with "hardcoded" strings in calendar_date_select.js. Is
> anybody aware of better ways to do that in Javascript or Prototype ?
> BTW I think we should delete calendarstyles.css and calendarTable.css. If
> it's ok, I will do it when I will upate the attached patch later.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-1824) Missing paginate target causes bugs on some screens
[ https://issues.apache.org/jira/browse/OFBIZ-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Mayur closed OFBIZ-1824. -- Resolution: Fixed Thanks Valentina, Your patch is in trunk rev. 663856 - Vikas > Missing paginate target causes bugs on some screens > > > Key: OFBIZ-1824 > URL: https://issues.apache.org/jira/browse/OFBIZ-1824 > Project: OFBiz > Issue Type: Bug > Components: party, product >Affects Versions: SVN trunk >Reporter: Valentina Sirkova >Assignee: Vikas Mayur >Priority: Trivial > Fix For: SVN trunk > > Attachments: PaginateTarget.patch > > > The first bug is observed when you go to "Promos" in Catalog manager and > attempt to change pages through the dropdown. > The second bug could be caught when you go to Party manager, choose a > security group, and then try to change pages through the drop down or remove > permission and then try to go to the next or the previous page(the remove > action is being processed one more time:) ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r663501 - in /ofbiz/trunk: ./ applications/ecommerce/webapp/ecommerce/blog/ applications/ecommerce/widget/ framework/common/webcommon/includes/ framework/common/widget/ framework/image
Thanks Adrian, calendarstyles.css removed in revision 663859. Jacques From: "Adrian Crum" <[EMAIL PROTECTED]> Keep calendarTable.css for now - it s used for the fixed asset calendar. I'm working on fixed assets right now, so I will take care of it. calendarstyles.css isn't being used anymore - it can be removed. -Adrian Jacques Le Roux wrote: Adrian, Scott, Should we also keep images/webapp/images/calendarstyles.css and images/webapp/images/calendarTable.css ? (Sorry it's late here, going to bed :o) Jacques From: "Scott Gray" <[EMAIL PROTECTED]> Sorry Adrian, I assumed it was the styles for the Tigra calendar because there is a separate css file (calendarstyles.css) that appeared to be referenced in the workeffort app. I can't fix it until I get home from work in about 8 hours. Regards Scott 2008/6/6 Adrian Crum <[EMAIL PROTECTED]>: Why was the calendar CSS class removed in this commit? Now the workeffort calendar screen layout is broken. -Adrian [EMAIL PROTECTED] wrote: Author: lektran Date: Thu Jun 5 01:45:10 2008 New Revision: 663501 URL: http://svn.apache.org/viewvc?rev=663501&view=rev Log: Replaced the Tigra calendar with Calendar Date Select ( http://code.google.com/p/calendardateselect/) - OFBIZ-1808 Added: ofbiz/trunk/framework/images/webapp/images/calendar_date_select.js (with props) Removed: ofbiz/trunk/framework/images/webapp/images/calendar.html ofbiz/trunk/framework/images/webapp/images/calendar1.js Modified: ofbiz/trunk/LICENSE ofbiz/trunk/NOTICE ofbiz/trunk/applications/ecommerce/webapp/ecommerce/blog/main.ftl ofbiz/trunk/applications/ecommerce/widget/CommonScreens.xml ofbiz/trunk/framework/common/webcommon/includes/lookup.ftl ofbiz/trunk/framework/common/widget/CommonScreens.xml ofbiz/trunk/framework/images/webapp/images/fieldlookup.js ofbiz/trunk/framework/images/webapp/images/maincss.css ofbiz/trunk/specialpurpose/cmssite/template/cms/HtmlHead.ftl ofbiz/trunk/specialpurpose/googlebase/widget/GoogleBaseScreens.xml Modified: ofbiz/trunk/LICENSE URL: http://svn.apache.org/viewvc/ofbiz/trunk/LICENSE?rev=663501&r1=663500&r2=663501&view=diff == --- ofbiz/trunk/LICENSE (original) +++ ofbiz/trunk/LICENSE Thu Jun 5 01:45:10 2008 @@ -1184,6 +1184,7 @@ ofbiz/trunk/framework/base/lib/icu4j_3_6.jar ofbiz/trunk/framework/entity/lib/ofbiz-minerva.jar ofbiz/trunk/framework/images/webapp/images/htmledit/whizzywig_v55i.js +ofbiz/trunk/framework/images/webapp/images/calendar_date_select.js = The MIT License @@ -2205,24 +2206,6 @@ of California, with venue lying in Santa Clara County, California. = -Apache OFBiz includes the Tigra Calendar HTML and JavaScript files: -ofbiz/trunk/framework/images/webapp/images/calendar.html -ofbiz/trunk/framework/images/webapp/images/calendar1.js -Tigra Calendar is licensed as follows: -= -Title: Tigra Calendar -URL: http://www.softcomplex.com/products/tigra_calendar/ -Version: 3.2 -Date: 10/14/2002 (mm/dd/) -Feedback: [EMAIL PROTECTED] (specify product title in the subject) -Note: Permission given to use this script in ANY kind of applications if - header lines are left unchanged. -Note: Script consists of two files: calendar?.js and calendar.html -About us: Our company provides offshore IT consulting services. -Contact us at [EMAIL PROTECTED] if you have any programming task you -want to be handled by professionals. Our typical hourly rate is $20. - -= Apache OFBiz includes the XML Schema files from the Open Applications Group, Inc NOTE: these files and the license are for an older version of the OAGIS specification, namely version 7.2.1. Modified: ofbiz/trunk/NOTICE URL: http://svn.apache.org/viewvc/ofbiz/trunk/NOTICE?rev=663501&r1=663500&r2=663501&view=diff == --- ofbiz/trunk/NOTICE (original) +++ ofbiz/trunk/NOTICE Thu Jun 5 01:45:10 2008 @@ -255,16 +255,6 @@ framework/images/webapp/images/pngbehavior.htc = -== Tigra Calendar Notice == -= - -This product includes files developed by -Softcomplex (www.softcomplex.com): - -framework\images\webapp\images\calendar.html -framework\images\webapp\images\calendar1.js - -= == JSON-LIB Notice== = Modified: ofbiz/tru
[jira] Updated: (OFBIZ-1676) JUnit Test case for update and return order.
[ https://issues.apache.org/jira/browse/OFBIZ-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Awdesh Parihar updated OFBIZ-1676: -- Attachment: TestCaseForEditAndReturnOrder I have implemented test case for "Create and Update return order" and "Edit Order Item" process. To implemente this i traced out whole process and findout service and entities which are responsible for completing process. Thanks to Ratnesh Upadhayay and Rishi for their help. Thanks and Regards -Awdesh Parihar > JUnit Test case for update and return order. > > > Key: OFBIZ-1676 > URL: https://issues.apache.org/jira/browse/OFBIZ-1676 > Project: OFBiz > Issue Type: Sub-task > Components: order >Affects Versions: SVN trunk >Reporter: Sumit Pandit > Fix For: SVN trunk > > Attachments: TestCaseForEditAndReturnOrder > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-1467) JUNIT test case for finding and editing a party(DemoCustomer)
[ https://issues.apache.org/jira/browse/OFBIZ-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Mayur closed OFBIZ-1467. -- Resolution: Fixed Thanks Awdesh, Ratnesh, Santosh and others, Patch along with few modifications is in trunk rev. 663913 - Vikas > JUNIT test case for finding and editing a party(DemoCustomer) > -- > > Key: OFBIZ-1467 > URL: https://issues.apache.org/jira/browse/OFBIZ-1467 > Project: OFBiz > Issue Type: Sub-task > Components: party >Affects Versions: SVN trunk >Reporter: Vikas Mayur >Assignee: Vikas Mayur >Priority: Minor > Fix For: SVN trunk > > Attachments: find_edit_party.patch, find_edit_party.patch, > find_edit_party.patch, find_edit_party.patch, find_edit_party.patch > > > Followed the process from link > http://docs.ofbiz.org/display/OFBENDUSER/Find+and+Edit+Customer -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Discussion: Ajax Development
I've been thinking about this and I'm wondering if we need a container element for the form and menu widgets, only have it operate more like the section element - so you can have conditionals. That way you could group fields or menu items together, have the group displayed conditionally, and have them wrapped by the rendering classes so they can be updated by Ajax calls. -Adrian Anil Patel wrote: thinking on same lines, We should have a set of input boxes that get rendered to meet formating requirements, like For phone number, I'll like to have a form widget that will render countryCode, areaCode, contactNumber input boxes in one row separated by some character like "-". Similarly Date field may be required to be rendered in some cases. Or Credit Card numbers etc. Regards Anil Patel On Jun 3, 2008, at 5:07 AM, Jacopo Cappellato wrote: Here is my wish list: 1) when you select a value from a drop down box, automatically enable a new drop down box for the selection of further data available after the first selection is done; for example: you select the country, then you have the option to select the state-province in the country 2) when, using a lookup button you select an id (e.g. productId) another field (or label) is automatically populated with the descriptive content of the id (productName etc...) Jacopo On Jun 3, 2008, at 3:35 AM, Anil Patel wrote: I think we should Ajax/Effects enable widgets where possible. Like, Make Panels collapsable using Effects, Ajax enable Tree widget, Enhance Single form Layout to use div and css, Use Model panel for Lookup windows, Allow display fields to be inline editable etc. Regards Anil Patel On Jun 2, 2008, at 6:11 PM, Jacques Le Roux wrote: From: "Adrian Crum" <[EMAIL PROTECTED]> Al Byers wrote: I started a post to your reply that talked about what I would like to see and whatever, but as I got into it, I realized that this whole thing could get quite messy. As soon as you do anything that is "customer facing", I think you are going to lose people (like me) because what we do with widgets could never approach what their specific toolkit can do. Well, the discussion is about adding Ajax capabilities to the screen widgets - which aren't usually used in customer facing websites. I picture this effort as something simpler than the type of work you described. Let's add some bells and whistles to the screen widgets. The screen widget XML to do it shouldn't be overly complicated. In other words, add some fancy embellishments without a lot of extra coding. I just think the work of trying to add some common features that can be supported by all tool kits will not be useful because it will never go far enough. And it will be a lot of work that will not add much advantage over just working in the toolkit (this is particularly true of Dojo since it has an XML markup language that lets me mix it with the widget environment within .ftl files.) There has been talk of doing that with Dojo and another XML based library (I can't remember the name - Jacopo mentioned it). I suppose you tall about Apache XAP ? Jacques Thanks for the reply - I appreciate your input! -Adrian
[jira] Closed: (OFBIZ-1722) CRUD services/UI for AgreementWorkEffortAppl Entity
[ https://issues.apache.org/jira/browse/OFBIZ-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Vijaywargiya closed OFBIZ-1722. -- Resolution: Fixed Ravinda and Nitin thanks for your work. Your patch is in rev # 663966. Thanks Mridul Pathak for your useful comments. -- Ashish Vijaywargiya > CRUD services/UI for AgreementWorkEffortAppl Entity > --- > > Key: OFBIZ-1722 > URL: https://issues.apache.org/jira/browse/OFBIZ-1722 > Project: OFBiz > Issue Type: New Feature > Components: accounting, workeffort >Affects Versions: SVN trunk >Reporter: Mridul Pathak >Assignee: Ashish Vijaywargiya >Priority: Minor > Fix For: SVN trunk > > Attachments: AgreementWorkEffortAppls.patch, > AgreementWorkEffortAppls.patch, AgrrementWorkEffortAppl.Patch, > AgrrementWorkEffortAppl.Patch > > > 1) Create CRUD services for AgreementWorkEffortAppl. This should go in > Accounting Component. > 2) Create CRUD UI for AgreementWorkEffortAppl in Accounting --> Agreement to > Add/Edit/Delete an AgreementWorkEffortAppl for an agreementId. > 3) Create another CRUD UI in WorkEffort --> WorkEffort to Add/Edit/Delete an > AgreementWorkEffortAppl for a workEffortId. > 4) Create Lookups for Agreement and AgreementItems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Interesting behavior of use-when fields
Jacopo, I liked the second option i.e ... ... -- Ashish On Thu, Jun 5, 2008 at 6:06 AM, Scott Gray <[EMAIL PROTECTED]> wrote: > Hi Jacopo > > I just ran a quick test and Groovy seems to throw an error when an > undeclared variable is used. > > Scott > > 2008/6/5 Jacopo Cappellato <[EMAIL PROTECTED]>: > > > > > In fact for the Beanshell interpreter (by the way... should we consider > to > > use Groovy instead of Beanshell for the use-when scripts too?) an > undeclared > > variable is void but not null. > > >
[jira] Commented: (OFBIZ-1825) Colors and localisation for the calendar
[
https://issues.apache.org/jira/browse/OFBIZ-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603071#action_12603071
]
Ashish Vijaywargiya commented on OFBIZ-1825:
Proposition.jpg looks good to me instead of Existing one.
+1 for Proposition.jpg.
--
Ashish
> Colors and localisation for the calendar
>
>
> Key: OFBIZ-1825
> URL: https://issues.apache.org/jira/browse/OFBIZ-1825
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL COMPONENTS
>Affects Versions: SVN trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: SVN trunk
>
> Attachments: calendarDateSelectColor.patch,
> calendarDateSelectColor.patch, Existing.jpg, Proposition.jpg, WE_CAL.gif
>
>
> I tried to change the calendar colors, to be more "in the OFBiz way". Please
> let me you know what you think.
> I also changed some colors to respect our CSS best practices (no color names).
> Here are some remarks :
> Colors
> * I kept the 3 chars scheme when it's was obvious. For instance we don't
> need to set #00 or #ff when actually #000 or #fff is sufficient.
> * I used Wikipedia as reference http://en.wikipedia.org/wiki/Web_colors for
> choising colors. While doing this change I wondered if we could not authorise
> and even recommend to use sandard names for colors as shown in Wikipedia
> page. I found it easier to recall a color by its names than by an hexa
> number...! As long as we would use this Wikipedia reference I think it could
> be possible to use names instead of hexa, WDYT ?
> * The days initials are not centered but at left (It's late and I did not
> found the reason)
> We need to provide a localisation mean. From
> http://electronicholas.com/calendar?style=default&format=natural it should
> not be too hard. I propose a simple way, maybe we can do better
> * More calendar formats in a calendar.properties file (like the euro or
> american ones)
> * For the moment I think all string are harcoded in calendar_date_select.js
> Date.weekdays = $w("S M T W T F S");
> Date.first_day_of_week = 0;
> Date.months = $w("January February March April May June July August
> September October November December" );
> _translations = {
> "OK": "OK",
> "Now": "Now",
> "Today": "Today"
> }
> A very simple way (but not very clever I must admit) could be to set a
> property for the language to use in calendar.properties file and use it in a
> switch statement with "hardcoded" strings in calendar_date_select.js. Is
> anybody aware of better ways to do that in Javascript or Prototype ?
> BTW I think we should delete calendarstyles.css and calendarTable.css. If
> it's ok, I will do it when I will upate the attached patch later.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Discussion: Ajax Development
In the form widget something similar to what you describe exists. After the field elements you can have a sort-order element which has a sort-field element in it for each field in the order you want it. Those sort-field elements can be put inside a field-group element, and the field-group element has the typical id and style attributes on it for CSS styling of a group of fields. There are no conditions on the group, as conditions are on the individual fields right now, but we could add something as simple as a use-when attribute there or as complex as a condition element with the various conditional sub-elements under it like in a screen widget section. Unless we think those will be used a lot I like the idea of the use-when attribute more, BTW. -David On Jun 6, 2008, at 8:42 AM, Adrian Crum wrote: I've been thinking about this and I'm wondering if we need a container element for the form and menu widgets, only have it operate more like the section element - so you can have conditionals. That way you could group fields or menu items together, have the group displayed conditionally, and have them wrapped by the rendering classes so they can be updated by Ajax calls. -Adrian Anil Patel wrote: thinking on same lines, We should have a set of input boxes that get rendered to meet formating requirements, like For phone number, I'll like to have a form widget that will render countryCode, areaCode, contactNumber input boxes in one row separated by some character like "-". Similarly Date field may be required to be rendered in some cases. Or Credit Card numbers etc. Regards Anil Patel On Jun 3, 2008, at 5:07 AM, Jacopo Cappellato wrote: Here is my wish list: 1) when you select a value from a drop down box, automatically enable a new drop down box for the selection of further data available after the first selection is done; for example: you select the country, then you have the option to select the state- province in the country 2) when, using a lookup button you select an id (e.g. productId) another field (or label) is automatically populated with the descriptive content of the id (productName etc...) Jacopo On Jun 3, 2008, at 3:35 AM, Anil Patel wrote: I think we should Ajax/Effects enable widgets where possible. Like, Make Panels collapsable using Effects, Ajax enable Tree widget, Enhance Single form Layout to use div and css, Use Model panel for Lookup windows, Allow display fields to be inline editable etc. Regards Anil Patel On Jun 2, 2008, at 6:11 PM, Jacques Le Roux wrote: From: "Adrian Crum" <[EMAIL PROTECTED]> Al Byers wrote: I started a post to your reply that talked about what I would like to see and whatever, but as I got into it, I realized that this whole thing could get quite messy. As soon as you do anything that is "customer facing", I think you are going to lose people (like me) because what we do with widgets could never approach what their specific toolkit can do. Well, the discussion is about adding Ajax capabilities to the screen widgets - which aren't usually used in customer facing websites. I picture this effort as something simpler than the type of work you described. Let's add some bells and whistles to the screen widgets. The screen widget XML to do it shouldn't be overly complicated. In other words, add some fancy embellishments without a lot of extra coding. I just think the work of trying to add some common features that can be supported by all tool kits will not be useful because it will never go far enough. And it will be a lot of work that will not add much advantage over just working in the toolkit (this is particularly true of Dojo since it has an XML markup language that lets me mix it with the widget environment within .ftl files.) There has been talk of doing that with Dojo and another XML based library (I can't remember the name - Jacopo mentioned it). I suppose you tall about Apache XAP ? Jacques Thanks for the reply - I appreciate your input! -Adrian
Re: Freemarker Timestamp rendering - Developers Take Note
+1.
On Wed, Jun 4, 2008 at 7:48 PM, Adrian Crum <[EMAIL PROTECTED]> wrote:
> I just noticed in a Freemarker template file something like:
>
> ${someTimestamp.toString()}
>
> There is a problem with that. Freemarker will call the Timestamp object's
> toString() method - which will output the date and time in the server's time
> zone and locale, NOT the user's.
>
> It is better to eliminate the toString method call, like so:
>
> ${someTimestamp}
>
> -Adrian
>
Re: Discussion: Ajax Development
David, Thanks for the info. I was looking at the field-group element yesterday but I wasn't sure how it was used. Your explanation helps. I don't have a good example of using conditionals on groups of fields, but the menu widget would be a prime candidate. Think of the application menu and how groups of menu items are displayed depending on whether or not the user is logged in. There are other places where groups of menu items are dependent upon the user's permissions. Having one condition controlling the group would be better than having the same condition applied to every menu item. -Adrian David E Jones wrote: In the form widget something similar to what you describe exists. After the field elements you can have a sort-order element which has a sort-field element in it for each field in the order you want it. Those sort-field elements can be put inside a field-group element, and the field-group element has the typical id and style attributes on it for CSS styling of a group of fields. There are no conditions on the group, as conditions are on the individual fields right now, but we could add something as simple as a use-when attribute there or as complex as a condition element with the various conditional sub-elements under it like in a screen widget section. Unless we think those will be used a lot I like the idea of the use-when attribute more, BTW. -David On Jun 6, 2008, at 8:42 AM, Adrian Crum wrote: I've been thinking about this and I'm wondering if we need a container element for the form and menu widgets, only have it operate more like the section element - so you can have conditionals. That way you could group fields or menu items together, have the group displayed conditionally, and have them wrapped by the rendering classes so they can be updated by Ajax calls. -Adrian Anil Patel wrote: thinking on same lines, We should have a set of input boxes that get rendered to meet formating requirements, like For phone number, I'll like to have a form widget that will render countryCode, areaCode, contactNumber input boxes in one row separated by some character like "-". Similarly Date field may be required to be rendered in some cases. Or Credit Card numbers etc. Regards Anil Patel On Jun 3, 2008, at 5:07 AM, Jacopo Cappellato wrote: Here is my wish list: 1) when you select a value from a drop down box, automatically enable a new drop down box for the selection of further data available after the first selection is done; for example: you select the country, then you have the option to select the state-province in the country 2) when, using a lookup button you select an id (e.g. productId) another field (or label) is automatically populated with the descriptive content of the id (productName etc...) Jacopo On Jun 3, 2008, at 3:35 AM, Anil Patel wrote: I think we should Ajax/Effects enable widgets where possible. Like, Make Panels collapsable using Effects, Ajax enable Tree widget, Enhance Single form Layout to use div and css, Use Model panel for Lookup windows, Allow display fields to be inline editable etc. Regards Anil Patel On Jun 2, 2008, at 6:11 PM, Jacques Le Roux wrote: From: "Adrian Crum" <[EMAIL PROTECTED]> Al Byers wrote: I started a post to your reply that talked about what I would like to see and whatever, but as I got into it, I realized that this whole thing could get quite messy. As soon as you do anything that is "customer facing", I think you are going to lose people (like me) because what we do with widgets could never approach what their specific toolkit can do. Well, the discussion is about adding Ajax capabilities to the screen widgets - which aren't usually used in customer facing websites. I picture this effort as something simpler than the type of work you described. Let's add some bells and whistles to the screen widgets. The screen widget XML to do it shouldn't be overly complicated. In other words, add some fancy embellishments without a lot of extra coding. I just think the work of trying to add some common features that can be supported by all tool kits will not be useful because it will never go far enough. And it will be a lot of work that will not add much advantage over just working in the toolkit (this is particularly true of Dojo since it has an XML markup language that lets me mix it with the widget environment within .ftl files.) There has been talk of doing that with Dojo and another XML based library (I can't remember the name - Jacopo mentioned it). I suppose you tall about Apache XAP ? Jacques Thanks for the reply - I appreciate your input! -Adrian
Re: Discussion: Permissions Checking Enhancement
+1 Adrian I liked your idea. On Thu, Jun 5, 2008 at 12:46 AM, Sumit Pandit <[EMAIL PROTECTED]> wrote: > +1 >-- >Sumit Pandit > > > On Jun 5, 2008, at 3:04 AM, Jacques Le Roux wrote: > > Yes this sounds good to me too >> >> Jacques >> >> From: "Bruno Busco" <[EMAIL PROTECTED]> >> >>> Wonderfull >>> Looking forward to having it !!! ;-) >>> This will let me also define a more granular permissions to simplify the >>> interface for not-so-skilled users. >>> -Bruno >>> 2008/6/4 Adrian Crum <[EMAIL PROTECTED]>: >>> In the screen widgets, you can check permissions with the or elements. That's fine if you only need to check a single permission to control access to the entire screen. Things get complicated when a screen's elements are controlled by more than one permission. Let's say you have a typical Edit Item screen. The screen should be viewable only to users who have the VIEW permission. Users who have the UPDATE permission can edit the item. Users who have the CREATE permission see a "New Item" button. Users who have DELETE permission see a "Delete Item" button. Users who have the ADMIN permission have unrestricted access to the screen. Wow. Five permission elements (and five service calls) are needed to control one screen. Here's my idea: have a permission service that returns ALL of the user's permissions in a Map. You call the service with the permission to check - "ACCOUNTING" for example. The service returns a Map containing all of the user's ACCOUNTING permissions stored as Boolean objects. Let's say the returned Map is called permissionsMap and the user has ACCOUNTING_VIEW and ACCOUNTING_UPDATE permissions, then the Map would contain these elements: CREATE=false UPDATE=true DELETE=false VIEW=true ADMIN=false If the service call is put in the screen's element, then the Map elements could be used to control the display of screen widget sections, menu items, and form fields. Freemarker code would be simpler too: <#if permissionsMap.CREATE> <#if permissionsMap.DELETE> What do you think? -Adrian >>> >
Re: Managing the status for non serialized inventory items
+1. On Thu, Jun 5, 2008 at 12:10 AM, Sumit Pandit <[EMAIL PROTECTED]> wrote: > +1 > > > > On Jun 5, 2008, at 12:36 AM, Jacopo Cappellato wrote: > > >> On Jun 4, 2008, at 8:13 PM, David E Jones wrote: >> >> >>> On Jun 4, 2008, at 8:35 AM, Jacopo Cappellato wrote: >>> >>> Hi all, I would like to add support for the status for non serialized inventory items (right now the status is used only for serialized items). The idea is to add a new status item for "Damaged" inventory (and maybe "On Hold" for inventory under inspection); the inventory items with this status will be excluded by the inventory counting algorithm and also by the inventory reservation service. The main goal is to add the ability to keep into the warehouse non serialized inventory items but don't use them in orders etc... (at least until they are fixed), but don't just remove them from the system (as it happens when you do a manual inventory variance). What do you think? Can I go on with this? >>> >>> It's an interesting idea. Right now all damaged/held/etc inventory is >>> treated per unit, ie as serialized inventory. When returns are received each >>> item is evaluated individually and tracked that way. >>> >>> If I understand where you are coming from, this becomes a problem when >>> you receive 1000 damaged widgets and would have to create a record for each >>> one. >>> >>> >> Yes, this is the exactly the scenario I have in mind. >> And maybe another one could be this: I have the suspect that the items in >> an inventory item could be damaged and I schedule an inspection... in the >> meantime I want to make sure the items are not reserved for new orders; so I >> change the status to "On Hold" until the inspection is done. >> >> Thanks, >> >> Jacopo >> >> >> With that in mind, perhaps this might be a good way to make the >>> management easier without any data structure change, though there could be a >>> number of code changes needed. >>> >>> -David >>> >>> >>> >> >
Re: Discussion: Permissions Checking Enhancement
I'll work on it this weekend. -Adrian Ashish Vijaywargiya wrote: +1 Adrian I liked your idea. On Thu, Jun 5, 2008 at 12:46 AM, Sumit Pandit <[EMAIL PROTECTED]> wrote: +1 -- Sumit Pandit On Jun 5, 2008, at 3:04 AM, Jacques Le Roux wrote: Yes this sounds good to me too Jacques From: "Bruno Busco" <[EMAIL PROTECTED]> Wonderfull Looking forward to having it !!! ;-) This will let me also define a more granular permissions to simplify the interface for not-so-skilled users. -Bruno 2008/6/4 Adrian Crum <[EMAIL PROTECTED]>: In the screen widgets, you can check permissions with the or elements. That's fine if you only need to check a single permission to control access to the entire screen. Things get complicated when a screen's elements are controlled by more than one permission. Let's say you have a typical Edit Item screen. The screen should be viewable only to users who have the VIEW permission. Users who have the UPDATE permission can edit the item. Users who have the CREATE permission see a "New Item" button. Users who have DELETE permission see a "Delete Item" button. Users who have the ADMIN permission have unrestricted access to the screen. Wow. Five permission elements (and five service calls) are needed to control one screen. Here's my idea: have a permission service that returns ALL of the user's permissions in a Map. You call the service with the permission to check - "ACCOUNTING" for example. The service returns a Map containing all of the user's ACCOUNTING permissions stored as Boolean objects. Let's say the returned Map is called permissionsMap and the user has ACCOUNTING_VIEW and ACCOUNTING_UPDATE permissions, then the Map would contain these elements: CREATE=false UPDATE=true DELETE=false VIEW=true ADMIN=false If the service call is put in the screen's element, then the Map elements could be used to control the display of screen widget sections, menu items, and form fields. Freemarker code would be simpler too: <#if permissionsMap.CREATE> <#if permissionsMap.DELETE> What do you think? -Adrian
Re: svn commit: r661450 - in /ofbiz/trunk/framework: common/webcommon/includes/ example/webapp/example/WEB-INF/actions/includes/ example/widget/example/ images/webapp/images/ widget/dtd/ widget/src/or
Adrian,
This commit along with svn #661345 is a great enhancement. I have a
feeling that its too generic. Like name of Sub element "on-field-
event-update-area" kind of tells me that on certain event, certain
area of screen will be updated. Like I select country code and list of
states will be updated, Something that can be otherwise called
"Partial Form Refresh (submission)". There can be various ways of this
generic element.
The way its implemented in this commit is very specialized use. On
change in textbox a dropdown appears and user can navigate in that
list and select a option. This is a clearly a very specialized
handling of form event and expected user Interaction. Unless somebody
looks at the implementation code its hard figure out.
I think we should add a sub element and this
element can have attributes and sub elements that we may need to pass
to the Ajax.Autocompleter control of Script.Aculo.us.
And for element we should be able to pass
in name of event handler function name. Developer can use such event
listeners to implement custom stuff.
Please ask questions if I am not clear enough. I'll like to clear this
asap because this is holding me up with my current project.
Thanks and Regards
Anil Patel
On May 29, 2008, at 3:48 PM, [EMAIL PROTECTED] wrote:
Author: adrianc
Date: Thu May 29 12:48:24 2008
New Revision: 661450
URL: http://svn.apache.org/viewvc?rev=661450&view=rev
Log:
Form widget Ajax refinements.
Changed attribute-based ajax calls to on-event-update-area elements.
Fixed bug in autocomplete. Cleaned up some of the rendering code.
Modified:
ofbiz/trunk/framework/common/webcommon/includes/
ajaxAutocompleteOptions.ftl
ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/
includes/findExampleFeatures.bsh
ofbiz/trunk/framework/example/widget/example/ExampleForms.xml
ofbiz/trunk/framework/images/webapp/images/selectall.js
ofbiz/trunk/framework/widget/dtd/widget-form.xsd
ofbiz/trunk/framework/widget/src/org/ofbiz/widget/form/
ModelFormField.java
ofbiz/trunk/framework/widget/src/org/ofbiz/widget/html/
HtmlFormRenderer.java
ofbiz/trunk/framework/widget/src/org/ofbiz/widget/html/
HtmlWidgetRenderer.java
Modified: ofbiz/trunk/framework/common/webcommon/includes/
ajaxAutocompleteOptions.ftl
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/webcommon/includes/ajaxAutocompleteOptions.ftl?rev=661450&r1=661449&r2=661450&view=diff
=
=
=
=
=
=
=
=
==
--- ofbiz/trunk/framework/common/webcommon/includes/
ajaxAutocompleteOptions.ftl (original)
+++ ofbiz/trunk/framework/common/webcommon/includes/
ajaxAutocompleteOptions.ftl Thu May 29 12:48:24 2008
@@ -17,9 +17,11 @@
under the License.
-->
-
- <#list autocompleteOptions as autocompleteOption>
- <#assign fields = autocompleteOption.values()/>
-<#list fields as field><#if field_index == 1>class="informal"> ${field}<#if (field_index > 0)><#if
field_has_next> <#else>
-
-
\ No newline at end of file
+<#if autocompleteOptions?exists>
+
+<#list autocompleteOptions as autocompleteOption>
+ <#assign fields = autocompleteOption.values()/>
+ <#list fields as field><#if field_index == 1>class="informal"> ${field}<#if (field_index > 0)><#if
field_has_next> <#else>
+
+
+
Modified: ofbiz/trunk/framework/example/webapp/example/WEB-INF/
actions/includes/findExampleFeatures.bsh
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/includes/findExampleFeatures.bsh?rev=661450&r1=661449&r2=661450&view=diff
=
=
=
=
=
=
=
=
==
--- ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/
includes/findExampleFeatures.bsh (original)
+++ ofbiz/trunk/framework/example/webapp/example/WEB-INF/actions/
includes/findExampleFeatures.bsh Thu May 29 12:48:24 2008
@@ -19,6 +19,7 @@
import java.util.TreeSet;
import javolution.util.FastList;
+import org.ofbiz.entity.condition.EntityCondition;
import org.ofbiz.entity.condition.EntityConditionList;
import org.ofbiz.entity.condition.EntityExpr;
import org.ofbiz.entity.condition.EntityFieldValue;
Modified: ofbiz/trunk/framework/example/widget/example/
ExampleForms.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/example/widget/example/ExampleForms.xml?rev=661450&r1=661449&r2=661450&view=diff
=
=
=
=
=
=
=
=
==
--- ofbiz/trunk/framework/example/widget/example/ExampleForms.xml
(original)
+++ ofbiz/trunk/framework/example/widget/example/ExampleForms.xml
Thu May 29 12:48:24 2008
@@ -173,7 +173,10 @@
target="example_createExampleFeatureAppl" title="">
-name="exampleFeatureId">target="findExampleFeatures">
+
+
+id="exampleFeatureId" area
Re: Discussion: Permissions Checking Enhancement
Adrian, may be a newbie question but... ...in the example you give what will happen if a user has the ADMIN permission but not the CREATE one? Will the Create New button be rendered? In other words who is responsible for the permission hierarchy ? In order to display the CREATE button, should a user be given with the CREATE permission explicitly or the ADMIN is sufficient? Thank you -Bruno 2008/6/6 Adrian Crum <[EMAIL PROTECTED]>: > I'll work on it this weekend. > > -Adrian > > > Ashish Vijaywargiya wrote: > >> +1 >> Adrian I liked your idea. >> >> On Thu, Jun 5, 2008 at 12:46 AM, Sumit Pandit < >> [EMAIL PROTECTED]> >> wrote: >> >> +1 >>> -- >>> Sumit Pandit >>> >>> >>> On Jun 5, 2008, at 3:04 AM, Jacques Le Roux wrote: >>> >>> Yes this sounds good to me too >>> Jacques From: "Bruno Busco" <[EMAIL PROTECTED]> Wonderfull > Looking forward to having it !!! ;-) > This will let me also define a more granular permissions to simplify > the > interface for not-so-skilled users. > -Bruno > 2008/6/4 Adrian Crum <[EMAIL PROTECTED]>: > > In the screen widgets, you can check permissions with the >> or elements. That's fine >> if >> you >> only need to check a single permission to control access to the entire >> screen. >> >> Things get complicated when a screen's elements are controlled by more >> than >> one permission. Let's say you have a typical Edit Item screen. The >> screen >> should be viewable only to users who have the VIEW permission. Users >> who >> have the UPDATE permission can edit the item. Users who have the >> CREATE >> permission see a "New Item" button. Users who have DELETE permission >> see >> a >> "Delete Item" button. Users who have the ADMIN permission have >> unrestricted >> access to the screen. Wow. Five permission elements (and five service >> calls) >> are needed to control one screen. >> >> >> Here's my idea: have a permission service that returns ALL of the >> user's >> permissions in a Map. You call the service with the permission to >> check >> - >> "ACCOUNTING" for example. The service returns a Map containing all of >> the >> user's ACCOUNTING permissions stored as Boolean objects. Let's say the >> returned Map is called permissionsMap and the user has ACCOUNTING_VIEW >> and >> ACCOUNTING_UPDATE permissions, then the Map would contain these >> elements: >> >> CREATE=false >> UPDATE=true >> DELETE=false >> VIEW=true >> ADMIN=false >> >> If the service call is put in the screen's element, then the >> Map >> elements could be used to control the display of screen widget >> sections, >> menu items, and form fields. >> >> Freemarker code would be simpler too: >> >> <#if permissionsMap.CREATE> >> >> >> <#if permissionsMap.DELETE> >> >> >> >> What do you think? >> >> -Adrian >> >> >> >>
Re: svn commit: r664048 - in /ofbiz/trunk/framework: entity/fieldtype/ shark/ shark/config/ shark/entitydef/ shark/src/org/enhydra/shark/ shark/src/org/ofbiz/shark/container/ shark/src/org/ofbiz/shark
This seems to need some more review... At the very least do NOT change the entity engine or other more critical/used framework pieces without careful review. In this case the "long" field type is really unnecessary and should not be added to OFBiz, the existing numeric type should be used instead. There may be other issues, but that one took about 10 seconds to spot... -David On Jun 6, 2008, at 11:32 AM, [EMAIL PROTECTED] wrote: Author: jleroux Date: Fri Jun 6 10:32:55 2008 New Revision: 664048 URL: http://svn.apache.org/viewvc?rev=664048&view=rev Log: Last patch (forgotten for more than one year) from Sergey Shutov "Integration Shark 1.1_2 into OfBiz" (https://issues.apache.org/jira/browse/OFBIZ-552 ) - OFBIZ-552 Added: ofbiz/trunk/framework/shark/config/SharkUiLabels.properties (with props) ofbiz/trunk/framework/shark/config/SharkUiLabels_it.properties (with props) Modified: ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypecloudscape.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypedaffodil.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypederby.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypefirebird.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypehsql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypemssql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypemysql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypeoracle.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypepostgres.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypesapdb.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypesybase.xml ofbiz/trunk/framework/shark/build.xml ofbiz/trunk/framework/shark/entitydef/entitymodel.xml ofbiz/trunk/framework/shark/src/org/enhydra/shark/ ThreadedToolAgentManager.java ofbiz/trunk/framework/shark/src/org/ofbiz/shark/container/ SharkContainer.java ofbiz/trunk/framework/shark/src/org/ofbiz/shark/repository/ EntityRepositoryMgr.java ofbiz/trunk/framework/shark/webapp/shark/WEB-INF/controller.xml ofbiz/trunk/framework/shark/widget/TaskListScreens.xml Modified: ofbiz/trunk/framework/entity/fieldtype/ fieldtypeadvantage.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml?rev=664048&r1=664047&r2=664048&view=diff = = = = = = = = == --- ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml (original) +++ ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml Fri Jun 6 10:32:55 2008 @@ -30,6 +30,7 @@ type="java.sql.Timestamp"> type="java.sql.Date"> type="java.sql.Time"> +type="java.lang.Long">def> type="Double"> type="Double"> Modified: ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml?rev=664048&r1=664047&r2=664048&view=diff = = = = = = = = == --- ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml (original) +++ ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml Fri Jun 6 10:32:55 2008 @@ -27,6 +27,7 @@ type="java.sql.Timestamp"> type="java.sql.Date"> type="java.sql.Time"> +type="java.lang.Long">def> java-type="Double">def> java-type="Double">def> @@ -60,3 +61,4 @@ + Modified: ofbiz/trunk/framework/entity/fieldtype/ fieldtypecloudscape.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/fieldtype/fieldtypecloudscape.xml?rev=664048&r1=664047&r2=664048&view=diff = = = = = = = = == --- ofbiz/trunk/framework/entity/fieldtype/fieldtypecloudscape.xml (original) +++ ofbiz/trunk/framework/entity/fieldtype/fieldtypecloudscape.xml Fri Jun 6 10:32:55 2008 @@ -27,6 +27,7 @@ type="java.sql.Timestamp"> type="java.sql.Date"> type="java.sql.Time"> +type="java.lang.Long">def> java-type="Double">def> java-type="Double">def> Modified: ofbiz/trunk/framework/entity/fieldtype/fieldtypedaffodil.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/fieldtype/fieldtypedaffodil.xml?rev=664048&r1=664047&r2=664048&view=diff = = = = = = = = == --- ofbiz/trunk/framework/entity/fieldtype/fieldtypedaffodil.xml (original) +++ ofbiz/trunk/framework/entity/fieldtype/fieldtypedaffodil.xml Fri Jun 6 10:32:55 2008 @@ -27,6 +27,7 @@ type="java.sql.Timestamp"> type="java.sql.Date"> type="java.sql.Time"> +type="java.lang.Long">def> java-type="Double">def> java-type="Double">def> Modified: ofbiz/trunk/framework/entity/fieldtype/fieldtypederby.xml URL: http://svn.apache.org/vi
[jira] Closed: (OFBIZ-552) Integration Shark 1.1_2 into OfBiz
[ https://issues.apache.org/jira/browse/OFBIZ-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-552. - Resolution: Fixed Fix Version/s: Release Branch 4.0 SVN trunk Assignee: Jacques Le Roux I applied the last patch in trunk revision: 664048 and release4.0 664052. In the patch there was some uilabels.properties files. I commited them all and removed after the Italian one since its labels were already in SharkUILabels.xml (but I have no ideas how this is possible, maybe Marco did it by hand ?). The labels of SharkUiLabels_ru.properties are not integrated in SharkUILabels.xml that why I let the file in. > Integration Shark 1.1_2 into OfBiz > -- > > Key: OFBIZ-552 > URL: https://issues.apache.org/jira/browse/OFBIZ-552 > Project: OFBiz > Issue Type: New Feature > Components: framework >Reporter: Sergey Shutov >Assignee: Jacques Le Roux > Fix For: SVN trunk, Release Branch 4.0 > > Attachments: EntityPersistentMgr.java.patch, example.xpdl, > shark_2.diff, shark_2.diff, shark_2.diff, shark_2.diff, shark_2~tabs.diff, > versioned_shark_jars.zip > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Discussion: Permissions Checking Enhancement
The pattern used so far is that the ADMIN permission is checked first, then the other permissions. So if a user has the ADMIN permission, they don't need the additional permissions. I'll probably have all of the permissions Map elements set to true if the user has the ADMIN permission. -Adrian Bruno Busco wrote: Adrian, may be a newbie question but... ...in the example you give what will happen if a user has the ADMIN permission but not the CREATE one? Will the Create New button be rendered? In other words who is responsible for the permission hierarchy ? In order to display the CREATE button, should a user be given with the CREATE permission explicitly or the ADMIN is sufficient? Thank you -Bruno 2008/6/6 Adrian Crum <[EMAIL PROTECTED]>: I'll work on it this weekend. -Adrian Ashish Vijaywargiya wrote: +1 Adrian I liked your idea. On Thu, Jun 5, 2008 at 12:46 AM, Sumit Pandit < [EMAIL PROTECTED]> wrote: +1 -- Sumit Pandit On Jun 5, 2008, at 3:04 AM, Jacques Le Roux wrote: Yes this sounds good to me too Jacques From: "Bruno Busco" <[EMAIL PROTECTED]> Wonderfull Looking forward to having it !!! ;-) This will let me also define a more granular permissions to simplify the interface for not-so-skilled users. -Bruno 2008/6/4 Adrian Crum <[EMAIL PROTECTED]>: In the screen widgets, you can check permissions with the or elements. That's fine if you only need to check a single permission to control access to the entire screen. Things get complicated when a screen's elements are controlled by more than one permission. Let's say you have a typical Edit Item screen. The screen should be viewable only to users who have the VIEW permission. Users who have the UPDATE permission can edit the item. Users who have the CREATE permission see a "New Item" button. Users who have DELETE permission see a "Delete Item" button. Users who have the ADMIN permission have unrestricted access to the screen. Wow. Five permission elements (and five service calls) are needed to control one screen. Here's my idea: have a permission service that returns ALL of the user's permissions in a Map. You call the service with the permission to check - "ACCOUNTING" for example. The service returns a Map containing all of the user's ACCOUNTING permissions stored as Boolean objects. Let's say the returned Map is called permissionsMap and the user has ACCOUNTING_VIEW and ACCOUNTING_UPDATE permissions, then the Map would contain these elements: CREATE=false UPDATE=true DELETE=false VIEW=true ADMIN=false If the service call is put in the screen's element, then the Map elements could be used to control the display of screen widget sections, menu items, and form fields. Freemarker code would be simpler too: <#if permissionsMap.CREATE> <#if permissionsMap.DELETE> What do you think? -Adrian
Re: svn commit: r661450 - in /ofbiz/trunk/framework: common/webcommon/includes/ example/webapp/example/WEB-INF/actions/includes/ example/widget/example/ images/webapp/images/ widget/dtd/ widget/src/or
Anil Patel wrote: The way its implemented in this commit is very specialized use. On change in textbox a dropdown appears and user can navigate in that list and select a option. This is a clearly a very specialized handling of form event and expected user Interaction. Unless somebody looks at the implementation code its hard figure out. I think we should add a sub element and this element can have attributes and sub elements that we may need to pass to the Ajax.Autocompleter control of Script.Aculo.us. That sounds good to me. My main objection to the original implementation was the use of attributes - so an additional sub element would be fine. And for element we should be able to pass in name of event handler function name. Developer can use such event listeners to implement custom stuff. I'd have to see an example. I'm not sure what you mean here. -Adrian
Re: Discussion: Permissions Checking Enhancement
Thank you, it make sense; so a CREATE permission check will be sufficient for the CREATE button rendering. -Bruno 2008/6/6 Adrian Crum <[EMAIL PROTECTED]>: > The pattern used so far is that the ADMIN permission is checked first, then > the other permissions. So if a user has the ADMIN permission, they don't > need the additional permissions. > > I'll probably have all of the permissions Map elements set to true if the > user has the ADMIN permission. > > -Adrian > > > Bruno Busco wrote: > >> Adrian, >> may be a newbie question but... >> ...in the example you give what will happen if a user has the ADMIN >> permission but not the CREATE one? >> Will the Create New button be rendered? >> >> In other words who is responsible for the permission hierarchy ? >> In order to display the CREATE button, should a user be given with the >> CREATE permission explicitly or the ADMIN is sufficient? >> >> Thank you >> -Bruno >> >> >> >> 2008/6/6 Adrian Crum <[EMAIL PROTECTED]>: >> >> I'll work on it this weekend. >>> >>> -Adrian >>> >>> >>> Ashish Vijaywargiya wrote: >>> >>> +1 Adrian I liked your idea. On Thu, Jun 5, 2008 at 12:46 AM, Sumit Pandit < [EMAIL PROTECTED]> wrote: +1 > -- > Sumit Pandit > > > On Jun 5, 2008, at 3:04 AM, Jacques Le Roux wrote: > > Yes this sounds good to me too > > Jacques >> >> From: "Bruno Busco" <[EMAIL PROTECTED]> >> >> Wonderfull >> >>> Looking forward to having it !!! ;-) >>> This will let me also define a more granular permissions to simplify >>> the >>> interface for not-so-skilled users. >>> -Bruno >>> 2008/6/4 Adrian Crum <[EMAIL PROTECTED]>: >>> >>> In the screen widgets, you can check permissions with the >>> or elements. That's fine if you only need to check a single permission to control access to the entire screen. Things get complicated when a screen's elements are controlled by more than one permission. Let's say you have a typical Edit Item screen. The screen should be viewable only to users who have the VIEW permission. Users who have the UPDATE permission can edit the item. Users who have the CREATE permission see a "New Item" button. Users who have DELETE permission see a "Delete Item" button. Users who have the ADMIN permission have unrestricted access to the screen. Wow. Five permission elements (and five service calls) are needed to control one screen. Here's my idea: have a permission service that returns ALL of the user's permissions in a Map. You call the service with the permission to check - "ACCOUNTING" for example. The service returns a Map containing all of the user's ACCOUNTING permissions stored as Boolean objects. Let's say the returned Map is called permissionsMap and the user has ACCOUNTING_VIEW and ACCOUNTING_UPDATE permissions, then the Map would contain these elements: CREATE=false UPDATE=true DELETE=false VIEW=true ADMIN=false If the service call is put in the screen's element, then the Map elements could be used to control the display of screen widget sections, menu items, and form fields. Freemarker code would be simpler too: <#if permissionsMap.CREATE> <#if permissionsMap.DELETE> What do you think? -Adrian >>
Re: Discussion: Permissions Checking Enhancement
Correct. Bruno Busco wrote: Thank you, it make sense; so a CREATE permission check will be sufficient for the CREATE button rendering. -Bruno 2008/6/6 Adrian Crum <[EMAIL PROTECTED]>: The pattern used so far is that the ADMIN permission is checked first, then the other permissions. So if a user has the ADMIN permission, they don't need the additional permissions. I'll probably have all of the permissions Map elements set to true if the user has the ADMIN permission. -Adrian Bruno Busco wrote: Adrian, may be a newbie question but... ...in the example you give what will happen if a user has the ADMIN permission but not the CREATE one? Will the Create New button be rendered? In other words who is responsible for the permission hierarchy ? In order to display the CREATE button, should a user be given with the CREATE permission explicitly or the ADMIN is sufficient? Thank you -Bruno 2008/6/6 Adrian Crum <[EMAIL PROTECTED]>: I'll work on it this weekend. -Adrian Ashish Vijaywargiya wrote: +1 Adrian I liked your idea. On Thu, Jun 5, 2008 at 12:46 AM, Sumit Pandit < [EMAIL PROTECTED]> wrote: +1 -- Sumit Pandit On Jun 5, 2008, at 3:04 AM, Jacques Le Roux wrote: Yes this sounds good to me too Jacques From: "Bruno Busco" <[EMAIL PROTECTED]> Wonderfull Looking forward to having it !!! ;-) This will let me also define a more granular permissions to simplify the interface for not-so-skilled users. -Bruno 2008/6/4 Adrian Crum <[EMAIL PROTECTED]>: In the screen widgets, you can check permissions with the or elements. That's fine if you only need to check a single permission to control access to the entire screen. Things get complicated when a screen's elements are controlled by more than one permission. Let's say you have a typical Edit Item screen. The screen should be viewable only to users who have the VIEW permission. Users who have the UPDATE permission can edit the item. Users who have the CREATE permission see a "New Item" button. Users who have DELETE permission see a "Delete Item" button. Users who have the ADMIN permission have unrestricted access to the screen. Wow. Five permission elements (and five service calls) are needed to control one screen. Here's my idea: have a permission service that returns ALL of the user's permissions in a Map. You call the service with the permission to check - "ACCOUNTING" for example. The service returns a Map containing all of the user's ACCOUNTING permissions stored as Boolean objects. Let's say the returned Map is called permissionsMap and the user has ACCOUNTING_VIEW and ACCOUNTING_UPDATE permissions, then the Map would contain these elements: CREATE=false UPDATE=true DELETE=false VIEW=true ADMIN=false If the service call is put in the screen's element, then the Map elements could be used to control the display of screen widget sections, menu items, and form fields. Freemarker code would be simpler too: <#if permissionsMap.CREATE> <#if permissionsMap.DELETE> What do you think? -Adrian
Re: svn commit: r661450 - in /ofbiz/trunk/framework: common/webcommon/includes/ example/webapp/example/WEB-INF/actions/includes/ example/widget/example/ images/webapp/images/ widget/dtd/ widget/src/or
I agree with Anil that there may be many different types of on-field- event-update-area If we want to keep things simple we may just add some attributes to the on-field-event-update-area element; for example: id="exampleFeatureId" area-target="findExampleFeatures" type="text- server-autocomplete"/> Just my 2 cents, Jacopo I'm sorry if I am saying something that is not in the c On Jun 6, 2008, at 7:58 PM, Adrian Crum wrote: Anil Patel wrote: The way its implemented in this commit is very specialized use. On change in textbox a dropdown appears and user can navigate in that list and select a option. This is a clearly a very specialized handling of form event and expected user Interaction. Unless somebody looks at the implementation code its hard figure out. I think we should add a sub element and this element can have attributes and sub elements that we may need to pass to the Ajax.Autocompleter control of Script.Aculo.us. That sounds good to me. My main objection to the original implementation was the use of attributes - so an additional sub element would be fine. And for element we should be able to pass in name of event handler function name. Developer can use such event listeners to implement custom stuff. I'd have to see an example. I'm not sure what you mean here. -Adrian
Re: svn commit: r664048 - in /ofbiz/trunk/framework: entity/fieldtype/ shark/ shark/config/ shark/entitydef/ shark/src/org/enhydra/shark/ shark/src/org/ofbiz/shark/container/ shark/src/org/ofbiz/shark
David, My conclusion to commit as is came from the last comment of these 3 (in order) https://issues.apache.org/jira/browse/OFBIZ-552?focusedCommentId=12467679#action_12467679 https://issues.apache.org/jira/browse/OFBIZ-552?focusedCommentId=12467749#action_12467749 https://issues.apache.org/jira/browse/OFBIZ-552?focusedCommentId=12478407#action_12478407 BTW, note this interesting topic : http://archives.postgresql.org/pgsql-interfaces/2000-01/msg00202.php So I thought that, even if the long name is not totally appropriate (but after all it's a name and only a name, we may call it numeric-long if we prefer) and even if later it turns that we have to increase above (19,0) (which was roughly retained by Sergey because it was the following number, I guess), this was a good start. Jacques From: "David E Jones" <[EMAIL PROTECTED]> This seems to need some more review... At the very least do NOT change the entity engine or other more critical/used framework pieces without careful review. In this case the "long" field type is really unnecessary and should not be added to OFBiz, the existing numeric type should be used instead. There may be other issues, but that one took about 10 seconds to spot... -David On Jun 6, 2008, at 11:32 AM, [EMAIL PROTECTED] wrote: Author: jleroux Date: Fri Jun 6 10:32:55 2008 New Revision: 664048 URL: http://svn.apache.org/viewvc?rev=664048&view=rev Log: Last patch (forgotten for more than one year) from Sergey Shutov "Integration Shark 1.1_2 into OfBiz" (https://issues.apache.org/jira/browse/OFBIZ-552 ) - OFBIZ-552 Added: ofbiz/trunk/framework/shark/config/SharkUiLabels.properties(with props) ofbiz/trunk/framework/shark/config/SharkUiLabels_it.properties(with props) Modified: ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypecloudscape.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypedaffodil.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypederby.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypefirebird.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypehsql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypemssql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypemysql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypeoracle.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypepostgres.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypesapdb.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypesybase.xml ofbiz/trunk/framework/shark/build.xml ofbiz/trunk/framework/shark/entitydef/entitymodel.xml ofbiz/trunk/framework/shark/src/org/enhydra/shark/ ThreadedToolAgentManager.java ofbiz/trunk/framework/shark/src/org/ofbiz/shark/container/ SharkContainer.java ofbiz/trunk/framework/shark/src/org/ofbiz/shark/repository/ EntityRepositoryMgr.java ofbiz/trunk/framework/shark/webapp/shark/WEB-INF/controller.xml ofbiz/trunk/framework/shark/widget/TaskListScreens.xml Modified: ofbiz/trunk/framework/entity/fieldtype/ fieldtypeadvantage.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml?rev=664048&r1=664047&r2=664048&view=diff = = = = = = = = == --- ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml (original) +++ ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml Fri Jun 6 10:32:55 2008 @@ -30,6 +30,7 @@ +def> /> /> Modified: ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml?rev=664048&r1=664047&r2=664048&view=diff = = = = = = = = == --- ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml (original) +++ ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml Fri Jun 6 10:32:55 2008 @@ -27,6 +27,7 @@ +/> /> /> @@ -60,3 +61,4 @@ + Modified: ofbiz/trunk/framework/entity/fieldtype/ fieldtypecloudscape.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/fieldtype/fieldtypecloudscape.xml?rev=664048&r1=664047&r2=664048&view=diff = = = = = = = = == --- ofbiz/trunk/framework/entity/fieldtype/fieldtypecloudscape.xml (original) +++ ofbiz/trunk/framework/entity/fieldtype/fieldtypecloudscape.xml Fri Jun 6 10:32:55 2008 @@ -27,6 +27,7 @@ +/> /> /> Modified: ofbiz/trunk/framework/entity/fieldtype/fieldtypedaffodil.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/fieldtype/fieldtypedaffodil.xml?rev=664048&r1=664047&r2=664048&view=diff = = = = = = = = == --- ofbiz/trunk/framework/entity/fie
Re: svn commit: r664048 - in /ofbiz/trunk/framework: entity/fieldtype/ shark/ shark/config/ shark/entitydef/ shark/src/org/enhydra/shark/ shark/src/org/ofbiz/shark/container/ shark/src/org/ofbiz/shark
I'm happy to go remove it myself... just let me know. The point of a data dictionary is to keep things pretty minimal so that it is fairly easy to remember the options and know what each option means in Java and the physical database. At the minute the "long" and "numeric" values are pretty redundant since long is a NUMERIC(19,0) and numeric is a NUMERIC(18,0). Is having one additional digit a sufficient reason to create a whole new type? -David On Jun 6, 2008, at 2:42 PM, Jacques Le Roux wrote: David, My conclusion to commit as is came from the last comment of these 3 (in order) https://issues.apache.org/jira/browse/OFBIZ-552?focusedCommentId=12467679 #action_12467679 https://issues.apache.org/jira/browse/OFBIZ-552?focusedCommentId=12467749 #action_12467749 https://issues.apache.org/jira/browse/OFBIZ-552?focusedCommentId=12478407 #action_12478407 BTW, note this interesting topic : http://archives.postgresql.org/pgsql-interfaces/2000-01/msg00202.php So I thought that, even if the long name is not totally appropriate (but after all it's a name and only a name, we may call it numeric- long if we prefer) and even if later it turns that we have to increase above (19,0) (which was roughly retained by Sergey because it was the following number, I guess), this was a good start. Jacques From: "David E Jones" <[EMAIL PROTECTED]> This seems to need some more review... At the very least do NOT change the entity engine or other more critical/used framework pieces without careful review. In this case the "long" field type is really unnecessary and should not be added to OFBiz, the existing numeric type should be used instead. There may be other issues, but that one took about 10 seconds to spot... -David On Jun 6, 2008, at 11:32 AM, [EMAIL PROTECTED] wrote: Author: jleroux Date: Fri Jun 6 10:32:55 2008 New Revision: 664048 URL: http://svn.apache.org/viewvc?rev=664048&view=rev Log: Last patch (forgotten for more than one year) from Sergey Shutov "Integration Shark 1.1_2 into OfBiz" (https://issues.apache.org/jira/browse/OFBIZ-552 ) - OFBIZ-552 Added: ofbiz/trunk/framework/shark/config/SharkUiLabels.properties (with props) ofbiz/trunk/framework/shark/config/ SharkUiLabels_it.properties(with props) Modified: ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypecloudscape.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypedaffodil.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypederby.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypefirebird.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypehsql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypemssql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypemysql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypeoracle.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypepostgres.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypesapdb.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypesybase.xml ofbiz/trunk/framework/shark/build.xml ofbiz/trunk/framework/shark/entitydef/entitymodel.xml ofbiz/trunk/framework/shark/src/org/enhydra/shark/ ThreadedToolAgentManager.java ofbiz/trunk/framework/shark/src/org/ofbiz/shark/container/ SharkContainer.java ofbiz/trunk/framework/shark/src/org/ofbiz/shark/repository/ EntityRepositoryMgr.java ofbiz/trunk/framework/shark/webapp/shark/WEB-INF/controller.xml ofbiz/trunk/framework/shark/widget/TaskListScreens.xml Modified: ofbiz/trunk/framework/entity/fieldtype/ fieldtypeadvantage.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml?rev=664048&r1=664047&r2=664048&view=diff = = = = = = = = = = --- ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml (original) +++ ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml Fri Jun 6 10:32:55 2008 @@ -30,6 +30,7 @@ type="java.sql.Timestamp"> type="java.sql.Date"> type="java.sql.Time"> +type="java.lang.Long">type- def> type="Double"> type="Double"> Modified: ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml?rev=664048&r1=664047&r2=664048&view=diff = = = = = = = = = = --- ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml (original) +++ ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml Fri Jun 6 10:32:55 2008 @@ -27,6 +27,7 @@ type="java.sql.Timestamp"> type="java.sql.Date"> type="java.sql.Time"> +type="java.lang.Long">type- def> java-type="Double">type- def> type="NUMBER(18,3)" java-type="Double">method="isSignedDouble" /> @@ -60,3 +61,4 @@ + Modified: ofbiz/
Re: Interesting behavior of use-when fields
I like it too, but what about Groovy from Scott's experience ? Jacques From: "Ashish Vijaywargiya" <[EMAIL PROTECTED]> Jacopo, I liked the second option i.e ... ... -- Ashish On Thu, Jun 5, 2008 at 6:06 AM, Scott Gray <[EMAIL PROTECTED]> wrote: Hi Jacopo I just ran a quick test and Groovy seems to throw an error when an undeclared variable is used. Scott 2008/6/5 Jacopo Cappellato <[EMAIL PROTECTED]>: > > In fact for the Beanshell interpreter (by the way... should we consider to > use Groovy instead of Beanshell for the use-when scripts too?) an undeclared > variable is void but not null. >
Re: Interesting behavior of use-when fields
Does the groovy "?" operator thrown in different places solve this problem? It seems like it's kind of like the "?if_exists" in FTL, and may help with things like this. -David On Jun 5, 2008, at 4:06 AM, Scott Gray wrote: Hi Jacopo I just ran a quick test and Groovy seems to throw an error when an undeclared variable is used. Scott 2008/6/5 Jacopo Cappellato <[EMAIL PROTECTED]>: In fact for the Beanshell interpreter (by the way... should we consider to use Groovy instead of Beanshell for the use-when scripts too?) an undeclared variable is void but not null.
Re: svn commit: r664048 - in /ofbiz/trunk/framework: entity/fieldtype/ shark/ shark/config/ shark/entitydef/ shark/src/org/enhydra/shark/ shark/src/org/ofbiz/shark/container/ shark/src/org/ofbiz/shark
I would prefer to keep it, just to avoid this futur issue to arise again and to have a memory of it. I would prefer to create a specific field "numeric-shark-long" (100,0) to be very sure (I will not push too 1000 ;o) and change the referenced name in shark/entitydef/entitymodel.xml. Is that ok to you ? Anyway this has no impact outside of Shark, but it's really needed by Shark (even if we know that Shark has its future behind it in OFBiz) Jacques From: "David E Jones" <[EMAIL PROTECTED]> I'm happy to go remove it myself... just let me know. The point of a data dictionary is to keep things pretty minimal so that it is fairly easy to remember the options and know what each option means in Java and the physical database. At the minute the "long" and "numeric" values are pretty redundant since long is a NUMERIC(19,0) and numeric is a NUMERIC(18,0). Is having one additional digit a sufficient reason to create a whole new type? -David On Jun 6, 2008, at 2:42 PM, Jacques Le Roux wrote: David, My conclusion to commit as is came from the last comment of these 3 (in order) https://issues.apache.org/jira/browse/OFBIZ-552?focusedCommentId=12467679 #action_12467679 https://issues.apache.org/jira/browse/OFBIZ-552?focusedCommentId=12467749 #action_12467749 https://issues.apache.org/jira/browse/OFBIZ-552?focusedCommentId=12478407 #action_12478407 BTW, note this interesting topic : http://archives.postgresql.org/pgsql-interfaces/2000-01/msg00202.php So I thought that, even if the long name is not totally appropriate (but after all it's a name and only a name, we may call it numeric- long if we prefer) and even if later it turns that we have to increase above (19,0) (which was roughly retained by Sergey because it was the following number, I guess), this was a good start. Jacques From: "David E Jones" <[EMAIL PROTECTED]> This seems to need some more review... At the very least do NOT change the entity engine or other more critical/used framework pieces without careful review. In this case the "long" field type is really unnecessary and should not be added to OFBiz, the existing numeric type should be used instead. There may be other issues, but that one took about 10 seconds to spot... -David On Jun 6, 2008, at 11:32 AM, [EMAIL PROTECTED] wrote: Author: jleroux Date: Fri Jun 6 10:32:55 2008 New Revision: 664048 URL: http://svn.apache.org/viewvc?rev=664048&view=rev Log: Last patch (forgotten for more than one year) from Sergey Shutov "Integration Shark 1.1_2 into OfBiz" (https://issues.apache.org/jira/browse/OFBIZ-552 ) - OFBIZ-552 Added: ofbiz/trunk/framework/shark/config/SharkUiLabels.properties (with props) ofbiz/trunk/framework/shark/config/ SharkUiLabels_it.properties(with props) Modified: ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypecloudscape.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypedaffodil.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypederby.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypefirebird.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypehsql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypemssql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypemysql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypeoracle.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypepostgres.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypesapdb.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypesybase.xml ofbiz/trunk/framework/shark/build.xml ofbiz/trunk/framework/shark/entitydef/entitymodel.xml ofbiz/trunk/framework/shark/src/org/enhydra/shark/ ThreadedToolAgentManager.java ofbiz/trunk/framework/shark/src/org/ofbiz/shark/container/ SharkContainer.java ofbiz/trunk/framework/shark/src/org/ofbiz/shark/repository/ EntityRepositoryMgr.java ofbiz/trunk/framework/shark/webapp/shark/WEB-INF/controller.xml ofbiz/trunk/framework/shark/widget/TaskListScreens.xml Modified: ofbiz/trunk/framework/entity/fieldtype/ fieldtypeadvantage.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml?rev=664048&r1=664047&r2=664048&view=diff = = = = = = = = = = --- ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml (original) +++ ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml Fri Jun 6 10:32:55 2008 @@ -30,6 +30,7 @@ + Modified: ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml?rev=664048&r1=664047&r2=664048&view=diff = = = = = = = = = = --- ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml (original) +++ ofbiz/trunk/framework/entity/fi
Re: Interesting behavior of use-when fields
Yes, it should I guess. BTW (and a bit OS) I don't think there is a default operator in Groovy like ! in freemarker http://freemarker.sourceforge.net/docs/dgui_template_exp.html#dgui_template_exp_missing_default Jacques From: "David E Jones" <[EMAIL PROTECTED]> Does the groovy "?" operator thrown in different places solve this problem? It seems like it's kind of like the "?if_exists" in FTL, and may help with things like this. -David On Jun 5, 2008, at 4:06 AM, Scott Gray wrote: Hi Jacopo I just ran a quick test and Groovy seems to throw an error when an undeclared variable is used. Scott 2008/6/5 Jacopo Cappellato <[EMAIL PROTECTED]>: In fact for the Beanshell interpreter (by the way... should we consider to use Groovy instead of Beanshell for the use-when scripts too?) an undeclared variable is void but not null.
[jira] Created: (OFBIZ-1826) Allow EntityListIterator to be created from JDBC ResultSet
Allow EntityListIterator to be created from JDBC ResultSet -- Key: OFBIZ-1826 URL: https://issues.apache.org/jira/browse/OFBIZ-1826 Project: OFBiz Issue Type: Bug Components: framework Reporter: Si Chen Priority: Minor EntitylistIterator can only be constructed from a SQLProcessor right now, but in fact, it does not really use the SQLProcessor except to .close(). I have created a new constructor for the EntityListIterator which allows it to be created from a JDBC ResultSet. When it comes to closing the list iterator, the behavior is the same as before, if there is a SQLProcessor. Otherwise, it will call the ResultSet's close method. This would not affect anybody who is already using the delegator, but it would make it more flexible for people who are not using the delegator. Please take a look at this. If nobody opposes it, I will commit it next week -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-1826) Allow EntityListIterator to be created from JDBC ResultSet
[ https://issues.apache.org/jira/browse/OFBIZ-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Si Chen updated OFBIZ-1826: --- Attachment: ofbiz-1826.patch > Allow EntityListIterator to be created from JDBC ResultSet > -- > > Key: OFBIZ-1826 > URL: https://issues.apache.org/jira/browse/OFBIZ-1826 > Project: OFBiz > Issue Type: Bug > Components: framework >Reporter: Si Chen >Priority: Minor > Attachments: ofbiz-1826.patch > > > EntitylistIterator can only be constructed from a SQLProcessor right now, > but in fact, it does not really use the SQLProcessor except to .close(). I > have created a new constructor for the EntityListIterator which allows it to > be created from a JDBC ResultSet. When it comes to closing the list > iterator, the behavior is the same as before, if there is a SQLProcessor. > Otherwise, it will call the ResultSet's close method. > This would not affect anybody who is already using the delegator, but it > would make it more flexible for people who are not using the delegator. > Please take a look at this. If nobody opposes it, I will commit it next week -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
OT: Unsubscription ineffective
Apologies for posting to the list generally, but I'm not sure who our list admin is (if we have one). I'm trying to shift from the high-traffic mailing lists onto the digest lists to get a bit of control over my email. Getting onto the digest lists is done, but I don't seem to be able to get off the high-traffic ones. I've sent the requisite unsubscribe messages to the list management address a couple of time, but no luck. Anyone know what's up? Apologies again for send to the general lists. - Iain
Re: Interesting behavior of use-when fields
I can't see a standalone "?" operator but there is the safe navigation operator "?." for accessing properties/methods, so I guess you could do this: use-when="context?.example==null" Scott 2008/6/7 David E Jones <[EMAIL PROTECTED]>: > > Does the groovy "?" operator thrown in different places solve this problem? > > It seems like it's kind of like the "?if_exists" in FTL, and may help with > things like this. > > -David > > > > On Jun 5, 2008, at 4:06 AM, Scott Gray wrote: > > Hi Jacopo >> >> I just ran a quick test and Groovy seems to throw an error when an >> undeclared variable is used. >> >> Scott >> >> 2008/6/5 Jacopo Cappellato <[EMAIL PROTECTED]>: >> >> >>> In fact for the Beanshell interpreter (by the way... should we consider >>> to >>> use Groovy instead of Beanshell for the use-when scripts too?) an >>> undeclared >>> variable is void but not null. >>> >>> >
Re: svn commit: r662852 - in /ofbiz/trunk/framework/entity/lib: commons-dbcp-1.3-20071125.225953-2.jar commons-dbcp-20070730.jar
Committed in revision 664195. Wiki updated as well. Not sure why we have also framework/catalina/lib/tomcat-6.0.16-tomcat-dbcp.jar BTW (not used I guess) Jacques From: "Jacques Le Roux" <[EMAIL PROTECTED]> Thanks Marco, I will do it tomorrow and Wiki also if needed (I did not check) Jacques From: <[EMAIL PROTECTED]> Hi to all, Can someone update LICENCE/Libraries Included in OFBiz/.classpath files because I'm not authorized to do it. Thanks Marco Il giorno 03/giu/08, alle ore 20:09, [EMAIL PROTECTED] ha scritto: Author: jaz Date: Tue Jun 3 11:09:56 2008 New Revision: 662852 URL: http://svn.apache.org/viewvc?rev=662852&view=rev Log: updated DBCP with latest snapshot from Maven repository 2007-11-25. This should correct the memory leak reported in JIRA OFBIZ-1818. Added: ofbiz/trunk/framework/entity/lib/commons- dbcp-1.3-20071125.225953-2.jar (with props) Removed: ofbiz/trunk/framework/entity/lib/commons-dbcp-20070730.jar Added: ofbiz/trunk/framework/entity/lib/commons- dbcp-1.3-20071125.225953-2.jar URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/lib/commons-dbcp-1.3-20071125.225953-2.jar?rev=662852&view=auto = = = = = = = = == Binary file - no diff available. Propchange: ofbiz/trunk/framework/entity/lib/commons- dbcp-1.3-20071125.225953-2.jar -- svn:mime-type = application/octet-stream
Re: Interesting behavior of use-when fields
Hi Jacques
The shortcut ternary operator (?:) would work:
productTypeId = null;
if ("FINISHED_GOOD" == productTypeId ?: "FINISHED_GOOD")
Scott
2008/6/7 Jacques Le Roux <[EMAIL PROTECTED]>:
> Yes, it should I guess.
>
> BTW (and a bit OS) I don't think there is a default operator in Groovy like
> ! in freemarker
> http://freemarker.sourceforge.net/docs/dgui_template_exp.html#dgui_template_exp_missing_default
>
> Jacques
>
> From: "David E Jones" <[EMAIL PROTECTED]>
>
>
>> Does the groovy "?" operator thrown in different places solve this
>> problem?
>>
>> It seems like it's kind of like the "?if_exists" in FTL, and may help
>> with things like this.
>>
>> -David
>>
>>
>> On Jun 5, 2008, at 4:06 AM, Scott Gray wrote:
>>
>> Hi Jacopo
>>>
>>> I just ran a quick test and Groovy seems to throw an error when an
>>> undeclared variable is used.
>>>
>>> Scott
>>>
>>> 2008/6/5 Jacopo Cappellato <[EMAIL PROTECTED]>:
>>>
>>>
In fact for the Beanshell interpreter (by the way... should we consider
to
use Groovy instead of Beanshell for the use-when scripts too?) an
undeclared
variable is void but not null.
>>
>
[jira] Commented: (OFBIZ-1826) Allow EntityListIterator to be created from JDBC ResultSet
[ https://issues.apache.org/jira/browse/OFBIZ-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603236#action_12603236 ] Si Chen commented on OFBIZ-1826: by the way, I have apply this patch and rerun all the entity unit tests, and they passed > Allow EntityListIterator to be created from JDBC ResultSet > -- > > Key: OFBIZ-1826 > URL: https://issues.apache.org/jira/browse/OFBIZ-1826 > Project: OFBiz > Issue Type: Bug > Components: framework >Reporter: Si Chen >Priority: Minor > Attachments: ofbiz-1826.patch > > > EntitylistIterator can only be constructed from a SQLProcessor right now, > but in fact, it does not really use the SQLProcessor except to .close(). I > have created a new constructor for the EntityListIterator which allows it to > be created from a JDBC ResultSet. When it comes to closing the list > iterator, the behavior is the same as before, if there is a SQLProcessor. > Otherwise, it will call the ResultSet's close method. > This would not affect anybody who is already using the delegator, but it > would make it more flexible for people who are not using the delegator. > Please take a look at this. If nobody opposes it, I will commit it next week -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Unused scripts in the accounting app
Hi All, Here's a list of orphaned scripts in the accounting app: admin/printChecks.groovy chartofaccounts/EditGlobalGlAccount.groovy chartofaccounts/FindGlobalGlAccount.groovy fixedasset/month.groovy invoice/addAmountToInvoiceList.groovy invoice/addTotalAmount.groovy invoice/createItemList.groovy invoice/findInvoices.groovy invoice/invoicePayments.groovy order/billingAccountOrders.goovy payment/editPayment.groovy payment/findPayment.groovy Any thoughts on what to do with them? My preference is to just get rid of them... Thanks Scott
Re: Unused scripts in the accounting app
On Jun 6, 2008, at 6:11 PM, Scott Gray wrote: Hi All, Here's a list of orphaned scripts in the accounting app: admin/printChecks.groovy chartofaccounts/EditGlobalGlAccount.groovy chartofaccounts/FindGlobalGlAccount.groovy fixedasset/month.groovy invoice/addAmountToInvoiceList.groovy invoice/addTotalAmount.groovy invoice/createItemList.groovy invoice/findInvoices.groovy invoice/invoicePayments.groovy order/billingAccountOrders.goovy payment/editPayment.groovy payment/findPayment.groovy Any thoughts on what to do with them? My preference is to just get rid of them... I'm all for getting rid of unused stuff, so +1. -David
Re: Unused scripts in the accounting app
Are you sure month.groovy isn't being used? --- On Fri, 6/6/08, Scott Gray <[EMAIL PROTECTED]> wrote: From: Scott Gray <[EMAIL PROTECTED]> Subject: Unused scripts in the accounting app To: dev@ofbiz.apache.org Date: Friday, June 6, 2008, 5:11 PM Hi All, Here's a list of orphaned scripts in the accounting app: admin/printChecks.groovy chartofaccounts/EditGlobalGlAccount.groovy chartofaccounts/FindGlobalGlAccount.groovy fixedasset/month.groovy invoice/addAmountToInvoiceList.groovy invoice/addTotalAmount.groovy invoice/createItemList.groovy invoice/findInvoices.groovy invoice/invoicePayments.groovy order/billingAccountOrders.goovy payment/editPayment.groovy payment/findPayment.groovy Any thoughts on what to do with them? My preference is to just get rid of them... Thanks Scott
Re: Unused scripts in the accounting app
Unless there's something wrong with my eclipse search, both month.bsh and month.groovy show zero hits... 2008/6/7 Adrian Crum <[EMAIL PROTECTED]>: > Are you sure month.groovy isn't being used? > > --- On Fri, 6/6/08, Scott Gray <[EMAIL PROTECTED]> wrote: > From: Scott Gray <[EMAIL PROTECTED]> > Subject: Unused scripts in the accounting app > To: dev@ofbiz.apache.org > Date: Friday, June 6, 2008, 5:11 PM > > Hi All, > > Here's a list of orphaned scripts in the accounting app: > admin/printChecks.groovy > chartofaccounts/EditGlobalGlAccount.groovy > chartofaccounts/FindGlobalGlAccount.groovy > fixedasset/month.groovy > invoice/addAmountToInvoiceList.groovy > invoice/addTotalAmount.groovy > invoice/createItemList.groovy > invoice/findInvoices.groovy > invoice/invoicePayments.groovy > order/billingAccountOrders.goovy > payment/editPayment.groovy > payment/findPayment.groovy > > Any thoughts on what to do with them? My preference is to just get rid of > them... > > Thanks > Scott > > > >
Re: svn commit: r664048 - in /ofbiz/trunk/framework: entity/fieldtype/ shark/ shark/config/ shark/entitydef/ shark/src/org/enhydra/shark/ shark/src/org/ofbiz/shark/container/ shark/src/org/ofbiz/shark
You would "prefer" to keep it? Could you please explain why? -David On Jun 6, 2008, at 3:20 PM, Jacques Le Roux wrote: I would prefer to keep it, just to avoid this futur issue to arise again and to have a memory of it. I would prefer to create a specific field "numeric-shark- long" (100,0) to be very sure (I will not push too 1000 ;o) and change the referenced name in shark/entitydef/entitymodel.xml. Is that ok to you ? Anyway this has no impact outside of Shark, but it's really needed by Shark (even if we know that Shark has its future behind it in OFBiz) Jacques From: "David E Jones" <[EMAIL PROTECTED]> I'm happy to go remove it myself... just let me know. The point of a data dictionary is to keep things pretty minimal so that it is fairly easy to remember the options and know what each option means in Java and the physical database. At the minute the "long" and "numeric" values are pretty redundant since long is a NUMERIC(19,0) and numeric is a NUMERIC(18,0). Is having one additional digit a sufficient reason to create a whole new type? -David On Jun 6, 2008, at 2:42 PM, Jacques Le Roux wrote: David, My conclusion to commit as is came from the last comment of these 3 (in order) https://issues.apache.org/jira/browse/OFBIZ-552?focusedCommentId=12467679 #action_12467679 https://issues.apache.org/jira/browse/OFBIZ-552?focusedCommentId=12467749 #action_12467749 https://issues.apache.org/jira/browse/OFBIZ-552?focusedCommentId=12478407 #action_12478407 BTW, note this interesting topic : http://archives.postgresql.org/pgsql-interfaces/2000-01/msg00202.php So I thought that, even if the long name is not totally appropriate (but after all it's a name and only a name, we may call it numeric- long if we prefer) and even if later it turns that we have to increase above (19,0) (which was roughly retained by Sergey because it was the following number, I guess), this was a good start. Jacques From: "David E Jones" <[EMAIL PROTECTED]> This seems to need some more review... At the very least do NOT change the entity engine or other more critical/used framework pieces without careful review. In this case the "long" field type is really unnecessary and should not be added to OFBiz, the existing numeric type should be used instead. There may be other issues, but that one took about 10 seconds to spot... -David On Jun 6, 2008, at 11:32 AM, [EMAIL PROTECTED] wrote: Author: jleroux Date: Fri Jun 6 10:32:55 2008 New Revision: 664048 URL: http://svn.apache.org/viewvc?rev=664048&view=rev Log: Last patch (forgotten for more than one year) from Sergey Shutov "Integration Shark 1.1_2 into OfBiz" (https://issues.apache.org/jira/browse/OFBIZ-552 ) - OFBIZ-552 Added: ofbiz/trunk/framework/shark/config/SharkUiLabels.properties (with props) ofbiz/trunk/framework/shark/config/ SharkUiLabels_it.properties(with props) Modified: ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypeaxion.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypecloudscape.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypedaffodil.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypederby.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypefirebird.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypehsql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypemssql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypemysql.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypeoracle.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypepostgres.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypesapdb.xml ofbiz/trunk/framework/entity/fieldtype/fieldtypesybase.xml ofbiz/trunk/framework/shark/build.xml ofbiz/trunk/framework/shark/entitydef/entitymodel.xml ofbiz/trunk/framework/shark/src/org/enhydra/shark/ ThreadedToolAgentManager.java ofbiz/trunk/framework/shark/src/org/ofbiz/shark/container/ SharkContainer.java ofbiz/trunk/framework/shark/src/org/ofbiz/shark/repository/ EntityRepositoryMgr.java ofbiz/trunk/framework/shark/webapp/shark/WEB-INF/controller.xml ofbiz/trunk/framework/shark/widget/TaskListScreens.xml Modified: ofbiz/trunk/framework/entity/fieldtype/ fieldtypeadvantage.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/fieldtype/fieldtypeadvantage.xml?rev=664048&r1=664047&r2=664048&view=diff = = = = = = = = = = = = == --- ofbiz/trunk/framework/entity/fieldtype/ fieldtypeadvantage.xml (original) +++ ofbiz/trunk/framework/entity/fieldtype/ fieldtypeadvantage.xml Fri Jun 6 10:32:55 2008 @@ -30,6 +30,7 @@ type="java.sql.Timestamp"> type="java.sql.Date"> type="java.sql.Time"> +type="java.lang.Long"> type- def> type="Double"> /> java- type="Double"> /> Modified: ofbiz/trunk/framework/entity/fieldtype/ fieldtypeaxion.xml URL: http://svn.apache.org/viewvc/
Re: Interesting behavior of use-when fields
Scott ,
In groovy we call it Elvis Operator (?:) :-)
--
Ashish
On Fri, Jun 6, 2008 at 7:43 PM, Scott Gray <[EMAIL PROTECTED]> wrote:
> Hi Jacques
>
> The shortcut ternary operator (?:) would work:
> productTypeId = null;
> if ("FINISHED_GOOD" == productTypeId ?: "FINISHED_GOOD")
>
> Scott
>
> 2008/6/7 Jacques Le Roux <[EMAIL PROTECTED]>:
>
> > Yes, it should I guess.
> >
> > BTW (and a bit OS) I don't think there is a default operator in Groovy
> like
> > ! in freemarker
> >
> http://freemarker.sourceforge.net/docs/dgui_template_exp.html#dgui_template_exp_missing_default
> >
> > Jacques
> >
> > From: "David E Jones" <[EMAIL PROTECTED]>
> >
> >
> >> Does the groovy "?" operator thrown in different places solve this
> >> problem?
> >>
> >> It seems like it's kind of like the "?if_exists" in FTL, and may help
> >> with things like this.
> >>
> >> -David
> >>
> >>
> >> On Jun 5, 2008, at 4:06 AM, Scott Gray wrote:
> >>
> >> Hi Jacopo
> >>>
> >>> I just ran a quick test and Groovy seems to throw an error when an
> >>> undeclared variable is used.
> >>>
> >>> Scott
> >>>
> >>> 2008/6/5 Jacopo Cappellato <[EMAIL PROTECTED]>:
> >>>
> >>>
> In fact for the Beanshell interpreter (by the way... should we
> consider
> to
> use Groovy instead of Beanshell for the use-when scripts too?) an
> undeclared
> variable is void but not null.
>
>
> >>
> >
>
Effect of a sentence in "Groovy"
Frenz ,
Suppose I have two sentence in Beanshell file :-
1). context.put("partyId" , UtilMisc.toMap("Key1","Value1"));
Key i.e partyId in the following sentence will be variable one.
2). partyId = parameters.get("partyId") ;
context.put(partyId , UtilMisc.topMap("Key1","Value1"));
The converted sentence for the Beanshell statement shown above will be :-
1) context.partyId = [Key1 : "Value1"];
And I am confused about the second one.
Can anybody of you give some pointer on it ?
--
Ashish Vijaywargiya
