Master-details

Hi Nico and Alex,

n> Hi Alex,

n> Be careful on Squeak with your blockclosure actions. Squeak doesn't
n> support full closures, you may discover unexpected issues and strange
n> behaviour soon.

n> One solution is to copy the #fixCallbackTemps from Seaside, but it would
n> still only be a hack.

the fixTemps issue is generally known in Squeak and in my example I
have to use it like:

...onClickDo: [myBlock here] fixTemps andUpdate: myWebElement.

to make it work.

So I changed the implementation of
onClickDo: aBlock andUpdate: anElementOrId
       ......
        self otherAt: #onClickBlock put: aBlock fixTemps.  "!!here!!"

which also makes it work on Squeak and would make it incompatible with
the other Smalltalks.

I see no way how Sport could attack this problem so I guess we should
leave the problem in Squeak. The topic comes up every now and then on
SqueakDev and closure support is on its way there.

Having read Alex' reasoning on the block solution I now prefer blocks
over methods.

Alex, big thanks for taking the time to explain in such detail! It
helped a lot.

You also covered what I was going to write in my unfinished mail about
how GUI's deal with these events and why WebApps are limited in this
regard. So I dropped that unfinished mail.

Next I will look into the Comet in more detail. AFAIR we have (on
JavaScript side) an unresolved stability problem with
AjaxPeriodicUpdater which is the basis for Aida's Comet pattern.

I would want to update several combinations of WebElement separately
which would require several of them.

I have not yet an opinion if Comet would make it more obscure, at
least in the onClick.. case or if this could bring us closer to MVC
feeling.

Cheers,

Herbert                            mailto:[hidden email]

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Alex,

Your examples work nicely out of the box in VW, thank you. However in Squeak (3.10 with Aida 6.0)  the block does not get executed. I have not had time to dig deeper, but it may be related to Nico's comments above?

Nicholas


Alex Baran wrote:

Hi Nico and Michael,

Thank you nico for pointing to the problem. I did not know about its
existence in Squeak. As far as I know Dolhpin was suffered from the
same issue, but for nowadays it probably not.

2009/4/14 nico [hidden email]:
  

Le mardi 14 avril 2009 � 15:51 +0200, Michael Rueger a �crit :
    

nico wrote:
      

Hi Alex,

Be careful on Squeak with your blockclosure actions. Squeak doesn't
support full closures, you may discover unexpected issues and strange
behaviour soon.
        

The newest Pharo images and VMs do :-)
      

Yes, I know that, and it's a *great* improvement. Many thanks to all
Pharo developpers. They are making a great Smalltalk.
    

Which Squeak versions you target for next Aida release?

Alex
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
  

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Nicholas,

Thank you for interest and experiments in different environment.

2009/4/16 Nicholas Moore <[hidden email]>:
> Alex,
>
> Your examples work nicely out of the box in VW, thank you. However in Squeak
> (3.10 with Aida 6.0)  the block does not get executed. I have not had time
> to dig deeper, but it may be related to Nico's comments above?

I didn't have Squeak installed on my Mac yet, so bellow is just guess.
If blocks does not get executed problem should be in different place,
I think. Because the problem that Nico describe is about capturing
wrong values, not about not executing at all.
But anyway, can you insert breakpoint in ajaxDoBlock:  and tell me
about value of "block" temporary variable?

