Servoy 3.0 Release Candidate 1

Release notes for Servoy betas

Postby Jan Blok » Fri Aug 18, 2006 12:08 am

Did you the useSeparateFoundSet property?
Jan Blok
Servoy
Jan Blok
 
Posts: 2684
Joined: Mon Jun 23, 2003 11:15 am
Location: Amsterdam

Postby chartpacs » Fri Aug 18, 2006 12:32 am

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?
Regards,
Servoy Developer
Version 3.1 beta2-build 401
Java version 1.5.0_06-64, Mac OS X 10.4.8
User avatar
chartpacs
 
Posts: 188
Joined: Wed May 10, 2006 6:50 pm
Location: Cleveland, OH

Postby chartpacs » Fri Aug 18, 2006 4:06 am

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.
Regards,
Servoy Developer
Version 3.1 beta2-build 401
Java version 1.5.0_06-64, Mac OS X 10.4.8
User avatar
chartpacs
 
Posts: 188
Joined: Wed May 10, 2006 6:50 pm
Location: Cleveland, OH

Postby Jan Blok » Fri Aug 18, 2006 9:06 am

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
Jan Blok
Servoy
Jan Blok
 
Posts: 2684
Joined: Mon Jun 23, 2003 11:15 am
Location: Amsterdam

Postby Riccardino » Fri Aug 18, 2006 9:31 am

chartpacs wrote: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.
ciao, ric
User avatar
Riccardino
 
Posts: 911
Joined: Thu Apr 24, 2003 11:42 am
Location: Ferrara, Italy

Order of events

Postby birgit » Fri Aug 18, 2006 11:45 am

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
Birgit Rieder
7r gmbh, Switzerland
SAN Developer
User avatar
birgit
 
Posts: 302
Joined: Sun Jan 15, 2006 10:04 pm
Location: Switzerland

Postby Jan Blok » Fri Aug 18, 2006 3:15 pm

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
Jan Blok
Servoy
Jan Blok
 
Posts: 2684
Joined: Mon Jun 23, 2003 11:15 am
Location: Amsterdam

Postby birgit » Fri Aug 18, 2006 4:03 pm

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
Birgit Rieder
7r gmbh, Switzerland
SAN Developer
User avatar
birgit
 
Posts: 302
Joined: Sun Jan 15, 2006 10:04 pm
Location: Switzerland

Postby Jan Blok » Fri Aug 18, 2006 4:48 pm

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)
Jan Blok
Servoy
Jan Blok
 
Posts: 2684
Joined: Mon Jun 23, 2003 11:15 am
Location: Amsterdam

Postby Robert Huber » Sun Aug 20, 2006 2:10 pm

Hi Jan

Jan Blok wrote: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.
Robert Huber
7r gmbh, Switzerland
SAN Developer
www.seven-r.ch
User avatar
Robert Huber
 
Posts: 1239
Joined: Tue Aug 23, 2005 6:52 pm
Location: Schaffhausen, Switzerland

Postby jcompagner » Sun Aug 20, 2006 3:01 pm

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.
Johan Compagner
Servoy
User avatar
jcompagner
 
Posts: 8828
Joined: Tue May 27, 2003 7:26 pm
Location: The Internet

Postby birgit » Sun Aug 20, 2006 11:06 pm

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 Rieder
7r gmbh, Switzerland
SAN Developer
User avatar
birgit
 
Posts: 302
Joined: Sun Jan 15, 2006 10:04 pm
Location: Switzerland

Postby birgit » Tue Aug 29, 2006 9:23 am

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
Last edited by birgit on Tue Aug 29, 2006 10:17 am, edited 1 time in total.
Birgit Rieder
7r gmbh, Switzerland
SAN Developer
User avatar
birgit
 
Posts: 302
Joined: Sun Jan 15, 2006 10:04 pm
Location: Switzerland

Postby jcompagner » Tue Aug 29, 2006 10:08 am

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.
Johan Compagner
Servoy
User avatar
jcompagner
 
Posts: 8828
Joined: Tue May 27, 2003 7:26 pm
Location: The Internet

Postby birgit » Tue Aug 29, 2006 10:17 am

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
Birgit Rieder
7r gmbh, Switzerland
SAN Developer
User avatar
birgit
 
Posts: 302
Joined: Sun Jan 15, 2006 10:04 pm
Location: Switzerland

PreviousNext

Return to Latest Releases

Who is online

Users browsing this forum: No registered users and 17 guests