Re: Beginner in ofbiz---pls help
Please use only user ML for such questions, see why here : http://cwiki.apache.org/confluence/display/OFBADMIN/Mailing+Lists#MailingLists-DesignanddevelopmentList:dev@ofbiz.apache.org Thanks Jacques From: Hi, I am very new to the ofbiz section. I have setup ofbiz in my sytem. And i am able to work successfuly with ofbiz/ecommerce, ofbiz-manufacturing etc. But My criteria is to setup ofbiz CRM and ofbiz SFA in my system. But i dont know what I have to do to setup ofbiz CRM/SFA. I dont see any folder with that name. Is this ofbiz CRM/SFA is a module like other modules(ecommerce, manufac etc) How can i run these CRM and SFA? ( eg for ecommerce i am using http://localhost:8080/ecommerce) Is there any other links to run / work with ofbiz CRM/SFA? I dont see any folder in the application with those names. What are the modules I have to setup to work with ofbiz CRM/SFA? Pls help me I am a beginner in this area. Thanks, Ammu -- View this message in context: http://n4.nabble.com/Beginner-in-ofbiz-pls-help-tp1574661p1574661.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Beginner in ofbiz---pls help
Hi, I am very new to the ofbiz section. I have setup ofbiz in my sytem. And i am able to work successfuly with ofbiz/ecommerce, ofbiz-manufacturing etc. But My criteria is to setup ofbiz CRM and ofbiz SFA in my system. But i dont know what I have to do to setup ofbiz CRM/SFA. I dont see any folder with that name. Is this ofbiz CRM/SFA is a module like other modules(ecommerce, manufac etc) How can i run these CRM and SFA? ( eg for ecommerce i am using http://localhost:8080/ecommerce) Is there any other links to run / work with ofbiz CRM/SFA? I dont see any folder in the application with those names. What are the modules I have to setup to work with ofbiz CRM/SFA? Pls help me I am a beginner in this area. Thanks, Ammu -- View this message in context: http://n4.nabble.com/Beginner-in-ofbiz-pls-help-tp1574661p1574661.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
[jira] Commented: (OFBIZ-3510) Step by step procedure to implement an autocomplete feature in ofbiz
[ https://issues.apache.org/jira/browse/OFBIZ-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839997#action_12839997 ] Vasu T commented on OFBIZ-3510: --- sir, why two fields namely userloginid and customer in following link https://localhost:8443/ordermgr/control/orderentry is not giving autocomplete output as partyid in https://localhost:8443/humanres/control/FindEmplLeaves need a urgent reply. --- On Fri, 26/2/10, Erwan de FERRIERES (JIRA) wrote: From: Erwan de FERRIERES (JIRA) Subject: [jira] Commented: (OFBIZ-3510) Step by step procedure to implement an autocomplete feature in ofbiz To: vasut...@yahoo.co.in Date: Friday, 26 February, 2010, 12:26 PM [ https://issues.apache.org/jira/browse/OFBIZ-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12838845#action_12838845 ] Erwan de FERRIERES commented on OFBIZ-3510: --- Hi, You may take a look at this commit : http://svn.apache.org/viewvc?rev=910587&view=rev Cheers, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/ > Step by step procedure to implement an autocomplete feature in ofbiz > > > Key: OFBIZ-3510 > URL: https://issues.apache.org/jira/browse/OFBIZ-3510 > Project: OFBiz > Issue Type: Wish > Components: order > Environment: Ubuntu >Reporter: Vasu .T > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > HI, > I am a student working on ofbiz.We have planned to create three features in > ofbiz which i dono exists or not. > Features: > 1)Implementing autocomplete in some places like countrylist,statelist etc. > 2)Reducing width of table rows in catalog and other places. > 3)Impplementing iphone interface in ofbiz. > Now we have created myinstitute component in ofbiz and now we are looking to > implement above 3 ui features.Please need some valuable suggestions to > implement autocomplete may be steps to modify existing code in ofbiz. > Below are some of URLS where we need autocomplete: > Look up Party - This comes in several places. Example URLs are > https://localhost:8443/ordermgr/control/orderentry > https://localhost:8443/catalog/control/EditProdCatalogParties?prodCatalogId=DemoCatalog > https://localhost:8443/facility/control/EditFacility > I ll be glad see comments and suggestions as early as possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3524) Some improvements for the layer lookup
[ https://issues.apache.org/jira/browse/OFBIZ-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839888#action_12839888 ] Jacques Le Roux commented on OFBIZ-3524: Sascha, I'm sorry but I don't see exactly how, when and where the fading is rendered. Could you explain in more details please? Maybe 2 pictures (before/after) will help? Thanks > Some improvements for the layer lookup > -- > > Key: OFBIZ-3524 > URL: https://issues.apache.org/jira/browse/OFBIZ-3524 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Jacques Le Roux > Fix For: SVN trunk > > Attachments: faded_background.png, OFBIZ-3524_Fade_Background.patch, > OFBIZ-3524_Fade_Background.patch > > > Hi Jacques, hi all > i created a new patch for the layer lookup field. > This Patch contains the patches > [OFBIZ-3491|https://issues.apache.org/jira/browse/OFBIZ-3491], > [OFBIZ-3492|https://issues.apache.org/jira/browse/OFBIZ-3492] (i will close > the issues). > Furthermore i added a flag to fade the background when a layer opened. In my > opinion it's nesseary when i want to give a focus to my lookup. > After apllying the patch the picture faded_background.png have to be copied > to the image folder of *each* theme. > Have a nice day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3527) Color of links in retrieved list for Tomahawk theme
[ https://issues.apache.org/jira/browse/OFBIZ-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839880#action_12839880 ] Jacques Le Roux commented on OFBIZ-3527: We have also a small issue with the navigation buttons (a bit horizontally mirrored) > Color of links in retrieved list for Tomahawk theme > --- > > Key: OFBIZ-3527 > URL: https://issues.apache.org/jira/browse/OFBIZ-3527 > Project: OFBiz > Issue Type: Sub-task >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3527) Color of links in retrieved list for Tomahawk theme
[ https://issues.apache.org/jira/browse/OFBIZ-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839857#action_12839857 ] Jacques Le Roux commented on OFBIZ-3527: In Tomahawk theme the links in the retrieved list are not following the theme colors. To reproduce on demo server: try "Examples Lookup Fields" at https://ofbiz-vm.apache.org/example/control/FormWidgetExamples. I have also found that it's not exactly the same problem depending on the place the lookup is used (or maybe how it's used). To see this you must apply the patches of the other related issues . > Color of links in retrieved list for Tomahawk theme > --- > > Key: OFBIZ-3527 > URL: https://issues.apache.org/jira/browse/OFBIZ-3527 > Project: OFBiz > Issue Type: Sub-task >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3527) Color of links in retrieved list for Tomahawk theme
Color of links in retrieved list for Tomahawk theme --- Key: OFBIZ-3527 URL: https://issues.apache.org/jira/browse/OFBIZ-3527 Project: OFBiz Issue Type: Sub-task Reporter: Jacques Le Roux Assignee: Jacques Le Roux -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3492) Tomahawk LookupLayer Layout update
[ https://issues.apache.org/jira/browse/OFBIZ-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-3492. -- Resolution: Fixed Close this issue to make things clear > Tomahawk LookupLayer Layout update > -- > > Key: OFBIZ-3492 > URL: https://issues.apache.org/jira/browse/OFBIZ-3492 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Jacques Le Roux > Fix For: SVN trunk > > Attachments: OFBIZ-3492_tomahawk_lookup_update.patch, > OFBIZ-3492_tomahawk_lookup_update.patch > > > Hi i made a little change in the tomahawk css to change the layer layout > (header image, border color). :-) > If you like the changes and commit it, the header_bg.gif in tomahawk\images > can be deleted > Have a nice day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3492) Tomahawk LookupLayer Layout update
[ https://issues.apache.org/jira/browse/OFBIZ-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839834#action_12839834 ] Jacques Le Roux commented on OFBIZ-3492: To reproduce on demo server: Try "Examples Lookup Fields" at https://ofbiz-vm.apache.org/example/control/FormWidgetExamples. But as it's a WIP I think it's better to wait Sascha or I review. Else you will have to apply also the OFBIZ-3442 patch and I'm not even quite sure you will get the same env than me (see below remark) BTW Sascha, I have just found that it's not exactly the same problem depending on the place the lookup is used (or maybe how it's used) > Tomahawk LookupLayer Layout update > -- > > Key: OFBIZ-3492 > URL: https://issues.apache.org/jira/browse/OFBIZ-3492 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Jacques Le Roux > Fix For: SVN trunk > > Attachments: OFBIZ-3492_tomahawk_lookup_update.patch, > OFBIZ-3492_tomahawk_lookup_update.patch > > > Hi i made a little change in the tomahawk css to change the layer layout > (header image, border color). :-) > If you like the changes and commit it, the header_bg.gif in tomahawk\images > can be deleted > Have a nice day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3492) Tomahawk LookupLayer Layout update
[ https://issues.apache.org/jira/browse/OFBIZ-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839829#action_12839829 ] Jacques Le Roux commented on OFBIZ-3492: BTW Sascha, Don't worry I will have a look at it. > Tomahawk LookupLayer Layout update > -- > > Key: OFBIZ-3492 > URL: https://issues.apache.org/jira/browse/OFBIZ-3492 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Jacques Le Roux > Fix For: SVN trunk > > Attachments: OFBIZ-3492_tomahawk_lookup_update.patch, > OFBIZ-3492_tomahawk_lookup_update.patch > > > Hi i made a little change in the tomahawk css to change the layer layout > (header image, border color). :-) > If you like the changes and commit it, the header_bg.gif in tomahawk\images > can be deleted > Have a nice day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Java Object Type Conversion (was: svn commit: r917376 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java)
Adam Heath wrote: Now, if we want to discuss removing these extra changes, then we also need to take it upon ourselves to fix any uses that required the code to function in this manner. I guess the community needs to discuss (and agree upon) a set of rules that Java object type conversion should follow. That would be a discussion worth having - just like the TimeZone issue David brought up earlier. Sometimes code just gets thrown into the project without a lot of planning, so it can be helpful to have the community agree on a design. Then we can change the code to follow that design. I admit I made a couple of code behavior changes while introducing the conversion framework. For the most part I kept things the same - to ensure backward compatibility. But I also changed some things because the original conversions didn't seem to follow any rules - they didn't make sense . In hindsight, I should have started a thread on the subject before changing it. -Adrian
[jira] Commented: (OFBIZ-3492) Tomahawk LookupLayer Layout update
[ https://issues.apache.org/jira/browse/OFBIZ-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839804#action_12839804 ] Adam Heath commented on OFBIZ-3492: --- How to get to a page that has the display problems? Assume that someone reading this has no idea how ofbiz functions, so don't leave out any steps. And assume a freshly installed set of demo data. > Tomahawk LookupLayer Layout update > -- > > Key: OFBIZ-3492 > URL: https://issues.apache.org/jira/browse/OFBIZ-3492 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Jacques Le Roux > Fix For: SVN trunk > > Attachments: OFBIZ-3492_tomahawk_lookup_update.patch, > OFBIZ-3492_tomahawk_lookup_update.patch > > > Hi i made a little change in the tomahawk css to change the layer layout > (header image, border color). :-) > If you like the changes and commit it, the header_bg.gif in tomahawk\images > can be deleted > Have a nice day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tomahawk theme
From: "Adam Heath" Jacques Le Roux wrote: Hi, I think we should change the color of the links inside the lookups list (stayed blue) As is normal with any reported issue, details are king. What page were you on? Did it require clicking on several links to get there? Voice of reason! This is only true with layered lookups. I was quickly testing them (between two other tasks) and as I have replaced all std lookups by layered forgot that point. Thanks Adam, I have (re)opened a specific issue https://issues.apache.org/jira/browse/OFBIZ-3492 Jacques
Re: svn commit: r911761 - /ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/Product.groovy
ash...@apache.org wrote:
> Author: ashish
> Date: Fri Feb 19 09:47:47 2010
> New Revision: 911761
>
> URL: http://svn.apache.org/viewvc?rev=911761&view=rev
> Log:
> Fix for groovy.lang.MissingPropertyException: No such property:
> configproductdetailScreen for class: Product.
> Patch from Anurag (Thanks!)
>
> Modified:
>
> ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/Product.groovy
>
> Modified:
> ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/Product.groovy
> URL:
> http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/Product.groovy?rev=911761&r1=911760&r2=911761&view=diff
> ==
> ---
> ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/Product.groovy
> (original)
> +++
> ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/Product.groovy
> Fri Feb 19 09:47:47 2010
> @@ -93,7 +93,7 @@
> context.metaKeywords = StringUtil.join(keywords, ", ");
>
> // Set the default template for aggregated product (product
> component configurator ui)
> -if (product.productTypeId &&
> "AGGREGATED".equals(product.productTypeId) && configproductdetailScreen) {
> +if (product.productTypeId &&
> "AGGREGATED".equals(product.productTypeId) &&
> context.configproductdetailScreen) {
> detailScreen = configproductdetailScreen;
> }
Shouldn't the line inside the condition also be changed too?
[jira] Assigned: (OFBIZ-3524) Some improvements for the layer lookup
[ https://issues.apache.org/jira/browse/OFBIZ-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-3524: -- Assignee: Jacques Le Roux > Some improvements for the layer lookup > -- > > Key: OFBIZ-3524 > URL: https://issues.apache.org/jira/browse/OFBIZ-3524 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Jacques Le Roux > Fix For: SVN trunk > > Attachments: faded_background.png, OFBIZ-3524_Fade_Background.patch, > OFBIZ-3524_Fade_Background.patch > > > Hi Jacques, hi all > i created a new patch for the layer lookup field. > This Patch contains the patches > [OFBIZ-3491|https://issues.apache.org/jira/browse/OFBIZ-3491], > [OFBIZ-3492|https://issues.apache.org/jira/browse/OFBIZ-3492] (i will close > the issues). > Furthermore i added a flag to fade the background when a layer opened. In my > opinion it's nesseary when i want to give a focus to my lookup. > After apllying the patch the picture faded_background.png have to be copied > to the image folder of *each* theme. > Have a nice day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OFBIZ-3492) Tomahawk LookupLayer Layout update
[ https://issues.apache.org/jira/browse/OFBIZ-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-3492: -- Assignee: Jacques Le Roux > Tomahawk LookupLayer Layout update > -- > > Key: OFBIZ-3492 > URL: https://issues.apache.org/jira/browse/OFBIZ-3492 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Jacques Le Roux > Fix For: SVN trunk > > Attachments: OFBIZ-3492_tomahawk_lookup_update.patch, > OFBIZ-3492_tomahawk_lookup_update.patch > > > Hi i made a little change in the tomahawk css to change the layer layout > (header image, border color). :-) > If you like the changes and commit it, the header_bg.gif in tomahawk\images > can be deleted > Have a nice day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (OFBIZ-3492) Tomahawk LookupLayer Layout update
[ https://issues.apache.org/jira/browse/OFBIZ-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reopened OFBIZ-3492: Hi Sascha, I just discovered that in Tomahawk the links in the retrieved list are not following the theme colors (stay blue) > Tomahawk LookupLayer Layout update > -- > > Key: OFBIZ-3492 > URL: https://issues.apache.org/jira/browse/OFBIZ-3492 > Project: OFBiz > Issue Type: Sub-task >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp > Fix For: SVN trunk > > Attachments: OFBIZ-3492_tomahawk_lookup_update.patch, > OFBIZ-3492_tomahawk_lookup_update.patch > > > Hi i made a little change in the tomahawk css to change the layer layout > (header image, border color). :-) > If you like the changes and commit it, the header_bg.gif in tomahawk\images > can be deleted > Have a nice day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tomahawk theme
Jacques Le Roux wrote: > Hi, > > I think we should change the color of the links inside the lookups list > (stayed blue) As is normal with any reported issue, details are king. What page were you on? Did it require clicking on several links to get there?
[jira] Commented: (OFBIZ-3442) Replace popup lookups by layer lookups
[ https://issues.apache.org/jira/browse/OFBIZ-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839773#action_12839773 ] Jacques Le Roux commented on OFBIZ-3442: Also, though I agree with Bilgin on the defaults to use, I think I will commit as is for now. For this 2 reasons: # It's easy to change later with a S/R and small changes in XSD # I'm not quite sure we should use these defaults without exchanging before with the community. However so far, we are few to be really interested (or simply aware), but I guess after it will be commited a lot of discussion will occurs and maybe new ideas, etc. > Replace popup lookups by layer lookups > -- > > Key: OFBIZ-3442 > URL: https://issues.apache.org/jira/browse/OFBIZ-3442 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-3442 replace popup lookups by layered > lookups.patch, OFBIZ-3442 replace popup lookups by layered lookups.patch, > OFBIZ-3442 replace popup lookups by layered lookups.patch, OFBIZ-3442 replace > popup lookups by layered lookups.patch, OFBIZ-3442 replace popup lookups by > layered lookups.patch > > > Following Sascha Rodekamp's work on layer lookups OFBIZ-3374 and > improvements OFBIZ-3430, I propose now to replace old the popup lookups by > layered (Ajaxified) lookups. > For that please find a patch attached. In this patch I followed a simple S/R > tactic: > * I replaced all occurences of LookupDecorator by LookupLayerPopupDecorator > in screens > * I replaced all occurences of position="center" > It's as simple as this. For the moment I decided to use as default > position="center" because it's was the easiest (sure that any lookups will be > out of the screen). I think we will refine this by removing position="center" > and use the default (position="normal") which does not move the layer from > the point it's called and will be more aesthetic. > I did not test anything in OFBIz OOTB for the moment, but I already use > layered lookups in a custom application without any issues so far. > The only drawback I found for the moment is when a lookup is called from a > lookup. If you are aware of such cases please chime in. > Of course everybody is encouraged to test this improvement as much as > possible. I really think it's a very cool feature for users, and they will > appreciate. There are still some ideas like that (see the link Sasca referred > to in OFBIZ-3374), and we will try to implement them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r917376 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Adrian Crum wrote:
> Adam Heath wrote:
>> Adrian Crum wrote:
>>> Adam Heath wrote:
Adrian Crum wrote:
> doo...@apache.org wrote:
>> Author: doogie
>> Date: Mon Mar 1 05:06:16 2010
>> New Revision: 917376
>>
>> URL: http://svn.apache.org/viewvc?rev=917376&view=rev
>> Log:
>> BUG FIX: Move the check that tests whether we are converting to the
>> passed object to before the loadClass call.
>>
>> Modified:
>>
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
>>
>> Modified:
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java?rev=917376&r1=917375&r2=917376&view=diff
>>
>>
>>
>> ==
>>
>>
>>
>> ---
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
>> (original)
>> +++
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
>> Mon Mar 1 05:06:16 2010
>> @@ -484,6 +484,9 @@
>> return obj.toString();
>> }
>> Class sourceClass = obj.getClass();
>> +if (sourceClass.getName().equals(type)) {
>> +return obj;
>> +}
>> if ("Object".equals(type) ||
>> "java.lang.Object".equals(type)) {
>> return obj;
>> }
> Are you sure this will work? Take a look at the following if
> statement.
Yes, due a combination of things.
If the object was null, return null.
If converting to the same exact class as the incoming obj, return with
no change.
If the incoming object is a string, and it is empty, return null.
The above 3 constraints were pulled from the old version of
simpleTypeConvert.
Without all three, if you tried to convert an empty String to a
String, you'd get null.
>>> I think you missed my point. Shouldn't the test be something like:
>>>
>>> if (sourceClass.getName().equals(type) ||
>>> sourceClass.getSimpleName().equals(type)) {
>>> return obj;
>>> }
>>>
>>> ?
>>>
>>> In other words, you can't count on type being "java.util.Date" - it
>>> might be simply "Date".
>>
>> Except always testing against simpleName isn't right, as only certain
>> classes had simpleName tests from the previous version.
>>
>> I see your point, however, and will fix it how you want, but only
>> insomuch that it matches the old version.
>
> I didn't care for the simple name test in the original code. Maybe
> that's why I changed it to be more reliable.
>
> Like you said in your summary, there were things in the original code
> that didn't work or didn't make sense.
Ok, no, I will not be implementing the change you suggest. The
original code did not check the short name there. And yes, that is
weird, but this series of fixes was to only make the new version
function exactly like the old, so that existing code wouldn't break.
Now, if we want to discuss removing these extra changes, then we also
need to take it upon ourselves to fix any uses that required the code
to function in this manner.
>
Re: svn commit: r917376 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Adam Heath wrote:
Adrian Crum wrote:
Adam Heath wrote:
Adrian Crum wrote:
doo...@apache.org wrote:
Author: doogie
Date: Mon Mar 1 05:06:16 2010
New Revision: 917376
URL: http://svn.apache.org/viewvc?rev=917376&view=rev
Log:
BUG FIX: Move the check that tests whether we are converting to the
passed object to before the loadClass call.
Modified:
ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Modified:
ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java?rev=917376&r1=917375&r2=917376&view=diff
==
--- ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
(original)
+++ ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Mon Mar 1 05:06:16 2010
@@ -484,6 +484,9 @@
return obj.toString();
}
Class sourceClass = obj.getClass();
+if (sourceClass.getName().equals(type)) {
+return obj;
+}
if ("Object".equals(type) ||
"java.lang.Object".equals(type)) {
return obj;
}
Are you sure this will work? Take a look at the following if statement.
Yes, due a combination of things.
If the object was null, return null.
If converting to the same exact class as the incoming obj, return with
no change.
If the incoming object is a string, and it is empty, return null.
The above 3 constraints were pulled from the old version of
simpleTypeConvert.
Without all three, if you tried to convert an empty String to a
String, you'd get null.
I think you missed my point. Shouldn't the test be something like:
if (sourceClass.getName().equals(type) ||
sourceClass.getSimpleName().equals(type)) {
return obj;
}
?
In other words, you can't count on type being "java.util.Date" - it
might be simply "Date".
Except always testing against simpleName isn't right, as only certain
classes had simpleName tests from the previous version.
I see your point, however, and will fix it how you want, but only
insomuch that it matches the old version.
I didn't care for the simple name test in the original code. Maybe
that's why I changed it to be more reliable.
Like you said in your summary, there were things in the original code
that didn't work or didn't make sense.
Re: svn commit: r917376 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Adrian Crum wrote:
> Adam Heath wrote:
>> Adrian Crum wrote:
>>> doo...@apache.org wrote:
Author: doogie
Date: Mon Mar 1 05:06:16 2010
New Revision: 917376
URL: http://svn.apache.org/viewvc?rev=917376&view=rev
Log:
BUG FIX: Move the check that tests whether we are converting to the
passed object to before the loadClass call.
Modified:
ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Modified:
ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java?rev=917376&r1=917375&r2=917376&view=diff
==
--- ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
(original)
+++ ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Mon Mar 1 05:06:16 2010
@@ -484,6 +484,9 @@
return obj.toString();
}
Class sourceClass = obj.getClass();
+if (sourceClass.getName().equals(type)) {
+return obj;
+}
if ("Object".equals(type) ||
"java.lang.Object".equals(type)) {
return obj;
}
>>> Are you sure this will work? Take a look at the following if statement.
>>
>> Yes, due a combination of things.
>>
>> If the object was null, return null.
>>
>> If converting to the same exact class as the incoming obj, return with
>> no change.
>>
>> If the incoming object is a string, and it is empty, return null.
>>
>> The above 3 constraints were pulled from the old version of
>> simpleTypeConvert.
>>
>> Without all three, if you tried to convert an empty String to a
>> String, you'd get null.
>
> I think you missed my point. Shouldn't the test be something like:
>
> if (sourceClass.getName().equals(type) ||
> sourceClass.getSimpleName().equals(type)) {
> return obj;
> }
>
> ?
>
> In other words, you can't count on type being "java.util.Date" - it
> might be simply "Date".
Another issue, is you are converting from a non-null String, that is
empty, then even if the class is not found, it still needs to return
null. That makes it difficult to place this particular test after the
loadClass call.
Re: svn commit: r917376 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Adrian Crum wrote:
> Adam Heath wrote:
>> Adrian Crum wrote:
>>> doo...@apache.org wrote:
Author: doogie
Date: Mon Mar 1 05:06:16 2010
New Revision: 917376
URL: http://svn.apache.org/viewvc?rev=917376&view=rev
Log:
BUG FIX: Move the check that tests whether we are converting to the
passed object to before the loadClass call.
Modified:
ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Modified:
ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java?rev=917376&r1=917375&r2=917376&view=diff
==
--- ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
(original)
+++ ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Mon Mar 1 05:06:16 2010
@@ -484,6 +484,9 @@
return obj.toString();
}
Class sourceClass = obj.getClass();
+if (sourceClass.getName().equals(type)) {
+return obj;
+}
if ("Object".equals(type) ||
"java.lang.Object".equals(type)) {
return obj;
}
>>> Are you sure this will work? Take a look at the following if statement.
>>
>> Yes, due a combination of things.
>>
>> If the object was null, return null.
>>
>> If converting to the same exact class as the incoming obj, return with
>> no change.
>>
>> If the incoming object is a string, and it is empty, return null.
>>
>> The above 3 constraints were pulled from the old version of
>> simpleTypeConvert.
>>
>> Without all three, if you tried to convert an empty String to a
>> String, you'd get null.
>
> I think you missed my point. Shouldn't the test be something like:
>
> if (sourceClass.getName().equals(type) ||
> sourceClass.getSimpleName().equals(type)) {
> return obj;
> }
>
> ?
>
> In other words, you can't count on type being "java.util.Date" - it
> might be simply "Date".
Except always testing against simpleName isn't right, as only certain
classes had simpleName tests from the previous version.
I see your point, however, and will fix it how you want, but only
insomuch that it matches the old version.
Re: svn commit: r917377 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/util: ObjectType.java test/ObjectTypeTests.java
Adam Heath wrote: I'd like to see others go thru and start *really* adding test cases. Every single time I have added full coverage on some class, I have *always* found something wrong. Sometimes, it was just a simple dead-code elimination. Others, like this latest push, had many more issues. If there is no coverage on a class/method/line, then it is *not* being tested. So how can you be sure that the change you are thinking of doing has any chance of working? Even with full coverage, all you can be certain is that your new code runs, and doesn't break any known test cases. It's still possible other things might break, but it's at least better than nothing. Thank you for all of the helpful information and advice. Personally, I'm trying to do a better job of testing code - so your recent work really helps me get a good feel for what is needed.
Re: svn commit: r917376 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Adam Heath wrote:
Adrian Crum wrote:
doo...@apache.org wrote:
Author: doogie
Date: Mon Mar 1 05:06:16 2010
New Revision: 917376
URL: http://svn.apache.org/viewvc?rev=917376&view=rev
Log:
BUG FIX: Move the check that tests whether we are converting to the
passed object to before the loadClass call.
Modified:
ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Modified:
ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java?rev=917376&r1=917375&r2=917376&view=diff
==
--- ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
(original)
+++ ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Mon Mar 1 05:06:16 2010
@@ -484,6 +484,9 @@
return obj.toString();
}
Class sourceClass = obj.getClass();
+if (sourceClass.getName().equals(type)) {
+return obj;
+}
if ("Object".equals(type) || "java.lang.Object".equals(type)) {
return obj;
}
Are you sure this will work? Take a look at the following if statement.
Yes, due a combination of things.
If the object was null, return null.
If converting to the same exact class as the incoming obj, return with
no change.
If the incoming object is a string, and it is empty, return null.
The above 3 constraints were pulled from the old version of
simpleTypeConvert.
Without all three, if you tried to convert an empty String to a
String, you'd get null.
I think you missed my point. Shouldn't the test be something like:
if (sourceClass.getName().equals(type) ||
sourceClass.getSimpleName().equals(type)) {
return obj;
}
?
In other words, you can't count on type being "java.util.Date" - it
might be simply "Date".
Re: svn commit: r917376 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Adrian Crum wrote:
> doo...@apache.org wrote:
>> Author: doogie
>> Date: Mon Mar 1 05:06:16 2010
>> New Revision: 917376
>>
>> URL: http://svn.apache.org/viewvc?rev=917376&view=rev
>> Log:
>> BUG FIX: Move the check that tests whether we are converting to the
>> passed object to before the loadClass call.
>>
>> Modified:
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
>>
>> Modified:
>> ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java?rev=917376&r1=917375&r2=917376&view=diff
>>
>> ==
>>
>> --- ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
>> (original)
>> +++ ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
>> Mon Mar 1 05:06:16 2010
>> @@ -484,6 +484,9 @@
>> return obj.toString();
>> }
>> Class sourceClass = obj.getClass();
>> +if (sourceClass.getName().equals(type)) {
>> +return obj;
>> +}
>> if ("Object".equals(type) || "java.lang.Object".equals(type)) {
>> return obj;
>> }
>
> Are you sure this will work? Take a look at the following if statement.
Yes, due a combination of things.
If the object was null, return null.
If converting to the same exact class as the incoming obj, return with
no change.
If the incoming object is a string, and it is empty, return null.
The above 3 constraints were pulled from the old version of
simpleTypeConvert.
Without all three, if you tried to convert an empty String to a
String, you'd get null.
Re: svn commit: r917369 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base: conversion/DateTimeConverters.java util/test/ObjectTypeTests.java
Adrian Crum wrote: > doo...@apache.org wrote: >> Author: doogie >> Date: Mon Mar 1 03:17:02 2010 >> New Revision: 917369 >> >> URL: http://svn.apache.org/viewvc?rev=917369&view=rev >> Log: >> BUG FIX: Forbid SqlDateToSqlTime and SqlTimeToSqlDate conversions. > > Good idea! Wasn't mine, that's how the original code functioned. But, the new way it was done is the best way, I think.
Re: svn commit: r917376 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
doo...@apache.org wrote:
Author: doogie
Date: Mon Mar 1 05:06:16 2010
New Revision: 917376
URL: http://svn.apache.org/viewvc?rev=917376&view=rev
Log:
BUG FIX: Move the check that tests whether we are converting to the
passed object to before the loadClass call.
Modified:
ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
Modified: ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java?rev=917376&r1=917375&r2=917376&view=diff
==
--- ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java
(original)
+++ ofbiz/trunk/framework/base/src/org/ofbiz/base/util/ObjectType.java Mon Mar
1 05:06:16 2010
@@ -484,6 +484,9 @@
return obj.toString();
}
Class sourceClass = obj.getClass();
+if (sourceClass.getName().equals(type)) {
+return obj;
+}
if ("Object".equals(type) || "java.lang.Object".equals(type)) {
return obj;
}
Are you sure this will work? Take a look at the following if statement.
Re: svn commit: r917369 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base: conversion/DateTimeConverters.java util/test/ObjectTypeTests.java
doo...@apache.org wrote: Author: doogie Date: Mon Mar 1 03:17:02 2010 New Revision: 917369 URL: http://svn.apache.org/viewvc?rev=917369&view=rev Log: BUG FIX: Forbid SqlDateToSqlTime and SqlTimeToSqlDate conversions. Good idea!
Re: OFBiz libraries versus Hot-deployed component ones
Adam Heath wrote: Christopher Snow wrote: Adam Heath wrote: Christopher Snow wrote: Adam Heath wrote: Christopher Snow wrote: I think each component gets its own class loader, so this should be happening anyway. No, there is a single classloader for all of ofbiz. Thanks for clarifying Adam. It's actually slightly more complex. start.jar begins, and it can only see itself. It is then hard-coded(sorta, thru the use of internal properties files embedded in the jar) to find all libraries in framework/base/lib, and add then to an initial classloader. This classloader contains the container and component loading logic. That finds the rest of ofbiz, and creates a second classloader. Note, that this second classloader has duplicate framework/base libs, and that the first one might have framework/base libs that it shouldn't, because the ofbiz-component.xml for base may not include some library folder. Then, all the containers start. One of those is catalina. For each web-app, it does create a separate classloader, and it might be possible to override libraries there, by using WEB-INF/lib. But this is not the standard ofbiz way. OSGi would be a nice solution to this problem! What problem? Control over which version of a library you depend on without having to setup and manage your own classloader.
Re: OFBiz libraries versus Hot-deployed component ones
Christopher Snow wrote: > Adam Heath wrote: >> Christopher Snow wrote: >> >>> Adam Heath wrote: >>> Christopher Snow wrote: > I think each component gets its own class loader, so this should be > happening anyway. > No, there is a single classloader for all of ofbiz. >>> Thanks for clarifying Adam. >>> >> >> It's actually slightly more complex. >> >> start.jar begins, and it can only see itself. >> >> It is then hard-coded(sorta, thru the use of internal properties files >> embedded in the jar) to find all libraries in framework/base/lib, and >> add then to an initial classloader. >> >> This classloader contains the container and component loading logic. >> That finds the rest of ofbiz, and creates a second classloader. Note, >> that this second classloader has duplicate framework/base libs, and >> that the first one might have framework/base libs that it shouldn't, >> because the ofbiz-component.xml for base may not include some library >> folder. >> >> Then, all the containers start. One of those is catalina. For each >> web-app, it does create a separate classloader, and it might be >> possible to override libraries there, by using WEB-INF/lib. But this >> is not the standard ofbiz way. >> > OSGi would be a nice solution to this problem! What problem?
Re: OFBiz libraries versus Hot-deployed component ones
Adam Heath wrote: Christopher Snow wrote: Adam Heath wrote: Christopher Snow wrote: I think each component gets its own class loader, so this should be happening anyway. No, there is a single classloader for all of ofbiz. Thanks for clarifying Adam. It's actually slightly more complex. start.jar begins, and it can only see itself. It is then hard-coded(sorta, thru the use of internal properties files embedded in the jar) to find all libraries in framework/base/lib, and add then to an initial classloader. This classloader contains the container and component loading logic. That finds the rest of ofbiz, and creates a second classloader. Note, that this second classloader has duplicate framework/base libs, and that the first one might have framework/base libs that it shouldn't, because the ofbiz-component.xml for base may not include some library folder. Then, all the containers start. One of those is catalina. For each web-app, it does create a separate classloader, and it might be possible to override libraries there, by using WEB-INF/lib. But this is not the standard ofbiz way. OSGi would be a nice solution to this problem!
Re: OFBiz libraries versus Hot-deployed component ones
Christopher Snow wrote: > Adam Heath wrote: >> Christopher Snow wrote: >> >>> I think each component gets its own class loader, so this should be >>> happening anyway. >>> >> >> No, there is a single classloader for all of ofbiz. >> >> > Thanks for clarifying Adam. It's actually slightly more complex. start.jar begins, and it can only see itself. It is then hard-coded(sorta, thru the use of internal properties files embedded in the jar) to find all libraries in framework/base/lib, and add then to an initial classloader. This classloader contains the container and component loading logic. That finds the rest of ofbiz, and creates a second classloader. Note, that this second classloader has duplicate framework/base libs, and that the first one might have framework/base libs that it shouldn't, because the ofbiz-component.xml for base may not include some library folder. Then, all the containers start. One of those is catalina. For each web-app, it does create a separate classloader, and it might be possible to override libraries there, by using WEB-INF/lib. But this is not the standard ofbiz way.
Re: OFBiz libraries versus Hot-deployed component ones
Adam Heath wrote: Christopher Snow wrote: I think each component gets its own class loader, so this should be happening anyway. No, there is a single classloader for all of ofbiz. Thanks for clarifying Adam.
Re: OFBiz libraries versus Hot-deployed component ones
Christopher Snow wrote: > I think each component gets its own class loader, so this should be > happening anyway. No, there is a single classloader for all of ofbiz.
[jira] Resolved: (OFBIZ-3518) German Label optimization
[ https://issues.apache.org/jira/browse/OFBIZ-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Geisert resolved OFBIZ-3518. -- Resolution: Fixed Committed after correcting some problems by hand (a few hunks FAILED, a few tabs removed, a few words changed (ProductStore, Locale ...)) Thanks for your contribution! Are you aware of http://cwiki.apache.org/confluence/display/OFBIZ/Dictionary+for+translations+to+German ? > German Label optimization > - > > Key: OFBIZ-3518 > URL: https://issues.apache.org/jira/browse/OFBIZ-3518 > Project: OFBiz > Issue Type: Improvement > Components: accounting, framework, marketing, party, product >Affects Versions: SVN trunk >Reporter: Mirko Vogelsmeier >Assignee: Christian Geisert >Priority: Minor > Attachments: OfbizLabelsUpdate.patch, OfbizLabelsUpdate2.patch > > > Update of german labels > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3442) Replace popup lookups by layer lookups
[ https://issues.apache.org/jira/browse/OFBIZ-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839691#action_12839691 ] Sascha Rodekamp commented on OFBIZ-3442: Hi Jacques, that sounds great... so if there anythink where i can help you... let me know! I think we can handle this :) > Replace popup lookups by layer lookups > -- > > Key: OFBIZ-3442 > URL: https://issues.apache.org/jira/browse/OFBIZ-3442 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-3442 replace popup lookups by layered > lookups.patch, OFBIZ-3442 replace popup lookups by layered lookups.patch, > OFBIZ-3442 replace popup lookups by layered lookups.patch, OFBIZ-3442 replace > popup lookups by layered lookups.patch, OFBIZ-3442 replace popup lookups by > layered lookups.patch > > > Following Sascha Rodekamp's work on layer lookups OFBIZ-3374 and > improvements OFBIZ-3430, I propose now to replace old the popup lookups by > layered (Ajaxified) lookups. > For that please find a patch attached. In this patch I followed a simple S/R > tactic: > * I replaced all occurences of LookupDecorator by LookupLayerPopupDecorator > in screens > * I replaced all occurences of position="center" > It's as simple as this. For the moment I decided to use as default > position="center" because it's was the easiest (sure that any lookups will be > out of the screen). I think we will refine this by removing position="center" > and use the default (position="normal") which does not move the layer from > the point it's called and will be more aesthetic. > I did not test anything in OFBIz OOTB for the moment, but I already use > layered lookups in a custom application without any issues so far. > The only drawback I found for the moment is when a lookup is called from a > lookup. If you are aware of such cases please chime in. > Of course everybody is encouraged to test this improvement as much as > possible. I really think it's a very cool feature for users, and they will > appreciate. There are still some ideas like that (see the link Sasca referred > to in OFBIZ-3374), and we will try to implement them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3442) Replace popup lookups by layer lookups
[ https://issues.apache.org/jira/browse/OFBIZ-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839686#action_12839686 ] Jacques Le Roux commented on OFBIZ-3442: Hi Sascha, Yes I had fixed that already. As I use the layered lookups in a custom application I had to fix it there. I fixed also the ListTimezones but at this time I did not create a patch as I thought I would commit all the changes. Actually it's ready to be commited for almost a month now and I think I will really commit pretty soon. I think I will let apart the lookups which are not working (with or without layering) to not let think we introduced bugs with the layering... Except if Iget enough time to fix them... > Replace popup lookups by layer lookups > -- > > Key: OFBIZ-3442 > URL: https://issues.apache.org/jira/browse/OFBIZ-3442 > Project: OFBiz > Issue Type: Sub-task > Components: ALL COMPONENTS >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-3442 replace popup lookups by layered > lookups.patch, OFBIZ-3442 replace popup lookups by layered lookups.patch, > OFBIZ-3442 replace popup lookups by layered lookups.patch, OFBIZ-3442 replace > popup lookups by layered lookups.patch, OFBIZ-3442 replace popup lookups by > layered lookups.patch > > > Following Sascha Rodekamp's work on layer lookups OFBIZ-3374 and > improvements OFBIZ-3430, I propose now to replace old the popup lookups by > layered (Ajaxified) lookups. > For that please find a patch attached. In this patch I followed a simple S/R > tactic: > * I replaced all occurences of LookupDecorator by LookupLayerPopupDecorator > in screens > * I replaced all occurences of position="center" > It's as simple as this. For the moment I decided to use as default > position="center" because it's was the easiest (sure that any lookups will be > out of the screen). I think we will refine this by removing position="center" > and use the default (position="normal") which does not move the layer from > the point it's called and will be more aesthetic. > I did not test anything in OFBIz OOTB for the moment, but I already use > layered lookups in a custom application without any issues so far. > The only drawback I found for the moment is when a lookup is called from a > lookup. If you are aware of such cases please chime in. > Of course everybody is encouraged to test this improvement as much as > possible. I really think it's a very cool feature for users, and they will > appreciate. There are still some ideas like that (see the link Sasca referred > to in OFBIZ-3374), and we will try to implement them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3526) Expression startDate.compareTo is undefined on line 60, column 11 in component://workeffort/webapp/workeffort/calendar/week.ftl
[ https://issues.apache.org/jira/browse/OFBIZ-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839683#action_12839683 ] Jacques Le Roux commented on OFBIZ-3526: Weird: I don't reproduce locally Release-revision : trunk-917457, but yes see it on trunk. Maybe it has been fixed already as the demo is still updated by hand... > Expression startDate.compareTo is undefined on line 60, column 11 in > component://workeffort/webapp/workeffort/calendar/week.ftl > --- > > Key: OFBIZ-3526 > URL: https://issues.apache.org/jira/browse/OFBIZ-3526 > Project: OFBiz > Issue Type: Bug > Components: workeffort >Affects Versions: SVN trunk > Environment: https://ofbiz-vm.apache.org/workeffort/control/calendar >Reporter: chris snow > > https://ofbiz-vm.apache.org/workeffort/control/calendar > returns: > Expression startDate.compareTo is undefined on line 60, column 11 in > component://workeffort/webapp/workeffort/calendar/week.ftl. The problematic > instruction: -- ==> if-else [on line 60, column 5 in > component://workeffort/webapp/workeffort/calendar/week.ftl] -- Java > backtrace for programmers: -- > freemarker.core.InvalidReferenceException: Expression startDate.compareTo is > undefined on line 60, column 11 in > component://workeffort/webapp/workeffort/calendar/week.ftl. at > freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:124) at > freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:134) > at freemarker.core.MethodCall._getAsTemplateModel(MethodCall.java:114) at > freemarker.core.Expression.getAsTemplateModel(Expression.java:89) at > freemarker.core.ComparisonExpression.isTrue(ComparisonExpression.java:111) at > freemarker.core.AndExpression.isTrue(AndExpression.java:68) at > freemarker.core.AndExpression.isTrue(AndExpression.java:68) at > freemarker.core.ParentheticalExpression.isTrue(ParentheticalExpression.java:66) > at freemarker.core.IfBlock.accept(IfBlock.java:80) at > freemarker.core.Environment.visit(Environment.java:209) at > freemarker.core.MixedContent.accept(MixedContent.java:92) at > freemarker.core.Environment.visit(Environment.java:209) at > freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:79) at > freemarker.core.Environment.visit(Environment.java:209) at > freemarker.core.MixedContent.accept(MixedContent.java:92) at > freemarker.core.Environment.visit(Environment.java:209) at > freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:167) at > freemarker.core.Environment.visit(Environment.java:416) at > freemarker.core.IteratorBlock.accept(IteratorBlock.java:102) at > freemarker.core.Environment.visit(Environment.java:209) at > freemarker.core.MixedContent.accept(MixedContent.java:92) at > freemarker.core.Environment.visit(Environment.java:209) at > freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:167) at > freemarker.core.Environment.visit(Environment.java:416) at > freemarker.core.IteratorBlock.accept(IteratorBlock.java:102) at > freemarker.core.Environment.visit(Environment.java:209) at > freemarker.core.MixedContent.accept(MixedContent.java:92) at > freemarker.core.Environment.visit(Environment.java:209) at > freemarker.core.IfBlock.accept(IfBlock.java:82) at > freemarker.core.Environment.visit(Environment.java:209) at > freemarker.core.MixedContent.accept(MixedContent.java:92) at > freemarker.core.Environment.visit(Environment.java:209) at > freemarker.core.Environment.process(Environment.java:189) at > org.ofbiz.base.util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:205) > at > org.ofbiz.widget.screen.HtmlWidget.renderHtmlTemplate(HtmlWidget.java:205) at > org.ofbiz.widget.screen.HtmlWidget$HtmlTemplate.renderWidgetString(HtmlWidget.java:250) > at > org.ofbiz.widget.screen.HtmlWidget.renderWidgetString(HtmlWidget.java:110) at > org.ofbiz.widget.screen.ModelScreenWidget$PlatformSpecific.renderWidgetString(ModelScreenWidget.java:1001) > at > org.ofbiz.widget.screen.MacroScreenRenderer.renderScreenletSubWidget(MacroScreenRenderer.java:704) > at > org.ofbiz.widget.screen.ModelScreenWidget$Screenlet.renderWidgetString(ModelScreenWidget.java:408) > at > org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:137) > at > org.ofbiz.widget.screen.ModelScreenWidget$Container.renderWidgetString(ModelScreenWidget.java:296) > at > org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:137) > at > org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:228) > at > org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScr
[jira] Created: (OFBIZ-3526) Expression startDate.compareTo is undefined on line 60, column 11 in component://workeffort/webapp/workeffort/calendar/week.ftl
Expression startDate.compareTo is undefined on line 60, column 11 in component://workeffort/webapp/workeffort/calendar/week.ftl --- Key: OFBIZ-3526 URL: https://issues.apache.org/jira/browse/OFBIZ-3526 Project: OFBiz Issue Type: Bug Components: workeffort Affects Versions: SVN trunk Environment: https://ofbiz-vm.apache.org/workeffort/control/calendar Reporter: chris snow https://ofbiz-vm.apache.org/workeffort/control/calendar returns: Expression startDate.compareTo is undefined on line 60, column 11 in component://workeffort/webapp/workeffort/calendar/week.ftl. The problematic instruction: -- ==> if-else [on line 60, column 5 in component://workeffort/webapp/workeffort/calendar/week.ftl] -- Java backtrace for programmers: -- freemarker.core.InvalidReferenceException: Expression startDate.compareTo is undefined on line 60, column 11 in component://workeffort/webapp/workeffort/calendar/week.ftl. at freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:124) at freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:134) at freemarker.core.MethodCall._getAsTemplateModel(MethodCall.java:114) at freemarker.core.Expression.getAsTemplateModel(Expression.java:89) at freemarker.core.ComparisonExpression.isTrue(ComparisonExpression.java:111) at freemarker.core.AndExpression.isTrue(AndExpression.java:68) at freemarker.core.AndExpression.isTrue(AndExpression.java:68) at freemarker.core.ParentheticalExpression.isTrue(ParentheticalExpression.java:66) at freemarker.core.IfBlock.accept(IfBlock.java:80) at freemarker.core.Environment.visit(Environment.java:209) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:209) at freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:79) at freemarker.core.Environment.visit(Environment.java:209) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:209) at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:167) at freemarker.core.Environment.visit(Environment.java:416) at freemarker.core.IteratorBlock.accept(IteratorBlock.java:102) at freemarker.core.Environment.visit(Environment.java:209) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:209) at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:167) at freemarker.core.Environment.visit(Environment.java:416) at freemarker.core.IteratorBlock.accept(IteratorBlock.java:102) at freemarker.core.Environment.visit(Environment.java:209) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:209) at freemarker.core.IfBlock.accept(IfBlock.java:82) at freemarker.core.Environment.visit(Environment.java:209) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:209) at freemarker.core.Environment.process(Environment.java:189) at org.ofbiz.base.util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:205) at org.ofbiz.widget.screen.HtmlWidget.renderHtmlTemplate(HtmlWidget.java:205) at org.ofbiz.widget.screen.HtmlWidget$HtmlTemplate.renderWidgetString(HtmlWidget.java:250) at org.ofbiz.widget.screen.HtmlWidget.renderWidgetString(HtmlWidget.java:110) at org.ofbiz.widget.screen.ModelScreenWidget$PlatformSpecific.renderWidgetString(ModelScreenWidget.java:1001) at org.ofbiz.widget.screen.MacroScreenRenderer.renderScreenletSubWidget(MacroScreenRenderer.java:704) at org.ofbiz.widget.screen.ModelScreenWidget$Screenlet.renderWidgetString(ModelScreenWidget.java:408) at org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:137) at org.ofbiz.widget.screen.ModelScreenWidget$Container.renderWidgetString(ModelScreenWidget.java:296) at org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:137) at org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:228) at org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:137) at org.ofbiz.widget.screen.ModelScreenWidget$Section.renderWidgetString(ModelScreenWidget.java:228) at org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:394) at org.ofbiz.widget.screen.ModelScreenWidget$IncludeScreen.renderWidgetString(ModelScreenWidget.java:576) at org.ofbiz.widget.screen.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:137) at org.ofbiz.widget.screen.ModelScreenWidget$DecoratorSection.renderWidgetString(ModelScreenWidget.java:704) at org.ofbiz.widget.screen.ModelScreenWidg
Tomahawk theme
Hi, I think we should change the color of the links inside the lookups list (stayed blue) Jacques
Re: Consistent result messages
Thanks guys, done in rev 917467 Bilgin
Re: OFBiz libraries versus Hot-deployed component ones
Thanks for replying, That's what I am doing, here is my ofbiz-component.xml http://www.w3.org/2001/XMLSchema-instance"; xsi:noNamespaceSchemaLocation="http://www.ofbiz.org/dtds/ofbiz-component.xsd";> But it still using a library from OFBiz rather than one declared on the classpath. May be I should set-up my class loader called "nova" somewhere else? -- View this message in context: http://n4.nabble.com/OFBiz-libraries-versus-Hot-deployed-component-ones-tp1573363p1573409.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: OFBiz libraries versus Hot-deployed component ones
I think each component gets its own class loader, so this should be happening anyway. Kévin Sailly wrote: Hello, I have searched on forum, documentation and on the code and didn't find an answer to this question: Is it possible to force a hot-deployed component to use it's own libraries rather than concurent ones used by OFBiz? Thanks a lot, Kévin Sailly
OFBiz libraries versus Hot-deployed component ones
Hello, I have searched on forum, documentation and on the code and didn't find an answer to this question: Is it possible to force a hot-deployed component to use it's own libraries rather than concurent ones used by OFBiz? Thanks a lot, Kévin Sailly -- View this message in context: http://n4.nabble.com/OFBiz-libraries-versus-Hot-deployed-component-ones-tp1573363p1573363.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
[jira] Closed: (OFBIZ-3525) Password Hint Message should be an event message, not error message
[
https://issues.apache.org/jira/browse/OFBIZ-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux closed OFBIZ-3525.
--
Resolution: Fixed
Fix Version/s: SVN trunk
Assignee: Jacques Le Roux
But of course please next time follow the contributor best practices, TIA.
Fixed in trunk at r917435 , R9.04 r917436
> Password Hint Message should be an event message, not error message
> ---
>
> Key: OFBIZ-3525
> URL: https://issues.apache.org/jira/browse/OFBIZ-3525
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Release Branch 9.04
>Reporter: Koon Sang
>Assignee: Jacques Le Roux
> Fix For: Release Branch 9.04, SVN trunk
>
> Attachments: LoginEvents.java
>
>
> Hi,
> When I change password from ecommerce, I got the following message which
> appears in red, meaning it is an error message.
> The Following Errors Occurred:
> The Password Hint is: x.
> This is alarming to the user. It should be an event message instead of an
> error message. I have changed the code at line 162 and here is the patch. I
> only change this line
> request.setAttribute("_ERROR_MESSAGE_", errMsg);
> to
> request.setAttribute("_EVENT_MESSAGE_", errMsg);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3525) Password Hint Message should be an event message, not error message
[
https://issues.apache.org/jira/browse/OFBIZ-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839617#action_12839617
]
Jacques Le Roux commented on OFBIZ-3525:
OK, forget my comment, I have checked it's ok I will commit your change in
trunk and R9.04
Thanks
> Password Hint Message should be an event message, not error message
> ---
>
> Key: OFBIZ-3525
> URL: https://issues.apache.org/jira/browse/OFBIZ-3525
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Release Branch 9.04
>Reporter: Koon Sang
> Fix For: Release Branch 9.04
>
> Attachments: LoginEvents.java
>
>
> Hi,
> When I change password from ecommerce, I got the following message which
> appears in red, meaning it is an error message.
> The Following Errors Occurred:
> The Password Hint is: x.
> This is alarming to the user. It should be an event message instead of an
> error message. I have changed the code at line 162 and here is the patch. I
> only change this line
> request.setAttribute("_ERROR_MESSAGE_", errMsg);
> to
> request.setAttribute("_EVENT_MESSAGE_", errMsg);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3524) Some improvements for the layer lookup
[ https://issues.apache.org/jira/browse/OFBIZ-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839612#action_12839612 ] Sascha Rodekamp commented on OFBIZ-3524: Hi Jacques. In my opinion it's nesseary when i want to give a focus to my lookup, it can be helpfull to dim the background (and it's a nice effect i think :-)). The fade_background.png is the image which is responsable for the backgroundfading, i put it in every theme that the fading color can be set theme sprecific (if someone want to). > Some improvements for the layer lookup > -- > > Key: OFBIZ-3524 > URL: https://issues.apache.org/jira/browse/OFBIZ-3524 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp > Fix For: SVN trunk > > Attachments: faded_background.png, OFBIZ-3524_Fade_Background.patch, > OFBIZ-3524_Fade_Background.patch > > > Hi Jacques, hi all > i created a new patch for the layer lookup field. > This Patch contains the patches > [OFBIZ-3491|https://issues.apache.org/jira/browse/OFBIZ-3491], > [OFBIZ-3492|https://issues.apache.org/jira/browse/OFBIZ-3492] (i will close > the issues). > Furthermore i added a flag to fade the background when a layer opened. In my > opinion it's nesseary when i want to give a focus to my lookup. > After apllying the patch the picture faded_background.png have to be copied > to the image folder of *each* theme. > Have a nice day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3525) Password Hint Message should be an event message, not error message
[
https://issues.apache.org/jira/browse/OFBIZ-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839609#action_12839609
]
Jacques Le Roux commented on OFBIZ-3525:
BTW did you try only with R9.04? Ie, is it the same situation with the trunk?
(I suppose it is)
> Password Hint Message should be an event message, not error message
> ---
>
> Key: OFBIZ-3525
> URL: https://issues.apache.org/jira/browse/OFBIZ-3525
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Release Branch 9.04
>Reporter: Koon Sang
> Fix For: Release Branch 9.04
>
> Attachments: LoginEvents.java
>
>
> Hi,
> When I change password from ecommerce, I got the following message which
> appears in red, meaning it is an error message.
> The Following Errors Occurred:
> The Password Hint is: x.
> This is alarming to the user. It should be an event message instead of an
> error message. I have changed the code at line 162 and here is the patch. I
> only change this line
> request.setAttribute("_ERROR_MESSAGE_", errMsg);
> to
> request.setAttribute("_EVENT_MESSAGE_", errMsg);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3524) Some improvements for the layer lookup
[ https://issues.apache.org/jira/browse/OFBIZ-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839610#action_12839610 ] Jacques Le Roux commented on OFBIZ-3524: Hi Sascha, Could you please explain why it's necessary? > Some improvements for the layer lookup > -- > > Key: OFBIZ-3524 > URL: https://issues.apache.org/jira/browse/OFBIZ-3524 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp > Fix For: SVN trunk > > Attachments: faded_background.png, OFBIZ-3524_Fade_Background.patch, > OFBIZ-3524_Fade_Background.patch > > > Hi Jacques, hi all > i created a new patch for the layer lookup field. > This Patch contains the patches > [OFBIZ-3491|https://issues.apache.org/jira/browse/OFBIZ-3491], > [OFBIZ-3492|https://issues.apache.org/jira/browse/OFBIZ-3492] (i will close > the issues). > Furthermore i added a flag to fade the background when a layer opened. In my > opinion it's nesseary when i want to give a focus to my lookup. > After apllying the patch the picture faded_background.png have to be copied > to the image folder of *each* theme. > Have a nice day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3525) Password Hint Message should be an event message, not error message
[
https://issues.apache.org/jira/browse/OFBIZ-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839607#action_12839607
]
Jacques Le Roux commented on OFBIZ-3525:
Hi Kon Sang,
Please provide a patch instead of a complete java file. See the [how to
here|http://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices]
> Password Hint Message should be an event message, not error message
> ---
>
> Key: OFBIZ-3525
> URL: https://issues.apache.org/jira/browse/OFBIZ-3525
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Release Branch 9.04
>Reporter: Koon Sang
> Fix For: Release Branch 9.04
>
> Attachments: LoginEvents.java
>
>
> Hi,
> When I change password from ecommerce, I got the following message which
> appears in red, meaning it is an error message.
> The Following Errors Occurred:
> The Password Hint is: x.
> This is alarming to the user. It should be an event message instead of an
> error message. I have changed the code at line 162 and here is the patch. I
> only change this line
> request.setAttribute("_ERROR_MESSAGE_", errMsg);
> to
> request.setAttribute("_EVENT_MESSAGE_", errMsg);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
CSS display error in project manager Gantt chart
Hi all,
In the project manager application, when displaying the Gantt chart, we
have a CSS display error.
the Gantt chart is made of 2 tables, one for the text (tasks labels,
...), and the second one is for the chart itself. The problem we have
is those two tables are drifted, and a label is not in front of the
right chart's line.
I have created an issue on this problem
(https://issues.apache.org/jira/browse/OFBIZ-3455), and found while
reading the jsgantt bug tracker this issue saying that the reason of
this may come from a CSS property like this one :
div { position:relative !important; }
The problem is present with all the themes.
So if some CSS guru could take a look at this problem, this would be
very nice.
Cheers,
--
Erwan de FERRIERES
www.nereide.biz
[jira] Updated: (OFBIZ-3525) Password Hint Message should be an event message, not error message
[
https://issues.apache.org/jira/browse/OFBIZ-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koon Sang updated OFBIZ-3525:
-
Attachment: LoginEvents.java
Change line 162
> Password Hint Message should be an event message, not error message
> ---
>
> Key: OFBIZ-3525
> URL: https://issues.apache.org/jira/browse/OFBIZ-3525
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Release Branch 9.04
>Reporter: Koon Sang
> Fix For: Release Branch 9.04
>
> Attachments: LoginEvents.java
>
>
> Hi,
> When I change password from ecommerce, I got the following message which
> appears in red, meaning it is an error message.
> The Following Errors Occurred:
> The Password Hint is: x.
> This is alarming to the user. It should be an event message instead of an
> error message. I have changed the code at line 162 and here is the patch. I
> only change this line
> request.setAttribute("_ERROR_MESSAGE_", errMsg);
> to
> request.setAttribute("_EVENT_MESSAGE_", errMsg);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3525) Password Hint Message should be an event message, not error message
Password Hint Message should be an event message, not error message
---
Key: OFBIZ-3525
URL: https://issues.apache.org/jira/browse/OFBIZ-3525
Project: OFBiz
Issue Type: Improvement
Affects Versions: Release Branch 9.04
Reporter: Koon Sang
Fix For: Release Branch 9.04
Hi,
When I change password from ecommerce, I got the following message which
appears in red, meaning it is an error message.
The Following Errors Occurred:
The Password Hint is: x.
This is alarming to the user. It should be an event message instead of an
error message. I have changed the code at line 162 and here is the patch. I
only change this line
request.setAttribute("_ERROR_MESSAGE_", errMsg);
to
request.setAttribute("_EVENT_MESSAGE_", errMsg);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3524) Some improvements for the layer lookup
[ https://issues.apache.org/jira/browse/OFBIZ-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sascha Rodekamp updated OFBIZ-3524: --- Attachment: (was: faded_background.png) > Some improvements for the layer lookup > -- > > Key: OFBIZ-3524 > URL: https://issues.apache.org/jira/browse/OFBIZ-3524 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp > Fix For: SVN trunk > > Attachments: faded_background.png, OFBIZ-3524_Fade_Background.patch, > OFBIZ-3524_Fade_Background.patch > > > Hi Jacques, hi all > i created a new patch for the layer lookup field. > This Patch contains the patches > [OFBIZ-3491|https://issues.apache.org/jira/browse/OFBIZ-3491], > [OFBIZ-3492|https://issues.apache.org/jira/browse/OFBIZ-3492] (i will close > the issues). > Furthermore i added a flag to fade the background when a layer opened. In my > opinion it's nesseary when i want to give a focus to my lookup. > After apllying the patch the picture faded_background.png have to be copied > to the image folder of *each* theme. > Have a nice day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3524) Some improvements for the layer lookup
[ https://issues.apache.org/jira/browse/OFBIZ-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sascha Rodekamp updated OFBIZ-3524: --- Attachment: faded_background.png OFBIZ-3524_Fade_Background.patch Hi Jacques, so i created a new (seperate) patch for the fading backgorund. The fade_background.png image have to put in the following folders: bizznesstime/webapp/bizznesstime/images/ blulight/webapp/bluelight/images/ droppingcrumbs/webapp/droppingcrumbs/images/ flatgrey/webapp/flatgrey/ tomahawk/webapp/tomahawk/images/ > Some improvements for the layer lookup > -- > > Key: OFBIZ-3524 > URL: https://issues.apache.org/jira/browse/OFBIZ-3524 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp > Fix For: SVN trunk > > Attachments: faded_background.png, faded_background.png, > OFBIZ-3524_Fade_Background.patch, OFBIZ-3524_Fade_Background.patch > > > Hi Jacques, hi all > i created a new patch for the layer lookup field. > This Patch contains the patches > [OFBIZ-3491|https://issues.apache.org/jira/browse/OFBIZ-3491], > [OFBIZ-3492|https://issues.apache.org/jira/browse/OFBIZ-3492] (i will close > the issues). > Furthermore i added a flag to fade the background when a layer opened. In my > opinion it's nesseary when i want to give a focus to my lookup. > After apllying the patch the picture faded_background.png have to be copied > to the image folder of *each* theme. > Have a nice day > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