Another problem that can arise, is that Aida 6.0 can have new
implementation of respondToAjaxRequest. So I think it's better to add
two lines to the  respondToAjaxRequest, instead of completely replace
it with modified 5.6 version. The lines is bellow, you can add them
before updating of an old element ("e := self ajaxUpdateOfOld:
oldElement"):

self session lastRequest isAjaxDoBlock ifTrue:
                [self ajaxDoBlock: ajaxForm].


Alex
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

"I didn't have Squeak installed on my Mac yet"

Sorry, should be: "I DON'T have Squeak installed on my Mac yet"
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Alex,

Good. Your fix would work for Aida 5.6 - but not for Aida 6.0! Aida6.0 has your fix included in respondToAjaxRequest but that method is no longer called by printWebPage. In 6.0 it calls respondToAjaxRequest: aRequest instead - which does not include the fix.

fyi the two block variables look like this:

[] in BlockDemoApp>>viewMasterDetail {[subcollection := each value]}


[] in BlockDemoApp>>viewCounter {[counter := counter + 1]}


So your examples have now worked for me in: VW, Aida 5.6 and Aida 6.0. Well done. I will be attempting to implement a more sophisticated use of the block and will let you know how it goes.

Nicholas


Alex Baran wrote:

Hi Nicholas,

Thank you for interest and experiments in different environment.

2009/4/16 Nicholas Moore [hidden email]:
  

Alex,

Your examples work nicely out of the box in VW, thank you. However in Squeak
(3.10 with Aida 6.0)� the block does not get executed. I have not had time
to dig deeper, but it may be related to Nico's comments above?
    

I didn't have Squeak installed on my Mac yet, so bellow is just guess.
If blocks does not get executed problem should be in different place,
I think. Because the problem that Nico describe is about capturing
wrong values, not about not executing at all.
But anyway, can you insert breakpoint in ajaxDoBlock:  and tell me
about value of "block" temporary variable?

Another problem that can arise, is that Aida 6.0 can have new
implementation of respondToAjaxRequest. So I think it's better to add
two lines to the  respondToAjaxRequest, instead of completely replace
it with modified 5.6 version. The lines is bellow, you can add them
before updating of an old element ("e := self ajaxUpdateOfOld:
oldElement"):

self session lastRequest isAjaxDoBlock ifTrue:
		[self ajaxDoBlock: ajaxForm].


Alex
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida
  

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Herbert,


2009/4/16 Herbert König <[hidden email]>:
> So I changed the implementation of
> onClickDo: aBlock andUpdate: anElementOrId
>       ......
>        self otherAt: #onClickBlock put: aBlock fixTemps.  "!!here!!"
>

Thanks, it looks good, I will try to add to it bellow.

> which also makes it work on Squeak and would make it incompatible with
> the other Smalltalks.
>
> I see no way how Sport could attack this problem so I guess we should
> leave the problem in Squeak. The topic comes up every now and then on
> SqueakDev and closure support is on its way there.

I'm not versed with Sport, but quick look revealed some possibility:

onClickDo: aBlock andUpdate: anElementOrId
       ......
       fullClosure := SpEnvironment isSqueak ifTrue: [aBlock fixTemps]
ifFalse: [aBlock].   "!!here!!"
        self otherAt: #onClickBlock put: fullClosure.


>
> Having read Alex' reasoning on the block solution I now prefer blocks
> over methods.
>
> Alex, big thanks for taking the time to explain in such detail! It
> helped a lot.

Thank you for reading!

Well, I have bad feeling about triggering communication from Aida
side. I think I should put my feeling into a words so we can see if
their are wrong, but right now I am not ready to express my thoughts.
Another possible(well, maybe) and slightly hackish solution is to have
some hidden element. That element is a container for a script
(represented by a WebScript in Aida).
When we in need to update several components we can do:
   onClickDo: [...] andUpdate: aWebScirpt   "(or maybe Aida will
require to wrap a WebScrip into a WebElement)"

So we can stuff WebScirpt with Ajax.Update for each component.
It seems like the solution will require "components.size + 1" number
of roundrips.


Alex
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Nicholas,

2009/4/16 Nicholas Moore <[hidden email]>:
> Alex,
>
> Good. Your fix would work for Aida 5.6 - but not for Aida 6.0! Aida6.0 has
> your fix included in respondToAjaxRequest but that method is no longer
> called by printWebPage. In 6.0 it calls respondToAjaxRequest: aRequest
> instead - which does not include the fix.

Thank you for figuring this out!
I think we can include two methods(respondToAjaxRequest and
respondToAjaxRequest:) in one patch, to allow patch deal with 5.6 and
6.0.

>
> fyi the two block variables look like this:
>
> [] in BlockDemoApp>>viewMasterDetail {[subcollection := each value]}
>
>
> [] in BlockDemoApp>>viewCounter {[counter := counter + 1]}

Yes, this are the values they supposed to have.

> So your examples have now worked for me in: VW, Aida 5.6 and Aida 6.0.

Nice news, thanks again!

> done. I will be attempting to implement a more sophisticated use of the
> block and will let you know how it goes.

It will be interesting to know.


Alex
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Aleks, guys,

I'm following debate, with one eye for now but it seems it is heading in
good direction. I'd just like to notify you that new beta of Aida 6.0 is
underway, that time in both VW and Squeak, probably next week already.
More in a separate post.

About blocks, I also recommend to consider Nico's comment, that is,
block related stuff must work on current Squeak too. This has better
chance to work on all other Smalltalks as well.

Best regards
Janko

Alex Baran pravi:
--
Janko Mivšek
Svetovalec za informatiko
Eranova d.o.o.
Ljubljana, Slovenija
www.eranova.si
tel:  01 514 22 55
faks: 01 514 22 56
gsm: 031 674 565
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Alex,

now I've built my onClickDo:andUpdateMany:

I' ve seen it's useful in that it's much faster in the browser and in
Squeak. And the code seems less involved than my initial attempt with
a view linking to itself.

It still has a problem (at least with Squeak and FF3.08) in that
multiple ajax.Updater on the same click sometimes seem to mess things
up. This happens more often on a slow computer.

At least it shows that it's desirable for me to have something like
that. Find the code at the end of the mail, it badly needs some factoring.

AB> I'm not versed with Sport, but quick look revealed some possibility:

AB> onClickDo: aBlock andUpdate: anElementOrId
AB>        ......
AB>        fullClosure := SpEnvironment isSqueak ifTrue: [aBlock fixTemps]
AB> ifFalse: [aBlock].   "!!here!!"
AB>         self otherAt: #onClickBlock put: fullClosure.

I looked if Sport did something for blocks and missed the obvious :-/.


>> I have not yet an opinion if Comet would make it more obscure, at
>> least in the onClick.. case or if this could bring us closer to MVC
>> feeling.

AB> Well, I have bad feeling about triggering communication from Aida
AB> side. I think I should put my feeling into a words so we can see if
AB> their are wrong, but right now I am not ready to express my thoughts.

Just to make me sure, this is a feeling to not use Comet?

AB> Another possible(well, maybe) and slightly hackish solution is to have
AB> some hidden element. That element is a container for a script
AB> (represented by a WebScript in Aida).
AB> When we in need to update several components we can do:
AB>    onClickDo: [...] andUpdate: aWebScirpt   "(or maybe Aida will
AB> require to wrap a WebScrip into a WebElement)"

