[jira] Commented: (OFBIZ-3843) Localized date format for end user
[ https://issues.apache.org/jira/browse/OFBIZ-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970737#action_12970737 ] Nicolas Malin commented on OFBIZ-3843: -- Sorry Jacques for latency, I look asap this. Localized date format for end user -- Key: OFBIZ-3843 URL: https://issues.apache.org/jira/browse/OFBIZ-3843 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Nicolas Malin Priority: Minor Attachments: OFBIZ-3843.patch, OFBIZ-3843.patch, With the patch.jpg, Without patch (in trunk demo).jpg, Wrong From Date.jpg Many French end users don't want to use this date format : -mm-dd. To make a better user friendly OFBiz interface, I've added the possibility to configure in general.properties a localized date format. OFBiz use localized format (as dd/mm/) for all interactions with users but keep universal format for its framework. It's then possible to set date with unniversal or localized format. What's working : * Dates in screen engine : display, date-find, date-time * performFind * Service call Know problem : * I don't find how to configure js calendar to support this functionality It's possible that my solution isn't the best one to do that. But I'm open to all comment -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: getter/setter facade
Le 13/12/2010 08:56, Nicolas Malin a écrit :
Le 12/12/2010 01:32, Adam Heath a écrit :
BJ Freeman wrote:
most of the frame works are objects.
so how would you implement your object in simple-methods
like GenericValue?
These new classes are still GenericValue, while also being more
specific.
class Party extends GenericValue {}
This system already exist with neogia addons. If you install the
persistance layer with ofbiz-generator addons you have a simulation
ORM over entity engine. It's not a greate revolution, we use this only
for big customer project.
Nicolas
Just an example from neogia accounting components :
String transId = (String) context.get(AcctgTransaction.transId);
AcctgTransaction acctgTransaction =
AcctgTransactionServices.findByPrimaryKey(delegator, transId);
ListAcctgTransactionItem listAcctgTransactionItems =
acctgTransaction.getAcctgTransactionItemsWC();
if
(AcctgTransactionStatus.FINALIZED.equals(acctgTransaction.getStatusId())) {
return
ServiceUtil.returnSuccess(UtilProperties.getMessage(resource,
NaccountingAlreadyFinalized, locale));
}
We also extend delegator interface :
ListAcctgTransaction transactions =
delegator.findNList(AcctgTransaction.ENTITY_NAME,
EntityExpr.makeCondition(UtilMisc.toMap(AcctgTransaction.statusId,
AcctgTransactionStatus.WIP)), null, null, null, false);
Nicolas
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
---
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
[jira] Commented: (OFBIZ-4014) i18n from DateTime display fields
[ https://issues.apache.org/jira/browse/OFBIZ-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970741#action_12970741 ] Nicolas Malin commented on OFBIZ-4014: -- Hi Sascha, I tried to manage locale date on display and edit field. But the second it's more difficult and I hope to manage hidden date as timestamp format to remove all probleme with pk date field. In your solution, you manage the timezone, I check it's possible to inclde this in my patch Nicolas i18n from DateTime display fields -- Key: OFBIZ-4014 URL: https://issues.apache.org/jira/browse/OFBIZ-4014 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Sascha Rodekamp Fix For: SVN trunk Attachments: OFBIZ-4014_ModelFormField_DateTimeField_i18n.patch Hi everybody, i did a little improvement in the display form fields from type date and date-time. In the past the timestamps where read from the DB and the string was simply cut, that didn't match with (i.e.) German date pattern. I changed this substring stuff and used the locale and timezone with the dateFormatter to create a i18n date string. This patch works for: display type=date / and display type=date-time / Hope that helps. Have a nice day Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4052) Update Docbook files and give a nice look to doc
[ https://issues.apache.org/jira/browse/OFBIZ-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970746#action_12970746 ] BJ Freeman commented on OFBIZ-4052: --- Yes I was talking about the demo server. for the windows there is a hickup in the core system, 1) the virtual file is fragmented 2) extensive use of the virtual file is being used to swap program memory segment 3) large virtual file that most is being used. it is a combination of thread racing and delay in response from the virtual file when doing program segment swaps. the above can be alleviated by 1) using Norton speed disk that put the virtual file on the outside of the disk tracks and defrags it completely and or 2) have sufficient real memory not to use the virtual file. per the code segment both condition are set in the class. on the isdecorator is modified by calling code. so it should never fail. if does not fail on my two machines, Update Docbook files and give a nice look to doc Key: OFBIZ-4052 URL: https://issues.apache.org/jira/browse/OFBIZ-4052 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: BJ Freeman Priority: Minor Attachments: docbook.css, OFBIZ-4052Docbookfiles.patch, OFBIZ-4052Docbookfiles.patch updateds all the docbook.css in themes. remove tags from the body -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4052) Update Docbook files and give a nice look to doc
[ https://issues.apache.org/jira/browse/OFBIZ-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970748#action_12970748 ] BJ Freeman commented on OFBIZ-4052: --- docbook once started is all XSL: that is why there is no log output till it completes. if because of memory corruption a element is corrupted the XSL: compilation is stopped with no error msg Update Docbook files and give a nice look to doc Key: OFBIZ-4052 URL: https://issues.apache.org/jira/browse/OFBIZ-4052 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: BJ Freeman Priority: Minor Attachments: docbook.css, OFBIZ-4052Docbookfiles.patch, OFBIZ-4052Docbookfiles.patch updateds all the docbook.css in themes. remove tags from the body -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4052) Update Docbook files and give a nice look to doc
[ https://issues.apache.org/jira/browse/OFBIZ-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970750#action_12970750 ] Jacques Le Roux commented on OFBIZ-4052: Thanks BJ, This should help. I understood it's an XSL issue, but not sure how to handle that yet. It still found weird though that both systems would be corrupted at the same time. I will try with my Ubuntu box... Update Docbook files and give a nice look to doc Key: OFBIZ-4052 URL: https://issues.apache.org/jira/browse/OFBIZ-4052 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: BJ Freeman Priority: Minor Attachments: docbook.css, OFBIZ-4052Docbookfiles.patch, OFBIZ-4052Docbookfiles.patch updateds all the docbook.css in themes. remove tags from the body -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-3833) Payment capture is less than Order total
[ https://issues.apache.org/jira/browse/OFBIZ-3833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970752#action_12970752 ] Jacques Le Roux commented on OFBIZ-3833: ping... Payment capture is less than Order total Key: OFBIZ-3833 URL: https://issues.apache.org/jira/browse/OFBIZ-3833 Project: OFBiz Issue Type: Bug Components: order Reporter: Akash Jain Priority: Minor Fix For: Release Branch 4.0, Release Branch 09.04, Release Branch 10.04, SVN trunk Attachments: OFBIZ-3833.patch Following are the steps to regenerate issue: (1) Create an order for state for which Sales Tax applied on product. (2) Cancel order item (for which sales tax applied) during Edit Items from order detail page. (3) Now depress Quick Ship Entire Orde button, order will be completed. (4) There will be diffrence between payment capture and order total (payment catpture will be less than order total). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4052) Update Docbook files and give a nice look to doc
[ https://issues.apache.org/jira/browse/OFBIZ-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970774#action_12970774 ] Jacques Le Roux commented on OFBIZ-4052: I doubt it's a virtual file issue and I just checked the virtual file using [pagedfrg.exe|http://technet.microsoft.com/en-us/sysinternals/bb897426.aspx], it's not fragmented (all files are on 1 frament) but I will defrag anyway on next boot. Update Docbook files and give a nice look to doc Key: OFBIZ-4052 URL: https://issues.apache.org/jira/browse/OFBIZ-4052 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: BJ Freeman Priority: Minor Attachments: docbook.css, OFBIZ-4052Docbookfiles.patch, OFBIZ-4052Docbookfiles.patch updateds all the docbook.css in themes. remove tags from the body -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4052) Update Docbook files and give a nice look to doc
[ https://issues.apache.org/jira/browse/OFBIZ-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970775#action_12970775 ] Jacques Le Roux commented on OFBIZ-4052: Also it does not use much memory (using XP_PageFileMon.exe) 13/12/2010 11:46:12 Pagefile Physical Location: C:\pagefile.sys Current Pagefile Usage: 81 MB Session Peak Usage: 83 MB Current Pagefile Size: 3326 MB Update Docbook files and give a nice look to doc Key: OFBIZ-4052 URL: https://issues.apache.org/jira/browse/OFBIZ-4052 Project: OFBiz Issue Type: Improvement Affects Versions: SVN trunk Reporter: BJ Freeman Priority: Minor Attachments: docbook.css, OFBIZ-4052Docbookfiles.patch, OFBIZ-4052Docbookfiles.patch updateds all the docbook.css in themes. remove tags from the body -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4014) i18n from DateTime display fields
[ https://issues.apache.org/jira/browse/OFBIZ-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970780#action_12970780 ] Sascha Rodekamp commented on OFBIZ-4014: Hi Nicolas, yes feel free. If you need any help, support, code lines :) don't hesitate to contact. Would be very great if we can get used to this issue and create a cool solution! Cheers Sascha i18n from DateTime display fields -- Key: OFBIZ-4014 URL: https://issues.apache.org/jira/browse/OFBIZ-4014 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: SVN trunk Reporter: Sascha Rodekamp Fix For: SVN trunk Attachments: OFBIZ-4014_ModelFormField_DateTimeField_i18n.patch Hi everybody, i did a little improvement in the display form fields from type date and date-time. In the past the timestamps where read from the DB and the string was simply cut, that didn't match with (i.e.) German date pattern. I changed this substring stuff and used the locale and timezone with the dateFormatter to create a i18n date string. This patch works for: display type=date / and display type=date-time / Hope that helps. Have a nice day Sascha -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Webtool Threads: is Java 5?
I think we can remove this whole line in trunk, 10.4 and even 9.04, please
confirm before I do
p${uiLabelMap.WebtoolsJavaVersionIs5} #if isJava5
${uiLabelMap.CommonYes}#else${uiLabelMap.CommonNo}/#if/p
Thanks
Jacques
Re: Marketing campaigns and contact lists
Calling it an application seems fine. Is there a good example of an upgradeable multi-table application? - BJ Freeman wrote: how about a contactlistappl that other entities can use in the future change the contactlistid to the contactlistappl. then would also a allow a upfrade path with a service. Ean Schuessler sent the following on 12/12/2010 4:50 PM: Currently, contact lists are associated with marketing campaigns via a contactListId field on ContactList. It seems to me that contact lists would be used repeatedly over a long period of time by numerous campaigns. Would there be an objection to deprecating the marketingCampaignId field in ContactList and creating a new MarketingCampaignContactList entity? I would imagine that this entity would follow the fromDate/thruDate pattern. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: service dispatcher map context just like GenericEntity
I suggested this a while ago and it got a mixed response. I started
writing code for it in case there was any interest. I can post that code
to Jira if you would like me to.
I started off with a Parameters class that is a simple wrapper around a
Map. The class has typed accessors and it is writable. The Parameters
class can be subclassed into type-specific contexts: RequestContext,
ServiceContext, ScreenContext, MethodContext, etc.
From my perspective, the advantage of typed contexts is the ability to
add type-specific behaviors to them.
If the idea makes its way into the project, the context must be writable
at first - generating a warning when modified. This is because a lot of
code modifies the context and the parameters Map it contains.
In addition, I think the context should throw an exception if client
code attempts to retrieve a parameter that is not in the service definition.
-Adrian
On 12/11/2010 12:57 PM, Adam Heath wrote:
The parameters to a service are a list of names, and the types of
those parameters. This is very similar to a GenericEntity.
GenericEntity is a map, that has special methods for fetching
type-specific values(getLong, getBigDecimal, etc).
Wouldn't it be nice to have type-specific maps passed to java-based
services?
My idea would introduce a GenericContext, used by both entity and
service. This context would be read-only. There would be a model
that defined the java types for each value.
The entity system would extend the java type definitions, to attach
the sql version of the backing store. It would also extend
GenericContext to be writable.
The service engine would the do similar things. Incoming service
calls could define that they'd like to take a GenericContext, instead
of a map. It would also extend the service model to support incoming
GenericContext type-specific methods.
Also, while doing all this, I'd like to move the specification of
default values from service code, into the definition. I've found
code like this:
if (!context.containsKey(someParameter)) {
context.put(someParameter, defaultValue);
}
or
Object value = context.get(someParameter);
if (value == null) {
value = defaultValue;
}
The former is broken, as it tries to write a value into the context.
The context is supposed to be read-only.
Re: Marketing campaigns and contact lists
the appl as I understand it is a many to many interface. to my knowledge no one has discussed migration, in detail, as an (semi)automated process but I think it would be a good thread. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Ean Schuessler sent the following on 12/13/2010 4:57 AM: Calling it an application seems fine. Is there a good example of an upgradeable multi-table application? - BJ Freeman wrote: how about a contactlistappl that other entities can use in the future change the contactlistid to the contactlistappl. then would also a allow a upfrade path with a service. Ean Schuessler sent the following on 12/12/2010 4:50 PM: Currently, contact lists are associated with marketing campaigns via a contactListId field on ContactList. It seems to me that contact lists would be used repeatedly over a long period of time by numerous campaigns. Would there be an objection to deprecating the marketingCampaignId field in ContactList and creating a new MarketingCampaignContactList entity? I would imagine that this entity would follow the fromDate/thruDate pattern.
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970884#action_12970884
]
Adrian Crum commented on OFBIZ-4053:
I like the concept, and I agree that this new functionality should be
implemented without adding a bunch of new methods to the Delegator interface.
It might help to get everyone to agree on the syntax before discussing the
implementation details.
My preference would be something like:
{code}
Query query = Query.newInstance(delegator); // create would be better, but it
might cause method name clash
EntityListIterator iterator = query.distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate
DESC)
.maxRows(viewSize *
(viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970884#action_12970884
]
Adrian Crum edited comment on OFBIZ-4053 at 12/13/10 11:42 AM:
---
I like the concept, and I agree that this new functionality should be
implemented without adding a bunch of new methods to the Delegator interface.
It might help to get everyone to agree on the syntax before discussing the
implementation details.
My preference would be something like:
{code}
Query query = Query.newInstance(delegator); // create would be better, but it
might cause method name clash
EntityListIterator iterator = query.distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
was (Author: adri...@hlmksw.com):
I like the concept, and I agree that this new functionality should be
implemented without adding a bunch of new methods to the Delegator interface.
It might help to get everyone to agree on the syntax before discussing the
implementation details.
My preference would be something like:
{code}
Query query = Query.newInstance(delegator); // create would be better, but it
might cause method name clash
EntityListIterator iterator = query.distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate
DESC)
.maxRows(viewSize *
(viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big
[jira] Issue Comment Edited: (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970884#action_12970884
]
Adrian Crum edited comment on OFBIZ-4053 at 12/13/10 11:45 AM:
---
I like the concept, and I agree that this new functionality should be
implemented without adding a bunch of new methods to the Delegator interface.
It might help to get everyone to agree on the syntax before discussing the
implementation details.
My preference would be something like:
{code}
Query query = Query.newInstance(delegator); // create would be better, but it
might cause method name clash
EntityListIterator iterator = query.execute()
.distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
was (Author: adri...@hlmksw.com):
I like the concept, and I agree that this new functionality should be
implemented without adding a bunch of new methods to the Delegator interface.
It might help to get everyone to agree on the syntax before discussing the
implementation details.
My preference would be something like:
{code}
Query query = Query.newInstance(delegator); // create would be better, but it
might cause method name clash
EntityListIterator iterator = query.distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm
ofbiz memory size
how much does simple methods effect total memory usage/ How much has ofbiz increased and by how much based on classes that have been added? how many of the Classes in applications can be reduced to simple-methods? what can be done to streamline ofbiz memory usage? I have experienced a error from an OOTB truck 104453 startofbiz Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. .\ant run works. this is on a windows xp with jdk1.6.0_19 = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970967#action_12970967
]
Scott Gray commented on OFBIZ-4053:
---
Hi Adrian,
It isn't clear to me what the Query class would represent, what would
instantiation of an EntityOne object look like? Also, what does the execute()
method do?
My only reason for wanting to add the methods to the delegator was to keep the
code required to create and execute a query as short as possible. If no one is
worried about that then fine, I'll accept that it isn't a possibility. I just
personally prefer practicality over purism.
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970984#action_12970984
]
Adrian Crum commented on OFBIZ-4053:
The Query class is just EntityBuilderUtil renamed.
The reason for the execute method is to tell the class when to execute the
query. In your current implementation, the iterator method call must appear
last - otherwise the settings from the previous method calls would be lost.
Actually, in my example, execute should appear last - which would imply the
same limitation. I was just trying to come up with a syntax that doesn't have
hidden rules or constraints.
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12970988#action_12970988
]
Scott Gray commented on OFBIZ-4053:
---
Okay but EntityBuilderUtil has two methods, one returns an EntityList object
and the other an EntityOne.
Okay so you are in favor of execute() over the query() that Adam proposed. The
iterator() method is an end-point in the method chaining, EntityList can return
multiple result types:
- execute() (or query() or list() have also been proposed) returns a List
- iterator() returns and EntityListIterator
- count() returns a long
- first() returns a GenericValue
I'm not sure that these are hidden rules, they're simply a requirement of the
implementation. The above methods are the only ones that would fix a query to
a given result type and it makes sense that they occur at the end and return
the result.
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12971002#action_12971002
]
Scott Gray commented on OFBIZ-4053:
---
We could always go for something like:
- execute()/query()
- executeIterator()/queryIterator()
- executeCount()/queryCount()
- executeFirst()/queryFirst()
That might help clarify their purpose and group them together during
autocompletion in IDEs. I'm not really a huge fan though because once again we
lose some brevity.
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12971025#action_12971025
]
Adrian Crum commented on OFBIZ-4053:
Keep in mind that I'm just tossing out suggestions - please don't let my
comments be a blocker. Overall I think it's a great idea. I commented on it
because I know it can help in the design stage to get various viewpoints on
syntax so that the end result makes sense to the most people.
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12971033#action_12971033
]
David E. Jones commented on OFBIZ-4053:
---
First off, I like this general direction. A while back (years ago) when
thinking about cleaning up the delegator API it seems like we discussed the
idea of using a query object with various methods instead of the find* methods
with their large numbers of parameters, that are individually sometimes complex
anyway. Scott's idea earlier this summer was an extension of that where the
various methods instead of returning void would return the query object to
allow chaining (definitely tightens up the code).
Anyway, in the Moqui framework here is what I've done with those ideas, for
those interested. Here is the EntityFind interface (for the query object):
http://moqui.svn.sourceforge.net/viewvc/moqui/trunk/moqui/framework/src-api/org/moqui/entity/EntityFind.java?revision=25content-type=text/plain
This is called from the find method on the EntityFacade interface (the
equivalent of the delegator in Moqui), and there are no other find methods:
http://moqui.svn.sourceforge.net/viewvc/moqui/trunk/moqui/framework/src-api/org/moqui/entity/EntityFind.java?revision=25content-type=text/plain
With this EntityFind interface the idea is that you are setting up the details
of the query, and you could potentially run more than query with the same
object. You'll also notice that Moqui includes a EntityList interface in
addition to the EntityListIterator concept instead of returning a generic
ListEntityValue, and that might be something useful in OFBiz too (mostly to
have convenience methods right there instead of using EntityUtil).
I actually started with the EntityFindOptions class and then expanded it based
on the various parameter and return value options for the delegator find
methods. The result has a LOT less redundancy, and the code should be more
readable (and more similar to the XML code where markup describes everything
instead of having to know which parameter means what).
Another detail: should the query object be immutable? I decided that it should
not be in Moqui, and the various methods on EntityFind that return an
EntityFind just return a this reference as it is ONLY for convenience and
having an immutable object would result in all sorts of unused query objects
being created.
Anyway, there are some thoughts, for what it's worth...
It would also be nice if the ShoppingCart and ShoppingCartItem worked in a
similar way... ;)
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the
[jira] Commented: (OFBIZ-4053) Implement an Entity Query Builder
[
https://issues.apache.org/jira/browse/OFBIZ-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12971043#action_12971043
]
Scott Gray commented on OFBIZ-4053:
---
@Adrian - no worries and thanks, feedback and ideas were the reason for the
jira issue instead of just committing it.
@David - thanks for the links, I was aware that you'd done some work in this
area but decided not to look at it ahead of time and instead see what I could
come up with. I was also hoping you'd comment sooner or later :-) I'll take a
close look as soon as I get a chance. Totally agree on the shopping cart
objects, it's another area where we have a stack of methods taking way too many
parameters.
Implement an Entity Query Builder
-
Key: OFBIZ-4053
URL: https://issues.apache.org/jira/browse/OFBIZ-4053
Project: OFBiz
Issue Type: New Feature
Components: framework
Affects Versions: SVN trunk
Reporter: Scott Gray
Assignee: Scott Gray
Attachments: builder.patch
As discussed on the dev list here:
http://ofbiz.markmail.org/thread/l6kiywqzfj656dhc
Attached is an initial implementation of builder classes (of sorts) that make
use of method chaining in order to simplify use of the Delegator interface to
query entities.
Rather than taking all possible query parameters into a single method as the
delegator does, this implementation instead builds a query through a
succession of distinct method calls.
A simple example:
{code}
// Using the Delegator interface directly
eli = delegator.find(FinAccountTrans, condition, null, null,
UtilMisc.toList(-transactionDate), null);
// Using the new implementation
eli =
EntityBuilderUtil.list(delegator).from(FinAccountTrans).where(condition).orderBy(-transactionDate).iterator();
{code}
A more complex example:
{code}
// Delegator
EntityCondition queryConditionsList =
EntityCondition.makeCondition(allConditions, EntityOperator.AND);
EntityFindOptions options = new EntityFindOptions(true,
EntityFindOptions.TYPE_SCROLL_INSENSITIVE,
EntityFindOptions.CONCUR_READ_ONLY, true);
options.setMaxRows(viewSize * (viewIndex + 1));
EntityListIterator iterator = delegator.find(OrderHeader,
queryConditionsList, null, null, UtilMisc.toList(orderDate DESC), options);
// becomes
EntityListIterator iterator = EntityBuilderUtil.list(delegator).distinct()
.from(OrderHeader)
.where(allConditions)
.orderBy(orderDate DESC)
.maxRows(viewSize * (viewIndex + 1))
.cursorScrollInsensitive()
.iterator();
{code}
A couple of issues with the implementation so far that I'm not entirely happy
with:
- I'm not so sure that I like EntityBuilderUtil.list(delegator) in place of
something like EntityList.use(delegator). The latter requires less typing
and I think is more intuitive than typing EntityBuilderUtil because of its
similarities to the corresponding minilang method calls, I actually kept
having trouble remembering what it was called when converting some delegator
calls over. It also requires a little more typing (16-17 characters vs.
12-13), not a big deal but every little bit helps with what would be a very
commonly used class.
- I'm struggling to see the point of having the GenericQueryBuilder
interface, the two classes share very little in the way of API and its use
seems a little superfluous to me.
Opinions on the above points or anything else to do with the implementation
are most welcome. I'd like to get the API locked down (and hopefully some
javadocs in place) before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r1045337 - /ofbiz/trunk/framework/widget/dtd/widget-screen.xsd
Hi Erwan,
Why force the parameters map? It seems a bit unnecessary and restricts the
scope of where the variable can be retrieved from.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 14/12/2010, at 8:44 AM, er...@apache.org wrote:
Author: erwan
Date: Mon Dec 13 19:44:54 2010
New Revision: 1045337
URL: http://svn.apache.org/viewvc?rev=1045337view=rev
Log:
Adding enumerations for the conf-mode and use-private elements. Those are
used for include-portal-page. This way we can use the parameters and the file
is still valid
Modified:
ofbiz/trunk/framework/widget/dtd/widget-screen.xsd
Modified: ofbiz/trunk/framework/widget/dtd/widget-screen.xsd
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/dtd/widget-screen.xsd?rev=1045337r1=1045336r2=1045337view=diff
==
--- ofbiz/trunk/framework/widget/dtd/widget-screen.xsd (original)
+++ ofbiz/trunk/framework/widget/dtd/widget-screen.xsd Mon Dec 13 19:44:54
2010
@@ -1101,6 +1101,7 @@ under the License.
xs:restriction base=xs:token
xs:enumeration value=true/
xs:enumeration value=false/
+xs:enumeration value=${parameters.confMode}/
/xs:restriction
/xs:simpleType
/xs:attribute
@@ -1110,6 +,7 @@ under the License.
xs:restriction base=xs:token
xs:enumeration value=true/
xs:enumeration value=false/
+xs:enumeration value=${parameters.usePrivate}/
/xs:restriction
/xs:simpleType
/xs:attribute
smime.p7s
Description: S/MIME cryptographic signature
Re: Marketing campaigns and contact lists
MarketingCampaignContactList makes more sense to me. It seems in line with tables such as PartyContactMech or ProductStoreCatalog. On 12/13/10 10:33, BJ Freeman wrote: the appl as I understand it is a many to many interface. to my knowledge no one has discussed migration, in detail, as an (semi)automated process but I think it would be a good thread. -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Marketing campaigns and contact lists
Contact list can be used for many operations. with a many to many relationship then it is achieved with out extra entities. Unless you are adding other fields then there maybe a reason. the model from the data model book is to use enumeration and types to define extra info. just sharing, not against you doing it that way. = BJ Freeman Strategic Power Office with Supplier Automation http://www.businessesnetwork.com/automation/viewforum.php?f=52 Specialtymarket.com http://www.specialtymarket.com/ Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man Ean Schuessler sent the following on 12/13/2010 4:10 PM: MarketingCampaignContactList makes more sense to me. It seems in line with tables such as PartyContactMech or ProductStoreCatalog. On 12/13/10 10:33, BJ Freeman wrote: the appl as I understand it is a many to many interface. to my knowledge no one has discussed migration, in detail, as an (semi)automated process but I think it would be a good thread.
Re: svn commit: r1045337 - /ofbiz/trunk/framework/widget/dtd/widget-screen.xsd
A variable name as enumeration value?
Sorry but I have never seen this pattern.
What's different in conf-mode and use-private from all other expandable
boolean attributes?
-Bruno
2010/12/13 er...@apache.org
Author: erwan
Date: Mon Dec 13 19:44:54 2010
New Revision: 1045337
URL: http://svn.apache.org/viewvc?rev=1045337view=rev
Log:
Adding enumerations for the conf-mode and use-private elements. Those are
used for include-portal-page. This way we can use the parameters and the
file is still valid
Modified:
ofbiz/trunk/framework/widget/dtd/widget-screen.xsd
Modified: ofbiz/trunk/framework/widget/dtd/widget-screen.xsd
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/dtd/widget-screen.xsd?rev=1045337r1=1045336r2=1045337view=diff
==
--- ofbiz/trunk/framework/widget/dtd/widget-screen.xsd (original)
+++ ofbiz/trunk/framework/widget/dtd/widget-screen.xsd Mon Dec 13 19:44:54
2010
@@ -1101,6 +1101,7 @@ under the License.
xs:restriction base=xs:token
xs:enumeration value=true/
xs:enumeration value=false/
+xs:enumeration value=${parameters.confMode}/
/xs:restriction
/xs:simpleType
/xs:attribute
@@ -1110,6 +,7 @@ under the License.
xs:restriction base=xs:token
xs:enumeration value=true/
xs:enumeration value=false/
+xs:enumeration value=${parameters.usePrivate}/
/xs:restriction
/xs:simpleType
/xs:attribute
