hmmmm looks like there are plans for the Eca stuff in webtools
found
<screen name="ServiceEcaDetail">
which point to
serviceecadetail.ftl
but there is no serviceecadetail.ftl
Is this being worked on?
if not I will take a stab at it.
BJ Freeman sent the following on 11/2/2007 10:40 PM:
> oops
> /framework/service/src/org/ofbiz/service/eca/ServiceEcaUtil.java
>
> BJ Freeman sent the following on 11/2/2007 10:25 PM:
>> in /framework/entity/src/org/ofbiz/service/eca/ServiceEcaUtil.java
>>
>> public static Map getServiceEventMap(String serviceName) {
>> if (ServiceEcaUtil.ecaCache == null) ServiceEcaUtil.readConfig();
>> return (Map) ServiceEcaUtil.ecaCache.get(serviceName);
>> }
>>
>> public static Collection getServiceEventRules(String serviceName,
>> String event)
>>
>> and
>> public static void evalRules(String serviceName, Map eventMap,
>> String event, DispatchContext dctx, Map context, Map result, boolean
>> isError, boolean isFailure) throws GenericServiceException {
>>
>> Since I need to understand these also will try to add this to webtools.
>>
>>
>>
>> [EMAIL PROTECTED] sent the following on 11/2/2007 8:23 PM:
>>> Hmmm. Well David, the sad thing is that this wasn't my first time through
>>> most of this code.
>>>
>>> It would have been REAL nice if the SECA had written in the log a trace of
>>> how it got triggered. But sadly, that would be a lot of work for very
>>> little reward.
>>>
>>> SECAs in concept are neat and nifty, but can have nightmarish consequences
>>> in unintended areas a month after it was applied.
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: David E Jones [mailto:[EMAIL PROTECTED]
>>> Sent: Friday, November 02, 2007 8:43 PM
>>> To: [email protected]
>>> Subject: Re: /framework/example
>>>
>>>
>>>
>>> Yeah, it's a lot easier when it's not your first time... it DOES get
>>> more boring though. ;)
>>>
>>> Seriously though, getting the technical part of OFBiz is easy, one
>>> with knowledge of the underlying technologies (like webapps,
>>> databases, etc) can usually be productive in a few weeks. On the
>>> business side of things (ie the applications and specialpurpose
>>> directories) things are a LOT more complicated. I usually tell people
>>> to give themselves 1-4 years, depending on how they dive into it and
>>> how much experience they have with business processes and practices
>>> (and I very much do NOT mean the practices of a particular company,
>>> but general practices, which are often very different... people make
>>> very funny decisions sometimes thinking it is the "only" way).
>>>
>>> -David
>>>
>>>
>>> On Nov 2, 2007, at 9:33 PM, [EMAIL PROTECTED] wrote:
>>>
>>>> Hmmm, well BJ, this can be a real plumbing nightmare. I have wasted
>>>> the
>>>> entire day trying to track down why processCreditReturn was being
>>>> run twice
>>>> for the same transaction (Opentaps code). I knew fairly soon that
>>>> updateReturnHeader service was the culprit, but it took a long time
>>>> to track
>>>> down the sequence of SECA events that caused it because one SECA was
>>>> triggering another and so on. A nightmare to troubleshoot if you
>>>> don't live
>>>> and breath this code. There were three hundred lines of log entries
>>>> involved for this single transaction and I had to go check what the
>>>> service
>>>> code did causing another SECA to be triggered and then on the the
>>>> next and
>>>> so on.
>>>>
>>>> But, at least I wasn't bored.
>>>>
>>>> Skip
>>>>
>>>> -----Original Message-----
>>>> From: BJ Freeman [mailto:[EMAIL PROTECTED]
>>>> Sent: Friday, November 02, 2007 9:10 PM
>>>> To: [email protected]
>>>> Subject: Re: /framework/example
>>>>
>>>>
>>>> there was some discussion when I brought this up a few years ago.
>>>> My impression it was not received well. As can be seen by the code
>>>> changes and not many comments.
>>>>
>>>> I believe I saw a jira that someone is adding it to the Webtools so
>>>> you
>>>> look up a service and the associated SECAS's
>>>>
>>>> should not be hard if you follow the code that loads the SECAS and
>>>> figures out which one to use.
>>>>
>>>> [EMAIL PROTECTED] sent the following on 11/2/2007 5:34 PM:
>>>>> BJ
>>>>>
>>>>> You are not alone here. Ofbiz is a great huge beast that unless
>>>>> you have
>>>>> lived with it for years, you cannot possibly comprehend it all.
>>>>> Sadly,
>>>>> comments, and examples are fairly minimal. Fortunately,
>>>>> documentation is
>>>>> slowly improving. Now if everyone would just comment the heck out of
>>>> their
>>>>> work, over time, things will improve.
>>>>>
>>>>> The biggest problem I see is in the use of SECAs. Things happen with
>>>> these
>>>>> bad boys that have you have no idea of unless you happened to write
>>>>> the
>>>>> thing.
>>>>>
>>>>> Skip
>>>>>
>>>>> -----Original Message-----
>>>>> From: BJ Freeman [mailto:[EMAIL PROTECTED]
>>>>> Sent: Friday, November 02, 2007 7:07 PM
>>>>> To: [email protected]
>>>>> Subject: /framework/example
>>>>>
>>>>>
>>>>> I am sometime, a slow dumb witted learner.
>>>>> I have to have examples, and most importantly something that ties
>>>>> things
>>>>> to gather step by step, from a code point on view.
>>>>>
>>>>> I have been looking for a way to put this down for others that have a
>>>>> hard time figuring things out.
>>>>>
>>>>> here is an example.
>>>>>
>>>>> in the /framework/example/webapp/example/WEB-INF/web.xml
>>>>>
>>>>> I would like to see
>>>>>
>>>>> <!-- Dispatcher and delegator are two of many parameter that are
>>>>> passed
>>>>> in context which is a map of parameters search code for examples-->
>>>>>
>>>>> <!-- Search for runsync( in code for how Dispatcher is used-->
>>>>>
>>>>> <context-param>
>>>>>
>>>> <param-name>localDispatcherName</param-name><param-value>example</
>>>> param-valu
>>>>> e>
>>>>> <description>A unique name used to identify/recognize the
>>>>> local
>>>>> dispatcher for the Service Engine</description>
>>>>> </context-param>
>>>>>
>>>>> <!-- See
>>>>>
>>> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Setu
>>>>> p+Guide
>>>>> Database Setup-->
>>>>>
>>>> <param-name>entityDelegatorName</param-name><param-value>default</
>>>> param-valu
>>>>> e>
>>>>> <description>The Name of the Entity Delegator to use,
>>>>> defined in
>>>>> entityengine.xml</description>
>>>>> </context-param>
>>>>>
>>>>> I am willing to add what I have learned this way into the example.
>>>>> Hopefully others will do the same
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>
>
>
