Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
From: "Jacques Le Roux" From: "Adam Heath" Jacques Le Roux wrote: Personnally, I see more harms than benefits as time goes by. I think it's time for a vote. +1 to remove Not official, but +1 from me too If we don't remove it we should at least take care of issues like the one we just crossed with JavaDoc. Actually, I can't see any other kind of issues, so simply commenting out JavaDoc targets in /shark/build.xml (with a comment about like in framework/build.xml) would be sufficient in this case. Well, I've made it compile, which should fix basic parse issues with javadoc. Yes, thanks Adam, but we all know this will come over and over in the future... If we remove it, we could attach an archive of the component at https://issues.apache.org/jira/browse/OFBIZ-552. And as David said (thanks for the links Scott), we should do the same for the workflow component which is even older... Don't need to attach an archive. It'll exist in svn history. Maybe it's more convenient though to have all ready in one place. We could also create a deprecated directories and put there all deprecated components in the future (for now workflow and shark) ? There will be easy to reach with special directions to use but disconnected from current work... Jacques Jacques
Re: Selenium ehlp
Bump! Jacques From: "Jacques Le Roux" Also, should we free the comment at ? With Oxygen it's "easy" to handle listitem and orderedlist, I mean I can do it if needed... Jacques From: "Jacques Le Roux" Hi, In HELP_WEBTOOLS_selenium.xml. This snippet refers to screen shots that don't exist. Is this a WIP or missing simply ? There also a such paragraph in OfbizSeleniumSetupHTTPS.xml Thanks Jacques
[jira] Updated: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine
[ https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Crum updated OFBIZ-3245: --- Attachment: conversion.patch Updated patch. The new field-type attribute is called jdbc-data-type. > Sandbox: Integrating The New Conversion Framework Into The Entity Engine > > > Key: OFBIZ-3245 > URL: https://issues.apache.org/jira/browse/OFBIZ-3245 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Adrian Crum >Assignee: Adrian Crum >Priority: Minor > Attachments: conversion.patch, conversion.patch, conversion.patch, > conversion.patch > > > This issue contains a patch intended for evaluation before it is committed. > See comments for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Clearing cache is really sloooowww
This is no longer an issue, thanks Adam Jacques From: "Jacques Le Roux" Hi, I don't know if some of you have tried to clear caches these last times, but it's now very, very, very slow... (more than 10 times, maybe even more than 100x...) Jacques
Re: from BIZZNESS_TIME to DROPPING_CRUMB ?
From: "Adrian Crum" -1 When the main application menu extends below the bottom of the screen, there is no way to select the hidden items. When you move the mouse cursor to the bottom, the menu disappears. Right, this is theo nly drawback I see so far, I have even reopened https://issues.apache.org/jira/browse/OFBIZ-3239 for that In the Bizznesstime theme, the main application menu stays on the screen until an item is selected. I have also suggested to Bruno to split the menu like it's done in Bizness Time, far easier to use than a very long menu. Thanks Jacques -Adrian Jacques Le Roux wrote: Hi, I wonder if we should no change the default theme from BIZZNESS_TIME to DROPPING_CRUMB. I know it will not be consistent anymore with Site and Doc but looking at https://issues.apache.org/jira/browse/OFBIZ-2398 I think DROPPING_CRUMB is doing a better job and has a real good look now Jacques
[jira] Reopened: (OFBIZ-3239) Styling flaws in DroppingCrumbs
[
https://issues.apache.org/jira/browse/OFBIZ-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Le Roux reopened OFBIZ-3239:
Quoting Adrian on dev ML
{quote}
When the main application menu extends below the bottom of the screen,
there is no way to select the hidden items. When you move the mouse
cursor to the bottom, the menu disappears.
{quote}
> Styling flaws in DroppingCrumbs
> ---
>
> Key: OFBIZ-3239
> URL: https://issues.apache.org/jira/browse/OFBIZ-3239
> Project: OFBiz
> Issue Type: Bug
> Components: ALL APPLICATIONS
>Affects Versions: SVN trunk
>Reporter: Jacques Le Roux
>Assignee: Bruno Busco
>Priority: Trivial
> Fix For: SVN trunk
>
>
> Main task
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
From: "Adam Heath" Jacques Le Roux wrote: Personnally, I see more harms than benefits as time goes by. I think it's time for a vote. +1 to remove Not official, but +1 from me too If we don't remove it we should at least take care of issues like the one we just crossed with JavaDoc. Actually, I can't see any other kind of issues, so simply commenting out JavaDoc targets in /shark/build.xml (with a comment about like in framework/build.xml) would be sufficient in this case. Well, I've made it compile, which should fix basic parse issues with javadoc. Yes, thanks Adam, but we all know this will come over and over in the future... If we remove it, we could attach an archive of the component at https://issues.apache.org/jira/browse/OFBIZ-552. And as David said (thanks for the links Scott), we should do the same for the workflow component which is even older... Don't need to attach an archive. It'll exist in svn history. Maybe it's more convenient though to have all ready in one place. Jacques
[jira] Commented: (OFBIZ-3261) DemoRepStore PartyId data not correct
[ https://issues.apache.org/jira/browse/OFBIZ-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782780#action_12782780 ] Aswath Satrasala commented on OFBIZ-3261: - admin is not removed. It is just the typo at that place I think. Instead of DemoRepStore, it is typed as admin. admin entry is already at DemoProduct.xml - line 128 > DemoRepStore PartyId data not correct > - > > Key: OFBIZ-3261 > URL: https://issues.apache.org/jira/browse/OFBIZ-3261 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: SVN trunk >Reporter: Aswath Satrasala > Attachments: DemoRepStore.patch > > > DemoRepStore party should be able to create orders for StoreId=9000 only. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3227) Drag'n'Drop update - add directly in the my portal application
[ https://issues.apache.org/jira/browse/OFBIZ-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782778#action_12782778 ] Sascha Rodekamp commented on OFBIZ-3227: Hi Bruno, yeah i see the problem, last night i had a good idea, how to fix it. I hope i can improve the code today. Jacques, i will have a look. Maybe i find some time at the weekend. :-) Best Regards and a nice day... Sascha > Drag'n'Drop update - add directly in the my portal application > -- > > Key: OFBIZ-3227 > URL: https://issues.apache.org/jira/browse/OFBIZ-3227 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Bruno Busco > Fix For: SVN trunk > > Attachments: myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, screen1.gif, screen2.gif, screen3.gif, > screenshot-1.jpg > > > Hi, > Michael ask to add the Drag'n' Drop Feature directly to the myPortal > application. So i did :-) > Beside this, i made a few fixes in the myportal.js. > I'm looking foward to your review. > So long > 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-3261) DemoRepStore PartyId data not correct
[ https://issues.apache.org/jira/browse/OFBIZ-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782777#action_12782777 ] Jacques Le Roux commented on OFBIZ-3261: Why would we remove admin ? > DemoRepStore PartyId data not correct > - > > Key: OFBIZ-3261 > URL: https://issues.apache.org/jira/browse/OFBIZ-3261 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: SVN trunk >Reporter: Aswath Satrasala > Attachments: DemoRepStore.patch > > > DemoRepStore party should be able to create orders for StoreId=9000 only. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
Jacques Le Roux wrote: > Personnally, I see more harms than benefits as time goes by. I think > it's time for a vote. +1 to remove > If we don't remove it we should at least take care of issues like the > one we just crossed with JavaDoc. Actually, I can't see any other kind > of issues, so simply commenting out JavaDoc targets in /shark/build.xml > (with a comment about like in framework/build.xml) would be sufficient > in this case. Well, I've made it compile, which should fix basic parse issues with javadoc. > If we remove it, we could attach an archive of the component at > https://issues.apache.org/jira/browse/OFBIZ-552. And as David said > (thanks for the links Scott), we should do the same for the workflow > component which is even older... Don't need to attach an archive. It'll exist in svn history.
Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
From: "Jacques Le Roux" Personnally, I see more harms than benefits as time goes by. I think it's time for a vote. If we don't remove it we should at least take care of issues like the one we just crossed with JavaDoc. Actually, I can't see any other kind of issues, so simply commenting out JavaDoc targets in /shark/build.xml (with a comment about like in framework/build.xml) would be sufficient in this case. Should be <> Jacques If we remove it, we could attach an archive of the component at https://issues.apache.org/jira/browse/OFBIZ-552. And as David said (thanks for the links Scott), we should do the same for the workflow component which is even older... This is my opinion Jacques From: "Adrian Crum" Thanks for the links Scott. David makes a good point: If it isn't doing any harm, then just leave it in there - someone might use it. And various people have tried to use it - with mixed success. I did a Google search, and for the last two years user questions about the Shark component have been left unanswered. What bothers me about it as a developer is what happens from time to time when the Shark component needs to be modified in order to make it compatible with changes in the framework. The rest of the project continues to move forward, and that component just sits there. When I make changes to it because of some change in the framework, I have no way to test those changes - because I can't compile it without the required libraries, and even if I could, I have no idea how to use it or test it. I end up crossing my fingers and hoping I didn't break anything. So, I have mixed feelings about removing it. I'm undecided. -Adrian --- On Wed, 11/25/09, Scott Gray wrote: From: Scott Gray Subject: Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java To: dev@ofbiz.apache.org Date: Wednesday, November 25, 2009, 4:55 PM On 26/11/2009, at 1:47 PM, Scott Gray wrote: > On 26/11/2009, at 1:37 PM, Adam Heath wrote: > >> Adam Heath wrote: >>> Jacques Le Roux wrote: I thought it would be easy to compile after some changes. But obviously nobody has done this for some time. It's late here, so I reopened https://issues.apache.org/jira/browse/OFBIZ-552 and uploaded a "shark.patch" from my current WIP, if someone wants to give it a try... Jacques >>> >>> Working on it... >> >> I vote to remove it. Latest shark is LGPL, which isn't compatible. > > That has always been the case, we need a better rationale for removal. > > Regards > Scott Also here are a couple of previous threads regarding this topic: http://markmail.org/thread/jwjh6v7dqeq5z4bn http://markmail.org/thread/x2cv6m2ikfw7m55g Regards Scott
Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
Personnally, I see more harms than benefits as time goes by. I think it's time for a vote. If we don't remove it we should at least take care of issues like the one we just crossed with JavaDoc. Actually, I can't see any other kind of issues, so simply commenting out JavaDoc targets in /shark/build.xml (with a comment about like in framework/build.xml) would be sufficient in this case. If we remove it, we could attach an archive of the component at https://issues.apache.org/jira/browse/OFBIZ-552. And as David said (thanks for the links Scott), we should do the same for the workflow component which is even older... This is my opinion Jacques From: "Adrian Crum" Thanks for the links Scott. David makes a good point: If it isn't doing any harm, then just leave it in there - someone might use it. And various people have tried to use it - with mixed success. I did a Google search, and for the last two years user questions about the Shark component have been left unanswered. What bothers me about it as a developer is what happens from time to time when the Shark component needs to be modified in order to make it compatible with changes in the framework. The rest of the project continues to move forward, and that component just sits there. When I make changes to it because of some change in the framework, I have no way to test those changes - because I can't compile it without the required libraries, and even if I could, I have no idea how to use it or test it. I end up crossing my fingers and hoping I didn't break anything. So, I have mixed feelings about removing it. I'm undecided. -Adrian --- On Wed, 11/25/09, Scott Gray wrote: From: Scott Gray Subject: Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java To: dev@ofbiz.apache.org Date: Wednesday, November 25, 2009, 4:55 PM On 26/11/2009, at 1:47 PM, Scott Gray wrote: > On 26/11/2009, at 1:37 PM, Adam Heath wrote: > >> Adam Heath wrote: >>> Jacques Le Roux wrote: I thought it would be easy to compile after some changes. But obviously nobody has done this for some time. It's late here, so I reopened https://issues.apache.org/jira/browse/OFBIZ-552 and uploaded a "shark.patch" from my current WIP, if someone wants to give it a try... Jacques >>> >>> Working on it... >> >> I vote to remove it. Latest shark is LGPL, which isn't compatible. > > That has always been the case, we need a better rationale for removal. > > Regards > Scott Also here are a couple of previous threads regarding this topic: http://markmail.org/thread/jwjh6v7dqeq5z4bn http://markmail.org/thread/x2cv6m2ikfw7m55g Regards Scott
[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: (was: Release Branch 4.0) Adam fixed it at r884347. I do not backport to R9.04 > 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 > > Attachments: EntityPersistentMgr.java.patch, example.xpdl, > shark.patch, 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: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
Thanks for the links Scott. David makes a good point: If it isn't doing any harm, then just leave it in there - someone might use it. And various people have tried to use it - with mixed success. I did a Google search, and for the last two years user questions about the Shark component have been left unanswered. What bothers me about it as a developer is what happens from time to time when the Shark component needs to be modified in order to make it compatible with changes in the framework. The rest of the project continues to move forward, and that component just sits there. When I make changes to it because of some change in the framework, I have no way to test those changes - because I can't compile it without the required libraries, and even if I could, I have no idea how to use it or test it. I end up crossing my fingers and hoping I didn't break anything. So, I have mixed feelings about removing it. I'm undecided. -Adrian --- On Wed, 11/25/09, Scott Gray wrote: > From: Scott Gray > Subject: Re: svn commit: r884308 - > /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java > To: dev@ofbiz.apache.org > Date: Wednesday, November 25, 2009, 4:55 PM > On 26/11/2009, at 1:47 PM, Scott Gray > wrote: > > > On 26/11/2009, at 1:37 PM, Adam Heath wrote: > > > >> Adam Heath wrote: > >>> Jacques Le Roux wrote: > I thought it would be easy to compile > after some changes. But obviously > nobody has done this for some time. > It's late here, so I reopened > https://issues.apache.org/jira/browse/OFBIZ-552 and > uploaded a > "shark.patch" from my current WIP, if > someone wants to give it a try... > > Jacques > >>> > >>> Working on it... > >> > >> I vote to remove it. Latest shark is LGPL, > which isn't compatible. > > > > That has always been the case, we need a better > rationale for removal. > > > > Regards > > Scott > > Also here are a couple of previous threads regarding this > topic: > http://markmail.org/thread/jwjh6v7dqeq5z4bn > http://markmail.org/thread/x2cv6m2ikfw7m55g > > Regards > Scott
[jira] Updated: (OFBIZ-3261) DemoRepStore PartyId data not correct
[ https://issues.apache.org/jira/browse/OFBIZ-3261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aswath Satrasala updated OFBIZ-3261: Attachment: DemoRepStore.patch With attached patch, the DemoRepStore party is given access to the storeid=9000 > DemoRepStore PartyId data not correct > - > > Key: OFBIZ-3261 > URL: https://issues.apache.org/jira/browse/OFBIZ-3261 > Project: OFBiz > Issue Type: Bug > Components: specialpurpose/ecommerce >Affects Versions: SVN trunk >Reporter: Aswath Satrasala > Attachments: DemoRepStore.patch > > > DemoRepStore party should be able to create orders for StoreId=9000 only. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3261) DemoRepStore PartyId data not correct
DemoRepStore PartyId data not correct - Key: OFBIZ-3261 URL: https://issues.apache.org/jira/browse/OFBIZ-3261 Project: OFBiz Issue Type: Bug Components: specialpurpose/ecommerce Affects Versions: SVN trunk Reporter: Aswath Satrasala DemoRepStore party should be able to create orders for StoreId=9000 only. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r884363 - /ofbiz/trunk/framework/entity/src/org/ofbiz/entity/sql/EntitySelectPlan.java
Buildbot reported a compilation failure for this commit, for some
reason no email was sent: http://ci.apache.org/builders/ofbiz-trunk/builds/1879
Regards
Scott
On 26/11/2009, at 2:33 PM, doo...@apache.org wrote:
Author: doogie
Date: Thu Nov 26 01:33:38 2009
New Revision: 884363
URL: http://svn.apache.org/viewvc?rev=884363&view=rev
Log:
Helper method to fetch all rows/values from a query.
Modified:
ofbiz/trunk/framework/entity/src/org/ofbiz/entity/sql/
EntitySelectPlan.java
Modified: ofbiz/trunk/framework/entity/src/org/ofbiz/entity/sql/
EntitySelectPlan.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/entity/src/org/ofbiz/entity/sql/EntitySelectPlan.java?rev=884363&r1=884362&r2=884363&view=diff
=
=
=
=
=
=
=
=
==
--- ofbiz/trunk/framework/entity/src/org/ofbiz/entity/sql/
EntitySelectPlan.java (original)
+++ ofbiz/trunk/framework/entity/src/org/ofbiz/entity/sql/
EntitySelectPlan.java Thu Nov 26 01:33:38 2009
@@ -21,6 +21,7 @@
import java.util.List;
import java.util.ListIterator;
import java.util.Map;
+import java.util.concurrent.Callable;
import javolution.util.FastList;
import javolution.util.FastMap;
@@ -35,6 +36,7 @@
import org.ofbiz.entity.condition.EntityCondition;
import org.ofbiz.entity.model.DynamicViewEntity;
import org.ofbiz.entity.model.ModelKeyMap;
+import org.ofbiz.entity.transaction.TransactionUtil;
import org.ofbiz.entity.util.EntityListIterator;
import org.ofbiz.sql.SelectPlan;
@@ -67,6 +69,20 @@
return delegator.findListIteratorByCondition(dve,
whereCondition, havingCondition, null, orderBy, null);
}
+public List getAll(final GenericDelegator
delegator, final Map params) throws
GenericEntityException {
+return TransactionUtil.doTransaction("sql select", new
Callable>() {
+public List call() throws Exception {
+EntityListIterator it = null;
+try {
+it = getEntityListIterator(delegator, params);
+return it.getCompleteList();
+} finally {
+if (it != null) it.close();
+}
+}
+});
+}
+
public DynamicViewEntity getDynamicViewEntity() {
return dve;
}
smime.p7s
Description: S/MIME cryptographic signature
Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
On 26/11/2009, at 1:47 PM, Scott Gray wrote: On 26/11/2009, at 1:37 PM, Adam Heath wrote: Adam Heath wrote: Jacques Le Roux wrote: I thought it would be easy to compile after some changes. But obviously nobody has done this for some time. It's late here, so I reopened https://issues.apache.org/jira/browse/OFBIZ-552 and uploaded a "shark.patch" from my current WIP, if someone wants to give it a try... Jacques Working on it... I vote to remove it. Latest shark is LGPL, which isn't compatible. That has always been the case, we need a better rationale for removal. Regards Scott Also here are a couple of previous threads regarding this topic: http://markmail.org/thread/jwjh6v7dqeq5z4bn http://markmail.org/thread/x2cv6m2ikfw7m55g Regards Scott smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
On 26/11/2009, at 1:37 PM, Adam Heath wrote: Adam Heath wrote: Jacques Le Roux wrote: I thought it would be easy to compile after some changes. But obviously nobody has done this for some time. It's late here, so I reopened https://issues.apache.org/jira/browse/OFBIZ-552 and uploaded a "shark.patch" from my current WIP, if someone wants to give it a try... Jacques Working on it... I vote to remove it. Latest shark is LGPL, which isn't compatible. That has always been the case, we need a better rationale for removal. Regards Scott smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
Adam Heath wrote: > Jacques Le Roux wrote: >> I thought it would be easy to compile after some changes. But obviously >> nobody has done this for some time. >> It's late here, so I reopened >> https://issues.apache.org/jira/browse/OFBIZ-552 and uploaded a >> "shark.patch" from my current WIP, if someone wants to give it a try... >> >> Jacques > > Working on it... I vote to remove it. Latest shark is LGPL, which isn't compatible.
Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
Jacques Le Roux wrote: > I thought it would be easy to compile after some changes. But obviously > nobody has done this for some time. > It's late here, so I reopened > https://issues.apache.org/jira/browse/OFBIZ-552 and uploaded a > "shark.patch" from my current WIP, if someone wants to give it a try... > > Jacques Working on it...
Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
I thought it would be easy to compile after some changes. But obviously nobody
has done this for some time.
It's late here, so I reopened https://issues.apache.org/jira/browse/OFBIZ-552 and uploaded a "shark.patch" from my current WIP, if
someone wants to give it a try...
Jacques
From: "Adrian Crum"
Except for it being touched occasionally by project-wide changes, I haven't
seen any work done in the Shark component in years.
-Adrian
Jacques Le Roux wrote:
Oops, Sorry
I missed "> 0" when replacing xpdls != null && xpdls.size() > 0 by
UtilValidate.isNotEmpty(xpdls)
Fixed at r884325
The reason of all these troubles is that Shark is not compiled anymore, not
Workflow (this answer Adam question).
Do we really need to keep them in trunk ? We may put them aside but still
accessible ?
Jacques
From: "Scott Gray"
Can a boolean be compared to an integer or did you just break it again?
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 26/11/2009, at 11:29 AM, jler...@apache.org wrote:
Author: jleroux
Date: Wed Nov 25 22:29:21 2009
New Revision: 884308
URL: http://svn.apache.org/viewvc?rev=884308&view=rev
Log:
Complete Scott's fix in r884292 (using initial code in r821643
Modified:
ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
EntityRepositoryMgr.java
Modified: ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/
repository/EntityRepositoryMgr.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java?rev=884308&r1=884307&r2=884308&view=diff
= = = = = = = =
==
--- ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
EntityRepositoryMgr.java (original)
+++ ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
EntityRepositoryMgr.java Wed Nov 25 22:29:21 2009
@@ -177,7 +177,7 @@
public boolean doesXPDLExist(RepositoryTransaction t, String xpdlId)
throws RepositoryException {
List xpdls = this.getXpdlValues(xpdlId, null, false);
-Debug.log(UtilValidate.isNotEmpty(xpdls) ? true : false, module);
+Debug.log("Does XPDL [" + xpdlId + "] Exist - " + xpdls + "(" +
(UtilValidate.isNotEmpty(xpdls) > 0 ? true : false) +
")", module);
return (UtilValidate.isNotEmpty(xpdls) ? true : false);
}
[jira] Updated: (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 updated OFBIZ-552: -- Attachment: shark.patch > 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: Release Branch 4.0, SVN trunk > > Attachments: EntityPersistentMgr.java.patch, example.xpdl, > shark.patch, 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.
[jira] Reopened: (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 reopened OFBIZ-552: --- I will soon add a patch from my current WIP trying to compile Shark > 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: Release Branch 4.0, SVN trunk > > 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: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
On 26/11/2009, at 12:20 PM, Jacques Le Roux wrote: From: "Scott Gray" On 26/11/2009, at 11:58 AM, Jacques Le Roux wrote: The reason of all these troubles is that Shark is not compiled anymore, not Workflow (this answer Adam question). Do we really need to keep them in trunk ? We may put them aside but still accessible ? When raising discussions like this it is always better to go back and read the previous discussions on the same topic and commenting with those in mind. It is really pointless for us to keep rehashing the same issue unless anything has changed since the last time. Actually if you have read all my message, I think a better proposition would be to remove them *also* from the JavaDoc ant target... I did read your entire message but removing them from the javadoc build is a separate discussion to removing them from the trunk and I didn't respond to it because it had already been discussed on the r884292 thread. smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
From: "Scott Gray"
On 26/11/2009, at 11:58 AM, Jacques Le Roux wrote:
Oops, Sorry
I missed "> 0" when replacing xpdls != null && xpdls.size() > 0 by
UtilValidate.isNotEmpty(xpdls)
Fixed at r884325
Thanks Jacques
The reason of all these troubles is that Shark is not compiled anymore, not
Workflow (this answer Adam question).
Do we really need to keep them in trunk ? We may put them aside but still
accessible ?
When raising discussions like this it is always better to go back and read the previous discussions on the same topic and
commenting with those in mind. It is really pointless for us to keep rehashing the same issue unless anything has changed since
the last time.
Actually if you have read all my message, I think a better proposition would be
to remove them *also* from the JavaDoc ant target...
I'm trying to compile them currently, it failed on Delegator new stuff, should
not be too hard to solve, looking at it quickly...
Jacques
Jacques
From: "Scott Gray"
Can a boolean be compared to an integer or did you just break it again?
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 26/11/2009, at 11:29 AM, jler...@apache.org wrote:
Author: jleroux
Date: Wed Nov 25 22:29:21 2009
New Revision: 884308
URL: http://svn.apache.org/viewvc?rev=884308&view=rev
Log:
Complete Scott's fix in r884292 (using initial code in r821643
Modified:
ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
EntityRepositoryMgr.java
Modified: ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/
repository/EntityRepositoryMgr.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java?rev=884308&r1=884307&r2=884308&view=diff
= = = = = = = = = =
--- ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/ repository/
EntityRepositoryMgr.java (original)
+++ ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/ repository/
EntityRepositoryMgr.java Wed Nov 25 22:29:21 2009
@@ -177,7 +177,7 @@
public boolean doesXPDLExist(RepositoryTransaction t, String xpdlId)
throws RepositoryException {
List xpdls = this.getXpdlValues(xpdlId, null, false);
-Debug.log(UtilValidate.isNotEmpty(xpdls) ? true : false, module);
+Debug.log("Does XPDL [" + xpdlId + "] Exist - " + xpdls + "(" + (UtilValidate.isNotEmpty(xpdls) > 0 ? true : false)
+ ")", module);
return (UtilValidate.isNotEmpty(xpdls) ? true : false);
}
Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
Except for it being touched occasionally by project-wide changes, I
haven't seen any work done in the Shark component in years.
-Adrian
Jacques Le Roux wrote:
Oops, Sorry
I missed "> 0" when replacing xpdls != null && xpdls.size() > 0 by
UtilValidate.isNotEmpty(xpdls)
Fixed at r884325
The reason of all these troubles is that Shark is not compiled anymore,
not Workflow (this answer Adam question).
Do we really need to keep them in trunk ? We may put them aside but
still accessible ?
Jacques
From: "Scott Gray"
Can a boolean be compared to an integer or did you just break it again?
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 26/11/2009, at 11:29 AM, jler...@apache.org wrote:
Author: jleroux
Date: Wed Nov 25 22:29:21 2009
New Revision: 884308
URL: http://svn.apache.org/viewvc?rev=884308&view=rev
Log:
Complete Scott's fix in r884292 (using initial code in r821643
Modified:
ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
EntityRepositoryMgr.java
Modified: ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/
repository/EntityRepositoryMgr.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java?rev=884308&r1=884307&r2=884308&view=diff
= = = = = = = =
==
--- ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
EntityRepositoryMgr.java (original)
+++ ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
EntityRepositoryMgr.java Wed Nov 25 22:29:21 2009
@@ -177,7 +177,7 @@
public boolean doesXPDLExist(RepositoryTransaction t, String
xpdlId) throws RepositoryException {
List xpdls = this.getXpdlValues(xpdlId, null, false);
-Debug.log(UtilValidate.isNotEmpty(xpdls) ? true : false,
module);
+Debug.log("Does XPDL [" + xpdlId + "] Exist - " + xpdls +
"(" + (UtilValidate.isNotEmpty(xpdls) > 0 ? true : false) + ")",
module);
return (UtilValidate.isNotEmpty(xpdls) ? true : false);
}
Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
On 26/11/2009, at 11:58 AM, Jacques Le Roux wrote:
Oops, Sorry
I missed "> 0" when replacing xpdls != null && xpdls.size() > 0 by
UtilValidate.isNotEmpty(xpdls)
Fixed at r884325
Thanks Jacques
The reason of all these troubles is that Shark is not compiled
anymore, not Workflow (this answer Adam question).
Do we really need to keep them in trunk ? We may put them aside but
still accessible ?
When raising discussions like this it is always better to go back and
read the previous discussions on the same topic and commenting with
those in mind. It is really pointless for us to keep rehashing the
same issue unless anything has changed since the last time.
Jacques
From: "Scott Gray"
Can a boolean be compared to an integer or did you just break it
again?
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 26/11/2009, at 11:29 AM, jler...@apache.org wrote:
Author: jleroux
Date: Wed Nov 25 22:29:21 2009
New Revision: 884308
URL: http://svn.apache.org/viewvc?rev=884308&view=rev
Log:
Complete Scott's fix in r884292 (using initial code in r821643
Modified:
ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
EntityRepositoryMgr.java
Modified: ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/
repository/EntityRepositoryMgr.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java?rev=884308&r1=884307&r2=884308&view=diff
= = = = = = = =
=
=
--- ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/
repository/ EntityRepositoryMgr.java (original)
+++ ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/
repository/ EntityRepositoryMgr.java Wed Nov 25 22:29:21 2009
@@ -177,7 +177,7 @@
public boolean doesXPDLExist(RepositoryTransaction t, String
xpdlId) throws RepositoryException {
List xpdls = this.getXpdlValues(xpdlId, null, false);
-Debug.log(UtilValidate.isNotEmpty(xpdls) ? true : false,
module);
+Debug.log("Does XPDL [" + xpdlId + "] Exist - " + xpdls
+ "(" + (UtilValidate.isNotEmpty(xpdls) > 0 ? true : false) +
")", module);
return (UtilValidate.isNotEmpty(xpdls) ? true : false);
}
smime.p7s
Description: S/MIME cryptographic signature
Re: svn commit: r884292 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
From: "Scott Gray" On 26/11/2009, at 11:36 AM, Jacques Le Roux wrote: This came from my commit at r886549 < 0) and (obj != null) || (obj.size > 0)>> I have fixed it the right way. I'm guessing this occurred because you were using a regex search and replace, they are useful but you have to be extremely careful if you want to avoid unintended changes. I have been careful, but it's very powefull and I forgot shark+workflow could not be detected :/ Yes, it's surprising it passes ant run but not ant docs-all shark+workflow reason, lesson learned: when doing global search/replace changes beware of them, and even uncomment them in build.xml to be sure. Even better IMO put them aside to avoid these kind of issues... When I get time I'll see if we can get the docs-all target to actually fail the build if it runs into problems so that we get notified via buildbot Without shark+workflow there are any other reason I'm aware of. Finally should we not simply remove them from the docs-all target (than putting them aside) So build-website and copy-apis targets are also used by scripts ? I thought only docs-all was needed ? Once again when I get time I'll look through the scripts at Contegix and see what targets are being used, let's leave everything as is for now. Sure! Enough troubles for the week Jacques Jacques From: "Scott Gray" On 26/11/2009, at 11:22 AM, Adam Heath wrote: lekt...@apache.org wrote: Author: lektran Date: Wed Nov 25 22:03:53 2009 New Revision: 884292 URL: http://svn.apache.org/viewvc?rev=884292&view=rev Log: Fix invalid code that causing the docs-all target to fail If this code isn't built during a normal ant compile run, then the docs should also skip it. Yeah I know, it was just a quick fix to get things running again.I'll take a look at it when I have time unless someone gets there first. Regards Scott
Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
Oops, Sorry
I missed "> 0" when replacing xpdls != null && xpdls.size() > 0 by
UtilValidate.isNotEmpty(xpdls)
Fixed at r884325
The reason of all these troubles is that Shark is not compiled anymore, not
Workflow (this answer Adam question).
Do we really need to keep them in trunk ? We may put them aside but still
accessible ?
Jacques
From: "Scott Gray"
Can a boolean be compared to an integer or did you just break it again?
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 26/11/2009, at 11:29 AM, jler...@apache.org wrote:
Author: jleroux
Date: Wed Nov 25 22:29:21 2009
New Revision: 884308
URL: http://svn.apache.org/viewvc?rev=884308&view=rev
Log:
Complete Scott's fix in r884292 (using initial code in r821643
Modified:
ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
EntityRepositoryMgr.java
Modified: ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/
repository/EntityRepositoryMgr.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java?rev=884308&r1=884307&r2=884308&view=diff
= = = = = = = =
==
--- ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
EntityRepositoryMgr.java (original)
+++ ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
EntityRepositoryMgr.java Wed Nov 25 22:29:21 2009
@@ -177,7 +177,7 @@
public boolean doesXPDLExist(RepositoryTransaction t, String xpdlId)
throws RepositoryException {
List xpdls = this.getXpdlValues(xpdlId, null, false);
-Debug.log(UtilValidate.isNotEmpty(xpdls) ? true : false, module);
+Debug.log("Does XPDL [" + xpdlId + "] Exist - " + xpdls + "(" + (UtilValidate.isNotEmpty(xpdls) > 0 ? true : false) +
")", module);
return (UtilValidate.isNotEmpty(xpdls) ? true : false);
}
Re: svn commit: r884325 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
jler...@apache.org wrote:
> Author: jleroux
> Date: Wed Nov 25 22:55:29 2009
> New Revision: 884325
>
> URL: http://svn.apache.org/viewvc?rev=884325&view=rev
> Log:
> Oops fix r884308 (missed the >0 part when replacing xpdls != null &&
> xpdls.size() > 0 by UtilValidate.isNotEmpty(xpdls)
>
> Modified:
>
> ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
>
> Modified:
> ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
> URL:
> http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java?rev=884325&r1=884324&r2=884325&view=diff
> ==
> ---
> ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
> (original)
> +++
> ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
> Wed Nov 25 22:55:29 2009
> @@ -177,7 +177,7 @@
>
> public boolean doesXPDLExist(RepositoryTransaction t, String xpdlId)
> throws RepositoryException {
> List xpdls = this.getXpdlValues(xpdlId, null, false);
> -Debug.log("Does XPDL [" + xpdlId + "] Exist - " + xpdls + "(" +
> (UtilValidate.isNotEmpty(xpdls) > 0 ? true : false) + ")", module);
> +Debug.log("Does XPDL [" + xpdlId + "] Exist - " + xpdls + "(" +
> (UtilValidate.isNotEmpty(xpdls) ? true : false) + ")", module);
> return (UtilValidate.isNotEmpty(xpdls) ? true : false);
You don't need the ?true:false part either.
Re: svn commit: r884292 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
On 26/11/2009, at 11:36 AM, Jacques Le Roux wrote: This came from my commit at r8865490) and (obj != null) || (obj.size > 0)>> I have fixed it the right way. I'm guessing this occurred because you were using a regex search and replace, they are useful but you have to be extremely careful if you want to avoid unintended changes. Yes, it's surprising it passes ant run but not ant docs-all When I get time I'll see if we can get the docs-all target to actually fail the build if it runs into problems so that we get notified via buildbot So build-website and copy-apis targets are also used by scripts ? I thought only docs-all was needed ? Once again when I get time I'll look through the scripts at Contegix and see what targets are being used, let's leave everything as is for now. Jacques From: "Scott Gray" On 26/11/2009, at 11:22 AM, Adam Heath wrote: lekt...@apache.org wrote: Author: lektran Date: Wed Nov 25 22:03:53 2009 New Revision: 884292 URL: http://svn.apache.org/viewvc?rev=884292&view=rev Log: Fix invalid code that causing the docs-all target to fail If this code isn't built during a normal ant compile run, then the docs should also skip it. Yeah I know, it was just a quick fix to get things running again. I'll take a look at it when I have time unless someone gets there first. Regards Scott smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r884292 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
Jacques Le Roux wrote: So build-website and copy-apis targets are also used by scripts ? I thought only docs-all was needed ? I was just guessing, since the folders that weren't found by Contegix are the same ones you commented out. -Adrian
Re: svn commit: r883017 - /ofbiz/trunk/framework/common/src/org/ofbiz/common/CommonWorkers.java
Hi Scott,
1st I find Marco's idea very good!
And I'd like to apply it also to languages. Who needs all languages ? Of course
if you use only one language (English ;o) you can't
see that as a drawback, but when you have continuously to change from one
language to English, it can be boring...
So OOTB we should even restrain to languages we currently support (a dozen I
guess). I hope to apply the concept soon...
Now about implementation, inline...
From: "Scott Gray"
[snip]
+List countriesList = FastList.newInstance();
+List countriesAvailable = StringUtil
.split(UtilProperties.getPropertyValue("general.properties",
"countries.geo.id.available"), ",");
+if (countriesAvailable != null) {
+for(String country : countriesAvailable) {
+GenericValue geoCountry = null;
+try {
+geoCountry = delegator.findOne("Geo",
UtilMisc.toMap("geoId", country.trim()), true);
+} catch (GenericEntityException e) {
+Debug.logError(e, "The country specified into
countries.geo.id.available does not exists in Geo", module);
+}
+if (geoCountry != null) {
+countriesList.add(country);
+}
+}
+}
You do realize that you are going through the list of countries and grabbing
each Geo just to make sure it exists and then in the
next block retrieving them all again? Somewhat pointless to have them all,
throw them away and then grab them again.
Even in worse cases (246 countries OOTB), for practical purpose I guess nobody
would have noticed anything on UI level.
But I agree we can do better so I tried to do it in another, faster way:
commited at r884317
BTW, you did not mention anyting about
if (countriesAvailable != null) {
This would be my main concern. I want to refactor StringUtil .split (and uses)
so that it renders an empty list when now it's
rendering null. To avoid this useless check when using an enhanced for loop (lists often use enhanced for loops) and mostly because
it's cleaner IMO. I have to check current uses though...
[snip]
+/* remove the default geo to avoid double rows in the
drop-down */
+int idx = 0;
+for (GenericValue geo : countryGeoList) {
+if (geo.get("geoId") != null && defaultGeo.get("geoId") != null
&&
+ geo.get("geoId").equals(defaultGeo.get("geoId")))
{
+countryGeoList.remove(idx);
+}
+idx += 1;
+}
geoList.addAll(countryGeoList);
} else {
geoList = countryGeoList;
Enhanced for loops are great but they're not really appropriate when you do
actually need to know the index during iteration.
I mostly prefer them because I like the concept, it's easier to write, to read
and that's important points to me. I agree that it's
maybe less efficient than a for loop with index on list for this case, or
rather ListIterator wich would have been perfect.
Also the geoId null checks are somewhat superfluous considering that geoId is
the primary key.
Thanks for the geoId the primary key spot, good idea indeed, lesson learned.
Even more now that we guarantee a primary key can't be
null (since r835303)
Thanks
Jacques
Re: svn commit: r884308 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
Can a boolean be compared to an integer or did you just break it again?
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 26/11/2009, at 11:29 AM, jler...@apache.org wrote:
Author: jleroux
Date: Wed Nov 25 22:29:21 2009
New Revision: 884308
URL: http://svn.apache.org/viewvc?rev=884308&view=rev
Log:
Complete Scott's fix in r884292 (using initial code in r821643
Modified:
ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
EntityRepositoryMgr.java
Modified: ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/
repository/EntityRepositoryMgr.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java?rev=884308&r1=884307&r2=884308&view=diff
=
=
=
=
=
=
=
=
==
--- ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
EntityRepositoryMgr.java (original)
+++ ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/
EntityRepositoryMgr.java Wed Nov 25 22:29:21 2009
@@ -177,7 +177,7 @@
public boolean doesXPDLExist(RepositoryTransaction t, String
xpdlId) throws RepositoryException {
List xpdls = this.getXpdlValues(xpdlId, null, false);
-Debug.log(UtilValidate.isNotEmpty(xpdls) ? true : false,
module);
+Debug.log("Does XPDL [" + xpdlId + "] Exist - " + xpdls +
"(" + (UtilValidate.isNotEmpty(xpdls) > 0 ? true : false) + ")",
module);
return (UtilValidate.isNotEmpty(xpdls) ? true : false);
}
smime.p7s
Description: S/MIME cryptographic signature
Re: svn commit: r884292 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
This came from my commit at r886549 < 0) and (obj != null) || (obj.size > 0)>> I have fixed it the right way. Yes, it's surprising it passes ant run but not ant docs-all So build-website and copy-apis targets are also used by scripts ? I thought only docs-all was needed ? Jacques From: "Scott Gray" On 26/11/2009, at 11:22 AM, Adam Heath wrote: lekt...@apache.org wrote: Author: lektran Date: Wed Nov 25 22:03:53 2009 New Revision: 884292 URL: http://svn.apache.org/viewvc?rev=884292&view=rev Log: Fix invalid code that causing the docs-all target to fail If this code isn't built during a normal ant compile run, then the docs should also skip it. Yeah I know, it was just a quick fix to get things running again. I'll take a look at it when I have time unless someone gets there first. Regards Scott
Re: svn commit: r884292 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
On 26/11/2009, at 11:22 AM, Adam Heath wrote: lekt...@apache.org wrote: Author: lektran Date: Wed Nov 25 22:03:53 2009 New Revision: 884292 URL: http://svn.apache.org/viewvc?rev=884292&view=rev Log: Fix invalid code that causing the docs-all target to fail If this code isn't built during a normal ant compile run, then the docs should also skip it. Yeah I know, it was just a quick fix to get things running again. I'll take a look at it when I have time unless someone gets there first. Regards Scott smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r884292 - /ofbiz/trunk/specialpurpose/shark/src/org/ofbiz/shark/repository/EntityRepositoryMgr.java
lekt...@apache.org wrote: > Author: lektran > Date: Wed Nov 25 22:03:53 2009 > New Revision: 884292 > > URL: http://svn.apache.org/viewvc?rev=884292&view=rev > Log: > Fix invalid code that causing the docs-all target to fail If this code isn't built during a normal ant compile run, then the docs should also skip it.
Re: dropping crumbs styling from brainfood/erik schuessler
Right now sleeping giant means not yet committed to the project :) Definitely looking for this look and feel to make it's way in there Erik - thanks so much! I'm glad you've found the right avenue for that style. Cheers, Ruppert On Nov 25, 2009, at 2:13 PM, Bruno Busco wrote: uhao! That's great! Now I see what you meant by "sleeping giant" ! -Bruno 2009/11/25 Adam Heath : http://www.brainfood.com/ofbizbackend smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (OFBIZ-3212) Improvement of Dutch language file for projectmgr
[ https://issues.apache.org/jira/browse/OFBIZ-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782628#action_12782628 ] Jacques Le Roux commented on OFBIZ-3212: I did not spot this one, it should be the last +Datum Start Aanyway I will wait Hans review for a reasonnable period of time, I can't read Dutch... > Improvement of Dutch language file for projectmgr > - > > Key: OFBIZ-3212 > URL: https://issues.apache.org/jira/browse/OFBIZ-3212 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Pierre Smits >Assignee: Jacques Le Roux >Priority: Minor > Fix For: SVN trunk > > Attachments: ProjectMgrUILabels-882093.patch, ProjectMgrUiLabels.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: dropping crumbs styling from brainfood/erik schuessler
uhao! That's great! Now I see what you meant by "sleeping giant" ! -Bruno 2009/11/25 Adam Heath : > http://www.brainfood.com/ofbizbackend >
Re: Clearing cache is really sloooowww
Adam Heath wrote: Adrian Crum wrote: On my local copy I'm seeing thousands of entitycache entries, each with only one item cached. That was what I needed to fix it. When I tested it after Jacques noted the problem, I went to webtools immediately after starting, so it only had a small list of entries. I've fixed this in 884262. cool - thanks!
Re: Clearing cache is really sloooowww
Adrian Crum wrote: > On my local copy I'm seeing thousands of entitycache entries, each with > only one item cached. That was what I needed to fix it. When I tested it after Jacques noted the problem, I went to webtools immediately after starting, so it only had a small list of entries. I've fixed this in 884262.
Re: dropping crumbs styling from brainfood/erik schuessler
INSERT INTO THEME_REVIEW
(THEME_REVIEW_ID, USER_LOGIN_ID, THEME_ID, THEME_RATING, THEME_REVIEW)
VALUES ('1', 'lektran', 'BF_DROPCRMB', 5, 'Looks awesome, would
view again. A');
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 26/11/2009, at 9:23 AM, Adam Heath wrote:
http://www.brainfood.com/ofbizbackend
smime.p7s
Description: S/MIME cryptographic signature
Re: dropping crumbs styling from brainfood/erik schuessler
Very, very nice - I see that Erik's still shooting for that ApacheERP setup that he did years ago. Awesome! Cheers, Ruppert -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Nov 25, 2009, at 1:23 PM, Adam Heath wrote: http://www.brainfood.com/ofbizbackend smime.p7s Description: S/MIME cryptographic signature
Re: dropping crumbs styling from brainfood/erik schuessler
It looks industrial. Nice! -Adrian Adam Heath wrote: http://www.brainfood.com/ofbizbackend
Re: Clearing cache is really sloooowww
On my local copy I'm seeing thousands of entitycache entries, each with only one item cached. -Adrian Jacques Le Roux wrote: Hi Adam, Jacques Le Roux wrote: Hi, I don't know if some of you have tried to clear caches these last times, but it's now very, very, very slow... (more than 10 times, maybe even more than 100x...) Is this after the last set of changes I *just* did? Yes I think so, but I just saw that you did some changes in util/cache are they related to this message ? Note, that if you clear caches from webtools, the caches will clear fast, but then it has to reload a bunch of data again; it's this that can be slow. I did not look at details yet In any event, I just tried clearing all caches, and it appears to run fast. Surprised, I tried on 2 local instances : same symptom. I will update your last changes, anyway... Jacques
Re: Clearing cache is really sloooowww
Jacques Le Roux wrote: >> >> Is this after the last set of changes I *just* did? > > Yes I think so, but I just saw that you did some changes in util/cache > are they related to this message ? Unrelated. I was just backporting changes from head to our(brainfood's) local package, and noticed some synchronized blocks that could be removed(I've converted a bunch of stuff in UtilCache to be non-blocking/unsynchronized).
dropping crumbs styling from brainfood/erik schuessler
http://www.brainfood.com/ofbizbackend
Re: Clearing cache is really sloooowww
Hi Adam, Jacques Le Roux wrote: Hi, I don't know if some of you have tried to clear caches these last times, but it's now very, very, very slow... (more than 10 times, maybe even more than 100x...) Is this after the last set of changes I *just* did? Yes I think so, but I just saw that you did some changes in util/cache are they related to this message ? Note, that if you clear caches from webtools, the caches will clear fast, but then it has to reload a bunch of data again; it's this that can be slow. I did not look at details yet In any event, I just tried clearing all caches, and it appears to run fast. Surprised, I tried on 2 local instances : same symptom. I will update your last changes, anyway... Jacques
Re: Ajaxifying lookup fields
From: "David E Jones" On Nov 24, 2009, at 2:49 PM, Jacques Le Roux wrote: From: "David E Jones" On Nov 24, 2009, at 3:51 AM, Jacques Le Roux wrote: Hi Bilgin, Just one question From: "Bilgin Ibryam" [big snip] 2. There is no way of indicating what field you actually want to search against. This would typically be a search on whatever the description is made up of (ie that's what users expect). Searching on one field is not useful for most of the cases. For example to search for a party, it is good to search in partyId, firstName, middleName, lastName, groupName fields. With other entities it would be good to search at lease in ID and description fields. But partyId is unique, so searching on only one field makes sense, or ? A partial partyId isn't unique though... I don't get it, Party has only partyId as primary key, isn'it ? It depends on the UI. You can assume that what was entered was the complete value and requires an exact match, or a partial value and can match multiple records. For example: If you specify a partial value, like only 3 characters, and you have coded it to not assume those 3 characters are the entire PK value, then you can query for all PK values that include those 3 characters. -David Ho I see now. I used something like that for the party search I recently wrote in POS (using a dynamic entity view) but not on PK though (as Bilgin pointed out it would be almost useless for final users and POS is all about them) Jacques
Re: Clearing cache is really sloooowww
Jacques Le Roux wrote: > Hi, > > I don't know if some of you have tried to clear caches these last times, > but it's now very, very, very slow... (more than 10 times, > maybe even more than 100x...) Is this after the last set of changes I *just* did? Note, that if you clear caches from webtools, the caches will clear fast, but then it has to reload a bunch of data again; it's this that can be slow. In any event, I just tried clearing all caches, and it appears to run fast.
Clearing cache is really sloooowww
Hi, I don't know if some of you have tried to clear caches these last times, but it's now very, very, very slow... (more than 10 times, maybe even more than 100x...) Jacques
Re: from BIZZNESS_TIME to DROPPING_CRUMB ?
-1 When the main application menu extends below the bottom of the screen, there is no way to select the hidden items. When you move the mouse cursor to the bottom, the menu disappears. In the Bizznesstime theme, the main application menu stays on the screen until an item is selected. -Adrian Jacques Le Roux wrote: Hi, I wonder if we should no change the default theme from BIZZNESS_TIME to DROPPING_CRUMB. I know it will not be consistent anymore with Site and Doc but looking at https://issues.apache.org/jira/browse/OFBIZ-2398 I think DROPPING_CRUMB is doing a better job and has a real good look now Jacques
Re: Ajaxifying lookup fields
On Nov 24, 2009, at 2:49 PM, Jacques Le Roux wrote: > From: "David E Jones" >> >> On Nov 24, 2009, at 3:51 AM, Jacques Le Roux wrote: >> >>> Hi Bilgin, >>> >>> Just one question >>> From: "Bilgin Ibryam" >>> [big snip] >>> 2. There is no way of indicating what field you actually want to >>> search against. >> >> This would typically be a search on whatever the description is made up >> of (ie that's what users expect). Searching on one field is not useful for most of the cases. For example to search for a party, it is good to search in partyId, firstName, middleName, lastName, groupName fields. With other entities it would be good to search at lease in ID and description fields. >>> >>> But partyId is unique, so searching on only one field makes sense, or ? >> >> A partial partyId isn't unique though... > > I don't get it, Party has only partyId as primary key, isn'it ? It depends on the UI. You can assume that what was entered was the complete value and requires an exact match, or a partial value and can match multiple records. For example: If you specify a partial value, like only 3 characters, and you have coded it to not assume those 3 characters are the entire PK value, then you can query for all PK values that include those 3 characters. -David
Re: birt component without duplicates : objection against merging?
-1 until the licensing and other issues are resolved. Cheers, Ruppert On Nov 25, 2009, at 11:40 AM, Scott Gray wrote: On 26/11/2009, at 1:29 AM, Hans Bakker wrote: Chattree has fixed the duplicated jar problem. concerning the license, my opinion is what is good for the eclipse foundation is good for Apache. We have a saying here: we should not be more roman catholic than the pope.. What on Earth are you talking about? Have you actually bothered to read any of the emails I've sent? Do not ask me to review anything again, I spent a good amount of time looking at the component only to be ignored. Regards Scott so what is the community opinion? -1 smime.p7s Description: S/MIME cryptographic signature
[jira] Updated: (OFBIZ-3212) Improvement of Dutch language file for projectmgr
[ https://issues.apache.org/jira/browse/OFBIZ-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-3212: Attachment: (was: ProjectMgrUiLabels.patch) > Improvement of Dutch language file for projectmgr > - > > Key: OFBIZ-3212 > URL: https://issues.apache.org/jira/browse/OFBIZ-3212 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Pierre Smits >Assignee: Jacques Le Roux >Priority: Minor > Fix For: SVN trunk > > Attachments: ProjectMgrUILabels-882093.patch, ProjectMgrUiLabels.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3212) Improvement of Dutch language file for projectmgr
[ https://issues.apache.org/jira/browse/OFBIZ-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-3212: Attachment: ProjectMgrUiLabels.patch Thanks, Jacques. My apologies for the mishap. Attached you'll find the corrected file. Regards, Pierre > Improvement of Dutch language file for projectmgr > - > > Key: OFBIZ-3212 > URL: https://issues.apache.org/jira/browse/OFBIZ-3212 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Pierre Smits >Assignee: Jacques Le Roux >Priority: Minor > Fix For: SVN trunk > > Attachments: ProjectMgrUILabels-882093.patch, > ProjectMgrUiLabels.patch, ProjectMgrUiLabels.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: birt component without duplicates : objection against merging?
On 26/11/2009, at 1:29 AM, Hans Bakker wrote: Chattree has fixed the duplicated jar problem. concerning the license, my opinion is what is good for the eclipse foundation is good for Apache. We have a saying here: we should not be more roman catholic than the pope.. What on Earth are you talking about? Have you actually bothered to read any of the emails I've sent? Do not ask me to review anything again, I spent a good amount of time looking at the component only to be ignored. Regards Scott so what is the community opinion? -1 smime.p7s Description: S/MIME cryptographic signature
[jira] Commented: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine
[ https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782545#action_12782545 ] Adrian Crum commented on OFBIZ-3245: Bah. Jira's Wiki markup doesn't work. C&P the table into a monospaced font. > Sandbox: Integrating The New Conversion Framework Into The Entity Engine > > > Key: OFBIZ-3245 > URL: https://issues.apache.org/jira/browse/OFBIZ-3245 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Adrian Crum >Assignee: Adrian Crum >Priority: Minor > Attachments: conversion.patch, conversion.patch, conversion.patch > > > This issue contains a patch intended for evaluation before it is committed. > See comments for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine
[
https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782544#action_12782544
]
Adrian Crum commented on OFBIZ-3245:
A good example of how the java-type attribute is not being used as intended:
all fieldtypes*.xml files have the "numeric" field type set to a Java type of
"Long." According to documentation I found online and elsewhere:
{{Database SQL type JDBC driver Java type
-- -
Advantage Integerjava.lang.Integer
Derby NUMERIC(20,0) java.math.BigDecimal
MS SQLINTint
MySql DECIMAL(20,0) java.math.BigDecimal
OracleNUMBER(20,0) java.math.BigDecimal}}
> Sandbox: Integrating The New Conversion Framework Into The Entity Engine
>
>
> Key: OFBIZ-3245
> URL: https://issues.apache.org/jira/browse/OFBIZ-3245
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
>Affects Versions: SVN trunk
>Reporter: Adrian Crum
>Assignee: Adrian Crum
>Priority: Minor
> Attachments: conversion.patch, conversion.patch, conversion.patch
>
>
> This issue contains a patch intended for evaluation before it is committed.
> See comments for details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3227) Drag'n'Drop update - add directly in the my portal application
[ https://issues.apache.org/jira/browse/OFBIZ-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco updated OFBIZ-3227: --- Attachment: screen3.gif screen2.gif screen1.gif Sorry for the large BMP files I was in a hurry and I did not realize how large they were. Replaced with much smaller gif files. > Drag'n'Drop update - add directly in the my portal application > -- > > Key: OFBIZ-3227 > URL: https://issues.apache.org/jira/browse/OFBIZ-3227 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Bruno Busco > Fix For: SVN trunk > > Attachments: myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, screen1.gif, screen2.gif, screen3.gif, > screenshot-1.jpg > > > Hi, > Michael ask to add the Drag'n' Drop Feature directly to the myPortal > application. So i did :-) > Beside this, i made a few fixes in the myportal.js. > I'm looking foward to your review. > So long > 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-3227) Drag'n'Drop update - add directly in the my portal application
[ https://issues.apache.org/jira/browse/OFBIZ-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco updated OFBIZ-3227: --- Attachment: (was: screen2.bmp) > Drag'n'Drop update - add directly in the my portal application > -- > > Key: OFBIZ-3227 > URL: https://issues.apache.org/jira/browse/OFBIZ-3227 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Bruno Busco > Fix For: SVN trunk > > Attachments: myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, screenshot-1.jpg > > > Hi, > Michael ask to add the Drag'n' Drop Feature directly to the myPortal > application. So i did :-) > Beside this, i made a few fixes in the myportal.js. > I'm looking foward to your review. > So long > 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-3227) Drag'n'Drop update - add directly in the my portal application
[ https://issues.apache.org/jira/browse/OFBIZ-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco updated OFBIZ-3227: --- Attachment: (was: screen3.bmp) > Drag'n'Drop update - add directly in the my portal application > -- > > Key: OFBIZ-3227 > URL: https://issues.apache.org/jira/browse/OFBIZ-3227 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Bruno Busco > Fix For: SVN trunk > > Attachments: myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, screenshot-1.jpg > > > Hi, > Michael ask to add the Drag'n' Drop Feature directly to the myPortal > application. So i did :-) > Beside this, i made a few fixes in the myportal.js. > I'm looking foward to your review. > So long > 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-3227) Drag'n'Drop update - add directly in the my portal application
[ https://issues.apache.org/jira/browse/OFBIZ-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco updated OFBIZ-3227: --- Attachment: (was: screen1.bmp) > Drag'n'Drop update - add directly in the my portal application > -- > > Key: OFBIZ-3227 > URL: https://issues.apache.org/jira/browse/OFBIZ-3227 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Bruno Busco > Fix For: SVN trunk > > Attachments: myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, screen2.bmp, screen3.bmp, screenshot-1.jpg > > > Hi, > Michael ask to add the Drag'n' Drop Feature directly to the myPortal > application. So i did :-) > Beside this, i made a few fixes in the myportal.js. > I'm looking foward to your review. > So long > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Interesting GIT/JIRA integration
Nice! Cheers, Ruppert -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Nov 25, 2009, at 11:00 AM, Ean Schuessler wrote: I haven't tried it yet but it would appear to automate some of our workflow. http://github.com/dreiss/git-jira-attacher -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com smime.p7s Description: S/MIME cryptographic signature
Interesting GIT/JIRA integration
I haven't tried it yet but it would appear to automate some of our workflow. http://github.com/dreiss/git-jira-attacher -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Ajaxifying lookup fields
From: "David E Jones" On Nov 24, 2009, at 3:51 AM, Jacques Le Roux wrote: Hi Bilgin, Just one question From: "Bilgin Ibryam" [big snip] 2. There is no way of indicating what field you actually want to search against. This would typically be a search on whatever the description is made up of (ie that's what users expect). Searching on one field is not useful for most of the cases. For example to search for a party, it is good to search in partyId, firstName, middleName, lastName, groupName fields. With other entities it would be good to search at lease in ID and description fields. But partyId is unique, so searching on only one field makes sense, or ? A partial partyId isn't unique though... I don't get it, Party has only partyId as primary key, isn'it ? Jacques -David
[jira] Commented: (OFBIZ-3260) Added drop down options replacing text box to configure sagepay
[ https://issues.apache.org/jira/browse/OFBIZ-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782519#action_12782519 ] Jacques Le Roux commented on OFBIZ-3260: Hi Abdullah, Your patch looks good, but please before creating new labels check that they don't already exist, for instance those one exist in OFBiz Payment Deferred Release Cancel Abort Also it should be better to create the others in Common Thanks > Added drop down options replacing text box to configure sagepay > --- > > Key: OFBIZ-3260 > URL: https://issues.apache.org/jira/browse/OFBIZ-3260 > Project: OFBiz > Issue Type: Improvement >Reporter: Abdullah Shaikh >Priority: Minor > Attachments: OFBIZ-3260_Added drop down options replacing text > box.patch > > > Added drop down options, replacing text box, to configure SagePay payment > gateway transaction types settings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3227) Drag'n'Drop update - add directly in the my portal application
[ https://issues.apache.org/jira/browse/OFBIZ-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782507#action_12782507 ] Jacques Le Roux commented on OFBIZ-3227: Hi Sascha, It seems that, to say the least, you have some skills in js programming. Would you mind to have a look at OFBIZ-1825 ? Thanks Bruno, .bmp is bad (bandwidth, at least it's very slow to download) please use rather the screen-copy feature ;) Thanks > Drag'n'Drop update - add directly in the my portal application > -- > > Key: OFBIZ-3227 > URL: https://issues.apache.org/jira/browse/OFBIZ-3227 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Bruno Busco > Fix For: SVN trunk > > Attachments: myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, screen1.bmp, screen2.bmp, screen3.bmp, > screenshot-1.jpg > > > Hi, > Michael ask to add the Drag'n' Drop Feature directly to the myPortal > application. So i did :-) > Beside this, i made a few fixes in the myportal.js. > I'm looking foward to your review. > So long > 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-3212) Improvement of Dutch language file for projectmgr
[ https://issues.apache.org/jira/browse/OFBIZ-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782504#action_12782504 ] Jacques Le Roux commented on OFBIZ-3212: Hi Pierre, There is at least one issue with your patch at end +Status +Status And as it introduces nl changes, I'd prefer that Hans review it also (it's easier before commiting) Thanks > Improvement of Dutch language file for projectmgr > - > > Key: OFBIZ-3212 > URL: https://issues.apache.org/jira/browse/OFBIZ-3212 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Pierre Smits >Assignee: Jacques Le Roux >Priority: Minor > Fix For: SVN trunk > > Attachments: ProjectMgrUILabels-882093.patch, ProjectMgrUiLabels.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (OFBIZ-3212) Improvement of Dutch language file for projectmgr
[ https://issues.apache.org/jira/browse/OFBIZ-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reopened OFBIZ-3212: Reopened : new improving patch > Improvement of Dutch language file for projectmgr > - > > Key: OFBIZ-3212 > URL: https://issues.apache.org/jira/browse/OFBIZ-3212 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Pierre Smits >Assignee: Jacques Le Roux >Priority: Minor > Fix For: SVN trunk > > Attachments: ProjectMgrUILabels-882093.patch, ProjectMgrUiLabels.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: birt component without duplicates : objection against merging?
Hans Bakker wrote: > concerning the license, my opinion is what is good for the eclipse > foundation is good for Apache. We have a saying here: we should not be > more roman catholic than the pope.. No. You can't just blindly relicense something. That's the whole point of it being a license. And if *all* those embedded jars are EPL, then I know, beyond a shadow of a doubt, that there are some libs that can *not* be relicensed. > so what is the community opinion? -1, tentively > can we merge the addbirt branch back into the trunk? I'd like to take the weekend to look this over. Here in the United States, it's a major holiday tomorrow, and most people have a 4 day weekend. Plus, some might be travelling today.
[jira] Issue Comment Edited: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine
[ https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782481#action_12782481 ] Adrian Crum edited comment on OFBIZ-3245 at 11/25/09 4:25 PM: -- I'm sure I am the one who is confused. It appeared to me the java-type attribute was being used as a target object type for the framework. If it was originally intended to be the object type the JDBC driver is expecting, then that's not how it is being used today. Or the fieldtype*.xml files are very much out-of-date. It appeared to me that the java-type attribute was a way of abstracting the database details, in effect saying "regardless of how this value in stored in the database, it will be xxx type when used in the framework." Based on your comment, I now know this is wrong, but like I said - that is how it is being used in the current code. My inaccurate evaluation of the java-type's use actually makes more sense than the original intent. For example, what Java object type should you expect to get when you call GenericValue.get()? I always assumed it was the type specified in the java-type attribute. Using that attribute the way it was originally intended, I won't know what Java object type I will get - because each JDBC driver might return something different. So, based on my misunderstanding of what that attribute was used for, this is how I pictured the changes proposed here working: Database -> JDBC driver -> sql-object-type -> (converted to) java-type -> framework code Last night I came up with a better name for the new attribute to help make things clearer: Database -> JDBC driver -> jdbc-type -> (converted to) java-type -> framework code In the majority of field types there is no conversion necessary. For example, all JDBC drivers are going to use the java.lang.String java object type for CHAR and VARCHAR, java.sql.Timestamp for TIMESTAMP, etc. But there are differences in how drivers handle some of the other SQL data types. It would be nice if client code didn't need to know about those differences. was (Author: adri...@hlmksw.com): I'm sure I am the one who is confused. It appeared to me the java-type attribute was being used as a target object type for the framework. If it was originally intended to be the object type the JDBC driver is expecting, then that's not how it is being used today. Or the fieldtype*.xml files are very much out-of-date. It appeared to me that the java-type attribute was a way of abstracting the database details, in effect saying "regardless of how this value in stored in the database, it will be xxx type when used in the framework." Based on your comment, I now know this is wrong, but like I said - that is how it is being used in the current code. My inaccurate evaluation of the java-type's use actually makes more sense than the original intent. For example, what Java object type should you expect to get when you call GenericValue.get()? I always assumed it was the type specified in the java-type attribute. Using that attribute the way it was originally intended, I won't know what Java object type I will get - because each JDBC driver might return something different. So, based on my misunderstanding of what that attribute was used for, this is how I pictured the changes proposed here working: Database -> JDBC driver -> sql-object-type (converted to) -> java-type -> framework code Last night I came up with a better name for the new attribute to help make things clearer: Database -> JDBC driver -> jdbc-type (converted to) -> java-type -> framework code In the majority of field types there is no conversion necessary. For example, all JDBC drivers are going to use the java.lang.String java object type for CHAR and VARCHAR, java.sql.Timestamp for TIMESTAMP, etc. But there are differences in how drivers handle some of the other SQL data types. It would be nice if client code didn't need to know about those differences. > Sandbox: Integrating The New Conversion Framework Into The Entity Engine > > > Key: OFBIZ-3245 > URL: https://issues.apache.org/jira/browse/OFBIZ-3245 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Adrian Crum >Assignee: Adrian Crum >Priority: Minor > Attachments: conversion.patch, conversion.patch, conversion.patch > > > This issue contains a patch intended for evaluation before it is committed. > See comments for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3245) Sandbox: Integrating The New Conversion Framework Into The Entity Engine
[ https://issues.apache.org/jira/browse/OFBIZ-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782481#action_12782481 ] Adrian Crum commented on OFBIZ-3245: I'm sure I am the one who is confused. It appeared to me the java-type attribute was being used as a target object type for the framework. If it was originally intended to be the object type the JDBC driver is expecting, then that's not how it is being used today. Or the fieldtype*.xml files are very much out-of-date. It appeared to me that the java-type attribute was a way of abstracting the database details, in effect saying "regardless of how this value in stored in the database, it will be xxx type when used in the framework." Based on your comment, I now know this is wrong, but like I said - that is how it is being used in the current code. My inaccurate evaluation of the java-type's use actually makes more sense than the original intent. For example, what Java object type should you expect to get when you call GenericValue.get()? I always assumed it was the type specified in the java-type attribute. Using that attribute the way it was originally intended, I won't know what Java object type I will get - because each JDBC driver might return something different. So, based on my misunderstanding of what that attribute was used for, this is how I pictured the changes proposed here working: Database -> JDBC driver -> sql-object-type (converted to) -> java-type -> framework code Last night I came up with a better name for the new attribute to help make things clearer: Database -> JDBC driver -> jdbc-type (converted to) -> java-type -> framework code In the majority of field types there is no conversion necessary. For example, all JDBC drivers are going to use the java.lang.String java object type for CHAR and VARCHAR, java.sql.Timestamp for TIMESTAMP, etc. But there are differences in how drivers handle some of the other SQL data types. It would be nice if client code didn't need to know about those differences. > Sandbox: Integrating The New Conversion Framework Into The Entity Engine > > > Key: OFBIZ-3245 > URL: https://issues.apache.org/jira/browse/OFBIZ-3245 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: SVN trunk >Reporter: Adrian Crum >Assignee: Adrian Crum >Priority: Minor > Attachments: conversion.patch, conversion.patch, conversion.patch > > > This issue contains a patch intended for evaluation before it is committed. > See comments for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3212) Improvement of Dutch language file for projectmgr
[ https://issues.apache.org/jira/browse/OFBIZ-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-3212: Attachment: ProjectMgrUiLabels.patch This patch includes enhanced translations for Dutch users. Including enhancements on workeffort labels. > Improvement of Dutch language file for projectmgr > - > > Key: OFBIZ-3212 > URL: https://issues.apache.org/jira/browse/OFBIZ-3212 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Pierre Smits >Assignee: Jacques Le Roux >Priority: Minor > Fix For: SVN trunk > > Attachments: ProjectMgrUILabels-882093.patch, ProjectMgrUiLabels.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OFBIZ-3227) Drag'n'Drop update - add directly in the my portal application
[ https://issues.apache.org/jira/browse/OFBIZ-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco updated OFBIZ-3227: --- Attachment: screen3.bmp screen2.bmp screen1.bmp Hi Sascha, the ESC key works well now. But please see what happens in screen1.bmp, screen2.bmp, screen2.bmp when I drag the second portlet and want to place in the last position. -screen1.bmp Dragging the System status info portlet over the Week view I would have expected to not see any dotted rectangle yet -screen2.bmp Dragging the System status info portlet after the Week view I would have expected to see the dotted rectangle -screen3.bmp Dropping the System status info portlet after the Week view I would have expected to have it in place > Drag'n'Drop update - add directly in the my portal application > -- > > Key: OFBIZ-3227 > URL: https://issues.apache.org/jira/browse/OFBIZ-3227 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Bruno Busco > Fix For: SVN trunk > > Attachments: myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, screen1.bmp, screen2.bmp, screen3.bmp, > screenshot-1.jpg > > > Hi, > Michael ask to add the Drag'n' Drop Feature directly to the myPortal > application. So i did :-) > Beside this, i made a few fixes in the myportal.js. > I'm looking foward to your review. > So long > 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-3227) Drag'n'Drop update - add directly in the my portal application
[ https://issues.apache.org/jira/browse/OFBIZ-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Busco reassigned OFBIZ-3227: -- Assignee: Bruno Busco > Drag'n'Drop update - add directly in the my portal application > -- > > Key: OFBIZ-3227 > URL: https://issues.apache.org/jira/browse/OFBIZ-3227 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp >Assignee: Bruno Busco > Fix For: SVN trunk > > Attachments: myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, screenshot-1.jpg > > > Hi, > Michael ask to add the Drag'n' Drop Feature directly to the myPortal > application. So i did :-) > Beside this, i made a few fixes in the myportal.js. > I'm looking foward to your review. > So long > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Managing OFBiz website with OFBiz
I think we can easily do this once the demo servers are migrated - which I think that they are on the infrastructure, but not the daily updates. Cheers, Ruppert -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 On Nov 25, 2009, at 6:48 AM, Erwan de FERRIERES wrote: Le 25/11/2009 14:41, Hans Bakker a écrit : Have a look at: http://ofbiz.in.th http://ofbiz.nl i have thai and dutch and run on the same website. anybody who want a copy or want to supply different language files let me know. So, I'd like to supply french... No, we did not progress because the move to the apache infrastructure has to be done first .../.. -- Erwan smime.p7s Description: S/MIME cryptographic signature
Re: ModelViewEntity warnings
Still big (one page) after r884047 :p Jacques From: "Jacques Le Roux" From: "Scott Gray" Umm... the list is only bigger because one of your commits uncomments a log statement that had previously been commented: [java] 2009-11-24 14:05:10,640 (main) [ModelReader.java: 365:INFO ] Existing relationship with the same name, but different specs found from w. Right, I did not spot it when rewieving, I have asked Bob Morley why he did so in https://issues.apache.org/jira/browse/OFBIZ-3107 I will wait his answer (for a reasonnable length of time) before commenting out again, except if there is a good reason to comment it right now Jacques Regards Scott HotWax Media http://www.hotwaxmedia.com On 25/11/2009, at 2:08 AM, Jacques Le Roux wrote: The list bet bigger and bigger [java] 2009-11-24 14:05:10,453 (main) [ModelViewEntity.java: 533:WARN ] Conversion for complex-alias needs to be implemented for cache and in-memory eval stuff to work correctly, will not work for ali as: statusDelay of view-entity ExampleStatusDetail [java] 2009-11-24 14:05:10,453 (main) [ModelViewEntity.java: 691:INFO ] Throwing out field alias in view entity ExampleFeatureAndApplAndType because one already exists with the alias name [description ] and field name [EFAAT(ExampleFeatureApplAndType).description], existing field name is [EXFT.description] [java] 2009-11-24 14:05:10,453 (main) [ModelViewEntity.java: 691:INFO ] Throwing out field alias in view entity ExampleFeatureAndApplFullView because one already exists with the alias name [descriptio n] and field name [EFAAAT(ExampleFeatureAndApplAndType).description], existing field name is [EX.description] [java] 2009-11-24 14:05:10,468 (main) [ModelViewEntity.java: 691:INFO ] Throwing out field alias in view entity AllExamplesWithDesiredCustomerFeaturesReport because one already exists with the alias n ame [description] and field name [EXFT(ExampleFeature).description], existing field name is [EFAATD.description] [java] 2009-11-24 14:05:10,468 (main) [ModelViewEntity.java: 691:INFO ] Throwing out field alias in view entity AllExamplesWithDesiredCustomerFeaturesReport because one already exists with the alias n ame [description] and field name [EX(Example).description], existing field name is [EFAATD.description] [java] 2009-11-24 14:05:10,484 (main) [ModelViewEntity.java: 691:INFO ] Throwing out field alias in view entity PartyRelationshipAndContactMechDetail because one already exists with the alias name [pa rtyTypeId] and field name [PTYCM(PartyAndContactMech).partyTypeId], existing field name is [PTYREL.partyTypeId] [java] 2009-11-24 14:05:10,484 (main) [ModelViewEntity.java: 691:INFO ] Throwing out field alias in view entity PartyRelationshipAndContactMechDetail because one already exists with the alias name [de scription] and field name [PTYCM(PartyAndContactMech).description], existing field name is [PTYREL.description] [java] 2009-11-24 14:05:10,484 (main) [ModelViewEntity.java: 691:INFO ] Throwing out field alias in view entity PartyRelationshipAndContactMechDetail because one already exists with the alias name [st atusId] and field name [PTYCM(PartyAndContactMech).statusId], existing field name is [PTYREL.statusId] [java] 2009-11-24 14:05:10,484 (main) [ModelViewEntity.java: 691:INFO ] Throwing out field alias in view entity PartyRelationshipAndContactMechDetail because one already exists with the alias name [fr omDate] and field name [PTYCM(PartyAndContactMech).fromDate], existing field name is [PTYREL.fromDate] [java] 2009-11-24 14:05:10,484 (main) [ModelViewEntity.java: 691:INFO ] Throwing out field alias in view entity PartyRelationshipAndContactMechDetail because one already exists with the alias name [th ruDate] and field name [PTYCM(PartyAndContactMech).thruDate], existing field name is [PTYREL.thruDate] [java] 2009-11-24 14:05:10,484 (main) [ModelViewEntity.java: 691:INFO ] Throwing out field alias in view entity PartyRelationshipAndContactMechDetail because one already exists with the alias name [co mments] and field name [PTYCM(PartyAndContactMech).comments], existing field name is [PTYREL.comments] [java] 2009-11-24 14:05:10,484 (main) [ModelViewEntity.java: 691:INFO ] Throwing out field alias in view entity PartyRoleAndContactMechDetail because one already exists with the alias name [partyTypeI d] and field name [PTYCM(PartyAndContactMech).partyTypeId], existing field name is [PTYRL.partyTypeId] [java] 2009-11-24 14:05:10,484 (main) [ModelViewEntity.java: 691:INFO ] Throwing out field alias in view entity PartyRoleAndContactMechDetail because one already exists with the alias name [externalId ] and field name [PTYCM(PartyAndContactMech).externalId], existing field name is [PTYRL.externalId] [java] 2009-11-24 14:05:10,484 (main) [ModelViewEntity.java: 691:INFO ] Throwing out fiel
Re: Managing OFBiz website with OFBiz
Le 25/11/2009 14:41, Hans Bakker a écrit : Have a look at: http://ofbiz.in.th http://ofbiz.nl i have thai and dutch and run on the same website. anybody who want a copy or want to supply different language files let me know. So, I'd like to supply french... No, we did not progress because the move to the apache infrastructure has to be done first .../.. -- Erwan
[jira] Updated: (OFBIZ-3227) Drag'n'Drop update - add directly in the my portal application
[ https://issues.apache.org/jira/browse/OFBIZ-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sascha Rodekamp updated OFBIZ-3227: --- Attachment: myPortalDragNDrop_v2.patch Hi, + cloning effect when draging a portlet. + ESC press bug, fixed Bruno i decided to create a new service, because i go a different way to replace my portlets. I can't use the original implementation. In my opinion one big service will become to complex/ confusing, so i created a second one. But if it's better to have only one service i see no problem to merge them. So what do you think? Best regards, Sascha > Drag'n'Drop update - add directly in the my portal application > -- > > Key: OFBIZ-3227 > URL: https://issues.apache.org/jira/browse/OFBIZ-3227 > Project: OFBiz > Issue Type: Improvement > Components: specialpurpose/projectmgr >Affects Versions: SVN trunk >Reporter: Sascha Rodekamp > Fix For: SVN trunk > > Attachments: myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, > myPortalDragNDrop_v2.patch, screenshot-1.jpg > > > Hi, > Michael ask to add the Drag'n' Drop Feature directly to the myPortal > application. So i did :-) > Beside this, i made a few fixes in the myportal.js. > I'm looking foward to your review. > So long > Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Managing OFBiz website with OFBiz
Have a look at: http://ofbiz.in.th http://ofbiz.nl i have thai and dutch and run on the same website. anybody who want a copy or want to supply different language files let me know. No, we did not progress because the move to the apache infrastructure has to be done first. Regards, Hans On Wed, 2009-11-25 at 14:27 +0100, Erwan de FERRIERES wrote: > Hi Hans and all, > > At the end of september, you suggested to use OFBiz to manage the OFBiz > website and also to add the multi-langage support in this new website. > > I know that you have plenty of work with birt and other things, but have > you progressed on this point ? > > Regards, > -- Antwebsystems.com: Quality OFBiz services for competitive rates
[jira] Updated: (OFBIZ-3260) Added drop down options replacing text box to configure sagepay
[ https://issues.apache.org/jira/browse/OFBIZ-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abdullah Shaikh updated OFBIZ-3260: --- Attachment: OFBIZ-3260_Added drop down options replacing text box.patch > Added drop down options replacing text box to configure sagepay > --- > > Key: OFBIZ-3260 > URL: https://issues.apache.org/jira/browse/OFBIZ-3260 > Project: OFBiz > Issue Type: Improvement >Reporter: Abdullah Shaikh >Priority: Minor > Attachments: OFBIZ-3260_Added drop down options replacing text > box.patch > > > Added drop down options, replacing text box, to configure SagePay payment > gateway transaction types settings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OFBIZ-3260) Added drop down options replacing text box to configure sagepay
Added drop down options replacing text box to configure sagepay --- Key: OFBIZ-3260 URL: https://issues.apache.org/jira/browse/OFBIZ-3260 Project: OFBiz Issue Type: Improvement Reporter: Abdullah Shaikh Priority: Minor Added drop down options, replacing text box, to configure SagePay payment gateway transaction types settings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Managing OFBiz website with OFBiz
Hi Hans and all, At the end of september, you suggested to use OFBiz to manage the OFBiz website and also to add the multi-langage support in this new website. I know that you have plenty of work with birt and other things, but have you progressed on this point ? Regards, -- Erwan
Re: svn commit: r882127 - /ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
As a reminder (I know we had already a discussion about that)
It should be noted that OfbizCurrencyTransform.java uses UtilFormatOut.formatCurrency() which in turn relies on
com.ibm.icu.text.NumberFormat.getCurrencyInstance(locale) to select the right format.
I guess in most cases it's ok. But I had recently a client who wanted to see only 1 decimals even if his currency is norammly
displayed with 2. I don't know why, I asked he was sure and he was. As we all know the client is King so I did it.
That's why I made this change for formatting outside of ofbizCurrency macro (it's the only place where
UtilFormatOut.formatCurrency() is currently used. As we already said in the case ofbizCurrency macro its maximumFractionDigits
parameter shoud be used.
HTH
Mmm... Now I begin to wonder if I should not replace all uses of UtilFormatOut.formatPrice() by UtilFormatOut.formatCurrency() BTW
it's only in the POS component, except of an exotic use in Webtools to format cache seconds :o)
Jacques
From: "Jacques Le Roux"
From: "Jacques Le Roux"
Thanks Akash,
I did not apply your patch since, as you said, accountLimit is below formated
using ofbizCurrency anyway and just above
?double is used in <#assign accountLimit = billingAccount.accountLimit?double />
So it's ok there.
Actually my demand was not really related to this commit but at large to "##0.00" in ftl files (there are 11 instances) which
should
better use also ofbizCurrency... I think I will do later..
Because at the moment my main concern is about UtilFormatOut.java[43-44]. I
would like to use properties there.
Because prices are always related to a currency, I'd use currency.decimal.format for priceNumberFormat but as it's never used, I
think we can remove
and I will introduce price.decimal.format=#,##0.00 in general.proprties to be
used for priceDecimalFormat in UtilFormatOut.java
I even wonder if we should not use only one string. I think I will write and
commit changes shortly...
Done in trunk at r884023 , R9.04 r884033
Jacques
Jacques
From: "Akash Jain"
Hello Jacques,
I have done R&D on "currency.decimal.format" and I came up the
conclusion, it is used for deciding how many digit you want after decimal
suppose,
input = 1.0;
currencyFormat = UtilProperties.getPropertyValue("general.properties",
"currency.decimal.format", "##0.00");
formatter = new DecimalFormat(currencyFormat);
output = formatter.format(input);
println("=output=="+output);
then,
if value of property currency.decimal.format = ##0.00 in
general.properties file then value of output = 1.00
if value of property currency.decimal.format = ##0.000 in
general.properties file then value of output = 1.000
if value of property currency.decimal.format = ##0. in
general.properties file then value of output = 1. and so on.
But there following issues in using "currency.decimal.format" property
for this commit:-
(1) There is need to assign (accountLimit = 0.00) value only, not
matter about digits after decimal.
(2) In this case output will be "string" and in the next step there is
used, <@ofbizCurrency
amount=accountLimit isoCode=billingAccount.accountCurrencyUomId/> it
will create problem
I have attached a patch in which I have used BigDecimal.Zero instead of
currency.decimal.format property.
Waiting for your/others suggestions.
Thanks and Regards
--
Akash Jain
Jacques Le Roux wrote:
Hi Ashish,
Sorry to be nit-picking, not a big deal, could it be possible to use
something Parameterized ? Sometimes we do not want to see 2
decimals (but more or less, I was confronted to such a demand recently
: 1 decimals only)
BTW we have a bunch of "##0.00" in ftl files and they should better
use currency.decimal.format.
Thanks
Jacques
Author: ashish
Date: Thu Nov 19 12:30:58 2009
New Revision: 882127
URL: http://svn.apache.org/viewvc?rev=882127&view=rev
Log:
Conditional check for billingAccount amount. If no account limit is
set with party's billing account then 0.00 will be shown on
checkout page. Thanks Akash for the patch.
Modified:
ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
Modified:
ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl?rev=882127&r1=882126&r2=882127&view=diff
==
---
ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
(original)
+++
ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
Thu Nov 19 12:30:58 2009
@@ -52,7 +52,11 @@
<#list billingAccountList as billingAccount>
<#assign availableAmount =
billingAccount.accountBalance?double>
- <#assign accountLimit =
billingAccount.accountLimit?double>
+ <#if (billingAccount.accountLimit)?exists>
birt component without duplicates : objection against merging?
Chattree has fixed the duplicated jar problem. concerning the license, my opinion is what is good for the eclipse foundation is good for Apache. We have a saying here: we should not be more roman catholic than the pope.. so what is the community opinion? can we merge the addbirt branch back into the trunk? Regards, Hans -- http://www.antwebsystems.com : Quality OFBiz support for competitive rates
Re: from BIZZNESS_TIME to DROPPING_CRUMB ?
Beware Bruno, I'm sure if we put it as default you will get some issues like in OFBIZ-2398 ;o) Maybe less though from what I have seen so far. Ryan's suggestion was good and Adrian's help also... Jacques From: "Bruno Busco" +1 ;-) 2009/11/25 Jacques Le Roux : Hi, I wonder if we should no change the default theme from BIZZNESS_TIME to DROPPING_CRUMB. I know it will not be consistent anymore with Site and Doc but looking at https://issues.apache.org/jira/browse/OFBIZ-2398 I think DROPPING_CRUMB is doing a better job and has a real good look now Jacques
[jira] Commented: (OFBIZ-3107) framework - entity
[ https://issues.apache.org/jira/browse/OFBIZ-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782374#action_12782374 ] Jacques Le Roux commented on OFBIZ-3107: Hi Scott, Done as suggested at r884047 > framework - entity > -- > > Key: OFBIZ-3107 > URL: https://issues.apache.org/jira/browse/OFBIZ-3107 > Project: OFBiz > Issue Type: Sub-task > Components: framework >Affects Versions: SVN trunk >Reporter: Bob Morley >Assignee: Jacques Le Roux > Fix For: SVN trunk > > Attachments: OFBIZ-3107-take2.patch, OFBIZ-3107.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: from BIZZNESS_TIME to DROPPING_CRUMB ?
+1 ;-) 2009/11/25 Jacques Le Roux : > Hi, > > I wonder if we should no change the default theme from BIZZNESS_TIME to > DROPPING_CRUMB. > I know it will not be consistent anymore with Site and Doc but looking at > https://issues.apache.org/jira/browse/OFBIZ-2398 I think DROPPING_CRUMB is > doing a better job and has a real good look now > > Jacques > >
from BIZZNESS_TIME to DROPPING_CRUMB ?
Hi, I wonder if we should no change the default theme from BIZZNESS_TIME to DROPPING_CRUMB. I know it will not be consistent anymore with Site and Doc but looking at https://issues.apache.org/jira/browse/OFBIZ-2398 I think DROPPING_CRUMB is doing a better job and has a real good look now Jacques
Re: svn commit: r882127 - /ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
From: "Jacques Le Roux"
Thanks Akash,
I did not apply your patch since, as you said, accountLimit is below formated
using ofbizCurrency anyway and just above
?double is used in <#assign accountLimit = billingAccount.accountLimit?double />
So it's ok there.
Actually my demand was not really related to this commit but at large to "##0.00" in ftl files (there are 11 instances) which
should
better use also ofbizCurrency... I think I will do later..
Because at the moment my main concern is about UtilFormatOut.java[43-44]. I
would like to use properties there.
Because prices are always related to a currency, I'd use currency.decimal.format for priceNumberFormat but as it's never used, I
think we can remove
and I will introduce price.decimal.format=#,##0.00 in general.proprties to be
used for priceDecimalFormat in UtilFormatOut.java
I even wonder if we should not use only one string. I think I will write and
commit changes shortly...
Done in trunk at r884023 , R9.04 r884033
Jacques
Jacques
From: "Akash Jain"
Hello Jacques,
I have done R&D on "currency.decimal.format" and I came up the
conclusion, it is used for deciding how many digit you want after decimal
suppose,
input = 1.0;
currencyFormat = UtilProperties.getPropertyValue("general.properties",
"currency.decimal.format", "##0.00");
formatter = new DecimalFormat(currencyFormat);
output = formatter.format(input);
println("=output=="+output);
then,
if value of property currency.decimal.format = ##0.00 in
general.properties file then value of output = 1.00
if value of property currency.decimal.format = ##0.000 in
general.properties file then value of output = 1.000
if value of property currency.decimal.format = ##0. in
general.properties file then value of output = 1. and so on.
But there following issues in using "currency.decimal.format" property
for this commit:-
(1) There is need to assign (accountLimit = 0.00) value only, not
matter about digits after decimal.
(2) In this case output will be "string" and in the next step there is
used, <@ofbizCurrency
amount=accountLimit isoCode=billingAccount.accountCurrencyUomId/> it
will create problem
I have attached a patch in which I have used BigDecimal.Zero instead of
currency.decimal.format property.
Waiting for your/others suggestions.
Thanks and Regards
--
Akash Jain
Jacques Le Roux wrote:
Hi Ashish,
Sorry to be nit-picking, not a big deal, could it be possible to use
something Parameterized ? Sometimes we do not want to see 2
decimals (but more or less, I was confronted to such a demand recently
: 1 decimals only)
BTW we have a bunch of "##0.00" in ftl files and they should better
use currency.decimal.format.
Thanks
Jacques
Author: ashish
Date: Thu Nov 19 12:30:58 2009
New Revision: 882127
URL: http://svn.apache.org/viewvc?rev=882127&view=rev
Log:
Conditional check for billingAccount amount. If no account limit is
set with party's billing account then 0.00 will be shown on
checkout page. Thanks Akash for the patch.
Modified:
ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
Modified:
ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl?rev=882127&r1=882126&r2=882127&view=diff
==
---
ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
(original)
+++
ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
Thu Nov 19 12:30:58 2009
@@ -52,7 +52,11 @@
<#list billingAccountList as billingAccount>
<#assign availableAmount =
billingAccount.accountBalance?double>
- <#assign accountLimit =
billingAccount.accountLimit?double>
+ <#if (billingAccount.accountLimit)?exists>
+ <#assign accountLimit =
billingAccount.accountLimit?double />
+ <#else>
+ <#assign accountLimit = 0.00 />
+
selected>${billingAccount.description?default("")}
[${billingAccount.billingAccountId}]
Available: <@ofbizCurrency amount=availableAmount
isoCode=billingAccount.accountCurrencyUomId/> Limit: <@ofbizCurrency
amount=accountLimit
isoCode=billingAccount.accountCurrencyUomId/>
[jira] Commented: (OFBIZ-3227) Drag'n'Drop update - add directly in the my portal application
[
https://issues.apache.org/jira/browse/OFBIZ-3227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782356#action_12782356
]
Bruno Busco commented on OFBIZ-3227:
Sascha,
I tested your last patch and I found that if I press the "ESC" key during the
dragging to cancel it, the dotted rectangle is not removed from the screen.
If you could please fix this I do not find any other problem to commit it.
BTW:
Making a deeper review of what I already committed of your patch I would like
to discuss with you if the new service you created updatePortletSeqDragDrop
could be merged to the service updatePortalPagePortletSeq that was already
there.
The "mode" attribute could be used to tell the updatePortalPagePortletSeq if a
relative ("UP", "DOWN","TOP","BOTTOM") or an absolute movement ir required.
What do you think about?
> Drag'n'Drop update - add directly in the my portal application
> --
>
> Key: OFBIZ-3227
> URL: https://issues.apache.org/jira/browse/OFBIZ-3227
> Project: OFBiz
> Issue Type: Improvement
> Components: specialpurpose/projectmgr
>Affects Versions: SVN trunk
>Reporter: Sascha Rodekamp
> Fix For: SVN trunk
>
> Attachments: myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch,
> myPortalDragNDrop_v2.patch, myPortalDragNDrop_v2.patch, screenshot-1.jpg
>
>
> Hi,
> Michael ask to add the Drag'n' Drop Feature directly to the myPortal
> application. So i did :-)
> Beside this, i made a few fixes in the myportal.js.
> I'm looking foward to your review.
> So long
> Sascha
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (OFBIZ-3258) Broken link on product parties screen
[ https://issues.apache.org/jira/browse/OFBIZ-3258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-3258. -- Resolution: Fixed Assignee: Jacques Le Roux Thanks Ean, Your patch has been commited in trunk at r883933, R9.04 at r884020 > Broken link on product parties screen > - > > Key: OFBIZ-3258 > URL: https://issues.apache.org/jira/browse/OFBIZ-3258 > Project: OFBiz > Issue Type: Bug > Components: product >Affects Versions: SVN trunk >Reporter: Ean Schuessler >Assignee: Jacques Le Roux > Fix For: SVN trunk > > Attachments: fix-bad-link-url.patch > > > The link to associated parties uses "party_id" instead of "partyId" as > expected by the party manager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r882127 - /ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
Thanks Akash,
I did not apply your patch since, as you said, accountLimit is below formated
using ofbizCurrency anyway and just above
?double is used in <#assign accountLimit = billingAccount.accountLimit?double />
So it's ok there.
Actually my demand was not really related to this commit but at large to
"##0.00" in ftl files (there are 11 instances) which should
better use also ofbizCurrency... I think I will do later..
Because at the moment my main concern is about UtilFormatOut.java[43-44]. I
would like to use properties there.
Because prices are always related to a currency, I'd use currency.decimal.format for priceNumberFormat but as it's never used, I
think we can remove
and I will introduce price.decimal.format=#,##0.00 in general.proprties to be
used for priceDecimalFormat in UtilFormatOut.java
I even wonder if we should not use only one string. I think I will write and
commit changes shortly...
Jacques
From: "Akash Jain"
Hello Jacques,
I have done R&D on "currency.decimal.format" and I came up the
conclusion, it is used for deciding how many digit you want after decimal
suppose,
input = 1.0;
currencyFormat = UtilProperties.getPropertyValue("general.properties",
"currency.decimal.format", "##0.00");
formatter = new DecimalFormat(currencyFormat);
output = formatter.format(input);
println("=output=="+output);
then,
if value of property currency.decimal.format = ##0.00 in
general.properties file then value of output = 1.00
if value of property currency.decimal.format = ##0.000 in
general.properties file then value of output = 1.000
if value of property currency.decimal.format = ##0. in
general.properties file then value of output = 1. and so on.
But there following issues in using "currency.decimal.format" property
for this commit:-
(1) There is need to assign (accountLimit = 0.00) value only, not
matter about digits after decimal.
(2) In this case output will be "string" and in the next step there is
used, <@ofbizCurrency
amount=accountLimit isoCode=billingAccount.accountCurrencyUomId/> it
will create problem
I have attached a patch in which I have used BigDecimal.Zero instead of
currency.decimal.format property.
Waiting for your/others suggestions.
Thanks and Regards
--
Akash Jain
Jacques Le Roux wrote:
Hi Ashish,
Sorry to be nit-picking, not a big deal, could it be possible to use
something Parameterized ? Sometimes we do not want to see 2
decimals (but more or less, I was confronted to such a demand recently
: 1 decimals only)
BTW we have a bunch of "##0.00" in ftl files and they should better
use currency.decimal.format.
Thanks
Jacques
Author: ashish
Date: Thu Nov 19 12:30:58 2009
New Revision: 882127
URL: http://svn.apache.org/viewvc?rev=882127&view=rev
Log:
Conditional check for billingAccount amount. If no account limit is
set with party's billing account then 0.00 will be shown on
checkout page. Thanks Akash for the patch.
Modified:
ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
Modified:
ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl?rev=882127&r1=882126&r2=882127&view=diff
==
---
ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
(original)
+++
ofbiz/trunk/applications/order/webapp/ordermgr/entry/billsettings.ftl
Thu Nov 19 12:30:58 2009
@@ -52,7 +52,11 @@
<#list billingAccountList as billingAccount>
<#assign availableAmount =
billingAccount.accountBalance?double>
- <#assign accountLimit =
billingAccount.accountLimit?double>
+ <#if (billingAccount.accountLimit)?exists>
+ <#assign accountLimit =
billingAccount.accountLimit?double />
+ <#else>
+ <#assign accountLimit = 0.00 />
+
selected>${billingAccount.description?default("")}
[${billingAccount.billingAccountId}]
Available: <@ofbizCurrency amount=availableAmount
isoCode=billingAccount.accountCurrencyUomId/> Limit: <@ofbizCurrency
amount=accountLimit
isoCode=billingAccount.accountCurrencyUomId/>
[jira] Commented: (OFBIZ-3151) fix for using "equals" operator with null field in performFind service.
[ https://issues.apache.org/jira/browse/OFBIZ-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782350#action_12782350 ] Jacques Le Roux commented on OFBIZ-3151: Chatree, Scott, Yes, but what if someone prefer "null" tomorrow, etc.? Should we not avoid redundancy which we now may lead to inconsistency? And I'm sure one day someone whill ask the differnce between nullField and empty... I'd prefer to revert > fix for using "equals" operator with null field in performFind service. > --- > > Key: OFBIZ-3151 > URL: https://issues.apache.org/jira/browse/OFBIZ-3151 > Project: OFBiz > Issue Type: Improvement > Components: framework >Reporter: Chatree Srichart > Fix For: SVN trunk > > Attachments: FindServices.java.diff > > > Because I can not use "equals" operator with null field in performFind > service. So I fixed for use one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
