date:20160712

[jira] [Comment Edited] (OFBIZ-7781) Have a configurable solution with respect to the default fields of all entities

2016-07-12 Thread Jacques Le Roux (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-7781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373268#comment-15373268
 ] 

Jacques Le Roux edited comment on OFBIZ-7781 at 7/13/16 5:56 AM:
-

There is indeed a specific mechanism for those special fields. It could be 
generalised (eg for status, with not only on/off but also the proposed ternary 
status). But, like [~nj] and [~rishisolankii] expressed in OFBIZ-7622, I doubt 
we need that automated on all entities...



was (Author: jacques.le.roux):
There is indeed a specific mechanism for those special fields. It could be used 
for that too (with not only on/off but also the proposed status ternary). But, 
like [~nj] and [~rishisolankii] expressed in OFBIZ-7622, I doubt we need that 
automated on all entities... Let's discuss it...


> Have a configurable solution with respect to the default fields of all 
> entities
> ---
>
> Key: OFBIZ-7781
> URL: https://issues.apache.org/jira/browse/OFBIZ-7781
> Project: OFBiz
>  Issue Type: Improvement
>  Components: datamodel
>Affects Versions: Trunk
>Reporter: Pierre Smits
>
> This issue follows up on comments posted in the  OFBIZ-7622 sub-task.
> Currently the fields to be added to all entities are defined in 
> ModelEntity.java. This is a limited list consisting of:
> * public static final String STAMP_FIELD = "lastUpdatedStamp";
> * public static final String STAMP_TX_FIELD = "lastUpdatedTxStamp";
> * public static final String CREATE_STAMP_FIELD = "createdStamp";
> * public static final String CREATE_STAMP_TX_FIELD = "createdTxStamp";
> After the implemented code change of the sub task mentioned above, a new 
> discussion evolved through postings of comments on the subject of how to get 
> more flexibility in.
> This issue is a starting point and potentially a place holder for sub 
> subtasks to get to a more flexible solution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7763) Replace bshInterpreter with groovyShell

2016-07-12 Thread Jacques Le Roux (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374400#comment-15374400
 ] 

Jacques Le Roux commented on OFBIZ-7763:


I finally don't think we need to say more about that to users. Variables names 
should simply follow Java syntax (I just learnt that $ is an acceptable 
character in a Java variable name but is not recommended, at least to start 
with http://www.oracle.com/technetwork/java/codeconventions-135099.html#367).

To follow Java syntax, where variables names can contain but not start by 
numbers, I'd simply replace Alpha by Alnum in the regexp. Of course, variables 
names starting by a number and isolated numbers should be removed from the 
variables names list. I see no other issues introduced by replacing Alpha by 
Alnum, but better to think twice ;)


> Replace bshInterpreter with groovyShell
> ---
>
> Key: OFBIZ-7763
> URL: https://issues.apache.org/jira/browse/OFBIZ-7763
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Gil Portenseigne
>Assignee: Gil Portenseigne
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7763.patch, beanshell-removal-part1.patch
>
>
> To support the migration to gradle, removing bsh.jar dependency from the 
> project, and improve readability and fonctionnalities following 
> [~deepak.dixit] idea expressed here 
> https://issues.apache.org/jira/browse/OFBIZ-7576?focusedCommentId=15347972



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Entity and Service definition

2016-07-12 Thread Jacques Le Roux

Jacques

Le 12/07/2016 à 14:02, Nicolas Malin a écrit :

Hi Rishi,

:) I totaly agree with your remarks

In line

Le 12/07/2016 10:31, Rishi Solanki a écrit :

Dear Folks,

While working/reviewing recent work in community, I observed some
improvement/fixes required at entity and related service implementation.
For few entities like InvoiceAttribute, InvoiceType, etc. no service exists
to create/update/delete. At the time of writing migration scripts I always
see lack of such services, which can be used to define new types or
attributes. Also Many entities have some other problems in basic design of
CRUD operations and in definitions;

On further look into this in detail found many such entities which do not
have services. I would like to propose a refactoring at basic design level
which covers following which does not impact on functionality we have;

1) Many entity definitions having relationships with view-entities, like
OrderHeader entity maintain relationship with OrderHeaderNoteView and
OrderItemAndShipGroupAssoc. We should remove it, maintain the relationship
at view-entities level if required. Also change the code where this
relation is in use.

Agree

2) Many entities having service implementation exists but they can be
simply convert into entity-auto, that means can use the power OFBiz
provides.
I has been started this work from 2 years :) , and currently I have stopped by Shipment Entities with a premission service refactoring
https://issues.apache.org/jira/browse/OFBIZ-7113 and https://issues.apache.org/jira/browse/OFBIZ-6996

I'm sure we can found some other service to convert ;)

3) As mentioned initially many entities do not have CRUD services exists,
we should implement or use entity-auto for them wherever applicable. Also
remove direct use of delegator for them.

After the migration, I would be move all generic service crud on the data model
component to detect what missing service and list the reason

4) Many entities having from date and thru date, Or status Or Enumeration
to manage the historical data, but services actually remove those entity
data. We should change the service implementation to maintain the
historical data.

1, I created the action expire on entity-auto to manage that ;)

After this effort, OFBiz will have minimum direct use of delegator,
enriched use of service engine, we would be able to established
patterns/best practice to introduce a new entities, and writing new
services.

1 2 >

1 - 100 of 102 matches

Mail list logo