Servoy 3.0 Release Candidate 1

[Jan Blok]

Did you the useSeparateFoundSet property?

[chartpacs]

Hi Jan,

No, I didn't select that property. Maybe this will explain my issue better:

1) I have a related list view in a tabpanel that shows 1 record.
2) If I simply switch to the list view form itself (using the Window menu), I see the same single record.
3) If I switch to the detail view form (again using the Window menu), I happen to see three records. I was expecting to see only the one record.

Is this expected behavior, given that the two forms share the same foundset?

[chartpacs]

FWIW, I can certainly avoid this issue altogether by loading the records from the list view form into the detail view form. I was just trying to understand the foundset behavior I was seeing.

[Jan Blok]

please file an support case in our support system with a small sample demonstrating the possible issue, it hard for us to understand what exactly is going on based on a textual explanation

[Riccardino]

Hi Jan,

No, I didn't select that property. Maybe this will explain my issue better:

1) I have a related list view in a tabpanel that shows 1 record.
2) If I simply switch to the list view form itself (using the Window menu), I see the same single record.
3) If I switch to the detail view form (again using the Window menu), I happen to see three records. I was expecting to see only the one record.

Is this expected behavior, given that the two forms share the same foundset?

Not sure 100%, but I think related foundset are not broadcasted to other form sharing the same foundset, unless you load the related foundset.
The foundset are shared across forms when you perform a search or do something similar.

Again: I'm not sure it's still the current behaviour, but I think it worked like that, some time ago.

[birgit]

Hi

I just installed the latest release (Version 3.0rc1-build 365) and get now a new error. Is it possible that you changed the order onShow and onLoad are triggered?

I have a form A which is used in a tab panel of form B. Earlier I found the following order the events are triggered: B.onLoad, A.onLoad, A.onShow, B.onShow. Now I find B.onLoad, A.onLoad, B.onShow, A.onShow. Is this correct?

Questions:
1.) If I'm right: What is the reason for the current order? I miss access to data of form A while initializing B.
2.) Is there an other hook for me where I can do my initialization after all (included) form data is loaded?
3.) Do you offer a sequence diagram for all events to let me understand when they are triggered and what happens during event handling?

Thanks and regards
Birgit

[Jan Blok]

The event fire is indeed changed for onShow, we had some complains that the onShow on a child was called before the parent was initialized. (which did make sense to us)

From Servoy 3.0 it's uniform now, the parent form always do receive the event first.
So when we have an order form with an sales employees tab, the event order is:

orders onLoad
employees onLoad
orders onShow
employees onShow
--switch to products form--
orders onHide
employees onHide
products onLoad
products onShow

[birgit]

Hi Jan Blok

Thank you for your fast response. I'm glad I found the reason for the errors in my application.

I have to admit that I'm a little confused. Changing this order is quite a change! What if I complain now about the order? Do you change it back?

The old order did make sense to you. So it did to me. And it still does: The last component to be informed should be the parent. From a hierarchy point of view this is the one with the most information (about the children). This component should be the last to do any initialization. And at this point you need the children to be initialized. And not vice versa. What advantage does a child have if the parent is initialized? If a child needs this, hierarchy is wrong. In my opinion.

I'd be very happy if you could think about it again. Please find a useful and clean solution. And please let me know how you decide.

Best regards
Birgit

[Jan Blok]

The old order was never properly defined, the child could not be visible when the parent is not yet visible.
Any parent is more important than it childs (the parent also creates the childs)

[Robert Huber]

Hi Jan

The old order was never properly defined, the child could not be visible when the parent is not yet visible.
Any parent is more important than it childs (the parent also creates the childs)

I do not understand what you mean. It sounds as you would agree what Birgit proposes, i. e. that when the parent is more important than the children it should be the last to be informed. With the changes you made in the event execution order it's just the oposite now, so the parent is less important than the children.
This change is one of series in Servoy which arises for me (once again) the question still not answered, if you intend to support clean OO programming in Servoy and therefore at least not doing things which prevent that (actively supporting OO programming would be even better) or if Servoy is just a better FileMaker tool where Spaghetti programming is standard. Don't get me wrong, I do not want to offend anyone using any programming style (everyone can do as he/she likes), it is just quite hard if we try to apply OO programming and Servoy is just not meant or intended for that.

I would be happy to hear your thoughts. I also would be very interested to know an example where the previous order of firing events is wrong, as we can not think of any (structured or OO) example in need for that. Obviously, I also vote as Birgit to change back the event firing order to how it was before the rc1 version.

Thanks in advance, Robert

PS: The event firing order is an essential part in Servoy and it would be good if it would be completely published, also taking all the circumstances into account when using modules.

[jcompagner]

No it isn't

a child can't be visible if a parent isn't already visible.
The same for onLoad. You can't have the childs onload already called before the parents onload.

Just look at it in real live how can a child exists before the parent?

In java itself it is exactly the same. visibility is chained through the children.
We didn't have a real defined order before this. But more and more people where depending of the order and we defined it now as it supposed to work.

There where problems in specific solutions that we get in our support system that where looking up things (with tab panels and foundsets) in the onshow of the child. But the parent wasn't in an valid state yet because his onshow wasn't called yet.

For example if the onshow of the parent would add or set a tab or set a foundset in a child (relationaless tab) and that tab's onshow depends on the state the parent did set in it. How would that work? So before rc1 relationalless tabs (the parent setting stuff in its onshow) completely where broken.

Now it is clear and defined how it supposed to work.

Modules and events don't have anything to do with it. At runtime there is no difference between een solution and a solution divided over modules. Everything is merged as it is one.

[birgit]

Hi Johan Compagner

I agree with the onLoad. I assume, onLoad is called within the loading process. The loading of a child is forced by loading the parent. So the parent may receive onLoad first.

But I do not agree with the onShow. A child's data should not depend on the parents data. If it does it breaks the order of responsibility. A child should be able to display its content independent of the parents state.

You said:

... and that tab's onshow depends on the state the parent did set in it. How would that work?

Why shouldn't it be possible for the child to assume a default state? The child does not know it is used by a parent which may set a state. The child could be implemented to be self sufficient. And it may offer a method to set or change this state. And this is the hook for the parent.

Read in the literature about events in capture phase and events in bubbling phase. The two different phases offer different hooks for the developers. You just eliminated one of them.

If you really don't want to change it back: What about adding another event e.g. finishedLoading or loaded or aboutToShow which bubbles up the hierarchy (from child to parent)?

I'm still sure you need to offer a hook where the parent can finish initialization process as the last element in the queue and as the one with most information and most overview. Please give it a rethink.

Best regards
Birgit

[birgit]

Hi

Since no further reply occurred I'd like to know

Code: Select all

if

this discussion is over for you

Code: Select all

or if

you still think about the old order

Code: Select all

or if

a new event might be introduced in an other version.

Thank you and best regards
Birgit Rieder

[jcompagner]

will will not revert it. The way it is now is how it supposed to work. (for the onload and onshow events)
Maybe we could introduce in a new version something like an onShowed that is really called after everything is initialized. (for only the main form)
Make a feature request for this in our support system.

[birgit]

Thank you for the reply. I'm not happy with the current solution, as you can imagine. But I'd appreciate the onShowed event a lot. I'll make it a feature request.

Best regards
Birgit Rieder