ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Taher Alkhateeb" <slidingfilame...@gmail.com>
Subject RE: [DISCUSSION] Refactor WorkEffort - Calendar(s)
Date Wed, 23 Mar 2016 16:17:20 GMT
Hi Pierre,

I would say that SystemProperty is definitely not the best solution. For
one thing, a system property is sort of a framework configuration, like the
theme, mail settings, some paths, etc ...

If you want an association between a calendar and a workeffort, then just
create an assoc entity. I would recommend to steer away from "not so
obvious" places as this is exactly why we started the refactoring project in
the first place.

Another thing to notice is that the service getWorkEffortEventsByPeriod
actually checks first in the incoming parameters whether a list of
entityExprList is passed to it, if not, it will call
getDefaultWorkEffortExprList passing in the WorkEffortType and CalendarType.
So maybe you can avoid the whole thing by making the filtration logic on the
screen level (or data preparation level) by passing the correct

My personal preference would be something like the following:
- actually delete getDefaultWorkEffortExprList and fix the calling code
- do not add any mapping entities
- either hardcode the filtration on screen level OR
- create a new service that applies the filters for each component
separately (manufacturing, project, etc ...)

In other words, change the world around the edges, not at the heart of the
thing! This makes the code more resilient and not too specialized and
component dependent.

My 2 cents.


Taher Alkhateeb

-----Original Message-----
From: Pierre Smits [mailto:pierre.smits@gmail.com] 
Sent: 23 March 2016 15:40
To: dev@ofbiz.apache.org
Subject: Re: [DISCUSSION] Refactor WorkEffort - Calendar(s)

One solution we could apply is storing the mapping in the SystemProperty
entity, like:
<SystemProperty systemResourceId="workeffort" systemPropertyId=
"calendarType.CAL_MAINTENANCE" systemPropertyValue="WEPT_MAINTENANCE"
description="Calendar Type to Work Effort Purpose Type association"/>

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace

On Wed, Mar 23, 2016 at 1:00 PM, Pierre Smits <pierre.smits@gmail.com>

> HI all,
> [pre-amble]
> Currently, the workeffort component is also housing functionalities 
> for calendars. For this we have the following datasets:
>    - <EnumerationType description="Calendar Type"
>    enumTypeId="CALENDAR_TYPE" hasTable="N" parentTypeId=""/>
>    - <Enumeration description="Personal Calendar" enumCode="PERSONAL"
>    enumId="CAL_PERSONAL" sequenceId="01" enumTypeId="CALENDAR_TYPE"/>
>    - <Enumeration description="Manufacturing Calendar"
>    enumCode="MANUFACTURING" enumId="CAL_MANUFACTURING" sequenceId="02"
>    enumTypeId="CALENDAR_TYPE"/>
>    - <Enumeration description="None" enumId="CAL_NONE" sequenceId="03"
>    enumTypeId="CALENDAR_TYPE"/>
> The Enumerations mentioned above are used in functions to help 
> filtering the overview of calendar items in the calendar screen(s), as 
> per function getDefaultWorkEffortExprList in WorkEffortServices.java.
> [case]
> Calendars are applied in various business domains to serve specific 
> purposes. We can consider the following:
>    - personal calendar
>    - manufacturing calendar
>    - maintenance calendar
>    - project calendar
>    - etc.
> We have only the first two defined and we have hardcoded the filtering 
> conditions (based on the workEffortTypeId).
> [suggestion]
>    1. We should remove the hardcoded filtering based on the
>    2. We should remove the hardcoded definitions
>    3. Association of CALENDAR_TYPE to the WorkEffort records should be
>    based on a mapping.
> [discussion]
> What are your thoughts on this? Should we have the mapping (item #3) 
> in an existing entity, and which one should that be? What are the 
> aspect to consider when refactoring this.
> I love to hear from you.
> Best regards,
> Pierre Smits
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message