[OFBiz] Dev - Cascading ECAs/Services

[cjhowe]

revision #5426 depedning on your viewpoint either
gives us the ability to make a "differences" custom
application (at least one that's based on ecommerce at
this point) or put another way, reuse screens from
from other applications while using the decorator of
your custom application.

So now from a developers point of view, we can reuse
freemarker code, beanshell scripts, java classes, CSS,
form widgets, services, and now screen widgets.  Which
gives us the ability to create applications that only
have code that we want to change from an existing
application, but we don't have to touch the core
applications (which makes bringing your custom
application up to date with svn so much easier).
Now all of those pieces of code just sit until they're
called, requested, included, imported, etc.  Which is
great.  Now the only thing that can give us trouble in
our custom application are the ECAs because they're
automatically "ON" just waiting for their condition to
be met.  In a custom application you may not want a
particual ECA to run, but you don't want to change or
comment out the ECA because it makes it difficult to
update.  So finally my question.

Is there a way to "undeclare" or "redeclare" an ECA or
a service without touching the xml file that it is in?
So that myapp could pick and choose what runs or how
it is run.  Kind of cascading CSSesque.  If this can
be obtained then offshoot, niche applications will be
so easy to create, manipulate and maintain.

, Chris
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Chris,

There isn't really any way of doing this right now. Something could  
be built to do it, though it is a bit complicated as ECA rules are  
just independent things that are meant to evaluated on their own, so  
other rules on the same service and event are run in addition and not  
instead of the other rule.

The easiest thing to do is: comment them out without changing any  
lines in the file, just add 2 new lines (one with a "<!--" before the  
ECA and the other with a "-->" after it). That way automated merges  
and such will be less conflict prone.

Various configuration and other files need to be modified when  
deploying OFBiz, there's no real way around some of that at this  
point, so a good patch or branch-merge management process and  
possibly system should be used anyway.

If anyone has any ideas or would like to work on it though, that'd be  
great.

-David


On Jul 31, 2005, at 2:16 PM, Chris Howe wrote:

> revision #5426 depedning on your viewpoint either
> gives us the ability to make a "differences" custom
> application (at least one that's based on ecommerce at
> this point) or put another way, reuse screens from
> from other applications while using the decorator of
> your custom application.
>
> So now from a developers point of view, we can reuse
> freemarker code, beanshell scripts, java classes, CSS,
> form widgets, services, and now screen widgets.  Which
> gives us the ability to create applications that only
> have code that we want to change from an existing
> application, but we don't have to touch the core
> applications (which makes bringing your custom
> application up to date with svn so much easier).
> Now all of those pieces of code just sit until they're
> called, requested, included, imported, etc.  Which is
> great.  Now the only thing that can give us trouble in
> our custom application are the ECAs because they're
> automatically "ON" just waiting for their condition to
> be met.  In a custom application you may not want a
> particual ECA to run, but you don't want to change or
> comment out the ECA because it makes it difficult to
> update.  So finally my question.
>
> Is there a way to "undeclare" or "redeclare" an ECA or
> a service without touching the xml file that it is in?
> So that myapp could pick and choose what runs or how
> it is run.  Kind of cascading CSSesque.  If this can
> be obtained then offshoot, niche applications will be
> so easy to create, manipulate and maintain.
>
> , Chris
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev