You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Harmeet Bedi <ha...@gmail.com> on 2009/08/31 05:28:10 UTC
action list in form inheritance
Actions seem to modeled part of form construction. e.g. when i construct a
form at runtime it first runs all the actions and then creates fields.
Sometimes it may create fields based on variables set in action block and
use-when conditions.
Now this construction step breaks down when i have a form inheriting from
another form. If the form does not define any actions, it gets the action
list from it's parent and everything is ok.
But if a form has any actions, even a 'set' for a field it masks all the
actions of the parent form.
In ModelForm
public void initForm(Element formElement) {
...
if ( parent != null ) {
...
this.actions = parent.actions;
...
}
...
Element actionsElement = UtilXml.firstChildElement(formElement,
"actions");
if (actionsElement != null) {
this.actions = ModelFormAction.readSubActions(this, actionsElement);
}
...
}
I was thinking of form actions as a list of steps that constitute runtime
form construction. It is instead done as an override. This is problematic
and a potential pitfall to me.
I would expect a user of ofbiz would have this interaction
- They see a form, like it fields and behaviour and then decide to inherit
and extend it to add some value.
- User decides to alter form actions to add some fields and alter some
actions. Suddenly ancestor form breaks unless all the form actions in each
ancestor are copied or somehow called from leaf form. Now often users will
not know this so will be left scratching their head for hours on why the
form that they liked does not behave as they expected.
To me it would be better to append actions as in:
in ModelForm
public void initForm(Element formElement) {
...
if ( parent != null ) {
...
this.actions.appendAll(parent.actions);
...
}
...
Element actionsElement = UtilXml.firstChildElement(formElement,
"actions");
if (actionsElement != null) {
this.actions.appendAll(ModelFormAction.readSubActions(this,
actionsElement));
}
...
}
Reasons:
It would be more consistent with inheritance semantics in construction -
that is when constructing a derived object - if constructor in base class
has functions and constructor in derived class has functions, the functions
in base class are run followed by functions in derived class.
Users will inherit and add to form fields and actions. Users would ideally
want to add limited value to base forms and want to keep it's behaviour
unchanged.
It could make form inheritance simpler to get for new users.
I did a walk through of existing ofbiz code. This change does not seem to
adversely impact.
Does this seem sensible. thoughts ?
Harmeet
Re: action list in form inheritance
Posted by Adrian Crum <ad...@hlmksw.com>.
One of the nice things about an element is you can place it anywhere in
the child form's actions. In other words, run some actions, call parent
actions, run some more actions.
-Adrian
David E Jones wrote:
>
> I'll admit that this is fairly subjective, and one can guess at what
> most people would find intuitive, but as for my subjectivity it says
> that additional extends-* attributes would be better. On the other hand,
> there are a lot of attributes on the form elements, but I guess that's
> another topic really...
>
> -David
>
>
> On Sep 1, 2009, at 11:53 AM, Harmeet Bedi wrote:
>
>> You have to look at form attributes to see how to extend. So seeing
>> related extends attributes - extends-actions and extends-row-actions
>> may help a person understand potential options with extend.
>>
>> I feel goal should be to help new users become more efficient and make
>> behavior assumptions more visible. I feel 'super' element may help
>> power users but does not reduce curve.
>>
>> Harmeet
>>
>>
>> ----- Original Message -----
>> From: "Bob Morley" <rm...@emforium.com>
>> To: dev@ofbiz.apache.org
>> Sent: Tuesday, September 1, 2009 10:03:01 AM GMT -05:00 US/Canada Eastern
>> Subject: Re: action list in form inheritance
>>
>>
>> I really like the super idea. Here is a proposal:
>>
>> - add support for the "super" element (or some reasonable name) to both
>> actions and row-actions
>> - add a new attribute "override" to the actions and row-actions. Its
>> only
>> value would be "true" (it would be nice to have attribute minimization
>> here
>> so we could have no attribute value)
>> - if the "override" attribute is not included on an actions or
>> row-actions
>> block that has a parent, a warning should be produced to the developer
>> informing them they should add that attribute
>>
>> Reasons:
>> - most flexibility
>> - most visibility
>> - does no harm (unless you count warning messages :) )
>>
>> The thing I do not like about the current approach is that you are
>> going to
>> bury more attributes on an already bloated form. The new attributes are
>> going to have defaults (for backwards compat) so no one is going to
>> set them
>> anyway. These attributes, if used, should be on the rows and row-actions
>> elements IMHO (but I prefer the proposal above).
>>
>>
>> David E Jones-4 wrote:
>>>
>>>
>>> Yes, that would be another way... ie don't call parent form actions
>>> unless it is explicitly specific as opposed to calling it unless
>>> something says not to call it.
>>>
>>> -David
>>>
>>>
>>> On Aug 31, 2009, at 5:23 PM, Adrian Crum wrote:
>>>
>>>> Maybe what the actions section needs is an element that would
>>>> duplicate super().
>>>>
>>>> -Adrian
>>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/action-list-in-form-inheritance-tp25217949p25240756.html
>>
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>
>
>
Re: action list in form inheritance
Posted by David E Jones <de...@me.com>.
I'll admit that this is fairly subjective, and one can guess at what
most people would find intuitive, but as for my subjectivity it says
that additional extends-* attributes would be better. On the other
hand, there are a lot of attributes on the form elements, but I guess
that's another topic really...
-David
On Sep 1, 2009, at 11:53 AM, Harmeet Bedi wrote:
> You have to look at form attributes to see how to extend. So seeing
> related extends attributes - extends-actions and extends-row-actions
> may help a person understand potential options with extend.
>
> I feel goal should be to help new users become more efficient and
> make behavior assumptions more visible. I feel 'super' element may
> help power users but does not reduce curve.
>
> Harmeet
>
>
> ----- Original Message -----
> From: "Bob Morley" <rm...@emforium.com>
> To: dev@ofbiz.apache.org
> Sent: Tuesday, September 1, 2009 10:03:01 AM GMT -05:00 US/Canada
> Eastern
> Subject: Re: action list in form inheritance
>
>
> I really like the super idea. Here is a proposal:
>
> - add support for the "super" element (or some reasonable name) to
> both
> actions and row-actions
> - add a new attribute "override" to the actions and row-actions.
> Its only
> value would be "true" (it would be nice to have attribute
> minimization here
> so we could have no attribute value)
> - if the "override" attribute is not included on an actions or row-
> actions
> block that has a parent, a warning should be produced to the developer
> informing them they should add that attribute
>
> Reasons:
> - most flexibility
> - most visibility
> - does no harm (unless you count warning messages :) )
>
> The thing I do not like about the current approach is that you are
> going to
> bury more attributes on an already bloated form. The new attributes
> are
> going to have defaults (for backwards compat) so no one is going to
> set them
> anyway. These attributes, if used, should be on the rows and row-
> actions
> elements IMHO (but I prefer the proposal above).
>
>
> David E Jones-4 wrote:
>>
>>
>> Yes, that would be another way... ie don't call parent form actions
>> unless it is explicitly specific as opposed to calling it unless
>> something says not to call it.
>>
>> -David
>>
>>
>> On Aug 31, 2009, at 5:23 PM, Adrian Crum wrote:
>>
>>> Maybe what the actions section needs is an element that would
>>> duplicate super().
>>>
>>> -Adrian
>>>
>>
>
> --
> View this message in context: http://www.nabble.com/action-list-in-form-inheritance-tp25217949p25240756.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
Re: action list in form inheritance
Posted by Harmeet Bedi <ha...@gmail.com>.
You have to look at form attributes to see how to extend. So seeing related extends attributes - extends-actions and extends-row-actions may help a person understand potential options with extend.
I feel goal should be to help new users become more efficient and make behavior assumptions more visible. I feel 'super' element may help power users but does not reduce curve.
Harmeet
----- Original Message -----
From: "Bob Morley" <rm...@emforium.com>
To: dev@ofbiz.apache.org
Sent: Tuesday, September 1, 2009 10:03:01 AM GMT -05:00 US/Canada Eastern
Subject: Re: action list in form inheritance
I really like the super idea. Here is a proposal:
- add support for the "super" element (or some reasonable name) to both
actions and row-actions
- add a new attribute "override" to the actions and row-actions. Its only
value would be "true" (it would be nice to have attribute minimization here
so we could have no attribute value)
- if the "override" attribute is not included on an actions or row-actions
block that has a parent, a warning should be produced to the developer
informing them they should add that attribute
Reasons:
- most flexibility
- most visibility
- does no harm (unless you count warning messages :) )
The thing I do not like about the current approach is that you are going to
bury more attributes on an already bloated form. The new attributes are
going to have defaults (for backwards compat) so no one is going to set them
anyway. These attributes, if used, should be on the rows and row-actions
elements IMHO (but I prefer the proposal above).
David E Jones-4 wrote:
>
>
> Yes, that would be another way... ie don't call parent form actions
> unless it is explicitly specific as opposed to calling it unless
> something says not to call it.
>
> -David
>
>
> On Aug 31, 2009, at 5:23 PM, Adrian Crum wrote:
>
>> Maybe what the actions section needs is an element that would
>> duplicate super().
>>
>> -Adrian
>>
>
--
View this message in context: http://www.nabble.com/action-list-in-form-inheritance-tp25217949p25240756.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: action list in form inheritance
Posted by Bob Morley <rm...@emforium.com>.
I really like the super idea. Here is a proposal:
- add support for the "super" element (or some reasonable name) to both
actions and row-actions
- add a new attribute "override" to the actions and row-actions. Its only
value would be "true" (it would be nice to have attribute minimization here
so we could have no attribute value)
- if the "override" attribute is not included on an actions or row-actions
block that has a parent, a warning should be produced to the developer
informing them they should add that attribute
Reasons:
- most flexibility
- most visibility
- does no harm (unless you count warning messages :) )
The thing I do not like about the current approach is that you are going to
bury more attributes on an already bloated form. The new attributes are
going to have defaults (for backwards compat) so no one is going to set them
anyway. These attributes, if used, should be on the rows and row-actions
elements IMHO (but I prefer the proposal above).
David E Jones-4 wrote:
>
>
> Yes, that would be another way... ie don't call parent form actions
> unless it is explicitly specific as opposed to calling it unless
> something says not to call it.
>
> -David
>
>
> On Aug 31, 2009, at 5:23 PM, Adrian Crum wrote:
>
>> Maybe what the actions section needs is an element that would
>> duplicate super().
>>
>> -Adrian
>>
>
--
View this message in context: http://www.nabble.com/action-list-in-form-inheritance-tp25217949p25240756.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: action list in form inheritance
Posted by David E Jones <de...@me.com>.
Yes, that would be another way... ie don't call parent form actions
unless it is explicitly specific as opposed to calling it unless
something says not to call it.
-David
On Aug 31, 2009, at 5:23 PM, Adrian Crum wrote:
> Maybe what the actions section needs is an element that would
> duplicate super().
>
> -Adrian
>
> David E Jones wrote:
>> Harmeet,
>> The original intent of this design was to be kind of like a method
>> in a class in that if you specify a method with the same name in a
>> sub-class then it will override the method in the parent class so
>> that none of that method is run.
>> The basic problem is what if you didn't want one or more of the
>> actions in the parent form to run, how would you do it? Because
>> there is no way to specify which if the parent actions you want or
>> don't want (unless we did some sort of action blocks with names and
>> you could include/exclude them explicitly), the idea is that you
>> either use the parent actions (like a parent class method), or you
>> override the action block and specify the ones you want to run.
>> As for my opinion on it, as long as we have a way to get it to not
>> run the parent actions (ie for cases when they are not desired or
>> they conflict with other things that need to be done in the sub-
>> form) then some variation on what it currently does would be fine.
>> -David
>> On Aug 30, 2009, at 9:28 PM, Harmeet Bedi wrote:
>>> Actions seem to modeled part of form construction. e.g. when i
>>> construct a
>>> form at runtime it first runs all the actions and then creates
>>> fields.
>>> Sometimes it may create fields based on variables set in action
>>> block and
>>> use-when conditions.
>>>
>>> Now this construction step breaks down when i have a form
>>> inheriting from
>>> another form. If the form does not define any actions, it gets the
>>> action
>>> list from it's parent and everything is ok.
>>> But if a form has any actions, even a 'set' for a field it masks
>>> all the
>>> actions of the parent form.
>>>
>>> In ModelForm
>>> public void initForm(Element formElement) {
>>> ...
>>> if ( parent != null ) {
>>> ...
>>> this.actions = parent.actions;
>>> ...
>>> }
>>> ...
>>> Element actionsElement = UtilXml.firstChildElement(formElement,
>>> "actions");
>>>
>>> if (actionsElement != null) {
>>> this.actions = ModelFormAction.readSubActions(this,
>>> actionsElement);
>>> }
>>> ...
>>>
>>> }
>>>
>>> I was thinking of form actions as a list of steps that constitute
>>> runtime
>>> form construction. It is instead done as an override. This is
>>> problematic
>>> and a potential pitfall to me.
>>>
>>> I would expect a user of ofbiz would have this interaction
>>> - They see a form, like it fields and behaviour and then decide to
>>> inherit
>>> and extend it to add some value.
>>> - User decides to alter form actions to add some fields and alter
>>> some
>>> actions. Suddenly ancestor form breaks unless all the form
>>> actions in each
>>> ancestor are copied or somehow called from leaf form. Now often
>>> users will
>>> not know this so will be left scratching their head for hours on
>>> why the
>>> form that they liked does not behave as they expected.
>>>
>>> To me it would be better to append actions as in:
>>>
>>>
>>> in ModelForm
>>>
>>> public void initForm(Element formElement) {
>>> ...
>>> if ( parent != null ) {
>>> ...
>>> this.actions.appendAll(parent.actions);
>>> ...
>>> }
>>> ...
>>> Element actionsElement = UtilXml.firstChildElement(formElement,
>>> "actions");
>>>
>>> if (actionsElement != null) {
>>> this.actions.appendAll(ModelFormAction.readSubActions(this,
>>> actionsElement));
>>> }
>>> ...
>>>
>>> }
>>>
>>> Reasons:
>>> It would be more consistent with inheritance semantics in
>>> construction -
>>> that is when constructing a derived object - if constructor in
>>> base class
>>> has functions and constructor in derived class has functions, the
>>> functions
>>> in base class are run followed by functions in derived class.
>>> Users will inherit and add to form fields and actions. Users would
>>> ideally
>>> want to add limited value to base forms and want to keep it's
>>> behaviour
>>> unchanged.
>>> It could make form inheritance simpler to get for new users.
>>> I did a walk through of existing ofbiz code. This change does not
>>> seem to
>>> adversely impact.
>>>
>>>
>>> Does this seem sensible. thoughts ?
>>>
>>> Harmeet
Re: action list in form inheritance
Posted by Adrian Crum <ad...@hlmksw.com>.
Maybe what the actions section needs is an element that would duplicate
super().
-Adrian
David E Jones wrote:
>
> Harmeet,
>
> The original intent of this design was to be kind of like a method in a
> class in that if you specify a method with the same name in a sub-class
> then it will override the method in the parent class so that none of
> that method is run.
>
> The basic problem is what if you didn't want one or more of the actions
> in the parent form to run, how would you do it? Because there is no way
> to specify which if the parent actions you want or don't want (unless we
> did some sort of action blocks with names and you could include/exclude
> them explicitly), the idea is that you either use the parent actions
> (like a parent class method), or you override the action block and
> specify the ones you want to run.
>
> As for my opinion on it, as long as we have a way to get it to not run
> the parent actions (ie for cases when they are not desired or they
> conflict with other things that need to be done in the sub-form) then
> some variation on what it currently does would be fine.
>
> -David
>
>
> On Aug 30, 2009, at 9:28 PM, Harmeet Bedi wrote:
>
>> Actions seem to modeled part of form construction. e.g. when i
>> construct a
>> form at runtime it first runs all the actions and then creates fields.
>> Sometimes it may create fields based on variables set in action block and
>> use-when conditions.
>>
>> Now this construction step breaks down when i have a form inheriting from
>> another form. If the form does not define any actions, it gets the action
>> list from it's parent and everything is ok.
>> But if a form has any actions, even a 'set' for a field it masks all the
>> actions of the parent form.
>>
>> In ModelForm
>> public void initForm(Element formElement) {
>> ...
>> if ( parent != null ) {
>> ...
>> this.actions = parent.actions;
>> ...
>> }
>> ...
>> Element actionsElement = UtilXml.firstChildElement(formElement,
>> "actions");
>>
>> if (actionsElement != null) {
>> this.actions = ModelFormAction.readSubActions(this,
>> actionsElement);
>> }
>> ...
>>
>> }
>>
>> I was thinking of form actions as a list of steps that constitute runtime
>> form construction. It is instead done as an override. This is problematic
>> and a potential pitfall to me.
>>
>> I would expect a user of ofbiz would have this interaction
>> - They see a form, like it fields and behaviour and then decide to
>> inherit
>> and extend it to add some value.
>> - User decides to alter form actions to add some fields and alter some
>> actions. Suddenly ancestor form breaks unless all the form actions in
>> each
>> ancestor are copied or somehow called from leaf form. Now often users
>> will
>> not know this so will be left scratching their head for hours on why the
>> form that they liked does not behave as they expected.
>>
>> To me it would be better to append actions as in:
>>
>>
>> in ModelForm
>>
>> public void initForm(Element formElement) {
>> ...
>> if ( parent != null ) {
>> ...
>> this.actions.appendAll(parent.actions);
>> ...
>> }
>> ...
>> Element actionsElement = UtilXml.firstChildElement(formElement,
>> "actions");
>>
>> if (actionsElement != null) {
>> this.actions.appendAll(ModelFormAction.readSubActions(this,
>> actionsElement));
>> }
>> ...
>>
>> }
>>
>> Reasons:
>> It would be more consistent with inheritance semantics in construction -
>> that is when constructing a derived object - if constructor in base class
>> has functions and constructor in derived class has functions, the
>> functions
>> in base class are run followed by functions in derived class.
>> Users will inherit and add to form fields and actions. Users would
>> ideally
>> want to add limited value to base forms and want to keep it's behaviour
>> unchanged.
>> It could make form inheritance simpler to get for new users.
>> I did a walk through of existing ofbiz code. This change does not seem to
>> adversely impact.
>>
>>
>> Does this seem sensible. thoughts ?
>>
>> Harmeet
>
>
Re: action list in form inheritance
Posted by David E Jones <de...@me.com>.
Harmeet,
The original intent of this design was to be kind of like a method in
a class in that if you specify a method with the same name in a sub-
class then it will override the method in the parent class so that
none of that method is run.
The basic problem is what if you didn't want one or more of the
actions in the parent form to run, how would you do it? Because there
is no way to specify which if the parent actions you want or don't
want (unless we did some sort of action blocks with names and you
could include/exclude them explicitly), the idea is that you either
use the parent actions (like a parent class method), or you override
the action block and specify the ones you want to run.
As for my opinion on it, as long as we have a way to get it to not run
the parent actions (ie for cases when they are not desired or they
conflict with other things that need to be done in the sub-form) then
some variation on what it currently does would be fine.
-David
On Aug 30, 2009, at 9:28 PM, Harmeet Bedi wrote:
> Actions seem to modeled part of form construction. e.g. when i
> construct a
> form at runtime it first runs all the actions and then creates fields.
> Sometimes it may create fields based on variables set in action
> block and
> use-when conditions.
>
> Now this construction step breaks down when i have a form inheriting
> from
> another form. If the form does not define any actions, it gets the
> action
> list from it's parent and everything is ok.
> But if a form has any actions, even a 'set' for a field it masks all
> the
> actions of the parent form.
>
> In ModelForm
> public void initForm(Element formElement) {
> ...
> if ( parent != null ) {
> ...
> this.actions = parent.actions;
> ...
> }
> ...
> Element actionsElement = UtilXml.firstChildElement(formElement,
> "actions");
>
> if (actionsElement != null) {
> this.actions = ModelFormAction.readSubActions(this,
> actionsElement);
> }
> ...
>
> }
>
> I was thinking of form actions as a list of steps that constitute
> runtime
> form construction. It is instead done as an override. This is
> problematic
> and a potential pitfall to me.
>
> I would expect a user of ofbiz would have this interaction
> - They see a form, like it fields and behaviour and then decide to
> inherit
> and extend it to add some value.
> - User decides to alter form actions to add some fields and alter some
> actions. Suddenly ancestor form breaks unless all the form actions
> in each
> ancestor are copied or somehow called from leaf form. Now often
> users will
> not know this so will be left scratching their head for hours on why
> the
> form that they liked does not behave as they expected.
>
> To me it would be better to append actions as in:
>
>
> in ModelForm
>
> public void initForm(Element formElement) {
> ...
> if ( parent != null ) {
> ...
> this.actions.appendAll(parent.actions);
> ...
> }
> ...
> Element actionsElement = UtilXml.firstChildElement(formElement,
> "actions");
>
> if (actionsElement != null) {
> this.actions.appendAll(ModelFormAction.readSubActions(this,
> actionsElement));
> }
> ...
>
> }
>
> Reasons:
> It would be more consistent with inheritance semantics in
> construction -
> that is when constructing a derived object - if constructor in base
> class
> has functions and constructor in derived class has functions, the
> functions
> in base class are run followed by functions in derived class.
> Users will inherit and add to form fields and actions. Users would
> ideally
> want to add limited value to base forms and want to keep it's
> behaviour
> unchanged.
> It could make form inheritance simpler to get for new users.
> I did a walk through of existing ofbiz code. This change does not
> seem to
> adversely impact.
>
>
> Does this seem sensible. thoughts ?
>
> Harmeet