AB> So we can stuff WebScirpt with Ajax.Update for each component.
AB> It seems like the solution will require "components.size + 1" number
AB> of roundrips.

I will give this a try next. I've just started to read the prototype
website to find out about multiple Ajax.Updater firing at the same
time. The use of WebScript in WebElement>>scriptAfter: gives me some
hope.


Cheers,

Herbert                            mailto:[hidden email]

now the method. For me it's easier to copy paste from email than copy
pasting from VW's fileout, so I guess the reverse is true for you.

onClickDo: aBlock andUpdateMany: anElementOrIdCollection
        | idSymbolCollection url parmsCollection onClickStream|
        idSymbolCollection := anElementOrIdCollection collect:
                                        [:each |
                                        each isSymbol
                                                ifTrue: [each]
                                                ifFalse:
                                                        [each registerId.
                                                        each id]].
        url := self ajaxCallUrl.
        parmsCollection := anElementOrIdCollection
                                collect: [:each| self ajaxCallUrlParametersFor: each].
        self otherAt: #onClickBlock put: aBlock.
        self registerId.
        parmsCollection := parmsCollection collect:
                                        [:parm |
                                        parm , '&amp;blockElementId=' , self id , '&amp;blockName=onClickBlock'].
        onClickStream := WriteStream on: String new.
        1 to: parmsCollection size do:
                [:index|
                onClickStream nextPutAll: 'new Ajax.Updater('''; nextPutAll: (idSymbolCollection at: index) asString;
                                                  nextPutAll: ''', ''';  nextPutAll: url; nextPutAll: ''', {method: ''post'', postBody: ''';
                                                  nextPutAll: (parmsCollection at: index); nextPutAll:''', evalScripts: true});'].
        self
                onClick: onClickStream contents

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Herbert,

I will get into details of you posts after the weekend. But maybe some
quick points would be of interest to you.

2009/4/18 Herbert König <[hidden email]>:
Do you have two grids on a one page? If you have, you can get into a
problem. A problem is in the way Aida looks for a component during
updating. Aida makes searching by a method that creates a component
(WebElement>>method). And if you have for example 2 grids then they
have exactly the same method (WebGrid>>ajaxUpdateWith:) so the first
one win the race. This problem is unrelated to onClickDo:andUpdate:
(at least as I can grasp it now) and I think the problem will make
Aida "components future" harder. More on that stuff here
http://www.nabble.com/Subtle-bug-on-updating-WebElements-td23021717.html


At least at first glance your solution is better than WebSript
updating. And I see no need to try WebSript.
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Janko,

It's interesting to know your opinion about our discussion.

2009/4/16 Janko Mivšek <[hidden email]>:
I see your point of making it works in other Smalltalks. One of the
solution that I see, is to lay on "value" message family, so it will
allow other objects, not only blocks, to handle events.


Alex
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Alex,

just quick:

I've renamed the thread. When I said 'not ready yet' I meant my reply
was not ready yet. Now with its many messages it reads as if
master-details is not ready yet, which was not intended to say.
AB> Do you have two grids on a one page? If you have, you can get into a

It's not a grid in the sense that it is not created by WebGrid new but
it is created by several newCell sends.

AB> problem. A problem is in the way Aida looks for a component during
AB> updating. Aida makes searching by a method that creates a component
(WebElement>>>method). And if you have for example 2 grids then they
AB> have exactly the same method (WebGrid>>ajaxUpdateWith:) so the first
AB> one win the race. This problem is unrelated to onClickDo:andUpdate:
AB> (at least as I can grasp it now) and I think the problem will make
AB> Aida "components future" harder. More on that stuff here
AB> http://www.nabble.com/Subtle-bug-on-updating-WebElements-td23021717.html

I misread it as :as long as we don't send WebElement>>method: we are
fine. But the symptoms are similar. Sometimes I get two of the grids,
sometimes two of the other elements. Sometimes I get a debugger in
Squeak.

AB> At least at first glance your solution is better than WebSript
AB> updating. And I see no need to try WebSript.

Saves me some work. I read up a bit on HTML, DOM and CSS (of which I
knew nothing but the names :-)) and was just about to start on the
docs of Prototype.

So now I will follow the hints in your other mail. At least I have a
way to reproduce the bug (if we can call it so already) with about
every third click. You need two computers, I never had it when
connecting to localhost.



Cheers,

Herbert                            mailto:[hidden email]

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Alex,

just quick:

I've renamed the thread (at least in my second attempt).

When I said 'not ready yet' I meant my reply was not ready yet. Now
with its many messages it reads as if master-details is not ready yet,
which was not intended to say.

AB> Do you have two grids on a one page? If you have, you can get into a

It's not a grid in the sense that it is not created by WebGrid new but
it is created by several newCell sends.

AB> problem. A problem is in the way Aida looks for a component during
AB> updating. Aida makes searching by a method that creates a component
(WebElement>>>method). And if you have for example 2 grids then they
AB> have exactly the same method (WebGrid>>ajaxUpdateWith:) so the first
AB> one win the race. This problem is unrelated to onClickDo:andUpdate:
AB> (at least as I can grasp it now) and I think the problem will make
AB> Aida "components future" harder. More on that stuff here
AB> http://www.nabble.com/Subtle-bug-on-updating-WebElements-td23021717.html

I misread it as :as long as we don't send WebElement>>method: we are
fine. But the symptoms are similar. Sometimes I get two of the grids,
sometimes two of the other elements. Sometimes I get a debugger in
Squeak.

AB> At least at first glance your solution is better than WebSript
AB> updating. And I see no need to try WebSript.

Saves me some work. I read up a bit on HTML, DOM and CSS (of which I
knew nothing but the names :-)) and was just about to start on the
docs of Prototype.

So now I will follow the hints in your other mail. At least I have a
way to reproduce the bug (if we can call it so already) with about
every third click. You need two computers, I never had it when
connecting to localhost.



Cheers,

Herbert                            mailto:[hidden email]

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Herbert,

I have a spare moment, I will try to make some guess now, and will
delve into the subject after the weekend.

2009/4/19 Herbert König <[hidden email]>:
You can check it in 2 ways:
1. In FireBug you can select suspicious element and see if the element
ID changes as a result of an update. It can change randomly, sometimes
it stay the same and sometimes it change (I suspect that change can
appear only after WebForm>>setOfRegisteredElements rehash).
2. Try this one:   ((yourForm setOfRegisteredElements collect: [:each
| each method]) reject: [:each | each isNil]) asBag
Messages that appears two or more times can lead to surprises. Because
Aida will pick any, depending on the order of elements in the set.
It will be interesting to know contents of the Bag.
P.S. maybe method have another name instead of
"setOfRegisteredElements" I can not verify it right now, but you can
find it easily by inspecting references to "ids' instance variable in
WebForm.
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Alex,


AB> You can check it in 2 ways:
AB> 1. In FireBug you can select suspicious element and see if the element
AB> ID changes as a result of an update. It can change randomly, sometimes

In every observed case the id stays constant but one or the other
Element is displayed twice. Most remarkable case was when the big grid
was displayed twice and I triggered the update in the correct instance
of the grid. I had the 4 times and some of the grids lines doubled.

I'd say Aida got completely confused here.

To capture this I had to try your test 2. on
WebForm alsInstances select: [:each| each view == #myRelevantViewsName]

In these (43, one too much to be THE answer :) I found that the bag
(if it was not empty) always contained each selector multiple times.
Maximum I found was 145 times of my update method. Usually it had

I've zipped that image and changes for further reference.

AB> 2. Try this one:   ((yourForm setOfRegisteredElements collect: [:each
AB> | each method]) reject: [:each | each isNil]) asBag

Doing this on the current form the bag contains:
2 * #ajaxUpdateWith
2 * #displaySelectedPositionComponent
8 * #doesNotUnderstand.

disregarding the first and the last row the bag should contain:
#displaySelectedPositionComponent and
#displayPositionenComponent (the one with onClickDo:AndUpdateMany:

As expected this gave me twice the displaySelectedPositionComponent
which has no onClickDo...

What I do not understand is that on a later call the bag contained the
same items as above, just that the numbers where 10, 10 and 8 but it
worked as expected.

Any enlightenment?

AB> P.S. maybe method have another name instead of
AB> "setOfRegisteredElements"

"registeredSet" and you have to send it asOrderedCollection.
"Collect:" returns a Set which may not contain nil.

I have browsed senders of #method and tried to make sense if it. See
attached Browser of what I condensed it to. I have no idea what
WebElement>>setCreationMethod is good for.

Alright this gets bigger than I seem to be able to grok right now.
It seems like WebForm>>registerIdFor: should not rely on
WebElement>>method as it can register duplicate id's for different
elements. So regarding your original post my guts say lets use
approach one.

May I ask for some guidance in this?

Cheers,

Herbert                            mailto:[hidden email]
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Herbert,

Because here we have a mix of a lot of decisions, I will try to
isolate possible problem and give an example that reveal it.
I will provide a watchdog, which, with slight modifications, you can
try with your code to identify a cause of your troubles.

So, lets for a moment forget about onChangeDo:andUpdate: and
onClickDo:AndUpdateMany:
We could see same problems in Aida 5.6 without extensions.
So my example with 2 grids: upper and lower. Also we will use
clickable text to update lower grid. After some amount of clicking on
the text and columns header(sorting) of lower grid we can end up at
situation when we have 2 copies of lower grid (screenshot at
attachment). Just like in your case, and I can imagine other situation
when it can be more than 2 duplicates. At screenshot you can see the
problem - same "id53" appeared twice. In retrospective, lower grid had
some different id, but after some update lower grid id had changed to
upper grid id, so they got same id and this id leads to same WebGrid
in Aida.
So my example that show the bug in Aida:

viewBugHunting
        | e upper lower |
        e := WebElement new.
        upper := e add: WebGrid new.
        upper columnNames: #('Upper').
        e addBreak.
        lower := e add: self lowerGrid.
        e addBreak.
        (e addText: 'Update lower grid') onClickUpdate: lower.
        self pageFrameWith: e title: ''

lowerGrid
        | grid e |
        e := WebElement new.
        grid := e add: WebGrid new.
        grid
                columnNames: #('Lower').
        ^e

As I mentioned previously, bug is pretty elusive, so to get into Aida
internals at the time when bug appear we can use watchdog:

registerIdFor: anElement instead: anOldElement
        "new anElement should have same id as an old one"
        anOldElement isNil ifTrue: [^nil].       "Not changed"

        "!!!watchdog.
        Will trigger when Lower grid replace Upper grid"
        ((((anElement isKindOf: WebGrid) and:
                [anOldElement isKindOf: WebGrid]) and:
                        [anElement columns first name = 'Lower']) and:
                                [anOldElement columns first name = 'Upper']) ifTrue: [self halt].
....

When wrong replacement take place, debugger will popup. It seems that
sometimes watchdog bark for a case when visually everything looks
good, but I suppose it's just hidden problems that don't appear
immediately.



2009/4/20 Herbert König <[hidden email]>:
> Hi Alex,
>
>
> AB> You can check it in 2 ways:
> AB> 1. In FireBug you can select suspicious element and see if the element
> AB> ID changes as a result of an update. It can change randomly, sometimes
>
> In every observed case the id stays constant but one or the other
> Element is displayed twice.

It looks similar to case I provide above.
ajaxUpdateWith: is WebGrid method used for update a grid. So you have
two registered grids in your form. With 2 registered grids you can get
into troubles. This troubles don't appear if you do just sorting in
grids, because for sorting new grid not constructed, so there is no
need to make old-new replacement. But when you create grid as part of
WebElement hierarchy and on update recreate the hierarchy, new-old
grids replacement take place. And here Aida is better to have
improvements, it's interesting to know Janko opinion on the topic.
Because this problem pretty much restrict Aida usage IMHO.
My guess. Set grew and rehash appeared, which cause elements
reordering. After rehash, first grid in the set is the right one. All
other strange behaviour needs time to analyze, I think it's better to
get rid of the bug, because such strange things can be the bug side
effects.


And if you have (10, 10) garbage is here too. For example I will try
just to make  browser refresh my previous two-grids program. Nothing
more just refresh. Each time I will count grids registered in the
form. So what we have:

grids count = 2
grids count = 4
grids count = 6
grids count = 8

Well, this is a memory leak. The problem, as I can grasp it, lies in
registration of WebGrids, and WebElements in general. When you
register id for your grid it will never die, unless form will die. And
form seems to be long-lived by design.  WebForm use Set for
registration. Maybe some kind of Weak collection can help in the
situation, but it can have their own issues.
As I can see, the general problem is if you have Weak registration,
you need to have some references to useful components. And maybe here
we can rely on WebElements composition, but I am not sure. It would be
nice to have Janko guide on the topic.


So in that light, onChangeDo:... will have memory leaks too because we
register WebElement's which are block holders. I have plans to try to
use a Weak collection for block registration.



>
> Any enlightenment?
>
> AB> P.S. maybe method have another name instead of
> AB> "setOfRegisteredElements"
>
> "registeredSet" and you have to send it asOrderedCollection.
> "Collect:" returns a Set which may not contain nil.

Yes it's my faults of weekend mental coding :)
You are welcome!


Alex

P.S.
> 8 * #doesNotUnderstand.
doesNotUnderstand: in the case above seems like resolved problem (from
Janko post about Aida 6.0 changes). Why it's appear in 5.6 version?
Well, when you do WebElement new, Aida behind the scene makes stack
inspecting to find WebApplication and method for recreating component
later. From other hand WebApplication reimplement DNU, to forward
unknown messages to WebStyle. So, I suspect, when a WebStyle do
"WebElement new", stack inspection leads to WebApplication>>DNU.

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Alex,

I read your reply in detail and tried your example.
To get the messages shorter again:
1- You found a bug in Aida.
2- This bug defeats the purpose of Ajax updates as soon as WebGrid (and
   possible user components) are involved.
3- The problem is located in WebForm>>registerIdFor: by using
   elementForMethod: to set the id which may result in duplicate id's
   for different elements.
4- The other things this thread dealt with are likely to disappear or
   get much clearer after 1- is resolved.
5- We'd like Janko's guidance in this.

6- There's a different problem regarding memory leaks which I confirm
   and consequences of that where discussed here some time ago.

So:
Please confirm (or reject) my diagnosis in 3-
We should make a separate thread of 6- ??
Is there an Aida issue tracker?
Don't misunderstand this, all your explanations about Aida workings
are valuable to me.


Cheers,

Herbert                            mailto:[hidden email]

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi guys,

I'm full-time in preparation of the next beta, so I cannot go deep in
your problem yet. But I have one idea: what if you prepare SUnit test
cases for the problem and surrounding stuff?

We need more tests anyway and also I found helpful to myself to write
tests down when solving such difficult cases.

Best regards
Janko


Herbert König pravi: --
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

Hi Herbert,

Your summary clear depict the situation. I just want to add some
points and answer your questions.

2009/4/21 Herbert König <[hidden email]>:
> Hi Alex,
>
> I read your reply in detail and tried your example.
> To get the messages shorter again:
> 1- You found a bug in Aida.
> 2- This bug defeats the purpose of Ajax updates as soon as WebGrid (and
>   possible user components) are involved.

Yes. To be general overall mechanism of setting WebElement>>method can
leads to the bug, be it WebGrid usage or your own components.

> 3- The problem is located in WebForm>>registerIdFor: by using
>   elementForMethod: to set the id which may result in duplicate id's
>   for different elements.

Yes it's located here, but the roots lie in the idea to search
components by selectors. And the problem need to be resolved in
another place.

> 4- The other things this thread dealt with are likely to disappear or
>   get much clearer after 1- is resolved.

I hope so.

I found nothing offensive in your post, quite contrary and it makes
things very clear!


Alex
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida